From owner-linux-origin@oss.sgi.com Thu Apr 6 15:14:07 2000 Received: by oss.sgi.com id ; Thu, 6 Apr 2000 15:13:57 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8511 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 6 Apr 2000 15:13:52 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA20341 for ; Thu, 6 Apr 2000 15:09:10 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA40317; Thu, 6 Apr 2000 15:12:34 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004062212.PAA40317@google.engr.sgi.com> Subject: Tlb shutdown bit To: linux-origin@oss.sgi.com Date: Thu, 6 Apr 2000 15:12:34 -0700 (PDT) Cc: sprasad@google.engr.sgi.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing It looks like when the first processor starts executing the Linux kernel entry point (from the IO6prom), it already has the TS (tlb shutdown) bit set. I am wondering why this might happen. Note that the Linux kernel is not loaded at xkphys (0xa800....), but rather at ckseg0 (0xffffffff80...). Kanoj From owner-linux-origin@oss.sgi.com Fri Apr 7 01:16:43 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 01:16:33 -0700 Received: from sgigate.SGI.COM ([204.94.209.1]:27421 "EHLO gate-sgigate.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 01:16:08 -0700 Received: by lappi.waldorf-gmbh.de id ; Fri, 7 Apr 2000 01:15:21 -0700 Date: Fri, 7 Apr 2000 01:15:21 -0700 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com, sprasad@google.engr.sgi.com Subject: Re: Tlb shutdown bit Message-ID: <20000407011521.A860@uni-koblenz.de> References: <200004062212.PAA40317@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004062212.PAA40317@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Apr 06, 2000 at 03:12:34PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Thu, Apr 06, 2000 at 03:12:34PM -0700, Kanoj Sarcar wrote: > It looks like when the first processor starts executing the Linux > kernel entry point (from the IO6prom), it already has the TS (tlb > shutdown) bit set. I am wondering why this might happen. Note that > the Linux kernel is not loaded at xkphys (0xa800....), but rather > at ckseg0 (0xffffffff80...). Maybe I'm now talking complete bull since I don't have the manuals at hand nor can find one at this time, but anyway ... Afair the TS bit in the R10000 can never be set because on tlbwi / tlbwr the processor examines all entries for a hit at the virtual address etc. of the new entry. If so, these entries will be invalidated. Good night ... Ralf From owner-linux-origin@oss.sgi.com Fri Apr 7 09:59:26 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 09:59:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64791 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 09:58:52 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA26477; Fri, 7 Apr 2000 09:54:09 -0700 (PDT) mail_from (sprasad@sprasad.engr.sgi.com) Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA37775; Fri, 7 Apr 2000 09:58:20 -0700 (PDT) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id JAA25867; Fri, 7 Apr 2000 09:54:39 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200004071654.JAA25867@sprasad.engr.sgi.com> Subject: Re: Tlb shutdown bit To: ralf@oss.sgi.com (Ralf Baechle) Date: Fri, 7 Apr 2000 09:54:38 -0700 (PDT) Cc: kanoj@google.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com, sprasad@google.engr.sgi.com, peltier@sprasad.engr.sgi.com, mahdi@sprasad.engr.sgi.com In-Reply-To: <20000407011521.A860@uni-koblenz.de> from "Ralf Baechle" at Apr 07, 2000 01:15:21 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing According to Ralf Baechle ... > > On Thu, Apr 06, 2000 at 03:12:34PM -0700, Kanoj Sarcar wrote: > > > It looks like when the first processor starts executing the Linux > > kernel entry point (from the IO6prom), it already has the TS (tlb > > shutdown) bit set. I am wondering why this might happen. Note that > > the Linux kernel is not loaded at xkphys (0xa800....), but rather > > at ckseg0 (0xffffffff80...). > > Maybe I'm now talking complete bull since I don't have the manuals at hand > nor can find one at this time, but anyway ... Afair the TS bit in the R10000 > can never be set because on tlbwi / tlbwr the processor examines all > entries for a hit at the virtual address etc. of the new entry. If so, > these entries will be invalidated. >From the manual available online at http://www.sgi.com/processors/r10k/manual/t5.Ver.2.0.book_275.html It says that this bit is set when tlb is "presented" with an entry that is already present and may cause multiple matches. It also goes on to say those conflicting entries are invalidated before the new entry is inserted. What we dont know is whether TS is sticky. We dont know whether it gets cleared after the the r10k 'fixes' everything. I will cc some more key folks. Steve/Mahdi, This is a thread from the linux on origin project. Could you please look at it and let us know what is the right interpretation. The kernel runs in ckseg0 space and TS gets set when the kernel is invoked. The kernel is launched from a prom which runs mapped. If you think TS must never be set, the linux kernel folks need to examine which code is causing dup entries. Thanks srinivasa > > Good night ... > > Ralf > From owner-linux-origin@oss.sgi.com Fri Apr 7 12:15:47 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 12:15:27 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:47431 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 12:14:56 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA17212; Fri, 7 Apr 2000 12:10:13 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA74594; Fri, 7 Apr 2000 12:14:24 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA10515; Fri, 7 Apr 2000 12:11:46 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004071911.MAA10515@google.engr.sgi.com> Subject: Re: Tlb shutdown bit To: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Date: Fri, 7 Apr 2000 12:11:46 -0700 (PDT) Cc: ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com, sprasad@google.engr.sgi.com, peltier@sprasad.engr.sgi.com, mahdi@sprasad.engr.sgi.com In-Reply-To: <200004071654.JAA25867@sprasad.engr.sgi.com> from "Srinivasa Prasad Thirumalachar" at Apr 07, 2000 09:54:38 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > According to Ralf Baechle ... > > > > On Thu, Apr 06, 2000 at 03:12:34PM -0700, Kanoj Sarcar wrote: > > > > > It looks like when the first processor starts executing the Linux > > > kernel entry point (from the IO6prom), it already has the TS (tlb > > > shutdown) bit set. I am wondering why this might happen. Note that > > > the Linux kernel is not loaded at xkphys (0xa800....), but rather > > > at ckseg0 (0xffffffff80...). > > > > Maybe I'm now talking complete bull since I don't have the manuals at hand > > nor can find one at this time, but anyway ... Afair the TS bit in the R10000 > > can never be set because on tlbwi / tlbwr the processor examines all > > entries for a hit at the virtual address etc. of the new entry. If so, > > these entries will be invalidated. > > >From the manual available online at > > http://www.sgi.com/processors/r10k/manual/t5.Ver.2.0.book_275.html > > It says that this bit is set when tlb is "presented" with an entry > that is already present and may cause multiple matches. It also > goes on to say those conflicting entries are invalidated before the > new entry is inserted. What we dont know is whether TS is sticky. > We dont know whether it gets cleared after the the r10k 'fixes' > everything. >From the hardcopy manual: In the R10000 processor, the TS bit indicates that a tlb write has introduced an entry that would allow matching of more than one virtual page entry during translation. In this case, the TLB entries that allow the multiple matches, even in the Wired area, are invalidated before the new tlb entry is written. This prevents multiple matches during translation. The TS bit is updated for each tlb write. For now, I am clearing the TS bit on entry into the kernel, and things aren't too crazy ... except I keep on wondering what is making the TS get set, and whether it has any connection to me not being able to talk to processors on other nodes (via prom routines). Kanoj > > I will cc some more key folks. > > Steve/Mahdi, > This is a thread from the linux on origin project. Could you please > look at it and let us know what is the right interpretation. > > The kernel runs in ckseg0 space and TS gets set when the kernel > is invoked. The kernel is launched from a prom which runs mapped. > > If you think TS must never be set, the linux kernel folks need to > examine which code is causing dup entries. > > Thanks > srinivasa > > > > > > > Good night ... > > > > Ralf > > > From owner-linux-origin@oss.sgi.com Fri Apr 7 14:30:58 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 14:30:38 -0700 Received: from sgigate.SGI.COM ([204.94.209.1]:24861 "EHLO gate-sgigate.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 14:30:07 -0700 Received: by lappi.waldorf-gmbh.de id ; Fri, 7 Apr 2000 14:28:59 -0700 Date: Fri, 7 Apr 2000 14:28:59 -0700 From: Ralf Baechle To: Kanoj Sarcar Cc: Srinivasa Prasad Thirumalachar , Ralf Baechle , linux-origin@oss.sgi.com, sprasad@google.engr.sgi.com, peltier@sprasad.engr.sgi.com, mahdi@sprasad.engr.sgi.com Subject: Re: Tlb shutdown bit Message-ID: <20000407142859.C12447@uni-koblenz.de> References: <200004071654.JAA25867@sprasad.engr.sgi.com> <200004071911.MAA10515@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004071911.MAA10515@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Fri, Apr 07, 2000 at 12:11:46PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Fri, Apr 07, 2000 at 12:11:46PM -0700, Kanoj Sarcar wrote: > For now, I am clearing the TS bit on entry into the kernel, and things > aren't too crazy ... except I keep on wondering what is making the > TS get set, and whether it has any connection to me not being able > to talk to processors on other nodes (via prom routines). At what time are you trying to launch the other processors? The experience I made over the last few years is that most firware is rather fragile, so my own code for launching the CPUs launches them in the very early startup phase and leaves them waiting with interrupts disabled in a spinlock. Later on the kernel actually launches the processors by unlocking these spinlocks. This seem to have mostly solved the problems that I was observing with my own code. Ralf From owner-linux-origin@oss.sgi.com Fri Apr 7 16:18:30 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 16:18:10 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37393 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 16:17:41 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA07117; Fri, 7 Apr 2000 16:21:29 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA19330; Fri, 7 Apr 2000 16:16:23 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004072316.QAA19330@google.engr.sgi.com> Subject: Re: Tlb shutdown bit To: ralf@oss.sgi.com (Ralf Baechle) Date: Fri, 7 Apr 2000 16:16:22 -0700 (PDT) Cc: sprasad@google.engr.sgi.com (Srinivasa Prasad Thirumalachar), ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com, sprasad@oss.sgi.com, peltier@sprasad.engr.sgi.com, mahdi@sprasad.engr.sgi.com In-Reply-To: <20000407142859.C12447@uni-koblenz.de> from "Ralf Baechle" at Apr 07, 2000 02:28:59 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > On Fri, Apr 07, 2000 at 12:11:46PM -0700, Kanoj Sarcar wrote: > > > For now, I am clearing the TS bit on entry into the kernel, and things > > aren't too crazy ... except I keep on wondering what is making the > > TS get set, and whether it has any connection to me not being able > > to talk to processors on other nodes (via prom routines). > > At what time are you trying to launch the other processors? The experience Linux kernel wise, during smp_boot_cpus(). Yes, I was thinking of doing this earlier (just as a test), right after the master comes into the kernel. This is _probably_ uninteresting to the cpu folks, so we can take this offline (on linux-origin). More interestingly, the slave cpu on the same node as the master does get launched, the other slaves on the other nodes fail. Srinivas said he is going to look into prom debugging this problem (it might be a xkphys/ckseg0 issue in the prom itself). Kanoj > I made over the last few years is that most firware is rather fragile, > so my own code for launching the CPUs launches them in the very early > startup phase and leaves them waiting with interrupts disabled in a > spinlock. Later on the kernel actually launches the processors by > unlocking these spinlocks. This seem to have mostly solved the problems > that I was observing with my own code. > > Ralf > From owner-linux-origin@oss.sgi.com Fri Apr 7 17:06:50 2000 Received: by oss.sgi.com id ; Fri, 7 Apr 2000 17:06:32 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:42792 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Apr 2000 17:06:08 -0700 Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA29323; Fri, 7 Apr 2000 17:01:26 -0700 (PDT) mail_from (sprasad@sprasad.engr.sgi.com) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id RAA26468; Fri, 7 Apr 2000 17:04:15 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200004080004.RAA26468@sprasad.engr.sgi.com> Subject: Re: Tlb shutdown bit To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Fri, 7 Apr 2000 17:04:14 -0700 (PDT) Cc: ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com In-Reply-To: <200004072316.QAA19330@google.engr.sgi.com> from "Kanoj Sarcar" at Apr 07, 2000 04:16:22 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing According to Kanoj Sarcar ... > > > > > On Fri, Apr 07, 2000 at 12:11:46PM -0700, Kanoj Sarcar wrote: > > > > > For now, I am clearing the TS bit on entry into the kernel, and things > > > aren't too crazy ... except I keep on wondering what is making the > > > TS get set, and whether it has any connection to me not being able > > > to talk to processors on other nodes (via prom routines). > > > > At what time are you trying to launch the other processors? The experience > > Linux kernel wise, during smp_boot_cpus(). Yes, I was thinking of doing > this earlier (just as a test), right after the master comes into the > kernel. This is _probably_ uninteresting to the cpu folks, so we can > take this offline (on linux-origin). More interestingly, the slave cpu > on the same node as the master does get launched, the other slaves on > the other nodes fail. Srinivas said he is going to look into prom > debugging this problem (it might be a xkphys/ckseg0 issue in the > prom itself). At this point I have just been able to get my kernel to build :-( I am in the lab in front of trillium. I am trying to set some LEDs in bootstrap() and go to a infinite loop, just to see if we get to that point. POD mode debug is not possible due to slaves going into a weird state. Can someone explain this? After including a plat file like hub.h in head.S, I get these errors?? mips64-linux-gcc -D__KERNEL__ -I/build3/sprasad/snmipsmp/linux/include -D__SMP__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mabi=64 -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r8000 -mips4 -Wa,-32 -fno-strict-aliasing -c head.S -o head.o /build3/sprasad/snmipsmp/linux/include/linux/posix_types.h: Assembler messages: /build3/sprasad/snmipsmp/linux/include/linux/posix_types.h:36: Error: unrecognized opcode `typedef struct{' ^^^^^^^^^^^^^^^^^^^^^^^^^^ ?? /build3/sprasad/snmipsmp/linux/include/linux/posix_types.h:37: Error: unrecognized opcode `unsigned long fds_bits[(1024/(8*sizeof(unsigned long)))]' /build3/sprasad/snmipsmp/linux/include/linux/posix_types.h:38: Error: Rest of line ignored. First ignored character is `}'. /build3/sprasad/snmipsmp/linux/include/linux/posix_types.h:41: Error: unrecogniz In fact, I think the local slave too does not look happy led wise. If it got successfully launched the led code should change and stay steady. Now, it is still blinking like in unlaunched state. Thanks srinivasa > > Kanoj > > > I made over the last few years is that most firware is rather fragile, > > so my own code for launching the CPUs launches them in the very early > > startup phase and leaves them waiting with interrupts disabled in a > > spinlock. Later on the kernel actually launches the processors by > > unlocking these spinlocks. This seem to have mostly solved the problems > > that I was observing with my own code. > > > > Ralf > > > From owner-linux-origin@oss.sgi.com Mon Apr 10 18:33:39 2000 Received: by oss.sgi.com id ; Mon, 10 Apr 2000 18:33:30 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:34355 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 10 Apr 2000 18:33:16 -0700 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 SAA00601 for ; Mon, 10 Apr 2000 18:37:08 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id SAA69675 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Mon, 10 Apr 2000 18:32:58 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id SAA12507 for linux-origin@oss.sgi.com; Mon, 10 Apr 2000 18:32:42 -0700 From: "Leo Dagum" Message-Id: <10004101832.ZM12505@barrel.engr.sgi.com> Date: Mon, 10 Apr 2000 18:32:42 -0700 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-origin@oss.sgi.com Subject: annie going away Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing annie will be going away soon, that system was always destined for Richard Gooch, and now that he's back from his travels abroad we need to ship it to him for further devfs development. I'd like to box it up Wed, so you have Tues to get whatever you need off it. The main thing I assume is the nfs roots. Ulf, can you move those over to rainy? Is there enough disk space? If not let me know and I'll see about scrounging some more disks for that system. I think we may also have some other pc servers around that aren't hooked up so we can replace the lost cycles as well. I'll check into that. Please let me know if you need more time to move your stuff off. Thanks, - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Mon Apr 10 18:56:38 2000 Received: by oss.sgi.com id ; Mon, 10 Apr 2000 18:56:29 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44393 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 10 Apr 2000 18:56:12 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA25600 for ; Mon, 10 Apr 2000 18:51:28 -0700 (PDT) mail_from (ulfc@sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA53064 for ; Mon, 10 Apr 2000 18:55:41 -0700 (PDT) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA77423; Mon, 10 Apr 2000 18:54:01 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id C2D2BA7904; Mon, 10 Apr 2000 17:50:37 -0700 (PDT) Date: Mon, 10 Apr 2000 17:50:37 -0700 (PDT) From: Ulf Carlsson To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: annie going away In-Reply-To: <10004101832.ZM12505@barrel.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > I'd like to box it up Wed, so you have Tues to get whatever you need > off it. The main thing I assume is the nfs roots. Ulf, can you move > those over to rainy? Is there enough disk space? If not let me know > and I'll see about scrounging some more disks for that system. I > think we may also have some other pc servers around that aren't > hooked up so we can replace the lost cycles as well. I'll check > into that. We have been doing some glibc/binutils development on annie, but we'll move somewhere else. No problem. I think there should be enough space. Maybe it would be possible to repartition the drives on rainy a bit? Ulf From owner-linux-origin@oss.sgi.com Tue Apr 11 11:11:34 2000 Received: by oss.sgi.com id ; Tue, 11 Apr 2000 11:11:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50953 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Apr 2000 11:11:02 -0700 Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA09427 for ; Tue, 11 Apr 2000 11:06:19 -0700 (PDT) mail_from (sprasad@sprasad.engr.sgi.com) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id LAA35289 for linux-origin@oss.sgi.com; Tue, 11 Apr 2000 11:09:28 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200004111809.LAA35289@sprasad.engr.sgi.com> Subject: TS bit explanation To: linux-origin@oss.sgi.com Date: Tue, 11 Apr 2000 11:09:28 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Hi, The final word on TS .... > It says that this bit is set when tlb is "presented" with an entry > that is already present and may cause multiple matches. It also > goes on to say those conflicting entries are invalidated before the > new entry is inserted. What we dont know is whether TS is sticky. > We dont know whether it gets cleared after the the r10k 'fixes' > everything. In case you still have this TS question.... The R10K "fixes" the other matching entries during the same write operation which caused them. Afterwards the TS bit stays set. If you later do another TLB write which doesn't match any other entry, the TS bit will be cleared. Thanks srinivasa From owner-linux-origin@oss.sgi.com Tue Apr 11 11:20:15 2000 Received: by oss.sgi.com id ; Tue, 11 Apr 2000 11:20:05 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4620 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Apr 2000 11:19:58 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA10645 for ; Tue, 11 Apr 2000 11:15:15 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA75472; Tue, 11 Apr 2000 11:18:34 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004111818.LAA75472@google.engr.sgi.com> Subject: Re: TS bit explanation To: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Date: Tue, 11 Apr 2000 11:18:34 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200004111809.LAA35289@sprasad.engr.sgi.com> from "Srinivasa Prasad Thirumalachar" at Apr 11, 2000 11:09:28 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > Hi, > The final word on TS .... > > > It says that this bit is set when tlb is "presented" with an entry > > that is already present and may cause multiple matches. It also > > goes on to say those conflicting entries are invalidated before the > > new entry is inserted. What we dont know is whether TS is sticky. > > We dont know whether it gets cleared after the the r10k 'fixes' > > everything. > > In case you still have this TS question.... > The R10K "fixes" the other matching entries during the same write operation > which caused them. Afterwards the TS bit stays set. That was my understanding from the above statement taken out of the manual. Lets your page fault handler be sloppy, ie not need to do a tlbp, then a tlb dropin, when you are updating the tlb entry. Or may be high performance, since you can avoid doing tlbp. So, I don't have any questions on the TS getting set on entry into the kernel, if you are saying that the PROM fault handlers are getting it set. > If you later do another TLB write which doesn't match any other entry, the TS > bit will be cleared. This is new to me. One wonders why the hardware guys exposed the bit at all, since other than detecting a sloppy fault handler, I can't see any reason for software using it. Kanoj > > Thanks > srinivasa > From owner-linux-origin@oss.sgi.com Tue Apr 11 11:47:45 2000 Received: by oss.sgi.com id ; Tue, 11 Apr 2000 11:47:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:40980 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Apr 2000 11:47:30 -0700 Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA14676 for ; Tue, 11 Apr 2000 11:42:47 -0700 (PDT) mail_from (sprasad@sprasad.engr.sgi.com) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id LAA20811; Tue, 11 Apr 2000 11:45:52 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200004111845.LAA20811@sprasad.engr.sgi.com> Subject: Re: TS bit explanation To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Tue, 11 Apr 2000 11:45:51 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200004111818.LAA75472@google.engr.sgi.com> from "Kanoj Sarcar" at Apr 11, 2000 11:18:34 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing According to Kanoj Sarcar ... > > > > > Hi, > > The final word on TS .... > > > > > It says that this bit is set when tlb is "presented" with an entry > > > that is already present and may cause multiple matches. It also > > > goes on to say those conflicting entries are invalidated before the > > > new entry is inserted. What we dont know is whether TS is sticky. > > > We dont know whether it gets cleared after the the r10k 'fixes' > > > everything. > > > > In case you still have this TS question.... > > The R10K "fixes" the other matching entries during the same write operation > > which caused them. Afterwards the TS bit stays set. > > That was my understanding from the above statement taken out of the manual. > Lets your page fault handler be sloppy, ie not need to do a tlbp, then a > tlb dropin, when you are updating the tlb entry. Or may be high performance, > since you can avoid doing tlbp. > > So, I don't have any questions on the TS getting set on entry into the > kernel, if you are saying that the PROM fault handlers are getting it set. There is no fault handler in the PROM. The PROM drops in a few tlb entries for the mapped prom. I dont know if TS is set on entry from the PROM. > > > If you later do another TLB write which doesn't match any other entry, the TS > > bit will be cleared. > > This is new to me. One wonders why the hardware guys exposed the bit at all, You mean news? This is typical of MIPS hardware. They do something only when it is necessary. This is a debug tool or a status indicator and can be used to fix sloppy fault handlers. The hw still does what one would 'expect' it to do in addition to showing status. Srinivasa > since other than detecting a sloppy fault handler, I can't see any reason > for software using it. > > Kanoj > > > > > Thanks > > srinivasa > > > From owner-linux-origin@oss.sgi.com Wed Apr 12 14:49:28 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 14:49:18 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49275 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 14:49:06 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08659 for ; Wed, 12 Apr 2000 14:53:00 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA57478 for linux-origin@oss.sgi.com; Wed, 12 Apr 2000 14:47:48 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004122147.OAA57478@google.engr.sgi.com> Subject: irq level mapping To: linux-origin@oss.sgi.com Date: Wed, 12 Apr 2000 14:47:48 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I just changed arch/mips64/sgi-ip27/ip27-irq.c to say #define IRQ_TO_SWLEVEL(i) i + 10 #define SWLEVEL_TO_IRQ(s) s - 10 from #define IRQ_TO_SWLEVEL(i) i + 7 #define SWLEVEL_TO_IRQ(s) s - 7 This _might_ break certain things, so if you do identify this as causing a problem, feel free to revert this change. I tested kernel boots, it seems to be working ... On a different note, how do the different drivers determine their irqs and call request_irq() for their own irqs? Kanoj From owner-linux-origin@oss.sgi.com Wed Apr 12 14:56:28 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 14:56:18 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23116 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 14:56:14 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA14406 for ; Wed, 12 Apr 2000 14:51:31 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA69165; Wed, 12 Apr 2000 14:54:56 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004122154.OAA69165@google.engr.sgi.com> Subject: Re: irq level mapping To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Wed, 12 Apr 2000 14:54:56 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200004122147.OAA57478@google.engr.sgi.com> from "Kanoj Sarcar" at Apr 12, 2000 02:47:48 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > I just changed arch/mips64/sgi-ip27/ip27-irq.c to say > > #define IRQ_TO_SWLEVEL(i) i + 10 > #define SWLEVEL_TO_IRQ(s) s - 10 > > > from > > #define IRQ_TO_SWLEVEL(i) i + 7 > #define SWLEVEL_TO_IRQ(s) s - 7 > > This _might_ break certain things, so if you do identify this as causing > a problem, feel free to revert this change. I tested kernel boots, it > seems to be working ... > > On a different note, how do the different drivers determine their > irqs and call request_irq() for their own irqs? > > Kanoj > Never mind, I reverted it back myself, it does not seem to be changing anything ... Kanoj From owner-linux-origin@oss.sgi.com Wed Apr 12 15:34:29 2000 Received: by oss.sgi.com id ; Wed, 12 Apr 2000 15:34:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:65365 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 12 Apr 2000 15:33:57 -0700 Received: from ledzep.cray.com (ledzep.cray.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA19284 for ; Wed, 12 Apr 2000 15:29:13 -0700 (PDT) mail_from (cngam@sgi.com) Received: from tulip-e185.americas.sgi.com (tulip.cray.com [128.162.185.208]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id RAA26215; Wed, 12 Apr 2000 17:32:39 -0500 (CDT) Received: from cray.com (cngam-h2.americas.sgi.com [206.11.104.19]) by tulip-e185.americas.sgi.com (8.8.8/SGI-server-1.4) with ESMTP id RAA3706009; Wed, 12 Apr 2000 17:32:39 -0500 (CDT) Message-ID: <38F4F986.FD9936F@cray.com> Date: Wed, 12 Apr 2000 17:32:38 -0500 From: Colin Ngam Organization: Cray Research, A Division Of SGI X-Mailer: Mozilla 4.05C-SGI [en] (X11; I; IRIX 6.5 IP32) MIME-Version: 1.0 To: Kanoj Sarcar CC: linux-origin@oss.sgi.com Subject: Re: irq level mapping References: <200004122147.OAA57478@google.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Kanoj Sarcar wrote: > I just changed arch/mips64/sgi-ip27/ip27-irq.c to say > > #define IRQ_TO_SWLEVEL(i) i + 10 > #define SWLEVEL_TO_IRQ(s) s - 10 > > from > > #define IRQ_TO_SWLEVEL(i) i + 7 > #define SWLEVEL_TO_IRQ(s) s - 7 > > This _might_ break certain things, so if you do identify this as causing > a problem, feel free to revert this change. I tested kernel boots, it > seems to be working ... > > On a different note, how do the different drivers determine their > irqs and call request_irq() for their own irqs? Kanoj, In some cases, I have noticed that the IRQ for the PCI slot is determined by the platform dependent(arch) layer druing PCI probe and written out into the PCI Config Area. Then when the driver does it's init, it reads this back out and call request_irq() with this number. For snia64, this is exactly what we are going to do. During out initial probe we will determine the IRQ for each slot/function, write it out and the driver later can use it to register. Thanks. Colin > > > Kanoj From owner-linux-origin@oss.sgi.com Thu Apr 13 15:27:34 2000 Received: by oss.sgi.com id ; Thu, 13 Apr 2000 15:27:15 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:22876 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 13 Apr 2000 15:26:50 -0700 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA25942 for ; Thu, 13 Apr 2000 15:22:07 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA60517 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 13 Apr 2000 15:26:32 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA16325; Thu, 13 Apr 2000 15:26:02 -0700 Date: Thu, 13 Apr 2000 15:26:02 -0700 From: dagum@barrel.engr.sgi.com (Leo Dagum) Message-Id: <200004132226.PAA16325@barrel.engr.sgi.com> To: linux-origin@oss.sgi.com, server1-plat@barrel.engr.sgi.com Subject: annie is back Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing annie is back as a 2x350mhz dell running rh6.2. root passwd= linux1 - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Fri Apr 21 13:11:02 2000 Received: by oss.sgi.com id ; Fri, 21 Apr 2000 13:10:52 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:31268 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 21 Apr 2000 13:10:31 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA07611 for ; Fri, 21 Apr 2000 13:14:35 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA68505 for linux-origin@oss.sgi.com; Fri, 21 Apr 2000 13:09:13 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004212009.NAA68505@google.engr.sgi.com> Subject: bootp handling broken To: linux-origin@oss.sgi.com Date: Fri, 21 Apr 2000 13:09:13 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing The latest kernel does not do a nfsroot boot, with a UP compile. If anyone has time to debug this, please let me know if you will be looking into it soon. Kanoj ttyS00 at 0x0000 (irq = 0) is a 16550A ttyS01 at 0x0000 (irq = 0) is a 16550A Sending BOOTP requests....... OK IP-Config: Got BOOTP answer from 163.154.18.85, my address is 163.154.18.57 kmem_create: Forcing size word alignment - nfs_fh Looking up port of RPC 100003/2 on 163.154.18.85 Looking up port of RPC 100005/2 on 163.154.18.85 bad magic 0 (should be 1e00000000000060), wq bug, forcing oops. bad magic 1 (should be 1e00000000000060), wq bug, forcing oops. bad magic 1 (should be 1e00000000000060), wq bug, forcing oops. From owner-linux-origin@oss.sgi.com Tue Apr 25 11:18:42 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 11:18:32 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49431 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 11:17:58 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07121; Tue, 25 Apr 2000 11:22:06 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA60449; Tue, 25 Apr 2000 11:16:39 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004251816.LAA60449@google.engr.sgi.com> Subject: compiler bug? To: ralf@oss.sgi.com, ulfc@google.engr.sgi.com Date: Tue, 25 Apr 2000 11:16:39 -0700 (PDT) Cc: linux-origin@oss.sgi.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I think I have hit another compiler bug. To demonstrate, check out a top of trunk source tree. Then try to compile the kernel in UP mode. The compilation fails like this: mips64-linux-gcc -D__KERNEL__ -I/build2/kanoj/mips64/linux.work2/include -Wall -Wst rict-prototypes -O2 -fomit-frame-pointer -mabi=64 -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r8000 -mips4 -Wa,-32 -fno-strict-aliasing -c r4k_genex.S -o r4k_genex.o r4k_genex.S: Assembler messages: r4k_genex.S:168: Warning: Missing .end or .bend at end of file mips64-linux-gcc: Internal compiler error: program as got fatal signal 11 make[1]: *** [r4k_genex.o] Error 1 make[1]: Leaving directory `/build2/kanoj/mips64/linux.work2/arch/mips64/kernel' make: *** [_dir_arch/mips64/kernel] Error 2 To fix this, you need to delete at least one instruction from the include/asm-mips64/stackframe.h file under the CONFIG_SMP code block. Ie, deleting at least one instruction from the code block mfc0 k1, CP0_WATCHHI mfc0 k0, CP0_WATCHLO dsll32 k1, k1, 0 or k1, k1, k0 li k0, K0BASE or k1, k1, k0 daddiu k1, k1, KERNEL_STACK_SIZE-32 will cure the problem. If any of you guys have a chance to track down what's going on, let me know. Otherwise, just aply this workaround while compiling an UP kernel. Kanoj From owner-linux-origin@oss.sgi.com Tue Apr 25 13:05:53 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 13:05:43 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:7972 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 13:05:35 -0700 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 NAA02367; Tue, 25 Apr 2000 13:09:43 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA96542; Tue, 25 Apr 2000 13:05:16 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 78923A7875; Tue, 25 Apr 2000 13:04:39 -0700 (PDT) Date: Tue, 25 Apr 2000 13:04:39 -0700 (PDT) From: Ulf Carlsson To: Kanoj Sarcar Cc: Ralf Baechle , linux-origin@oss.sgi.com Subject: Re: compiler bug? In-Reply-To: <200004251816.LAA60449@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > If any of you guys have a chance to track down what's going on, let me > know. Otherwise, just aply this workaround while compiling an UP kernel. I will look at it today. Ulf From owner-linux-origin@oss.sgi.com Tue Apr 25 18:32:57 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 18:32:38 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:62036 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 18:32:09 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA12541; Tue, 25 Apr 2000 18:27:22 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA44845; Tue, 25 Apr 2000 17:17:12 -0700 (PDT) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA70870; Tue, 25 Apr 2000 17:15:35 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 70257A7875; Tue, 25 Apr 2000 17:14:58 -0700 (PDT) Date: Tue, 25 Apr 2000 17:14:58 -0700 (PDT) From: Ulf Carlsson To: Kanoj Sarcar Cc: ralf@oss.sgi.com, ulfc@google.engr.sgi.com, linux-origin@oss.sgi.com Subject: Re: compiler bug? In-Reply-To: <200004251816.LAA60449@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > If any of you guys have a chance to track down what's going on, let me > know. Otherwise, just aply this workaround while compiling an UP kernel. Hm.. this is actually the code that makes it crash: .macro COMMENT # 1 "comment" .endm .ent foo, 0 COMMENT nop .end foo .ent bar, 0 COMMENT nop .end bar The preprocessor adds a source line comment when it finds the ifdef you've added. The same source line comment is being used several times when you use the macros. This nukes the assembler. It's the same for both the current CVS and the version we're using for the kernel compiles. I'll see what I can do. Ulf From owner-linux-origin@oss.sgi.com Tue Apr 25 22:38:09 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 22:37:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40775 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 22:37:26 -0700 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 WAA08964 for ; Tue, 25 Apr 2000 22:41:34 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id WAA01635 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Tue, 25 Apr 2000 22:37:07 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id WAA09693 for linux-origin@oss.sgi.com; Tue, 25 Apr 2000 22:36:35 -0700 Date: Tue, 25 Apr 2000 22:36:35 -0700 From: dagum@barrel.engr.sgi.com (Leo Dagum) Message-Id: <200004260536.WAA09693@barrel.engr.sgi.com> To: linux-origin@oss.sgi.com Subject: bootp working again Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Did anyone do anything to get bootp to rainy working again? Or was it just a side effect of NOC fixing something else in the network. Sending BOOTP requests....... OK IP-Config: Got BOOTP answer from 163.154.10.28, my address is 163.154.10.17 - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Tue Apr 25 22:47:19 2000 Received: by oss.sgi.com id ; Tue, 25 Apr 2000 22:47:09 -0700 Received: from sgigate.SGI.COM ([204.94.209.1]:36144 "EHLO gate-sgigate.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 25 Apr 2000 22:46:46 -0700 Received: by lappi.waldorf-gmbh.de id ; Tue, 25 Apr 2000 22:42:23 -0700 Date: Tue, 25 Apr 2000 22:42:23 -0700 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: bootp working again Message-ID: <20000425224223.F3093@uni-koblenz.de> References: <200004260536.WAA09693@barrel.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004260536.WAA09693@barrel.engr.sgi.com>; from dagum@barrel.engr.sgi.com on Tue, Apr 25, 2000 at 10:36:35PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Apr 25, 2000 at 10:36:35PM -0700, Leo Dagum wrote: > Did anyone do anything to get bootp to rainy working again? > Or was it just a side effect of NOC fixing something > else in the network. > > Sending BOOTP requests....... OK > IP-Config: Got BOOTP answer from 163.154.10.28, my address is 163.154.10.17 Strange, I had a bootp bug report just like yours from somebody outside of SGI for a non-SGI system. Don't ask, just accept that it's working right now :-) Ralf From owner-linux-origin@oss.sgi.com Wed Apr 26 00:09:39 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 00:09:29 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:843 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 00:09:06 -0700 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 AAA06605 for ; Wed, 26 Apr 2000 00:13:14 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA28156; Wed, 26 Apr 2000 00:08:42 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 24FEEA7875; Wed, 26 Apr 2000 00:08:04 -0700 (PDT) Date: Wed, 26 Apr 2000 00:08:04 -0700 (PDT) From: Ulf Carlsson To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: bootp working again In-Reply-To: <200004260536.WAA09693@barrel.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, 25 Apr 2000, Leo Dagum wrote: > Did anyone do anything to get bootp to rainy working again? > Or was it just a side effect of NOC fixing something > else in the network. > > Sending BOOTP requests....... OK > IP-Config: Got BOOTP answer from 163.154.10.28, my address is 163.154.10.17 I installed the bootp RPM package :-) Ulf From owner-linux-origin@oss.sgi.com Wed Apr 26 08:10:36 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 08:10:26 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4709 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 08:10:03 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA02214 for ; Wed, 26 Apr 2000 08:14:11 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA79987; Wed, 26 Apr 2000 08:08:43 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004261508.IAA79987@google.engr.sgi.com> Subject: compilers ... again To: ulfc@google.engr.sgi.com, linux-origin@oss.sgi.com Date: Wed, 26 Apr 2000 08:08:43 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Okay, Ulf seems to have isolated a test case for the previous preprocessor bug. As I mentioned, there is a workaround for the bug, but Ulf, did you play with restructuring the code to see whether we can workaround the problem? Here's another more serious problem: create a UP kernel, then disassemble handle_sys. Identify the code that corresponds to the STI. You will see the generated code is using registers t4 and t5, instead of t0 and t1 as in the definition of STI in asm/stackframe.h. I can't say this is causing any problems, but it is surely disturbing me ... Kanoj From owner-linux-origin@oss.sgi.com Wed Apr 26 14:18:39 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 14:18:29 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:35600 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 14:18:09 -0700 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 OAA01342 for ; Wed, 26 Apr 2000 14:22:18 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA50796; Wed, 26 Apr 2000 14:17:50 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 522EEA7875; Wed, 26 Apr 2000 14:17:10 -0700 (PDT) Date: Wed, 26 Apr 2000 14:17:10 -0700 (PDT) From: Ulf Carlsson To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: compilers ... again In-Reply-To: <200004261508.IAA79987@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, 26 Apr 2000, Kanoj Sarcar wrote: > Okay, Ulf seems to have isolated a test case for the previous preprocessor > bug. As I mentioned, there is a workaround for the bug, but Ulf, did you > play with restructuring the code to see whether we can workaround the > problem? We could pass the -P option to gcc to prevent cpp from generating those comments, I don't know that we need the comments for any reason. We could apply something like.. --- Makefile.orig Wed Apr 26 14:12:36 2000 +++ Makefile Wed Apr 26 14:12:24 2000 @@ -36,7 +36,7 @@ # machines may also. Since BFD is incredibly buggy with respect to # crossformat linking we rely on the elf2ecoff tool for format conversion. # -CFLAGS += -G 0 -mno-abicalls -fno-pic +CFLAGS += -P -G 0 -mno-abicalls -fno-pic LINKFLAGS += -static -G 0 MODFLAGS += -mlong-calls .. to the makefile if that's ok. Ulf From owner-linux-origin@oss.sgi.com Wed Apr 26 14:35:09 2000 Received: by oss.sgi.com id ; Wed, 26 Apr 2000 14:34:49 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58897 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 26 Apr 2000 14:34:23 -0700 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 OAA07139 for ; Wed, 26 Apr 2000 14:38:32 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA52529; Wed, 26 Apr 2000 14:34:04 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 9D246A7875; Wed, 26 Apr 2000 14:33:24 -0700 (PDT) Date: Wed, 26 Apr 2000 14:33:24 -0700 (PDT) From: Ulf Carlsson To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: compilers ... again In-Reply-To: <200004261508.IAA79987@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > Here's another more serious problem: create a UP kernel, then disassemble > handle_sys. Identify the code that corresponds to the STI. You will see > the generated code is using registers t4 and t5, instead of t0 and t1 > as in the definition of STI in asm/stackframe.h. I can't say this is > causing any problems, but it is surely disturbing me ... This is not really a problem. In a 32-bit kernel we are using the register definition that's from System V Application Binary Interface, but in the 64-bit kernel we're using another register definition. I don't know where the latter one is specified, but you can find it documented in for example the MIPSpro Assembly Language Programmer's Guide. As you've already noticed objdump is using the first one.. Ulf From owner-linux-origin@oss.sgi.com Thu Apr 27 05:20:39 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 05:20:29 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:29495 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 05:20:22 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA01294 for ; Thu, 27 Apr 2000 05:15:36 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id FAA34701 for ; Thu, 27 Apr 2000 05:19:51 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id FAA24706 for linux-origin@oss.sgi.com; Thu, 27 Apr 2000 05:17:17 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004271217.FAA24706@google.engr.sgi.com> Subject: IP35 support To: linux-origin@oss.sgi.com Date: Thu, 27 Apr 2000 05:17:17 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing What is the story on the SN1/IP35 support in the oss tree? I saw some checkins go in for that, then a set of reverse checkins to pull that out. Anyway, there is still a lot of IP35 hooks lying around in source files (and makefiles). > gid CONFIG_SGI_IP35 include/asm-mips64/sn/addrs.h:24:#elif defined(CONFIG_SGI_IP35) include/asm-mips64/sn/agent.h:21:#elif defined(CONFIG_SGI_IP35) include/asm-mips64/sn/agent.h:23:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ include/asm-mips64/sn/klconfig.h:54:#elif defined(CONFIG_SGI_IP35) include/asm-mips64/sn/klconfig.h:65:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ include/asm-mips64/sn/kldir.h:239:#elif defined(CONFIG_SGI_IP35) If we are not planning to do the IP35 work right now, maybe we should just pull all these out too? Kanoj From owner-linux-origin@oss.sgi.com Thu Apr 27 09:12:21 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 09:12:11 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42830 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 09:11:56 -0700 Received: from sprasad.engr.sgi.com (sprasad.engr.sgi.com [163.154.5.109]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA09317 for ; Thu, 27 Apr 2000 09:16:06 -0700 (PDT) mail_from (sprasad@sprasad.engr.sgi.com) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id JAA67626; Thu, 27 Apr 2000 09:10:11 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200004271610.JAA67626@sprasad.engr.sgi.com> Subject: Re: IP35 support To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Thu, 27 Apr 2000 09:10:11 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200004271217.FAA24706@google.engr.sgi.com> from "Kanoj Sarcar" at Apr 27, 2000 05:17:17 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing According to Kanoj Sarcar ... > > What is the story on the SN1/IP35 support in the oss tree? I saw some > checkins go in for that, then a set of reverse checkins to pull that out. There were some legal issues to be resolved before the bedrock (IP35) features were made public. Like the SN1 MIPS product should be released first etc. At this point, if it is possible it should be removed from oss. > > Anyway, there is still a lot of IP35 hooks lying around in source files > (and makefiles). > > > gid CONFIG_SGI_IP35 > include/asm-mips64/sn/addrs.h:24:#elif defined(CONFIG_SGI_IP35) > include/asm-mips64/sn/agent.h:21:#elif defined(CONFIG_SGI_IP35) > include/asm-mips64/sn/agent.h:23:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ > include/asm-mips64/sn/klconfig.h:54:#elif defined(CONFIG_SGI_IP35) > include/asm-mips64/sn/klconfig.h:65:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ > include/asm-mips64/sn/kldir.h:239:#elif defined(CONFIG_SGI_IP35) > > If we are not planning to do the IP35 work right now, maybe we should > just pull all these out too? Work can proceed internally in a ptools tree, but they should not go out on OSS. Thanks srinivasa > > Kanoj > From owner-linux-origin@oss.sgi.com Thu Apr 27 09:34:10 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 09:34:02 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61776 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 09:33:36 -0700 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 JAA08452 for ; Thu, 27 Apr 2000 09:37:45 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: from barrel.engr.sgi.com (barrel.engr.sgi.com [163.154.5.63]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id JAA39331 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 27 Apr 2000 09:33:16 -0700 (PDT) mail_from (dagum@barrel.engr.sgi.com) Received: (from dagum@localhost) by barrel.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id JAA01419; Thu, 27 Apr 2000 09:32:24 -0700 From: "Leo Dagum" Message-Id: <10004270932.ZM1417@barrel.engr.sgi.com> Date: Thu, 27 Apr 2000 09:32:24 -0700 In-Reply-To: sprasad@sprasad (Srinivasa Prasad Thirumalachar) "Re: IP35 support" (Apr 27, 9:10am) References: <200004271610.JAA67626@sprasad.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar), kanoj@google.engr.sgi.com (Kanoj Sarcar) Subject: Re: IP35 support Cc: linux-origin@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Apr 27, 9:10am, Srinivasa Prasad Thirumalachar wrote: > Subject: Re: IP35 support > According to Kanoj Sarcar ... > > > > What is the story on the SN1/IP35 support in the oss tree? I saw some > > checkins go in for that, then a set of reverse checkins to pull that out. > > There were some legal issues to be resolved before the bedrock (IP35) > features were made public. Like the SN1 MIPS product should be released > first etc. > I understood Rich's latest email on the subject as saying it was ok to check in whatever sn1 code we needed into oss: From: Rich Altmaier I don't feel that exposing SN chipset programming information is a problem. I don't think we should make public the chip programming manual, but header files and code is not a problem. If we were prepared to release code today for SN, this would be fine. - leo > At this point, if it is possible it should be removed from oss. > > > > > Anyway, there is still a lot of IP35 hooks lying around in source files > > (and makefiles). > > > > > gid CONFIG_SGI_IP35 > > include/asm-mips64/sn/addrs.h:24:#elif defined(CONFIG_SGI_IP35) > > include/asm-mips64/sn/agent.h:21:#elif defined(CONFIG_SGI_IP35) > > include/asm-mips64/sn/agent.h:23:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ > > include/asm-mips64/sn/klconfig.h:54:#elif defined(CONFIG_SGI_IP35) > > include/asm-mips64/sn/klconfig.h:65:#endif /* !CONFIG_SGI_IP27 && !CONFIG_SGI_IP35 */ > > include/asm-mips64/sn/kldir.h:239:#elif defined(CONFIG_SGI_IP35) > > > > If we are not planning to do the IP35 work right now, maybe we should > > just pull all these out too? > > Work can proceed internally in a ptools tree, but they should not > go out on OSS. > > > Thanks > srinivasa > > > > > Kanoj > > >-- End of excerpt from Srinivasa Prasad Thirumalachar -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Thu Apr 27 14:06:44 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 14:06:24 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:9538 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 14:06:20 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA02790 for ; Thu, 27 Apr 2000 14:01:33 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA28528 for linux-origin@oss.sgi.com; Thu, 27 Apr 2000 14:05:01 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200004272105.OAA28528@google.engr.sgi.com> Subject: SMP kernel To: linux-origin@oss.sgi.com Date: Thu, 27 Apr 2000 14:05:01 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing As of today, the top of trunk code will let you compile a SMP kernel that will try to activate all the cpus to do work. I have just tested single user boot on a 2 cpu o200. Both cpus picks up tasks from the runq and execute them (no, you still do not see 2 cpus reported from /proc/cpuinfo, the /proc code needs to be developed). A 32 cpu o2000 refuses to even boot single user. I will try to see what's up with that, if I get some time while looking at multiuser boot and seeing why the network has stopped working. Kanoj From owner-linux-origin@oss.sgi.com Thu Apr 27 18:38:06 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 18:37:56 -0700 Received: from sgigate.SGI.COM ([204.94.209.1]:14418 "EHLO gate-sgigate.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 18:37:37 -0700 Received: by lappi.waldorf-gmbh.de id ; Wed, 26 Apr 2000 14:40:56 -0700 Date: Wed, 26 Apr 2000 14:40:56 -0700 From: Ralf Baechle To: Ulf Carlsson Cc: Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: compilers ... again Message-ID: <20000426144056.A3146@uni-koblenz.de> References: <200004261508.IAA79987@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from ulfc@calypso.engr.sgi.com on Wed, Apr 26, 2000 at 02:33:24PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Apr 26, 2000 at 02:33:24PM -0700, Ulf Carlsson wrote: > > Here's another more serious problem: create a UP kernel, then disassemble > > handle_sys. Identify the code that corresponds to the STI. You will see > > the generated code is using registers t4 and t5, instead of t0 and t1 > > as in the definition of STI in asm/stackframe.h. I can't say this is > > causing any problems, but it is surely disturbing me ... > > This is not really a problem. In a 32-bit kernel we are using the register > definition that's from System V Application Binary Interface, but in the > 64-bit kernel we're using another register definition. I don't know where the > latter one is specified, but you can find it documented in for example the > MIPSpro Assembly Language Programmer's Guide. It's defined in the n32 / 64-bit psABI. > As you've already noticed objdump is using the first one.. I've been confused by this buglet before. SGI's tools set some flag in the ELF header indicating the ABI flavour the code was compiled for. If we'd have the same thing objdump could select the register names for the disassembler based on those flags. Ralf From owner-linux-origin@oss.sgi.com Thu Apr 27 18:38:25 2000 Received: by oss.sgi.com id ; Thu, 27 Apr 2000 18:38:06 -0700 Received: from sgigate.SGI.COM ([204.94.209.1]:14418 "EHLO gate-sgigate.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 27 Apr 2000 18:37:38 -0700 Received: by lappi.waldorf-gmbh.de id ; Thu, 27 Apr 2000 15:36:25 -0700 Date: Thu, 27 Apr 2000 15:36:25 -0700 From: Ralf Baechle To: Kanoj Sarcar Cc: ulfc@google.engr.sgi.com, linux-origin@oss.sgi.com Subject: Re: network problems Message-ID: <20000427153625.D894@uni-koblenz.de> References: <200004272144.OAA21780@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004272144.OAA21780@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Apr 27, 2000 at 02:44:42PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Thu, Apr 27, 2000 at 02:44:42PM -0700, Kanoj Sarcar wrote: > Okay, here's the problem I am running into with top of trunk, UP kernel, > trying to do a nfsroot boot, with > > CONFIG_ROOT_NFS=y > CONFIG_IP_PNP=y > CONFIG_IP_PNP_BOOTP=y > > Sending BOOTP requests....... OK > IP-Config: Got BOOTP answer from 163.154.10.28, my address is 163.154.10.23 > kmem_create: Forcing size word alignment - nfs_fh > Looking up port of RPC 100003/2 on 163.154.10.28 > Looking up port of RPC 100005/2 on 163.154.10.28 > bad magic 0 (should be 1e00010000000060), wq bug, forcing oops. > bad magic 1 (should be 1e00010000000060), I'm merging with 2.3.99-pre6. I suggest that we postpone debugging this problem until we've tested that this problem which most probably was inherited via Linus' -pre5 patch gets fixed by pre6. Ralf