From owner-linux-origin@oss.sgi.com Sun Jul 2 02:16:23 2000 Received: by oss.sgi.com id ; Sun, 2 Jul 2000 02:16:14 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:12910 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sun, 2 Jul 2000 02:15:52 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA02924 for ; Sun, 2 Jul 2000 02:21:23 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA64951; Sun, 2 Jul 2000 02:11:08 -0700 (PDT) Message-ID: <395F072A.87290B51@sgi.com> Date: Sun, 02 Jul 2000 02:11:06 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-origin@oss.sgi.com CC: slinx-xfs@cthulhu.engr.sgi.com Subject: Full-circle: XFS on Linux on Origin 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 Just as an experiment, started porting linux-xfs to MIPS64. Although the Origin port is not an intended product, it enables studying the scalability of linux on bigger hardware. Most of the "port" involved seriously hacking the typedefs, such as uint64_t etc ... I also had to workaround what appears to be a compiler bug in the static initializer of DECLARE_WAIT_QUEUE_HEAD(). Here are the results on a machine called "penguin3", which claims to be the first O2000 running linux 2.3 (from its /etc/motd), but really looks like a O200. Following shows that (a) creating & mounting an XFS filesystem under linux-mips (b) mouting an exiting filesystem (created under IRIX) onto linux. ------------- [root@penguin3 /xfs.irix]# cat /proc/cpuinfo cpu : MIPS BogoMIPS : 179.81 Number of cpus : 1 byteorder : big endian [ ... ] [root@penguin3 /xfs.irix]# mount /dev/sdb1 on / type ext2 (rw) none on /proc type proc (rw) /dev/sdc2 on /xfs type xfs (rw) /dev/sdc1 on /xfs.irix type xfs (rw) [ ... ] # /dev/sdc2 is a new filesystem, created under linux # /dev/sdc1 is an old IRIX filesystem, created under IRIX # ... and here's good old the IRIX binary from whence XFS came! [ ... ] [root@penguin3 /xfs.irix]# pwd /xfs.irix [root@penguin3 /xfs.irix]# file unix unix: ELF 64-bit MSB executable, MIPS R3000_BE, version 1, not stripped # The R3000 is bogus -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-origin@oss.sgi.com Thu Jul 6 15:14:11 2000 Received: by oss.sgi.com id ; Thu, 6 Jul 2000 15:13:51 -0700 Received: from u-145.karlsruhe.ipdial.viaginterkom.de ([62.180.10.145]:4868 "EHLO u-145.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Thu, 6 Jul 2000 15:13:43 -0700 Received: by lappi.waldorf-gmbh.de id ; Thu, 6 Jul 2000 04:05:47 -0700 Date: Thu, 6 Jul 2000 13:05:47 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: sys32_newstat() and friends Message-ID: <20000706130547.A6744@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing This is sys32_newstat from today's CVS: asmlinkage int sys32_newstat(char * filename, struct stat32 *statbuf) { int ret; struct stat s; mm_segment_t old_fs = get_fs(); set_fs (KERNEL_DS); ret = sys_newstat(filename, &s); set_fs (old_fs); if (putstat (statbuf, &s)) return -EFAULT; return ret; } Note that set_fs(KERNEL_DS) also allows the filename to be fetched from anywhere in memory including kernel space resulting in a potencial information leak or crash. Question: why do we have two implementations of each of sys32_newstat, sys32_newlstat and sys32_newfstat in linux32.c? Ralf From owner-linux-origin@oss.sgi.com Thu Jul 6 15:32:51 2000 Received: by oss.sgi.com id ; Thu, 6 Jul 2000 15:32:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:56378 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 6 Jul 2000 15:32:20 -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 PAA18911 for ; Thu, 6 Jul 2000 15:27:28 -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 PAA60529 for ; Thu, 6 Jul 2000 15:30:43 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA20540; Thu, 6 Jul 2000 15:27:43 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007062227.PAA20540@google.engr.sgi.com> Subject: Re: sys32_newstat() and friends To: ralf@uni-koblenz.de (Ralf Baechle) Date: Thu, 6 Jul 2000 15:27:43 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000706130547.A6744@bacchus.dhis.org> from "Ralf Baechle" at Jul 06, 2000 01:05:47 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 > > This is sys32_newstat from today's CVS: > > asmlinkage int > sys32_newstat(char * filename, struct stat32 *statbuf) > { > int ret; > struct stat s; > mm_segment_t old_fs = get_fs(); > > set_fs (KERNEL_DS); > ret = sys_newstat(filename, &s); > set_fs (old_fs); > if (putstat (statbuf, &s)) > return -EFAULT; > > return ret; > } Whoever did this picked the arch/ia64/ia32/sys_ia32.c verbatim. > > Note that set_fs(KERNEL_DS) also allows the filename to be fetched from > anywhere in memory including kernel space resulting in a potencial > information leak or crash. Define how you can get a information leak or crash. I haven't looked too closely, but I assume the fs/namei.c routines protect themselves. In any case, most other ioctls on 64 bit platforms have this same problem then. > > Question: why do we have two implementations of each of sys32_newstat, > sys32_newlstat and sys32_newfstat in linux32.c? > One is probably the sparc64, and the other the ia64 implementation. Kanoj > Ralf > From owner-linux-origin@oss.sgi.com Thu Jul 6 16:25:41 2000 Received: by oss.sgi.com id ; Thu, 6 Jul 2000 16:25:21 -0700 Received: from u-145.karlsruhe.ipdial.viaginterkom.de ([62.180.10.145]:13060 "EHLO u-145.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Thu, 6 Jul 2000 16:24:56 -0700 Received: by lappi.waldorf-gmbh.de id ; Fri, 7 Jul 2000 01:24:36 +0200 Date: Fri, 7 Jul 2000 01:24:36 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: sys32_newstat() and friends Message-ID: <20000707012436.A2303@bacchus.dhis.org> References: <20000706130547.A6744@bacchus.dhis.org> <200007062227.PAA20540@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007062227.PAA20540@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Jul 06, 2000 at 03:27:43PM -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, Jul 06, 2000 at 03:27:43PM -0700, Kanoj Sarcar wrote: > > Note that set_fs(KERNEL_DS) also allows the filename to be fetched from > > anywhere in memory including kernel space resulting in a potencial > > information leak or crash. > > Define how you can get a information leak or crash. I haven't looked > too closely, but I assume the fs/namei.c routines protect themselves. > In any case, most other ioctls on 64 bit platforms have this same problem > then. Nope, these routines don't - and can't protect themselfes. The user has to set_fs() correctly and that's broken in these functions. Information leak - it's not exactly a superconvenient peephole into the kernelspace. Assume you want to read a certain address space in memory. To do so you have to guess that memory's content. If you guess right you'll stat some random object on the fs. You can guess which one it was from the inode number. Crash - there are some hardware registers which don't like to be read. Point the filename argument to one of those and poof, game over. For now some pointer to non-decoded address space should do, you get a DBE exception, game over. Ralf From owner-linux-origin@oss.sgi.com Thu Jul 6 18:15:32 2000 Received: by oss.sgi.com id ; Thu, 6 Jul 2000 18:15:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62833 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 6 Jul 2000 18:15:11 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA05915; Thu, 6 Jul 2000 18:20:46 -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 SAA02733; Thu, 6 Jul 2000 18:14:48 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA25994; Thu, 6 Jul 2000 18:11:45 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007070111.SAA25994@google.engr.sgi.com> Subject: Re: sys32_newstat() and friends To: ralf@oss.sgi.com (Ralf Baechle) Date: Thu, 6 Jul 2000 18:11:45 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000707012436.A2303@bacchus.dhis.org> from "Ralf Baechle" at Jul 07, 2000 01:24:36 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 > > On Thu, Jul 06, 2000 at 03:27:43PM -0700, Kanoj Sarcar wrote: > > > > Note that set_fs(KERNEL_DS) also allows the filename to be fetched from > > > anywhere in memory including kernel space resulting in a potencial > > > information leak or crash. > > > > Define how you can get a information leak or crash. I haven't looked > > too closely, but I assume the fs/namei.c routines protect themselves. > > In any case, most other ioctls on 64 bit platforms have this same problem > > then. > > Nope, these routines don't - and can't protect themselfes. The user has > to set_fs() correctly and that's broken in these functions. > > Information leak - it's not exactly a superconvenient peephole into the > kernelspace. Assume you want to read a certain address space in memory. > To do so you have to guess that memory's content. If you guess right > you'll stat some random object on the fs. You can guess which one it > was from the inode number. Okay, so you can guess a specific filename exists at a specific location in memory (assuming you have the permissions to do stat on that file). It doesn't reassure you much, but it can't disturb you much either, but then I am no security expert ... > > Crash - there are some hardware registers which don't like to be read. > Point the filename argument to one of those and poof, game over. For now > some pointer to non-decoded address space should do, you get a DBE > exception, game over. > The right way to fix this is to fix the fault handlers to give SIGSEGV to the process incurring the DBE, and move on. If the architecture is such that receovery from a DBE is not possible, yes, then all the arch specific code must validate user input. For sys32_newstat, that would mean copying the user string into a temporary kernel buffer, then setting the set_fs() before invoking sys_newstat() and pointing it to the temporary kernel buffer. Kanoj > Ralf > From owner-linux-origin@oss.sgi.com Thu Jul 6 18:33:12 2000 Received: by oss.sgi.com id ; Thu, 6 Jul 2000 18:33:02 -0700 Received: from u-145.karlsruhe.ipdial.viaginterkom.de ([62.180.10.145]:15876 "EHLO u-145.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Thu, 6 Jul 2000 18:32:52 -0700 Received: by lappi.waldorf-gmbh.de id ; Fri, 7 Jul 2000 03:32:43 +0200 Date: Fri, 7 Jul 2000 03:32:43 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: sys32_newstat() and friends Message-ID: <20000707033243.A3743@bacchus.dhis.org> References: <20000707012436.A2303@bacchus.dhis.org> <200007070111.SAA25994@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007070111.SAA25994@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Jul 06, 2000 at 06:11:45PM -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, Jul 06, 2000 at 06:11:45PM -0700, Kanoj Sarcar wrote: > > Crash - there are some hardware registers which don't like to be read. > > Point the filename argument to one of those and poof, game over. For now > > some pointer to non-decoded address space should do, you get a DBE > > exception, game over. > > > > The right way to fix this is to fix the fault handlers to give SIGSEGV > to the process incurring the DBE, and move on. If you get a DBE. Pick the right hardware register and it'll freeze your system. Doesn't seem to happen easily on the Origin but frequently on less nice hardware. > If the architecture is such that receovery from a DBE is not possible, > yes, then all the arch specific code must validate user input. For > sys32_newstat, that would mean copying the user string into a temporary > kernel buffer, then setting the set_fs() before invoking sys_newstat() > and pointing it to the temporary kernel buffer. I fixed the other code which probably copied from Sparc64. This one won't copy filenames multiple times around. Ralf From owner-linux-origin@oss.sgi.com Fri Jul 7 18:31:43 2000 Received: by oss.sgi.com id ; Fri, 7 Jul 2000 18:31:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4714 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 7 Jul 2000 18:31:19 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA06441 for ; Fri, 7 Jul 2000 18:36:55 -0700 (PDT) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA71427; Fri, 7 Jul 2000 18:26:26 -0700 (PDT) Message-ID: <39668494.212357AD@sgi.com> Date: Fri, 07 Jul 2000 18:32:04 -0700 From: Rajagopal Ananthanarayanan Reply-To: linux-origin@oss.sgi.com X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-origin@oss.sgi.com Subject: KDB for mips64? References: <3907.963017623@ocs3.ocs-net> 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 Keith Owens wrote: > > On Fri, 07 Jul 2000 16:04:22 -0700, > Rajagopal Ananthanarayanan wrote: > >Debugging any of these problems is not easy since there > >is no KDB for mips64 (hint, keith ;-). > > Usual problem - to build kdb for any architecture I need access to > hardware that has a serial console and that I can power cycle at any > time. Plus hardware manuals for that arch. That shouldn't be a big problem. Ulf Karlsson has set up the following web page for m/c access: http://oss.sgi.com/~ulfc/linuxmips64.html > > I just subscribed to linux-origin, no mention of a web page or mailing > list archive. Where do I start looking to get up to speed on kernel, > gcc, binutils, instruction set etc.? You should direct these questions to linux-origin; some of the key people in random order are: Ralf Baechle, Kanoj Sarcar and Ulf. I compile on dbear.engr, with "ARCH=mips64" added to the make line. Kanoj gives me sources, but you should be able to get them from a CVS repository (details not known to me). If you want a recent source snap, find them at: dbear.engr:/build2/ananth/mips64xfs/linux.0705 Let's carry over this discussion to linux-origin@oss ... For anyone (from slinx-xfs) interested in the on-goings, please subscribe to that list. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-origin@oss.sgi.com Mon Jul 10 13:31:00 2000 Received: by oss.sgi.com id ; Mon, 10 Jul 2000 13:30:41 -0700 Received: from u-113.karlsruhe.ipdial.viaginterkom.de ([62.180.18.113]:46598 "EHLO u-113.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 10 Jul 2000 13:30:30 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 10 Jul 2000 21:39:20 +0200 Date: Mon, 10 Jul 2000 21:39:20 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: libc problem Message-ID: <20000710213920.A12950@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Crosscompiling I ran into a small problem with IRIX's libc. Could somebody bring me into contact with a libc guy such that I could discuss the issue with them? Thanks. Ralf From owner-linux-origin@oss.sgi.com Tue Jul 11 00:04:04 2000 Received: by oss.sgi.com id ; Tue, 11 Jul 2000 00:03:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:16480 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Jul 2000 00:03:30 -0700 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 XAA21391 for ; Mon, 10 Jul 2000 23:58:36 -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 AAA37230 for ; Tue, 11 Jul 2000 00:03:23 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: by calypso.engr.sgi.com (Postfix, from userid 37984) id 08243A7875; Tue, 11 Jul 2000 00:01:31 -0700 (PDT) From: Ulf Carlsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14698.50762.984930.220493@calypso.engr.sgi.com> Date: Tue, 11 Jul 2000 00:01:30 -0700 (PDT) To: linux-origin@oss.sgi.com Subject: CVS breakage X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Hi, I noticed that I don't get any output from the serial console on the current CVS kernel. On the debug port it only prints: 1A 000: *** XTLB Refill Exception on node 0 1A 000: *** EPC: 0xffffffff80036cc8 (0xffffffff80036cc8) 1A 000: *** Press ENTER to continue. Ulf From owner-linux-origin@oss.sgi.com Tue Jul 11 15:38:04 2000 Received: by oss.sgi.com id ; Tue, 11 Jul 2000 15:37:45 -0700 Received: from u-215.karlsruhe.ipdial.viaginterkom.de ([62.180.10.215]:26887 "EHLO u-215.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 11 Jul 2000 15:37:34 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 11 Jul 2000 05:33:49 +0200 Date: Tue, 11 Jul 2000 05:33:49 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Merge status Message-ID: <20000711053349.A22591@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing The race for merging with Linus shows effect - after Linus today took most of what I had sent him already several times we had less than 40kb left to merge. This makes maintenance significantly easier. Ralf From owner-linux-origin@oss.sgi.com Tue Jul 11 16:17:53 2000 Received: by oss.sgi.com id ; Tue, 11 Jul 2000 16:17:44 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26891 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Jul 2000 16:17:38 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA00827 for ; Tue, 11 Jul 2000 10:13:47 -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 KAA78256 for ; Tue, 11 Jul 2000 10:07:44 -0700 (PDT) Received: (from sprasad@localhost) by sprasad.engr.sgi.com (980427.SGI.8.8.8/960327.SGI.AUTOCF) id KAA46442; Tue, 11 Jul 2000 10:04:15 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200007111704.KAA46442@sprasad.engr.sgi.com> Subject: Re: CVS breakage To: ulfc@calypso.engr.sgi.com (Ulf Carlsson) Date: Tue, 11 Jul 2000 10:04:15 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <14698.50762.984930.220493@calypso.engr.sgi.com> from "Ulf Carlsson" at Jul 11, 2000 12:01:30 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 Ulf Carlsson ... > > Hi, > > I noticed that I don't get any output from the serial console on the > current CVS kernel. On the debug port it only prints: > > 1A 000: *** XTLB Refill Exception on node 0 > 1A 000: *** EPC: 0xffffffff80036cc8 (0xffffffff80036cc8) > 1A 000: *** Press ENTER to continue. This means that processor in slot N1, cpu A, took the exception and it had not gotten past iodiscovery yet to print it on the serial console. swapping n1 with other slots may help?? Is there a good baseio in io1-6 Srinivasa > > Ulf > From owner-linux-origin@oss.sgi.com Tue Jul 11 16:43:53 2000 Received: by oss.sgi.com id ; Tue, 11 Jul 2000 16:43:34 -0700 Received: from u-215.karlsruhe.ipdial.viaginterkom.de ([62.180.10.215]:29447 "EHLO u-215.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 11 Jul 2000 16:43:06 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 12 Jul 2000 01:42:53 +0200 Date: Wed, 12 Jul 2000 01:42:53 +0200 From: Ralf Baechle To: Srinivasa Prasad Thirumalachar Cc: Ulf Carlsson , linux-origin@oss.sgi.com Subject: Re: CVS breakage Message-ID: <20000712014253.C4547@bacchus.dhis.org> References: <14698.50762.984930.220493@calypso.engr.sgi.com> <200007111704.KAA46442@sprasad.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007111704.KAA46442@sprasad.engr.sgi.com>; from sprasad@sprasad.engr.sgi.com on Tue, Jul 11, 2000 at 10:04:15AM -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, Jul 11, 2000 at 10:04:15AM -0700, Srinivasa Prasad Thirumalachar wrote: > > > > I noticed that I don't get any output from the serial console on the > > current CVS kernel. On the debug port it only prints: > > > > 1A 000: *** XTLB Refill Exception on node 0 > > 1A 000: *** EPC: 0xffffffff80036cc8 (0xffffffff80036cc8) > > 1A 000: *** Press ENTER to continue. > > This means that processor in slot N1, cpu A, took the exception > and it had not gotten past iodiscovery yet to print it on the > serial console. swapping n1 with other slots may help?? > > Is there a good baseio in io1-6 There is. This is the typical way for an Origin kernel to die when it gets struck by a fatal bug in the very early startup. Ralf From owner-linux-origin@oss.sgi.com Tue Jul 11 17:38:05 2000 Received: by oss.sgi.com id ; Tue, 11 Jul 2000 17:37:55 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20758 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 11 Jul 2000 17:37:37 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09806; Tue, 11 Jul 2000 17:43:18 -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 RAA24852; Tue, 11 Jul 2000 17:37:16 -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 RAA43300; Tue, 11 Jul 2000 17:35:44 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: by calypso.engr.sgi.com (Postfix, from userid 37984) id 8D3E7A7875; Tue, 11 Jul 2000 17:33:49 -0700 (PDT) From: Ulf Carlsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14699.48365.496117.171517@calypso.engr.sgi.com> Date: Tue, 11 Jul 2000 17:33:49 -0700 (PDT) To: Ralf Baechle Cc: Srinivasa Prasad Thirumalachar , linux-origin@oss.sgi.com Subject: Re: CVS breakage In-Reply-To: <20000712014253.C4547@bacchus.dhis.org> References: <14698.50762.984930.220493@calypso.engr.sgi.com> <200007111704.KAA46442@sprasad.engr.sgi.com> <20000712014253.C4547@bacchus.dhis.org> X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > > I noticed that I don't get any output from the serial console on the > > > current CVS kernel. On the debug port it only prints: > > > > > > 1A 000: *** XTLB Refill Exception on node 0 > > > 1A 000: *** EPC: 0xffffffff80036cc8 (0xffffffff80036cc8) > > > 1A 000: *** Press ENTER to continue. > > > > This means that processor in slot N1, cpu A, took the exception > > and it had not gotten past iodiscovery yet to print it on the > > serial console. swapping n1 with other slots may help?? > > > > Is there a good baseio in io1-6 > > There is. This is the typical way for an Origin kernel to die when it > gets struck by a fatal bug in the very early startup. I applied a fix for this earlier today. Ulf From owner-linux-origin@oss.sgi.com Mon Jul 17 15:26:53 2000 Received: by oss.sgi.com id ; Mon, 17 Jul 2000 15:26:43 -0700 Received: from u-166.karlsruhe.ipdial.viaginterkom.de ([62.180.19.166]:52740 "EHLO u-166.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 17 Jul 2000 15:26:22 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 18 Jul 2000 00:25:33 +0200 Date: Tue, 18 Jul 2000 00:25:33 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: IOC3 driver Message-ID: <20000718002533.A8679@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I just added a minor fix to the IOC3 driver. We were loosing the SSRAM bits from the emcr register when we did a driver reset. As trivial as this fix is I didn't have any network hangs since then. There however isn't any obvious link between those bits and the UP network lockups we were observing, so I'm interested in test reports from others. Ralf From owner-linux-origin@oss.sgi.com Mon Jul 17 16:02:23 2000 Received: by oss.sgi.com id ; Mon, 17 Jul 2000 16:02:13 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32031 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 17 Jul 2000 16:01:37 -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 QAA07461 for ; Mon, 17 Jul 2000 16:06:53 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id PAA51428; Mon, 17 Jul 2000 15:59:57 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007172259.PAA51428@google.engr.sgi.com> Subject: Re: IOC3 driver To: ralf@uni-koblenz.de (Ralf Baechle) Date: Mon, 17 Jul 2000 15:59:56 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000718002533.A8679@bacchus.dhis.org> from "Ralf Baechle" at Jul 18, 2000 12:25:33 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 > > I just added a minor fix to the IOC3 driver. We were loosing the SSRAM > bits from the emcr register when we did a driver reset. As trivial as > this fix is I didn't have any network hangs since then. There however > isn't any obvious link between those bits and the UP network lockups we > were observing, so I'm interested in test reports from others. Nothing UP specific there, the same network lockups have been observed on SMP kernels too ... Kanoj > > Ralf > From owner-linux-origin@oss.sgi.com Mon Jul 17 16:09:03 2000 Received: by oss.sgi.com id ; Mon, 17 Jul 2000 16:08:53 -0700 Received: from u-166.karlsruhe.ipdial.viaginterkom.de ([62.180.19.166]:55300 "EHLO u-166.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 17 Jul 2000 16:08:32 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 18 Jul 2000 01:07:55 +0200 Date: Tue, 18 Jul 2000 01:07:55 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: IOC3 driver Message-ID: <20000718010755.A9283@bacchus.dhis.org> References: <20000718002533.A8679@bacchus.dhis.org> <200007172259.PAA51428@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007172259.PAA51428@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Mon, Jul 17, 2000 at 03:59:56PM -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 Mon, Jul 17, 2000 at 03:59:56PM -0700, Kanoj Sarcar wrote: > > I just added a minor fix to the IOC3 driver. We were loosing the SSRAM > > bits from the emcr register when we did a driver reset. As trivial as > > this fix is I didn't have any network hangs since then. There however > > isn't any obvious link between those bits and the UP network lockups we > > were observing, so I'm interested in test reports from others. > > Nothing UP specific there, the same network lockups have been observed on > SMP kernels too ... Ok, that makes more sense. I probably missunderstood Ulf's description. Ralf From owner-linux-origin@oss.sgi.com Mon Jul 17 22:18:25 2000 Received: by oss.sgi.com id ; Mon, 17 Jul 2000 22:18:15 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54076 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 17 Jul 2000 22:17:40 -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 WAA06535 for ; Mon, 17 Jul 2000 22:22:56 -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 WAA09190 for ; Mon, 17 Jul 2000 22:17:00 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: by calypso.engr.sgi.com (Postfix, from userid 37984) id 35A76A7875; Mon, 17 Jul 2000 22:15:42 -0700 (PDT) From: Ulf Carlsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14707.59390.144205.450968@calypso.engr.sgi.com> Date: Mon, 17 Jul 2000 22:15:42 -0700 (PDT) To: linux-origin@oss.sgi.com Cc: skunx@calypso.engr.sgi.com Subject: Kernel profiles from MIPS64 X-Mailer: VM 6.75 under Emacs 20.5.1 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Hi, I have done some kernel profiling on the Origin kernel on a 2 CPU O200 and a 8 CPU O2000. The results are available at: http://oss.sgi.com/~ulfc/profiles/000717/ I tried to do profiling on a 32 CPU machine as well, but the machine wouldn't let me finish the compiles before it crashed. Anyway, the graphs generated are rather interesting. Almost 50% of the CPU time is in cpu_idle from the compiles on a Origin 2000. This looks like a bug caused that may be caused by the recent generic changes in the priority handling. I also observed that the discontig memory option is broken during my tests, the machine crashed. The configuration I used for these tests is the default configuration except for SMP support, modules support and of course kernel profiling support. Ulf From owner-linux-origin@oss.sgi.com Fri Jul 21 13:49:54 2000 Received: by oss.sgi.com id ; Fri, 21 Jul 2000 13:49:45 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:4900 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 21 Jul 2000 13:49:12 -0700 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 NAA02806 for ; Fri, 21 Jul 2000 13:41:19 -0700 (PDT) mail_from (dimitris@darkside.engr.sgi.com) Received: from darkside.engr.sgi.com (darkside.engr.sgi.com [163.154.5.83]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA66593; Fri, 21 Jul 2000 13:48:34 -0700 (PDT) mail_from (dimitris@darkside.engr.sgi.com) Received: (from dimitris@localhost) by darkside.engr.sgi.com (8.9.3/8.8.7) id NAA08136; Fri, 21 Jul 2000 13:48:33 -0700 Message-ID: X-Mailer: XFMail 1.4.4 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <14707.59390.144205.450968@calypso.engr.sgi.com> Date: Fri, 21 Jul 2000 13:48:33 -0700 (PDT) Organization: SGI From: Dimitris Michailidis To: Ulf Carlsson Subject: RE: Kernel profiles from MIPS64 Cc: skunx@calypso.engr.sgi.com, linux-origin@oss.sgi.com Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On 18-Jul-2000 Ulf Carlsson wrote: > I tried to do profiling on a 32 CPU machine as well, but the machine > wouldn't let me finish the compiles before it crashed. Anyway, the > graphs generated are rather interesting. Almost 50% of the CPU time > is in cpu_idle from the compiles on a Origin 2000. This looks like a > bug caused that may be caused by the recent generic changes in the > priority handling. This is in line with the 421% CPU utilization reported by time. Are you sure that kernel builds are parallel enough to keep all 8 CPUs busy? Otherwise you'll have idle CPUs giving you a lot of idle time. -- Dimitris Michailidis dimitris@engr.sgi.com From owner-linux-origin@oss.sgi.com Fri Jul 21 14:00:53 2000 Received: by oss.sgi.com id ; Fri, 21 Jul 2000 14:00:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55079 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 21 Jul 2000 14:00:20 -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 NAA04140 for ; Fri, 21 Jul 2000 13:52:27 -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 NAA18471 for ; Fri, 21 Jul 2000 13:59:27 -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 NAA51010; Fri, 21 Jul 2000 13:57:55 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: by calypso.engr.sgi.com (Postfix, from userid 37984) id 016EEA7875; Fri, 21 Jul 2000 13:56:26 -0700 (PDT) To: Dimitris Michailidis Cc: skunx@calypso.engr.sgi.com, linux-origin@oss.sgi.com Subject: Re: Kernel profiles from MIPS64 References: From: Ulf Carlsson Date: 21 Jul 2000 13:56:26 -0700 In-Reply-To: Dimitris Michailidis's message of "Fri, 21 Jul 2000 13:48:33 -0700 (PDT)" Message-ID: <6ovwvif2oed.fsf@calypso.engr.sgi.com> Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > On 18-Jul-2000 Ulf Carlsson wrote: > > I tried to do profiling on a 32 CPU machine as well, but the machine > > wouldn't let me finish the compiles before it crashed. Anyway, the > > graphs generated are rather interesting. Almost 50% of the CPU time > > is in cpu_idle from the compiles on a Origin 2000. This looks like a > > bug caused that may be caused by the recent generic changes in the > > priority handling. > > This is in line with the 421% CPU utilization reported by time. Are you sure > that kernel builds are parallel enough to keep all 8 CPUs busy? Otherwise > you'll have idle CPUs giving you a lot of idle time. No, I would see better results if I did make -j8 MAKE="make -j8", but unfortanately that didn't work. I'll try it again later today. We don't have enough top-level directories in the kernel tree. Ulf From owner-linux-origin@oss.sgi.com Fri Jul 21 17:50:16 2000 Received: by oss.sgi.com id ; Fri, 21 Jul 2000 17:50:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:29525 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 21 Jul 2000 17:49:34 -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 RAA25861 for ; Fri, 21 Jul 2000 17:41:40 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id RAA92284; Fri, 21 Jul 2000 17:47:53 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007220047.RAA92284@google.engr.sgi.com> Subject: eth drivers To: ralf@uni-koblenz.de Date: Fri, 21 Jul 2000 17:47:52 -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 Ralf, while running some tests (the kernel got a BUG()), I keep getting eth0: RX overflow. messages. It might be because of the previous BUG(), which may be preventing normal operation, but thought I would let you know ... Kanoj From owner-linux-origin@oss.sgi.com Fri Jul 21 18:06:26 2000 Received: by oss.sgi.com id ; Fri, 21 Jul 2000 18:06:16 -0700 Received: from u-35.karlsruhe.ipdial.viaginterkom.de ([62.180.19.35]:34564 "EHLO u-35.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Fri, 21 Jul 2000 18:05:54 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sat, 22 Jul 2000 03:05:13 +0200 Date: Sat, 22 Jul 2000 03:05:13 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: eth drivers Message-ID: <20000722030513.I863@bacchus.dhis.org> References: <200007220047.RAA92284@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007220047.RAA92284@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Fri, Jul 21, 2000 at 05:47:52PM -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, Jul 21, 2000 at 05:47:52PM -0700, Kanoj Sarcar wrote: > Ralf, while running some tests (the kernel got a BUG()), I keep getting > eth0: RX overflow. messages. It might be because of the previous BUG(), > which may be preventing normal operation, but thought I would let you > know ... RX overflow mean the receiver ringbuffer did overflow. Being a silly chip the IOC3 signals this condition by disabling receiver & receiver DMA and and signaling interrupt. It's no serious problem yet the IOC3 overreacts and requires reinitalization of the chip. And this is where the trouble starts. Above state can be also be entered if interrupts are disabled for some time or by heavy traffic, try for example (as root): ping -l 10000000 origin A few seconds of flooding like this will reliably blow the IOC3 out of the socks. The problem I have is that my attempts to reinitialize the chip were rarely successful for some reason but I'm working on it. If you hit this problem during normal operation then you may try to increase the value of RX_BUFFS in ioc3-eth.c. It's 32 by default but can be increased in x 16 steps upto 512. Large values are probably a waste of money, though. Ralf From owner-linux-origin@oss.sgi.com Sat Jul 22 17:26:26 2000 Received: by oss.sgi.com id ; Sat, 22 Jul 2000 17:26:16 -0700 Received: from u-84.karlsruhe.ipdial.viaginterkom.de ([62.180.10.84]:16900 "EHLO u-84.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Sat, 22 Jul 2000 17:25:41 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sun, 23 Jul 2000 02:08:34 +0200 Date: Sun, 23 Jul 2000 02:08:34 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Cache tuning results Message-ID: <20000723020834.A1487@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing This are lmbench results from recent Linux/MIPS kernels. The machines - vitima is Origin 200, 2 x R10000, 1mb L2 running IRIX 6.5.4 - ralf is Origin 200, 2 x R10000, 2mb L2 running Linux 2.4.0-test5-pre3 with cache and TLB optimizations. - ice is an R4400 200MHz, 1mb L2 Indy running 2.4.0-test5-pre1 stock CVS kernel. - Ulf results where obtained by Ulf on penguin4 with 2.3.99-pre8. Note the dramatical improvments of the ``exec proc'' benchmark due to the cache hacks. The latency benchmarks are entirely being won by Linux, the local bandwith benchmarks are still all won by IRIX - mosty because our memcpy and ip checksum code are still just 32-bit code. The ridiculously bad mmap latency numbers for `ralf' are due to running diskless. The numbers for penguin4 show how Linux actually performs. Processor, Processes - times in microseconds - smaller is better ---------------------------------------------------------------- Host OS Mhz null null open selct sig sig fork exec sh call I/O stat clos inst hndl proc proc proc --------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ---- vitima IRIX64 6.5 180 2.8 11. 103 132 0.27K 8.1 29 1.4K 8K 14K ralf Linux 2.4.0-t 180 1.2 1.8 20 26 0.13K 3.0 11 0.5K 1K 36K ice Linux 2.4.0-t 198 0.9 2.0 25 28 0.15K 6.6 16 4.9K 19K 64K ulf Linux 2.3.99- 180 1.3 1.8 13 15 0.13K 3.0 15 1.2K 13K 43K Context switching - times in microseconds - smaller is better ------------------------------------------------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ----- ------ ------ ------ ------ ------- ------- vitima IRIX64 6.5 18 19 44 31 50 61 137 ralf Linux 2.4.0-t 2 6 42 15 48 18 95 ice Linux 2.4.0-t 4 78 529 91 402 115 600 ulf Linux 2.3.99- 1 6 216 46 582 123 966 *Local* Communication latencies in microseconds - smaller is better ------------------------------------------------------------------- Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP ctxsw UNIX UDP TCP conn --------- ------------- ----- ----- ---- ----- ----- ----- ----- ---- vitima IRIX64 6.5 18 76 136 187 194 382 ralf Linux 2.4.0-t 3 14 31 54 78 251 ice Linux 2.4.0-t 4 24 66 ulf Linux 2.3.99- 1 16 38 File & VM system latencies in microseconds - smaller is better -------------------------------------------------------------- Host OS 0K File 10K File Mmap Prot Page Create Delete Create Delete Latency Fault Fault --------- ------------- ------ ------ ------ ------ ------- ----- ----- vitima IRIX64 6.5 10305 7 16.2K ralf Linux 2.4.0-t 531477 2 0.0K ice Linux 2.4.0-t 53 5 103 11 4034 4 0.0K ulf Linux 2.3.99- 24 4 62 14 7443 2 0.0K [...] Ralf From owner-linux-origin@oss.sgi.com Sun Jul 23 15:45:24 2000 Received: by oss.sgi.com id ; Sun, 23 Jul 2000 15:45:15 -0700 Received: from u-46.karlsruhe.ipdial.viaginterkom.de ([62.180.18.46]:7172 "EHLO u-46.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Sun, 23 Jul 2000 15:44:53 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 24 Jul 2000 00:44:10 +0200 Date: Mon, 24 Jul 2000 00:44:09 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: update_mmu_cache Message-ID: <20000724004409.B2678@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Kanoj, we've got one left problem with my new implementation of flush_icache_page(). This function receives a vma ptr and a struct page ptr as arguments. That means we don't know the virtual address of the userspace mapping when flushing. We could either pass the virtual address as a new additional argument or could move the icache flushing stuff into update_mmu_cache() which already has all these arguments. flush_icache_page() doesn't properly cover all code paths also, see for example this fragment of handle_pte_fault: [...] tatic inline int handle_pte_fault(struct mm_struct *mm, struct vm_area_struct * vma, unsigned long address, int write_access, pte_t * pte) { pte_t entry; entry = *pte; if (!pte_present(entry)) { if (pte_none(entry)) return do_no_page(mm, vma, address, write_access, pte); return do_swap_page(mm, vma, address, pte, pte_to_swp_entry(entry), write_access); } [...] which could bring a codepage in without properly flushing the icache. I'm not sure why things are as they are but afair flush_icache_page() was added due to some sparc problem. So I see three approaches now: - sprinkle some more flush_icache_pages over generic mm and add a third vaddr argument. - move icache flushing into update_mmu_cache. - handle the cache flushing thing in do_page_fault in fault.c. What do you think? Ralf From owner-linux-origin@oss.sgi.com Mon Jul 24 09:42:30 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 09:42:20 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:26426 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 09:41:51 -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 JAA26251; Mon, 24 Jul 2000 09:33:57 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA50710; Mon, 24 Jul 2000 09:40:12 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007241640.JAA50710@google.engr.sgi.com> Subject: Re: update_mmu_cache To: ralf@oss.sgi.com (Ralf Baechle) Date: Mon, 24 Jul 2000 09:40:12 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000724004409.B2678@bacchus.dhis.org> from "Ralf Baechle" at Jul 24, 2000 12:44:09 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 > > Kanoj, > > we've got one left problem with my new implementation of flush_icache_page(). Could you send the logic of your optimized cache flushing? As I mentioned before, getting that right first is more important than doing the coding ... Btw, the generic cpu type in your patch can come in later, after we have made sure the r10k works fine, instead of piling up multiple changes into one patch. I did some coding too, and am currently debugging it. My logic is this: flush_icache_page will writeback-invalidate dcache, invalidate icache. flush_icache_range will writeback-invalidate dcache ... additionally, if flush_icache_range is invoked on a kernel address (module loading), it will also invalidate icache (since it can not rely on flush_icache_page having done the icache flush). > This function receives a vma ptr and a struct page ptr as arguments. > That means we don't know the virtual address of the userspace mapping > when flushing. We could either pass the virtual address as a new Don't know the answer yet ... working on it ... > additional argument or could move the icache flushing stuff into > update_mmu_cache() which already has all these arguments. flush_icache_page() > doesn't properly cover all code paths also, see for example this > fragment of handle_pte_fault: > > [...] > tatic inline int handle_pte_fault(struct mm_struct *mm, > struct vm_area_struct * vma, unsigned long address, > int write_access, pte_t * pte) > { > pte_t entry; > > entry = *pte; > if (!pte_present(entry)) { > if (pte_none(entry)) > return do_no_page(mm, vma, address, write_access, pte); > return do_swap_page(mm, vma, address, pte, pte_to_swp_entry(entry), write_access); > } > [...] > > which could bring a codepage in without properly flushing the icache. Don't see that. Both of do_no_page and do_swap_page have flush_icache_pages in them, what else might get thru? > > I'm not sure why things are as they are but afair flush_icache_page() was > added due to some sparc problem. So I see three approaches now: > > - sprinkle some more flush_icache_pages over generic mm and add a third > vaddr argument. > - move icache flushing into update_mmu_cache. > - handle the cache flushing thing in do_page_fault in fault.c. All of these are possibilities. As I said before, before we decide which is the best one, we need to decide exactly when we need to flush caches. First, we need to see if the current (icache flush) hooks will suffice (this is what I am trying and debugging currently). If not, we need to move the flushes into code that has all the information, or get more information added into the generic hooks. Kanoj > > What do you think? > > Ralf > From owner-linux-origin@oss.sgi.com Mon Jul 24 13:10:30 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 13:10:20 -0700 Received: from u-183.karlsruhe.ipdial.viaginterkom.de ([62.180.18.183]:3844 "EHLO u-183.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 13:09:46 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 24 Jul 2000 21:54:01 +0200 Date: Mon, 24 Jul 2000 21:54:01 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: update_mmu_cache Message-ID: <20000724215401.A16062@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Kanoj, when running ``strace rpm --rebuilddb'' I receive the following message whenever I've straced though rpm upto a certain point: update_mmu_cache: Wheee, bogus tlbpid mmpid=112 tlbpid=110 The numbers of mmpid and tlbpid are different each time but the relation mmpid = (tlbpid + 2) & 0xff is always true. This is on yesterday's CVS kernel + my cache patch which I've sent to you. It seems that under certain circumstances we may destroy the current MMU context but miss to reload a new ASID value into c0_entryhi. Ideas how this might happen? Ralf From owner-linux-origin@oss.sgi.com Mon Jul 24 14:31:51 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 14:31:41 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:27917 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 14:31:11 -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 OAA02483; Mon, 24 Jul 2000 14:23:17 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA22407; Mon, 24 Jul 2000 14:29:32 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007242129.OAA22407@google.engr.sgi.com> Subject: Re: update_mmu_cache To: ralf@oss.sgi.com (Ralf Baechle) Date: Mon, 24 Jul 2000 14:29:32 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000724215401.A16062@bacchus.dhis.org> from "Ralf Baechle" at Jul 24, 2000 09:54:01 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 > > Kanoj, > > when running ``strace rpm --rebuilddb'' I receive the following message > whenever I've straced though rpm upto a certain point: > > update_mmu_cache: Wheee, bogus tlbpid mmpid=112 > tlbpid=110 > > The numbers of mmpid and tlbpid are different each time but the relation > mmpid = (tlbpid + 2) & 0xff is always true. This is on yesterday's > CVS kernel + my cache patch which I've sent to you. > > It seems that under certain circumstances we may destroy the current > MMU context but miss to reload a new ASID value into c0_entryhi. Ideas > how this might happen? > A quick look does not give me any clues ... but I am not looking at the cache patch that you sent yet ... Kanoj > Ralf > From owner-linux-origin@oss.sgi.com Mon Jul 24 15:31:11 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 15:31:02 -0700 Received: from u-169.karlsruhe.ipdial.viaginterkom.de ([62.180.18.169]:10756 "EHLO u-169.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 15:30:28 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 25 Jul 2000 00:29:47 +0200 Date: Tue, 25 Jul 2000 00:29:47 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: update_mmu_cache Message-ID: <20000725002947.A1802@bacchus.dhis.org> References: <20000724215401.A16062@bacchus.dhis.org> <200007242129.OAA22407@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007242129.OAA22407@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Mon, Jul 24, 2000 at 02:29:32PM -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 Mon, Jul 24, 2000 at 02:29:32PM -0700, Kanoj Sarcar wrote: > A quick look does not give me any clues ... but I am not looking at > the cache patch that you sent yet ... The patch should not have influence on that behaviour but I didn't yet test that. Ralf From owner-linux-origin@oss.sgi.com Mon Jul 24 18:03:12 2000 Received: by oss.sgi.com id ; Mon, 24 Jul 2000 18:03:02 -0700 Received: from u-169.karlsruhe.ipdial.viaginterkom.de ([62.180.18.169]:18180 "EHLO u-169.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 24 Jul 2000 18:02:33 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 25 Jul 2000 03:01:45 +0200 Date: Tue, 25 Jul 2000 03:01:44 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: update_mmu_cache Message-ID: <20000725030144.C3042@bacchus.dhis.org> References: <20000724004409.B2678@bacchus.dhis.org> <200007241640.JAA50710@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007241640.JAA50710@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Mon, Jul 24, 2000 at 09:40:12AM -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 Mon, Jul 24, 2000 at 09:40:12AM -0700, Kanoj Sarcar wrote: > Could you send the logic of your optimized cache flushing? As I mentioned > before, getting that right first is more important than doing the coding ... > Btw, the generic cpu type in your patch can come in later, after we have > made sure the r10k works fine, instead of piling up multiple changes into > one patch. The generic cpu type was a side product. Since most of the R10k cache functions are empty functions now the obvious final step was to inline those into the callers also getting rid of the overhead of the function pointers. The generic cpu type is implemented only exactly to the degree that is necessary to achieve this. > I did some coding too, and am currently debugging it. My logic is this: > flush_icache_page will writeback-invalidate dcache, invalidate icache. > flush_icache_range will writeback-invalidate dcache ... additionally, if > flush_icache_range is invoked on a kernel address (module loading), it > will also invalidate icache (since it can not rely on flush_icache_page > having done the icache flush). Sounds good. Under the assumption flush_icache_range'd only be called for modules I left it out of my optimizations, it's being called very rarely, so the whole job of making i & d cache coherent is left to flush_icache_page. > Don't see that. Both of do_no_page and do_swap_page have flush_icache_pages > in them, what else might get thru? Sorry, I had tomatoes on my eyes. The only case the goes through is do_anonymous_page() but that one doesn't make sense for code, so no need to flush caches. > > I'm not sure why things are as they are but afair flush_icache_page() was > > added due to some sparc problem. So I see three approaches now: > > > > - sprinkle some more flush_icache_pages over generic mm and add a third > > vaddr argument. > > - move icache flushing into update_mmu_cache. > > - handle the cache flushing thing in do_page_fault in fault.c. > > All of these are possibilities. As I said before, before we decide which > is the best one, we need to decide exactly when we need to flush caches. > First, we need to see if the current (icache flush) hooks will suffice > (this is what I am trying and debugging currently). If not, we need to > move the flushes into code that has all the information, or get more > information added into the generic hooks. I've now choosen the last possibility, it results in the most compact code. Ralf From owner-linux-origin@oss.sgi.com Wed Jul 26 23:17:38 2000 Received: by oss.sgi.com id ; Wed, 26 Jul 2000 23:17:28 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:54611 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 26 Jul 2000 23:16:59 -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 XAA20148 for ; Wed, 26 Jul 2000 23:09:04 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id XAA37634 for linux-origin@oss.sgi.com; Wed, 26 Jul 2000 23:15:20 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007270615.XAA37634@google.engr.sgi.com> Subject: state of mips64 port To: linux-origin@oss.sgi.com Date: Wed, 26 Jul 2000 23:15:20 -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 Under high memory/processor loads induced by AIM7, thr kernel starts seeing random bus errors etc. It is not clear to me how this starts happening. Just a heads up ... Kanoj From owner-linux-origin@oss.sgi.com Sat Jul 29 18:25:43 2000 Received: by oss.sgi.com id ; Sat, 29 Jul 2000 18:25:23 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58985 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Sat, 29 Jul 2000 18:25:04 -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 SAA02675 for ; Sat, 29 Jul 2000 18:30:55 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id SAA92252 for linux-origin@oss.sgi.com; Sat, 29 Jul 2000 18:23:48 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200007300123.SAA92252@google.engr.sgi.com> Subject: performance improvements To: linux-origin@oss.sgi.com Date: Sat, 29 Jul 2000 18:23: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 Remember the kernel build times that I sent out a while back: SMP+DISCONTIG ------------- 781.20user 203.99system 5:05.95elapsed 322%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (508064major+1830860minor)pagefaults 0swaps After the cache flushing optimizations, this came down to: SMP+DISCONTIG ------------- 699.72user 132.15system 4:48.63elapsed 288%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (458609major+1632642minor)pagefaults 0swaps And after the recent tlbflush optimizations: SMP --- 771.97user 55.22system 4:24.73elapsed 312%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (508064major+1831879minor)pagefaults 0swaps I am still trying to figure out the DISCONTIGMEM problem, but at least it seems that on specific memory configurations, not ignoring the 128Mb memory on the 7th bank seems to create problems. Go figure. Kanoj From owner-linux-origin@oss.sgi.com Sun Jul 30 17:38:00 2000 Received: by oss.sgi.com id ; Sun, 30 Jul 2000 17:37:40 -0700 Received: from u-101.karlsruhe.ipdial.viaginterkom.de ([62.180.19.101]:22024 "EHLO u-101.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Sun, 30 Jul 2000 17:37:25 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sun, 30 Jul 2000 13:39:42 +0200 Date: Sun, 30 Jul 2000 13:39:42 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: performance improvements Message-ID: <20000730133942.D6603@bacchus.dhis.org> References: <200007300123.SAA92252@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007300123.SAA92252@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Sat, Jul 29, 2000 at 06:23:48PM -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 Sat, Jul 29, 2000 at 06:23:48PM -0700, Kanoj Sarcar wrote: > And after the recent tlbflush optimizations: > > SMP > --- > 771.97user 55.22system 4:24.73elapsed 312%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (508064major+1831879minor)pagefaults 0swaps > > I am still trying to figure out the DISCONTIGMEM problem, but at least > it seems that on specific memory configurations, not ignoring the 128Mb > memory on the 7th bank seems to create problems. Go figure. I'm rewriting some important routines like memcpy, memmove and ip checksums. As a result of the first crude test implementation the results of microbenchmarks like lmbench have increased significantly, sometimes beyond factor of two. A analysis of lmbench also shows that some of our number degrade much worse than IRIX's for large datasets; the graphs seem to indicate that the lack of cache colouring is the cause. Ralf