From owner-linux-origin@oss.sgi.com Thu Jun 1 06:47:10 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 06:46:50 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41573 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 06:46:21 -0700 Received: from albion.engr.sgi.com (albion.engr.sgi.com [163.154.5.55]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA03563 for ; Thu, 1 Jun 2000 07:51:09 -0700 (PDT) mail_from (sp@albion.engr.sgi.com) Received: from albion.engr.sgi.com (localhost [127.0.0.1]) by albion.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA89431; Thu, 1 Jun 2000 07:45:04 -0700 (PDT) Message-Id: <200006011445.HAA89431@albion.engr.sgi.com> X-Mailer: exmh version 2.0.2 2/24/98 To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Cc: linux-origin@oss.sgi.com, skunx@albion.engr.sgi.com Subject: Re: kernel compile time In-Reply-To: Your message of "Wed, 31 May 2000 20:43:22 PDT." <200006010343.UAA93168@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Jun 2000 07:45:03 -0700 From: Simon Patience Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing How many cpus does this machine have? Simon. > Here's some more "time" results: > > make > 742.60user 98.79system 13:28.03elapsed 104%CPU (0avgtext+0avgdata 0maxresiden > t)k0inputs+0outputs (497099major+616071minor)pagefaults 0swaps > > make -j4 > 741.31user 127.30system 4:14.02elapsed 341%CPU (0avgtext+0avgdata 0maxresiden > t)k0inputs+0outputs (497100major+616061minor)pagefaults 0swaps > > make -j6 > 751.95user 127.98system 4:00.42elapsed 365%CPU (0avgtext+0avgdata 0maxresiden > t)k0inputs+0outputs (497100major+616009minor)pagefaults 0swaps > > make -j8 > 754.64user 129.48system 4:07.33elapsed 357%CPU (0avgtext+0avgdata 0maxresiden > t)k0inputs+0outputs (497100major+615999minor)pagefaults 0swaps > > Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 1 09:18:33 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 09:18:13 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51802 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 09:17:53 -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 KAA14143 for ; Thu, 1 Jun 2000 10:12:59 -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 KAA82918; Thu, 1 Jun 2000 10:16:41 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011716.KAA82918@google.engr.sgi.com> Subject: Re: kernel compile time To: sp@albion.engr.sgi.com (Simon Patience) Date: Thu, 1 Jun 2000 10:16:41 -0700 (PDT) Cc: linux-origin@oss.sgi.com, skunx@albion.engr.sgi.com In-Reply-To: <200006011445.HAA89431@albion.engr.sgi.com> from "Simon Patience" at Jun 01, 2000 07:45:03 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 > > > How many cpus does this machine have? How stupid of me - 8 cpus, 128Mb (on 1 node). Kanoj > > Simon. > > > Here's some more "time" results: > > > > make > > 742.60user 98.79system 13:28.03elapsed 104%CPU (0avgtext+0avgdata 0maxresiden > > t)k0inputs+0outputs (497099major+616071minor)pagefaults 0swaps > > > > make -j4 > > 741.31user 127.30system 4:14.02elapsed 341%CPU (0avgtext+0avgdata 0maxresiden > > t)k0inputs+0outputs (497100major+616061minor)pagefaults 0swaps > > > > make -j6 > > 751.95user 127.98system 4:00.42elapsed 365%CPU (0avgtext+0avgdata 0maxresiden > > t)k0inputs+0outputs (497100major+616009minor)pagefaults 0swaps > > > > make -j8 > > 754.64user 129.48system 4:07.33elapsed 357%CPU (0avgtext+0avgdata 0maxresiden > > t)k0inputs+0outputs (497100major+615999minor)pagefaults 0swaps > > > > Kanoj > > From owner-linux-origin@oss.sgi.com Thu Jun 1 09:35:43 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 09:35:33 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:22132 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 09:35:18 -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 KAA06264 for ; Thu, 1 Jun 2000 10:40:05 -0700 (PDT) mail_from (hawkes@cthulhu.engr.sgi.com) Received: from pchawkes (dhcp-163-154-5-206.engr.sgi.com [163.154.5.206]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id KAA62097 for ; Thu, 1 Jun 2000 10:34:57 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <006d01bfcbf0$17167300$ce059aa3@engr.sgi.com> From: "John Hawkes" To: "linux-origin" Subject: more peeks at performance Date: Thu, 1 Jun 2000 10:37:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing FYI, I was playing around with AIM7 on Linux-Origin last week, trying to diagnose why performance was so bad. I didn't get very far, yet. Even when I stripped the AIM7 subtests down to a single compute-bound test, I wasn't seeing 'top' report that process as compute-bound. A known standalone compute-bound program (i.e., a simple program that just loops) does get seen by 'top' and 'vmstat' as compute-bound. Multiple copies of that program do appear to property share the overall available CPU cycles. But there's something about the AIM environment that isn't behaving well. AIM uses forked children and pipes for parent-child communication. Perhaps it's something in there. Or perhaps the stripped-down AIM is just executing each subtest within the display-refresh time. I need to play with it more. When I ran the same AIM7 workload that I typically run on an SMP i386 Kayak -- a workload that runs compute-bound -- I see pretty awful performance on Origin. On my i386 (two 266-MHz PentiumII) my AIM7 peaks at about 50 jobs/minute and stays fairly flat until 80 or 90 or so (when it begins to thrash). On a 2-200Mhz O200 I see a peak below *10* (at half the performance of the i386) and a huge falloff from there. Something is clearly wrong. John H. From owner-linux-origin@oss.sgi.com Thu Jun 1 09:39:33 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 09:39:23 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:52835 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 09:39:13 -0700 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA17750 for ; Thu, 1 Jun 2000 10:34:19 -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 KAA28749; Thu, 1 Jun 2000 10:32:58 -0700 (PDT) Message-ID: <39369F00.A9F2279A@sgi.com> Date: Thu, 01 Jun 2000 10:36:00 -0700 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_11smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Kanoj Sarcar CC: linux-origin@oss.sgi.com, skunx@engr.sgi.com Subject: Re: kernel compile time References: <200006011716.KAA82918@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: > > > > > > > How many cpus does this machine have? > > How stupid of me - 8 cpus, 128Mb (on 1 node). > > Kanoj > > > > > Simon. > > > > > Here's some more "time" results: > > > > > > make > > > 742.60user 98.79system 13:28.03elapsed 104%CPU (0avgtext+0avgdata 0maxresiden > > > t)k0inputs+0outputs (497099major+616071minor)pagefaults 0swaps > > > > > > make -j4 > > > 741.31user 127.30system 4:14.02elapsed 341%CPU (0avgtext+0avgdata 0maxresiden > > > t)k0inputs+0outputs (497100major+616061minor)pagefaults 0swaps > > > > > > make -j6 > > > 751.95user 127.98system 4:00.42elapsed 365%CPU (0avgtext+0avgdata 0maxresiden > > > t)k0inputs+0outputs (497100major+616009minor)pagefaults 0swaps > > > > > > make -j8 > > > 754.64user 129.48system 4:07.33elapsed 357%CPU (0avgtext+0avgdata 0maxresiden > > > t)k0inputs+0outputs (497100major+615999minor)pagefaults 0swaps > > > Kanoj, earlier you had said the wall time looks bad. I don't understand. For the 1-way make, it took 13:28 == 808 seconds, of which 742sec were in user mode (> 90%) ... which is typical of large compilation workloads. Going to -j4, elapsed time went from 808sec -> 254sec (4:14) which is a scaling of ~3.2 times ... if -j4 had had an elapsed time of 202sec (3:22) then it would have been perfect scaling. But add in the fact that -j4 vs. NO-J would introduce additional complexity in the make itself, which now spawns more processes, etc. ... this shows in the increased system time for -j4; of course the extra system time also counts increased lock contention. For this particular workload (primarily user-mode, little-or-no-shared parallelism), -j4 did pretty good. Finally, -j6 & -j8 may not discover any extra parallelism in the makes ... one gross way to check this is to watch "top" and see how many "cc" processes are running on an average. If it stays at 4, then -j4 is all that'll work. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. -------------------------------------------------------------------------- From owner-linux-origin@oss.sgi.com Thu Jun 1 09:51:43 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 09:51:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:63591 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 09:51: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 KAA19560 for ; Thu, 1 Jun 2000 10:46: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 KAA69793 for ; Thu, 1 Jun 2000 10:50:51 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA83240; Thu, 1 Jun 2000 10:48:25 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011748.KAA83240@google.engr.sgi.com> Subject: Re: kernel compile time To: ananth@sgi.com (Rajagopal Ananthanarayanan) Date: Thu, 1 Jun 2000 10:48:25 -0700 (PDT) Cc: linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com In-Reply-To: <39369F00.A9F2279A@sgi.com> from "Rajagopal Ananthanarayanan" at Jun 01, 2000 10:36:00 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, earlier you had said the wall time looks bad. > I don't understand. For the 1-way make, it took 13:28 == 808 seconds, > of which 742sec were in user mode (> 90%) ... which is typical of > large compilation workloads. 13:28 seconds for a 1 way make is just not an acceptable number. Refer to John's recent mail about AIM7 performance too. > > Going to -j4, elapsed time went from 808sec -> 254sec (4:14) > which is a scaling of ~3.2 times ... if -j4 had had an > elapsed time of 202sec (3:22) then it would have been perfect > scaling. But add in the fact that -j4 vs. NO-J would introduce > additional complexity in the make itself, which now spawns > more processes, etc. ... this shows in the increased system time > for -j4; of course the extra system time also counts increased > lock contention. For this particular workload (primarily user-mode, > little-or-no-shared parallelism), -j4 did pretty good. > > Finally, -j6 & -j8 may not discover any extra parallelism > in the makes ... one gross way to check this is to watch "top" > and see how many "cc" processes are running on an average. > If it stays at 4, then -j4 is all that'll work. > j6 is the best, as you can make out from the results. j4 and j8 both do worse. (I guess that's why make -j6 is accepted as a good stress test in the linux world). I have absolutely no issues with how the compile time scales with higher cpu (ie j-value) counts. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 1 10:14:23 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:14:14 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:23409 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:13:58 -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 LAA23458 for ; Thu, 1 Jun 2000 11:09:03 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA54731; Thu, 1 Jun 2000 11:13:36 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from localhost (tduffy@localhost) by dbear.engr.sgi.com (8.9.3/8.8.7) with ESMTP id LAA27969; Thu, 1 Jun 2000 11:11:32 -0700 Date: Thu, 1 Jun 2000 11:11:32 -0700 (PDT) From: Thomas Duffy To: Rajagopal Ananthanarayanan cc: Kanoj Sarcar , linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com Subject: Re: kernel compile time In-Reply-To: <39369F00.A9F2279A@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 Question: is this using -j4 MAKE="make -j4" so that it will spawn 4 proccesses for every subdir? I have found that doing this yeilds about 60 compile proccesses on average during the build. On Thu, 1 Jun 2000, Rajagopal Ananthanarayanan wrote: > Going to -j4, elapsed time went from 808sec -> 254sec (4:14) > which is a scaling of ~3.2 times ... if -j4 had had an > elapsed time of 202sec (3:22) then it would have been perfect > scaling. But add in the fact that -j4 vs. NO-J would introduce > additional complexity in the make itself, which now spawns > more processes, etc. ... this shows in the increased system time > for -j4; of course the extra system time also counts increased > lock contention. For this particular workload (primarily user-mode, > little-or-no-shared parallelism), -j4 did pretty good. > > Finally, -j6 & -j8 may not discover any extra parallelism > in the makes ... one gross way to check this is to watch "top" > and see how many "cc" processes are running on an average. > If it stays at 4, then -j4 is all that'll work. From owner-linux-origin@oss.sgi.com Thu Jun 1 10:15:43 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:15:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:48497 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:15:29 -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 LAA23604 for ; Thu, 1 Jun 2000 11:10:35 -0700 (PDT) mail_from (hawkes@cthulhu.engr.sgi.com) Received: from pchawkes (dhcp-163-154-5-206.engr.sgi.com [163.154.5.206]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA95281; Thu, 1 Jun 2000 11:15:07 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <021301bfcbf5$b3ac41e0$ce059aa3@engr.sgi.com> From: "John Hawkes" To: , "Rajagopal Ananthanarayanan" Cc: , References: <200006011748.KAA83240@google.engr.sgi.com> Subject: Re: kernel compile time Date: Thu, 1 Jun 2000 11:17:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > 13:28 seconds for a 1 way make is just not an acceptable number. But if that time is dominated by user time (vs. kernel time), doesn't that suggest that the slow compiles are due to a combination of (1) a compiler comprised of inefficiently emitted code, and/or (2) inefficient libraries, and/or (3) cache thrashing? John H. From owner-linux-origin@oss.sgi.com Thu Jun 1 10:21:03 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:20:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:7540 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:20:33 -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 LAA24445 for ; Thu, 1 Jun 2000 11:15:39 -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 LAA95967; Thu, 1 Jun 2000 11:20:12 -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 LAA01250; Thu, 1 Jun 2000 11:19:11 -0700 From: "Leo Dagum" Message-Id: <10006011119.ZM1248@barrel.engr.sgi.com> Date: Thu, 1 Jun 2000 11:19:10 -0700 In-Reply-To: kanoj@google (Kanoj Sarcar) "Re: kernel compile time" (Jun 1, 10:48am) References: <200006011748.KAA83240@google.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: kanoj@google.engr.sgi.com (Kanoj Sarcar), ananth@sgi.com (Rajagopal Ananthanarayanan) Subject: Re: kernel compile time Cc: linux-origin@oss.sgi.com, skunx@cthulhu.engr.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 Jun 1, 10:48am, Kanoj Sarcar wrote: > Subject: Re: kernel compile time > > > > Kanoj, earlier you had said the wall time looks bad. > > I don't understand. For the 1-way make, it took 13:28 == 808 seconds, > > of which 742sec were in user mode (> 90%) ... which is typical of > > large compilation workloads. > > 13:28 seconds for a 1 way make is just not an acceptable number. > Refer to John's recent mail about AIM7 performance too. > I think you guys may be neglecting the issue of the compiler itself. Does anyone have any idea how good (or bad) the optimized code generated by our mips-gnu compiler is? If it's not generating good optimized code, then all single cpu performance results are going to be lousy, be they AIM7 or running the compiler itself. - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Thu Jun 1 10:43:53 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:43:33 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17531 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:43:26 -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 LAA00399 for ; Thu, 1 Jun 2000 11:48: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 LAA88614 for ; Thu, 1 Jun 2000 11:42:55 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA87286; Thu, 1 Jun 2000 11:40:28 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011840.LAA87286@google.engr.sgi.com> Subject: Re: kernel compile time To: tduffy@dbear.engr.sgi.com (Thomas Duffy) Date: Thu, 1 Jun 2000 11:40:28 -0700 (PDT) Cc: ananth@sgi.com (Rajagopal Ananthanarayanan), linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com In-Reply-To: from "Thomas Duffy" at Jun 01, 2000 11:11:32 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 > > Question: is this using -j4 MAKE="make -j4" so that it will spawn 4 > proccesses for every subdir? I have found that doing this yeilds about > 60 compile proccesses on average during the build. > make -j4 ARCH=mips vmlinux. Kanoj > On Thu, 1 Jun 2000, Rajagopal Ananthanarayanan wrote: > > > Going to -j4, elapsed time went from 808sec -> 254sec (4:14) > > which is a scaling of ~3.2 times ... if -j4 had had an > > elapsed time of 202sec (3:22) then it would have been perfect > > scaling. But add in the fact that -j4 vs. NO-J would introduce > > additional complexity in the make itself, which now spawns > > more processes, etc. ... this shows in the increased system time > > for -j4; of course the extra system time also counts increased > > lock contention. For this particular workload (primarily user-mode, > > little-or-no-shared parallelism), -j4 did pretty good. > > > > Finally, -j6 & -j8 may not discover any extra parallelism > > in the makes ... one gross way to check this is to watch "top" > > and see how many "cc" processes are running on an average. > > If it stays at 4, then -j4 is all that'll work. > From owner-linux-origin@oss.sgi.com Thu Jun 1 10:45:54 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:45:34 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26235 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:45:29 -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 LAA00031 for ; Thu, 1 Jun 2000 11:50:17 -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 LAA86466 for ; Thu, 1 Jun 2000 11:44:59 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA84787; Thu, 1 Jun 2000 11:42:32 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011842.LAA84787@google.engr.sgi.com> Subject: Re: kernel compile time To: hawkes@cthulhu.engr.sgi.com (John Hawkes) Date: Thu, 1 Jun 2000 11:42:32 -0700 (PDT) Cc: kanoj@cthulhu.engr.sgi.com (Kanoj Sarcar), ananth@sgi.com (Rajagopal Ananthanarayanan), linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com In-Reply-To: <021301bfcbf5$b3ac41e0$ce059aa3@engr.sgi.com> from "John Hawkes" at Jun 01, 2000 11:17:52 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 > > > 13:28 seconds for a 1 way make is just not an acceptable number. > > But if that time is dominated by user time (vs. kernel time), doesn't > that suggest that the slow compiles are due to a combination of (1) a > compiler comprised of inefficiently emitted code, and/or (2) inefficient > libraries, and/or (3) cache thrashing? > > John H. > True. And the other culprit is probably all the locore code (like fast tlb handlers, inital syscall/intr/pagefault code) that executes before the timers are switched from user to kernel/system. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 1 10:48:04 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:47:54 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33915 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:47:36 -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 LAA04638 for ; Thu, 1 Jun 2000 11:52:24 -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 LAA88802 for ; Thu, 1 Jun 2000 11:47:05 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA86223; Thu, 1 Jun 2000 11:44:38 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011844.LAA86223@google.engr.sgi.com> Subject: Re: kernel compile time To: dagum@barrel.engr.sgi.com (Leo Dagum) Date: Thu, 1 Jun 2000 11:44:38 -0700 (PDT) Cc: ananth@sgi.com (Rajagopal Ananthanarayanan), linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com In-Reply-To: <10006011119.ZM1248@barrel.engr.sgi.com> from "Leo Dagum" at Jun 01, 2000 11:19:10 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 Jun 1, 10:48am, Kanoj Sarcar wrote: > > Subject: Re: kernel compile time > > > > > > Kanoj, earlier you had said the wall time looks bad. > > > I don't understand. For the 1-way make, it took 13:28 == 808 seconds, > > > of which 742sec were in user mode (> 90%) ... which is typical of > > > large compilation workloads. > > > > 13:28 seconds for a 1 way make is just not an acceptable number. > > Refer to John's recent mail about AIM7 performance too. > > > > I think you guys may be neglecting the issue of the compiler itself. > Does anyone have any idea how good (or bad) the optimized code generated by > our mips-gnu compiler is? If it's not generating good optimized > code, then all single cpu performance results are going to be lousy, > be they AIM7 or running the compiler itself. > > - leo > > > -- > Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) > Yes, you are right, we should probably think of this. Maybe its not that worthwhile thinking of single processor performance right now. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 1 10:52:03 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:51:53 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51204 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:51:36 -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 LAA29416 for ; Thu, 1 Jun 2000 11:46:42 -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 LAA84123 for ; Thu, 1 Jun 2000 11:49:50 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA91892; Thu, 1 Jun 2000 11:47:23 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006011847.LAA91892@google.engr.sgi.com> Subject: Re: more peeks at performance To: hawkes@cthulhu.engr.sgi.com (John Hawkes) Date: Thu, 1 Jun 2000 11:47:23 -0700 (PDT) Cc: linux-origin@oss.sgi.com (linux-origin), skunx@google.engr.sgi.com In-Reply-To: <006d01bfcbf0$17167300$ce059aa3@engr.sgi.com> from "John Hawkes" at Jun 01, 2000 10:37:42 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 > > FYI, I was playing around with AIM7 on Linux-Origin last week, trying to > diagnose why performance was so bad. I didn't get very far, yet. Even > when I stripped the AIM7 subtests down to a single compute-bound test, I > wasn't seeing 'top' report that process as compute-bound. > > A known standalone compute-bound program (i.e., a simple program that > just loops) does get seen by 'top' and 'vmstat' as compute-bound. > Multiple copies of that program do appear to property share the overall > available CPU cycles. > > But there's something about the AIM environment that isn't behaving > well. AIM uses forked children and pipes for parent-child > communication. Perhaps it's something in there. Or perhaps the > stripped-down AIM is just executing each subtest within the > display-refresh time. I need to play with it more. > > When I ran the same AIM7 workload that I typically run on an SMP i386 > Kayak -- a workload that runs compute-bound -- I see pretty awful > performance on Origin. On my i386 (two 266-MHz PentiumII) my AIM7 peaks > at about 50 jobs/minute and stays fairly flat until 80 or 90 or so (when > it begins to thrash). On a 2-200Mhz O200 I see a peak below *10* (at > half the performance of the i386) and a huge falloff from there. > Something is clearly wrong. > > John H. > John, I comnpiled a while(1) program, and ran it on a UP kernel, watching what top shows. Nearly 100% cpu time. 2 copies share 50% cpu time. Running and timing 2 copies over a wall time of 20 seconds yields user times of nearly 10 seconds for each. Experiments suggested by Ananth. Looking good. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 1 10:52:54 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 10:52:34 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:63236 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 10:52: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 LAA29484 for ; Thu, 1 Jun 2000 11:47:27 -0700 (PDT) mail_from (hawkes@cthulhu.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 LAA87982 for ; Thu, 1 Jun 2000 11:50:36 -0700 (PDT) Received: from pchawkes (dhcp-163-154-5-206.engr.sgi.com [163.154.5.206]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA29287; Thu, 1 Jun 2000 11:48:58 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <03ab01bfcbfa$6e5cc7e0$ce059aa3@engr.sgi.com> From: "John Hawkes" To: , "John Hawkes" Cc: "linux-origin" , References: <200006011847.LAA91892@google.engr.sgi.com> Subject: Re: more peeks at performance Date: Thu, 1 Jun 2000 11:51:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > I comnpiled a while(1) program, and ran it on a UP kernel, watching > what top shows. Nearly 100% cpu time. 2 copies share 50% cpu time. > Running and timing 2 copies over a wall time of 20 seconds yields > user times of nearly 10 seconds for each. Experiments suggested by > Ananth. > > Looking good. > > Kanoj I did that same thing on a 2-CPU O200 last week. Same results. John From owner-linux-origin@oss.sgi.com Thu Jun 1 11:28:14 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 11:28:04 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:52966 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 11:27:47 -0700 Received: from cacc-14.uni-koblenz.de (cacc-14.uni-koblenz.de [141.26.131.14]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id VAA06739; Thu, 1 Jun 2000 21:27:36 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 1 Jun 2000 21:27:19 +0200 Date: Thu, 1 Jun 2000 21:27:19 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: John Hawkes , Rajagopal Ananthanarayanan , linux-origin@oss.sgi.com, skunx@cthulhu.engr.sgi.com Subject: Re: kernel compile time Message-ID: <20000601212719.A24488@uni-koblenz.de> References: <021301bfcbf5$b3ac41e0$ce059aa3@engr.sgi.com> <200006011842.LAA84787@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006011842.LAA84787@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Jun 01, 2000 at 11:42:32AM -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, Jun 01, 2000 at 11:42:32AM -0700, Kanoj Sarcar wrote: > True. And the other culprit is probably all the locore code (like > fast tlb handlers, inital syscall/intr/pagefault code) that executes > before the timers are switched from user to kernel/system. Ulf's lmbench results for a UP Origin kernel are significantly below what I achieve on my R5000 Indy. That's suspicious. I don't think all of the difference can be explained by 32-bit vs. 64-bit code. Ralf From owner-linux-origin@oss.sgi.com Thu Jun 1 21:31:43 2000 Received: by oss.sgi.com id ; Thu, 1 Jun 2000 21:31:33 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:55109 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 1 Jun 2000 21:31:24 -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 VAA06054 for ; Thu, 1 Jun 2000 21:27: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 VAA03522 for ; Thu, 1 Jun 2000 21:31:36 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA48612 for linux-origin@oss.sgi.com; Thu, 1 Jun 2000 21:29:10 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006020429.VAA48612@google.engr.sgi.com> Subject: cpu enabling To: linux-origin@oss.sgi.com Date: Thu, 1 Jun 2000 21:29:10 -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 On my 8cpu, 4node machine, I can now disable arbitrary cpus, so that the kernel comes up with anywhere between 1 to 8 cpus. I haven't run a kernel compile in this configuration though. Neither have I tried disabling cpu A on nasid 0 (as a special case). I did shoot myself in the foot though by disabling node boards that were the only routes to the console port via the baseio board (prom appears to be a little stupid about this). I will have to pull boards around tomorrow to get the machine back up. Feel free to try enabling/disabling cpus (take care not to render your system unbootable though). Kanoj From owner-linux-origin@oss.sgi.com Fri Jun 2 09:53:47 2000 Received: by oss.sgi.com id ; Fri, 2 Jun 2000 09:53:37 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8808 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Jun 2000 09:53:20 -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 JAA09283 for ; Fri, 2 Jun 2000 09:58:51 -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 JAA47875; Fri, 2 Jun 2000 09:52:20 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200006021652.JAA47875@sprasad.engr.sgi.com> Subject: Re: cpu enabling To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Fri, 2 Jun 2000 09:52:20 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200006020429.VAA48612@google.engr.sgi.com> from "Kanoj Sarcar" at Jun 01, 2000 09:29:10 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 my 8cpu, 4node machine, I can now disable arbitrary cpus, so that > the kernel comes up with anywhere between 1 to 8 cpus. I haven't run > a kernel compile in this configuration though. Neither have I tried > disabling cpu A on nasid 0 (as a special case). > > I did shoot myself in the foot though by disabling node boards that > were the only routes to the console port via the baseio board (prom > appears to be a little stupid about this). I will have to pull boards The prom does try a lot to find the user a good console. But if the hw config is such that *no* node board can talk to a baseio it then fails. Probably your console turned up on a baseio that did not have the cable connected. The master cpu is selected based on the fact that it has a connection to a baseio. Every origin module is shipped with a baseio by default. So if all modules have a baseio intact and if either node board N1 or N3 is available and enabled, the console will be available on one of them. Conditions for no console are that all modules except 1 have baseio. N1 and N3 on this module are disabled etc. Thanks srinivasa > around tomorrow to get the machine back up. > > Feel free to try enabling/disabling cpus (take care not to render > your system unbootable though). > > Kanoj > From owner-linux-origin@oss.sgi.com Fri Jun 2 10:39:56 2000 Received: by oss.sgi.com id ; Fri, 2 Jun 2000 10:39:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:38175 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Jun 2000 10:39:33 -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 KAA24524 for ; Fri, 2 Jun 2000 10:35:22 -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 KAA25336 for ; Fri, 2 Jun 2000 10:39:45 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA40798; Fri, 2 Jun 2000 10:37:13 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006021737.KAA40798@google.engr.sgi.com> Subject: Re: cpu enabling To: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Date: Fri, 2 Jun 2000 10:37:13 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200006021652.JAA47875@sprasad.engr.sgi.com> from "Srinivasa Prasad Thirumalachar" at Jun 02, 2000 09:52:20 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 ... > > > > On my 8cpu, 4node machine, I can now disable arbitrary cpus, so that > > the kernel comes up with anywhere between 1 to 8 cpus. I haven't run > > a kernel compile in this configuration though. Neither have I tried > > disabling cpu A on nasid 0 (as a special case). > > > > I did shoot myself in the foot though by disabling node boards that > > were the only routes to the console port via the baseio board (prom > > appears to be a little stupid about this). I will have to pull boards > > The prom does try a lot to find the user a good console. But if the > hw config is such that *no* node board can talk to a baseio it > then fails. Probably your console turned up on a baseio that did > not have the cable connected. The master cpu is selected based on > the fact that it has a connection to a baseio. > > Every origin module is shipped with a baseio by default. So if > all modules have a baseio intact and if either node board N1 or > N3 is available and enabled, the console will be available on one of > them. I disabled all the 4 cpus on N1 and N3 (by mistake). So, is there no way N2 and N4 cpus can get to the console? I was under the assumption that any cpu could get to any device on the system. Of course, it does not make sense to build all this intelligence into the PROM, just to safeguard against rare administrator mistakes. Kanoj > > Conditions for no console are that all modules except 1 have baseio. > N1 and N3 on this module are disabled etc. > > Thanks > srinivasa > > > around tomorrow to get the machine back up. > > > > Feel free to try enabling/disabling cpus (take care not to render > > your system unbootable though). > > > > Kanoj > > > From owner-linux-origin@oss.sgi.com Fri Jun 2 12:05:17 2000 Received: by oss.sgi.com id ; Fri, 2 Jun 2000 12:04:58 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:21576 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 2 Jun 2000 12:04:52 -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 MAA11170 for ; Fri, 2 Jun 2000 12:00:41 -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 MAA48248; Fri, 2 Jun 2000 12:03:53 -0700 (PDT) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200006021903.MAA48248@sprasad.engr.sgi.com> Subject: Re: cpu enabling To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Fri, 2 Jun 2000 12:03:52 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <200006021737.KAA40798@google.engr.sgi.com> from "Kanoj Sarcar" at Jun 02, 2000 10:37:13 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 ... > > > > > Every origin module is shipped with a baseio by default. So if > > all modules have a baseio intact and if either node board N1 or > > N3 is available and enabled, the console will be available on one of > > them. > > I disabled all the 4 cpus on N1 and N3 (by mistake). So, is there no > way N2 and N4 cpus can get to the console? I was under the assumption No, N2 and N4 cannot get to the console if the baseio board is anywhere between slots io1 to io6. If it is in io7 to io12, then only N2 and N4 can talk to them. The PROM during boot, 'knows` that it will not have a console and wants to tell it to the user. But there is no console to tell it :-) I think it is too early to send a msg to the sys controller. There may be some LED patterns for this, but I am not sure. Also it will the LEDs on one of the node boards and you have to look at each node board for tell tale LED patterns :-( > that any cpu could get to any device on the system. Of course, it does > not make sense to build all this intelligence into the PROM, just to > safeguard against rare administrator mistakes. All this is part of the sys adm guide and notes. > > Kanoj > > > > > Conditions for no console are that all modules except 1 have baseio. > > N1 and N3 on this module are disabled etc. > > > > Thanks > > srinivasa > > > > > From owner-linux-origin@oss.sgi.com Tue Jun 6 15:58:55 2000 Received: by oss.sgi.com id ; Tue, 6 Jun 2000 15:58:36 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:48863 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 6 Jun 2000 15:58:24 -0700 Received: from cacc-30.uni-koblenz.de (cacc-30.uni-koblenz.de [141.26.131.30]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA14888; Wed, 7 Jun 2000 00:58:20 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 6 Jun 2000 17:14:00 +0200 Date: Tue, 6 Jun 2000 17:14:00 +0200 From: Ralf Baechle To: Cc: Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: networking changes Message-ID: <20000606171400.A31656@uni-koblenz.de> References: <200006010039.RAA19754@google.engr.sgi.com> <20000601024930.C20148@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000601024930.C20148@uni-koblenz.de>; from ralf@oss.sgi.com on Thu, Jun 01, 2000 at 02:49:30AM +0200 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, Jun 01, 2000 at 02:49:30AM +0200, Ralf Baechle wrote: > > FWIW, I tried ioc3-eth.c rev 1.16, and UP networking works with that. > > So does tot rev 1.18. I don't think Ralf (or anyone else) yet understands > > what the problem with UP networking is/was, but temporarily it seems > > to be getting masked. > > > > Just fyi, and please let me know if you observe the same behavior. > > I still have the UP networking problem on my machine. Update on this networking problem - seems I accidently commited the mdelay(10) kludge for ioc3_start_xmit into CVS which pasted over the bug for everybody but me. Ralf From owner-linux-origin@oss.sgi.com Wed Jun 7 15:50:03 2000 Received: by oss.sgi.com id ; Wed, 7 Jun 2000 15:49:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:50276 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 7 Jun 2000 15:25:22 -0700 Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA00846; Wed, 7 Jun 2000 15:19:56 -0700 (PDT) mail_from (nobody@info.engr.sgi.com) Received: (from nobody@localhost) by info.engr.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id PAA32033; Wed, 7 Jun 2000 15:24:44 -0700 (PDT) Date: Wed, 7 Jun 2000 15:24:44 -0700 (PDT) Message-Id: <200006072224.PAA32033@info.engr.sgi.com> X-Pv-Incident: 792097 webPV: www-proxy.engr.sgi.com webExec: webpvupdate,pvincident Reply-To: sgi.bugs.linux-origin@fido.engr.sgi.com From: pv@fddi-odin.corp.sgi.com (hawkes@engr.sgi.com) Subject: CLOSE 792097 - 'top', 'vmstat', 'ps' cputime all say zero To: hawkes@cthulhu.engr.sgi.com Cc: linux-origin@oss.sgi.com Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=792097 *Status : closed Priority : 2 Assigned Engineer : hawkes Submitter : hawkes Opened Date : 05/26/00 *Closed Date : 06/07/00 *Fixed By : hawkes *Fixed By Domain : engr *Modified Date : 06/07/00 *Modified User : hawkes *Modified User Domain : engr *Fix Description : ========================== ADDITIONAL INFORMATION (CLOSE) From: hawkes@engr (BugWorks) Date: Jun 07 2000 03:24:43PM ========================== Fixed type decl of __kernel_clock_t From owner-linux-origin@oss.sgi.com Wed Jun 7 15:50:03 2000 Received: by oss.sgi.com id ; Wed, 7 Jun 2000 15:49:43 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:7308 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 7 Jun 2000 15:15:02 -0700 Received: from cacc-26.uni-koblenz.de (cacc-26.uni-koblenz.de [141.26.131.26]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA15306; Thu, 8 Jun 2000 00:14:27 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 8 Jun 2000 00:13:59 +0200 Date: Thu, 8 Jun 2000 00:13:59 +0200 From: Ralf Baechle To: hawkes@engr.sgi.com Cc: linux-origin@oss.sgi.com Subject: halt bug fixed Message-ID: <20000608001359.B11515@uni-koblenz.de> References: <20000607220358Z42275-10984+26@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000607220358Z42275-10984+26@oss.sgi.com>; from ralf@oss.sgi.com on Wed, Jun 07, 2000 at 03:03:47PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing John, > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 00/06/07 15:03:47 > > Modified files: > arch/mips64/sgi-ip27: ip27-reset.c > > Log message: > Reboot was doing halt and halt was crashing the machine, fixed. this fixes the crash on halt bug for which you recently filed to bugworks. The support for powerdown (halt -p) is still not implemented. For me the PROM powerdown routine doesn't work and the code from IRIX is somewhat complex, it involves porting elsc.c and i2c.c from IRIX to Linux. I was hacking today but it's not yet complete. Ralf From owner-linux-origin@oss.sgi.com Thu Jun 8 11:18:45 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 11:18:35 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:46654 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 11:18:20 -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 LAA26632 for ; Thu, 8 Jun 2000 11:13:25 -0700 (PDT) mail_from (hawkes@cthulhu.engr.sgi.com) Received: from ppphawkeswa ([169.238.112.29]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA22508 for ; Thu, 8 Jun 2000 11:17:56 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <018301bfd176$51039a80$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "linux-origin" Subject: compiling an i386 kernel using the linux-mips64 CVS sources? Date: Thu, 8 Jun 2000 11:21:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Has anyone tried to compile an i386 kernel using the linux-mips64 CVS sources? I'm just starting that process now and am seeing a compile error in drivers/block/floppy.c. Are these sources *really* supposed to be 2.3.99-pre8? Maybe I should just download a clean copy of 2.3.99-pre8, if I can find it. My goal is to be able to do an apples-to-apples performance and behavioral comparison of an i386 kernel vs. a mips64 kernel. I don't want to waste time chasing 2.3.99-pre8 mips64 performance problems that are general 2.3.99-pre8 problems. John Hawkes From owner-linux-origin@oss.sgi.com Thu Jun 8 12:49:46 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 12:49:37 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40046 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 12:49:20 -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 MAA01737 for ; Thu, 8 Jun 2000 12:54:15 -0700 (PDT) mail_from (hawkes@cthulhu.engr.sgi.com) Received: from ppphawkeswa ([169.238.112.29]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id MAA61620 for ; Thu, 8 Jun 2000 12:48:51 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <02b101bfd182$fd6d0fc0$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "linux-origin" Subject: 2.3.99-pre8 performance on i386 sucks, too Date: Thu, 8 Jun 2000 12:51:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing The good news is that 2.3.99-pre8 AIM7 performance on i386 SMP is just as awful as mips64 SMP. Maybe even worse. My "modified AIM7" workload that previously on i386 (2.3.99-pre2) would run compute-bound (25% user, 75% system), now on 2.3.99-pre8 runs 95+% idle. And on one i386 run it even fails with a "Cannot allocate memory" error. I think the mips64 CVS tree needs to move forward to 2.4.something ASAP, as soon as someone can confirm that 2.4.something performs better than 2.3.99-pre8. John Hawkes From owner-linux-origin@oss.sgi.com Thu Jun 8 14:54:28 2000 Received: by oss.sgi.com id ; Thu, 8 Jun 2000 14:54:08 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:57243 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 8 Jun 2000 14:53:41 -0700 Received: from cacc-6.uni-koblenz.de (cacc-6.uni-koblenz.de [141.26.131.6]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA03136 for ; Thu, 8 Jun 2000 23:53:22 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 8 Jun 2000 23:51:45 +0200 Date: Thu, 8 Jun 2000 23:51:45 +0200 From: Ralf Baechle To: linux-origin Subject: Re: compiling an i386 kernel using the linux-mips64 CVS sources? Message-ID: <20000608235144.B18543@uni-koblenz.de> References: <018301bfd176$51039a80$1d70eea9@seattle.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <018301bfd176$51039a80$1d70eea9@seattle.sgi.com>; from hawkes@cthulhu.engr.sgi.com on Thu, Jun 08, 2000 at 11:21:06AM -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, Jun 08, 2000 at 11:21:06AM -0700, John Hawkes wrote: > Has anyone tried to compile an i386 kernel using the linux-mips64 CVS > sources? I'm just starting that process now and am seeing a compile > error in drivers/block/floppy.c. Are these sources *really* supposed to > be 2.3.99-pre8? Maybe I should just download a clean copy of > 2.3.99-pre8, if I can find it. My goal is to be able to do an > apples-to-apples performance and behavioral comparison of an i386 kernel > vs. a mips64 kernel. I don't want to waste time chasing 2.3.99-pre8 > mips64 performance problems that are general 2.3.99-pre8 problems. The floppy driver problem are the portability changes which we need for various MIPS systems. Ralf From owner-linux-origin@oss.sgi.com Fri Jun 9 08:51:32 2000 Received: by oss.sgi.com id ; Fri, 9 Jun 2000 08:51:22 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37951 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Jun 2000 08:51:11 -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 IAA01595; Fri, 9 Jun 2000 08:56:07 -0700 (PDT) mail_from (hawkes@cthulhu.engr.sgi.com) Received: from ppphawkeswa ([169.238.112.29]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id IAA15612; Fri, 9 Jun 2000 08:50:47 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <002301bfd22a$504f58e0$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "Ralf Baechle" , "linux-origin" References: <018301bfd176$51039a80$1d70eea9@seattle.sgi.com> <20000608235144.B18543@uni-koblenz.de> Subject: Re: compiling an i386 kernel using the linux-mips64 CVS sources? Date: Fri, 9 Jun 2000 08:49:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > The floppy driver problem are the portability changes which we need > for various MIPS systems. The workaround was simple (include/asm-i386/floppy.h) and that was the only build problem (other than having to change the ARCH=mips in the highest level Makefile). John From owner-linux-origin@oss.sgi.com Fri Jun 9 15:38:16 2000 Received: by oss.sgi.com id ; Fri, 9 Jun 2000 15:38:06 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:19578 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 9 Jun 2000 15:37:46 -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 PAA08190 for ; Fri, 9 Jun 2000 15:42:42 -0700 (PDT) mail_from (hawkes@cthulhu.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 PAA22737 for ; Fri, 9 Jun 2000 15:37:15 -0700 (PDT) Received: from ppphawkeswa ([169.238.112.29]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA20527; Fri, 9 Jun 2000 15:35:34 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <000f01bfd262$a90888c0$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "linux-origin" Cc: Subject: Mips64-O200 vs. ia32-Kayak Date: Fri, 9 Jun 2000 15:32:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Okay, so I've determined that my lousy AIM performance was my fault, not a Linux problem -- I was using a set of subtests that include some that saturate a single disk spindle. (I was using this fuller set of subtests on a 4-Xeon system with a nicely striped/RAID filesystem, and things ran compute-bound on that platform.) So when I remove the non-computebound subtests from my mix, I see that 2.3.99pre8 behaves reasonably. My HP Kayak with 2-266MHz PentiumII (512KB cache) executes only 30% faster than penguin3.engr, a 2-180MHz R10000, despite having a core clock speed almost 50% faster. (The O200 has 128MB, the Kayak has 64MB, but neither system was swapping, so memory isn't an issue at this load level.) This particular mix of AIM subtests executes about 70% user, 30% system, plus or minus 10%, on both systems. See penguin3:/var/tmp/s7110/workfile for the specific subtest mix. I believe we're ready to try this same test suite on an Origin and a Xeon with more CPUs (and more main memory) and begin to examine the CPU scaling curves. I have some 4-Xeon CPU scaling numbers in my files somewhere, but those numbers were generated using an older kernel version. My recollection is that the Xeon system I was using (dozin? I forget) shows less-than-perfect scaling for a near-100% user-time benchmark load (i.e., a 4-Xeon system performed only 3.8x better than 1-Xeon system, vs. an ideal 4.0x scaling), which I attributed to the 4-Xeon configuration beginning to saturate the memory bus. (You first need to determine how a system scales using autonomous user-time compute-bound loads, not the 70%/30% user/system loads, because you want to keep kernel lock and I/O contention out of the picture.) John Hawkes From owner-linux-origin@oss.sgi.com Thu Jun 15 10:07:10 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:07:00 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:18139 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:06:46 -0700 Received: from cacc-3.uni-koblenz.de (cacc-3.uni-koblenz.de [141.26.131.3]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id TAA17449 for ; Thu, 15 Jun 2000 19:06:43 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 15 Jun 2000 16:14:26 +0200 Date: Thu, 15 Jun 2000 16:14:26 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: tarball Message-ID: <20000615161426.A1876@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 Could somebody create a reasonably small tarball of a Linux installation for an Origin 2000 and put it on oss? I've been contacted by one of the guys at the University of Waterloo, Canada and think that's what they'll need to get started. Ralf From owner-linux-origin@oss.sgi.com Thu Jun 15 10:12:09 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:11:59 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:1644 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:11:42 -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 KAA00137; Thu, 15 Jun 2000 10:16:45 -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 KAA73320; Thu, 15 Jun 2000 10:10:41 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006151710.KAA73320@google.engr.sgi.com> Subject: Re: tarball To: ralf@oss.sgi.com (Ralf Baechle) Date: Thu, 15 Jun 2000 10:10:41 -0700 (PDT) Cc: linux-origin@oss.sgi.com, tduffy@google.engr.sgi.com In-Reply-To: <20000615161426.A1876@bacchus.dhis.org> from "Ralf Baechle" at Jun 15, 2000 04:14:26 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 > > Could somebody create a reasonably small tarball of a Linux installation > for an Origin 2000 and put it on oss? I've been contacted by one of > the guys at the University of Waterloo, Canada and think that's what > they'll need to get started. > > Ralf > Tom Duffy is working on this stuff, although for now we will probably put it on an internal machine, then on oss once we are a little more confident with it. It will probably take a while. Worst comes to worst, we can always ship them a disk that they can clone. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 15 10:15:00 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:14:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:6003 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:14:25 -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 KAA04724; Thu, 15 Jun 2000 10:09:27 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA73229; Thu, 15 Jun 2000 10:13:58 -0700 (PDT) mail_from (tduffy@dbear.engr.sgi.com) Received: from localhost (tduffy@localhost) by dbear.engr.sgi.com (8.9.3/8.8.7) with ESMTP id KAA11477; Thu, 15 Jun 2000 10:13:57 -0700 Date: Thu, 15 Jun 2000 10:13:56 -0700 (PDT) From: Thomas Duffy To: Ralf Baechle cc: linux-origin@oss.sgi.com Subject: Re: tarball In-Reply-To: <20000615161426.A1876@bacchus.dhis.org> 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 am in the process of trying to put together an installation script for the o2000 but I could also throw a tarball up there as well. -tduffy On Thu, 15 Jun 2000, Ralf Baechle wrote: > Could somebody create a reasonably small tarball of a Linux installation > for an Origin 2000 and put it on oss? I've been contacted by one of > the guys at the University of Waterloo, Canada and think that's what > they'll need to get started. > > Ralf > From owner-linux-origin@oss.sgi.com Thu Jun 15 10:30:00 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:29:40 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:35807 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:29:32 -0700 Received: from cacc-3.uni-koblenz.de (cacc-3.uni-koblenz.de [141.26.131.3]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id TAA19298 for ; Thu, 15 Jun 2000 19:29:28 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 15 Jun 2000 19:29:06 +0200 Date: Thu, 15 Jun 2000 19:29:06 +0200 From: Ralf Baechle To: Thomas Duffy Cc: linux-origin@oss.sgi.com Subject: Re: tarball Message-ID: <20000615192906.A2932@bacchus.dhis.org> References: <20000615161426.A1876@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from tduffy@dbear.engr.sgi.com on Thu, Jun 15, 2000 at 10:13:56AM -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, Jun 15, 2000 at 10:13:56AM -0700, Thomas Duffy wrote: > I am in the process of trying to put together an installation script for > the o2000 but I could also throw a tarball up there as well. For the moment a minimal tarball is probably good enough to get them started. Ralf From owner-linux-origin@oss.sgi.com Thu Jun 15 10:42:40 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 10:42:30 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:44549 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 10:42:11 -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 KAA08630; Thu, 15 Jun 2000 10:37:14 -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 KAA63756; Thu, 15 Jun 2000 10:40:25 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA15101; Thu, 15 Jun 2000 10:38:09 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006151738.KAA15101@google.engr.sgi.com> Subject: Re: tarball To: ralf@oss.sgi.com (Ralf Baechle) Date: Thu, 15 Jun 2000 10:38:09 -0700 (PDT) Cc: tduffy@dbear.engr.sgi.com (Thomas Duffy), linux-origin@oss.sgi.com In-Reply-To: <20000615192906.A2932@bacchus.dhis.org> from "Ralf Baechle" at Jun 15, 2000 07:29:06 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 Thu, Jun 15, 2000 at 10:13:56AM -0700, Thomas Duffy wrote: > > > I am in the process of trying to put together an installation script for > > the o2000 but I could also throw a tarball up there as well. > > For the moment a minimal tarball is probably good enough to get them > started. > > Ralf > Okay, I will try to get this done. I will probably _not_ put it on oss though, just somewhere the Waterloo guys can ftp out of. Ralf, send me a contact email, I will probably have to babysit their network install also. I will keep you and Tom in the loop. Kanoj From owner-linux-origin@oss.sgi.com Thu Jun 15 14:35:53 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 14:35:43 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:64127 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 14:35:23 -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 OAA13088 for ; Thu, 15 Jun 2000 14:30:26 -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 OAA04557 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 15 Jun 2000 14:34: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 OAA16226 for linux-origin@oss.sgi.com; Thu, 15 Jun 2000 14:34:57 -0700 Date: Thu, 15 Jun 2000 14:34:57 -0700 From: dagum@barrel.engr.sgi.com (Leo Dagum) Message-Id: <200006152134.OAA16226@barrel.engr.sgi.com> To: linux-origin@oss.sgi.com Subject: hubbard (o2k) available Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Folks, I have to shamefully admit I'd been keeping an o2k to myself for development, but now I feel compelled to share it with the linux-origin world. So available for your use is hubbard, an 8p origin2000. You can get the console through slab-annex1 ports 5021 for serial console and 5058 for msc. There's an ext-2 disk in /dev/sdb2 (or dksc0d2s0 in irix-speak). This system will probably go away in the not too distant future so make use of it if you can. Cheers, - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Thu Jun 15 16:15:35 2000 Received: by oss.sgi.com id ; Thu, 15 Jun 2000 16:15:26 -0700 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:10899 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Thu, 15 Jun 2000 16:15:01 -0700 Received: from cacc-15.uni-koblenz.de (cacc-15.uni-koblenz.de [141.26.131.15]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA09020 for ; Fri, 16 Jun 2000 01:14:55 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 16 Jun 2000 01:14:39 +0200 Date: Fri, 16 Jun 2000 01:14:39 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: Thomas Duffy , linux-origin@oss.sgi.com Subject: Re: tarball Message-ID: <20000616011439.A32251@bacchus.dhis.org> References: <20000615192906.A2932@bacchus.dhis.org> <200006151738.KAA15101@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006151738.KAA15101@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Jun 15, 2000 at 10:38:09AM -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, Jun 15, 2000 at 10:38:09AM -0700, Kanoj Sarcar wrote: > > > I am in the process of trying to put together an installation script for > > > the o2000 but I could also throw a tarball up there as well. > > > > For the moment a minimal tarball is probably good enough to get them > > started. > > Okay, I will try to get this done. I will probably _not_ put it on > oss though, just somewhere the Waterloo guys can ftp out of. Ralf, send > me a contact email, I will probably have to babysit their network > install also. I will keep you and Tom in the loop. The guy's email address is "Robyn Landers [MFCF]" . We haven't yet discussed too many details about the Linux installation, first they need something to install ... I also think they should probably subscribe to this list which should be ok with our policy? Ralf From owner-linux-origin@oss.sgi.com Mon Jun 19 13:44:16 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 13:44:06 -0700 Received: from [62.180.18.37] ([62.180.18.37]:7684 "EHLO lappi") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 13:43:52 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 19 Jun 2000 18:53:38 +0200 Date: Mon, 19 Jun 2000 18:53:38 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Qlogicfc driver Message-ID: <20000619185338.A8852@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 Currently we've got below patch for the qlogicfc driver in the CVS. Could whoever is responsible for this drivers either - submit it to the maintainer - tell me that this patch is ok to submit to Linus Thanks, Ralf diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.c linux-sgi/drivers/scsi/qlogicfc.c --- linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.c Mon Jun 19 03:13:49 2000 +++ linux-sgi/drivers/scsi/qlogicfc.c Mon Jun 19 15:40:18 2000 @@ -72,12 +72,21 @@ #define pci64_map_sg(d,s,n,dir) pci_map_sg((d),(s),(n),(dir)) #define pci64_unmap_single(d,a,s,dir) pci_unmap_single((d),(a),(s),(dir)) #define pci64_unmap_sg(d,s,n,dir) pci_unmap_sg((d),(s),(n),(dir)) +#if BITS_PER_LONG > 32 +#define pci64_dma_hi32(a) ((u32) (0xffffffff & (a>>32))) +#define pci64_dma_lo32(a) ((u32) (0xffffffff & (a))) +#else #define pci64_dma_hi32(a) 0 #define pci64_dma_lo32(a) (a) +#endif /* BITS_PER_LONG */ #define pci64_dma_build(hi,lo) (lo) #define sg_dma64_address(s) sg_dma_address(s) #define sg_dma64_len(s) sg_dma_len(s) +#if BITS_PER_LONG > 32 +#define PCI64_DMA_BITS 64 +#else #define PCI64_DMA_BITS 32 +#endif /* BITS_PER_LONG */ #endif #include "qlogicfc.h" @@ -101,15 +110,12 @@ #define ISP2x00_FABRIC 1 /* Macros used for debugging */ -/* -#define DEBUG_ISP2x00 1 -#define DEBUG_ISP2x00_INT 1 -#define DEBUG_ISP2x00_INTR 1 -#define DEBUG_ISP2x00_SETUP 1 - -#define DEBUG_ISP2x00_FABRIC 1 -*/ -/* #define TRACE_ISP 1 */ +#define DEBUG_ISP2x00 0 +#define DEBUG_ISP2x00_INT 0 +#define DEBUG_ISP2x00_INTR 0 +#define DEBUG_ISP2x00_SETUP 0 +#define DEBUG_ISP2x00_FABRIC 0 +#define TRACE_ISP 0 #define DEFAULT_LOOP_COUNT 1000000000 @@ -1233,7 +1239,7 @@ for (i = in_ptr; i != (in_ptr - 1) && hostdata->handle_ptrs[i]; i = ((i + 1) % (QLOGICFC_REQ_QUEUE_LEN + 1))); if (!hostdata->handle_ptrs[i]) { - cmd->handle = i; + cmd->handle = cpu_to_le32(i); hostdata->handle_ptrs[i] = Cmnd; hostdata->handle_serials[i] = Cmnd->serial_number; } else { @@ -1358,6 +1364,13 @@ break; } } + /* + * TEST_UNIT_READY commands from scsi_scan will fail due to "overlapped + * commands attempted" unless we setup at least a simple queue (midlayer + * will embelish this once it can do an INQUIRY command to the device) + */ + else + cmd->control_flags |= cpu_to_le16(CFLAG_SIMPLE_TAG); outw(in_ptr, host->io_port + MBOX4); hostdata->req_in_ptr = in_ptr; @@ -1541,12 +1554,14 @@ DEBUG_INTR(printk("qlogicfc%d : response queue depth %d\n", hostdata->host_id, RES_QUEUE_DEPTH(in_ptr, out_ptr))); while (out_ptr != in_ptr) { + unsigned le_hand; sts = (struct Status_Entry *) &hostdata->res[out_ptr*QUEUE_ENTRY_LEN]; out_ptr = (out_ptr + 1) & RES_QUEUE_LEN; TRACE("done", out_ptr, Cmnd); DEBUG_INTR(isp2x00_print_status_entry(sts)); - if (sts->hdr.entry_type == ENTRY_STATUS && (Cmnd = hostdata->handle_ptrs[sts->handle])) { + le_hand = le32_to_cpu(sts->handle); + if (sts->hdr.entry_type == ENTRY_STATUS && (Cmnd = hostdata->handle_ptrs[le_hand])) { Cmnd->result = isp2x00_return_status(Cmnd, sts); hostdata->queued--; @@ -1565,10 +1580,10 @@ * we dont have to call done because the upper * level should already know its aborted. */ - if (hostdata->handle_serials[sts->handle] != Cmnd->serial_number + if (hostdata->handle_serials[le_hand] != Cmnd->serial_number || le16_to_cpu(sts->completion_status) == CS_ABORTED){ - hostdata->handle_serials[sts->handle] = 0; - hostdata->handle_ptrs[sts->handle] = NULL; + hostdata->handle_serials[le_hand] = 0; + hostdata->handle_ptrs[le_hand] = NULL; outw(out_ptr, host->io_port + MBOX5); continue; } @@ -1589,7 +1604,7 @@ continue; } - hostdata->handle_ptrs[sts->handle] = NULL; + hostdata->handle_ptrs[le_hand] = NULL; if (sts->completion_status == cpu_to_le16(CS_RESET_OCCURRED) || (sts->status_flags & cpu_to_le16(STF_BUS_RESET))) @@ -1912,23 +1927,14 @@ } #endif -#ifdef __BIG_ENDIAN - { - u64 val; - memcpy(&val, &hostdata->control_block.node_name, sizeof(u64)); - hostdata->wwn = ((val & 0xff00ff00ff00ff00ULL) >> 8) - | ((val & 0x00ff00ff00ff00ffULL) << 8); - } -#else - hostdata->wwn = (u64) (hostdata->control_block.node_name[0]) << 56; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[0] & 0xff00) << 48; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[1] & 0xff00) << 24; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[1] & 0x00ff) << 48; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[2] & 0x00ff) << 24; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[2] & 0xff00) << 8; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[3] & 0x00ff) << 8; - hostdata->wwn |= (u64) (hostdata->control_block.node_name[3] & 0xff00) >> 8; -#endif + hostdata->wwn = (u64) (cpu_to_le16(hostdata->control_block.node_name[0])) << 56; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[0]) & 0xff00) << 48; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[1]) & 0xff00) << 24; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[1]) & 0x00ff) << 48; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[2]) & 0x00ff) << 24; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[2]) & 0xff00) << 8; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[3]) & 0x00ff) << 8; + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[3]) & 0xff00) >> 8; /* FIXME: If the DMA transfer goes one way only, this should use PCI_DMA_TODEVICE and below as well. */ busaddr = pci64_map_single(hostdata->pci_dev, &hostdata->control_block, sizeof(hostdata->control_block), diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.h linux-sgi/drivers/scsi/qlogicfc.h --- linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.h Wed Feb 23 22:37:35 2000 +++ linux-sgi/drivers/scsi/qlogicfc.h Fri Mar 31 03:50:09 2000 @@ -62,7 +62,7 @@ * determined for each queue request anew. */ -#if PCI64_DMA_BITS > 32 +#if BITS_PER_LONG > 32 #define DATASEGS_PER_COMMAND 2 #define DATASEGS_PER_CONT 5 #else From owner-linux-origin@oss.sgi.com Mon Jun 19 13:51:26 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 13:51:16 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:39284 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 13:51: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 NAA25318 for ; Mon, 19 Jun 2000 13:46:18 -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 NAA46122; Mon, 19 Jun 2000 13:50:16 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006192050.NAA46122@google.engr.sgi.com> Subject: Re: Qlogicfc driver To: ralf@uni-koblenz.de (Ralf Baechle) Date: Mon, 19 Jun 2000 13:50:16 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000619185338.A8852@bacchus.dhis.org> from "Ralf Baechle" at Jun 19, 2000 06:53:38 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 Qlogicfc was probably update by Leo (dagum). Kanoj From owner-linux-origin@oss.sgi.com Mon Jun 19 14:17:26 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 14:17:07 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:32779 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 14:16:36 -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 OAA00104 for ; Mon, 19 Jun 2000 14:11:40 -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 OAA09946; Mon, 19 Jun 2000 14:16:06 -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 OAA24369; Mon, 19 Jun 2000 14:15:30 -0700 From: "Leo Dagum" Message-Id: <10006191415.ZM24367@barrel.engr.sgi.com> Date: Mon, 19 Jun 2000 14:15:29 -0700 In-Reply-To: Ralf Baechle "Qlogicfc driver" (Jun 19, 6:53pm) References: <20000619185338.A8852@bacchus.dhis.org> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ralf Baechle , linux-origin@oss.sgi.com Subject: Re: Qlogicfc driver 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 Jun 19, 6:53pm, Ralf Baechle wrote: > Subject: Qlogicfc driver > Currently we've got below patch for the qlogicfc driver in the CVS. > Could whoever is responsible for this drivers either > > - submit it to the maintainer > - tell me that this patch is ok to submit to Linus Yes, please submit it to Linus. I tried a couple times but got ignored. Without this patch qlogicfc simply will not work (on *any* machine, not just mips64.) Thanks, - leo > > Thanks, > > Ralf > > diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.c linux-sgi/drivers/scsi/qlogicfc.c > --- linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.c Mon Jun 19 03:13:49 2000 > +++ linux-sgi/drivers/scsi/qlogicfc.c Mon Jun 19 15:40:18 2000 > @@ -72,12 +72,21 @@ > #define pci64_map_sg(d,s,n,dir) pci_map_sg((d),(s),(n),(dir)) > #define pci64_unmap_single(d,a,s,dir) pci_unmap_single((d),(a),(s),(dir)) > #define pci64_unmap_sg(d,s,n,dir) pci_unmap_sg((d),(s),(n),(dir)) > +#if BITS_PER_LONG > 32 > +#define pci64_dma_hi32(a) ((u32) (0xffffffff & (a>>32))) > +#define pci64_dma_lo32(a) ((u32) (0xffffffff & (a))) > +#else > #define pci64_dma_hi32(a) 0 > #define pci64_dma_lo32(a) (a) > +#endif /* BITS_PER_LONG */ > #define pci64_dma_build(hi,lo) (lo) > #define sg_dma64_address(s) sg_dma_address(s) > #define sg_dma64_len(s) sg_dma_len(s) > +#if BITS_PER_LONG > 32 > +#define PCI64_DMA_BITS 64 > +#else > #define PCI64_DMA_BITS 32 > +#endif /* BITS_PER_LONG */ > #endif > > #include "qlogicfc.h" > @@ -101,15 +110,12 @@ > #define ISP2x00_FABRIC 1 > > /* Macros used for debugging */ > -/* > -#define DEBUG_ISP2x00 1 > -#define DEBUG_ISP2x00_INT 1 > -#define DEBUG_ISP2x00_INTR 1 > -#define DEBUG_ISP2x00_SETUP 1 > - > -#define DEBUG_ISP2x00_FABRIC 1 > -*/ > -/* #define TRACE_ISP 1 */ > +#define DEBUG_ISP2x00 0 > +#define DEBUG_ISP2x00_INT 0 > +#define DEBUG_ISP2x00_INTR 0 > +#define DEBUG_ISP2x00_SETUP 0 > +#define DEBUG_ISP2x00_FABRIC 0 > +#define TRACE_ISP 0 > > > #define DEFAULT_LOOP_COUNT 1000000000 > @@ -1233,7 +1239,7 @@ > for (i = in_ptr; i != (in_ptr - 1) && hostdata->handle_ptrs[i]; i = ((i + 1) % (QLOGICFC_REQ_QUEUE_LEN + 1))); > > if (!hostdata->handle_ptrs[i]) { > - cmd->handle = i; > + cmd->handle = cpu_to_le32(i); > hostdata->handle_ptrs[i] = Cmnd; > hostdata->handle_serials[i] = Cmnd->serial_number; > } else { > @@ -1358,6 +1364,13 @@ > break; > } > } > + /* > + * TEST_UNIT_READY commands from scsi_scan will fail due to "overlapped > + * commands attempted" unless we setup at least a simple queue (midlayer > + * will embelish this once it can do an INQUIRY command to the device) > + */ > + else > + cmd->control_flags |= cpu_to_le16(CFLAG_SIMPLE_TAG); > outw(in_ptr, host->io_port + MBOX4); > hostdata->req_in_ptr = in_ptr; > > @@ -1541,12 +1554,14 @@ > DEBUG_INTR(printk("qlogicfc%d : response queue depth %d\n", hostdata->host_id, RES_QUEUE_DEPTH(in_ptr, out_ptr))); > > while (out_ptr != in_ptr) { > + unsigned le_hand; > sts = (struct Status_Entry *) &hostdata->res[out_ptr*QUEUE_ENTRY_LEN]; > out_ptr = (out_ptr + 1) & RES_QUEUE_LEN; > > TRACE("done", out_ptr, Cmnd); > DEBUG_INTR(isp2x00_print_status_entry(sts)); > - if (sts->hdr.entry_type == ENTRY_STATUS && (Cmnd = hostdata->handle_ptrs[sts->handle])) { > + le_hand = le32_to_cpu(sts->handle); > + if (sts->hdr.entry_type == ENTRY_STATUS && (Cmnd = hostdata->handle_ptrs[le_hand])) { > Cmnd->result = isp2x00_return_status(Cmnd, sts); > hostdata->queued--; > > @@ -1565,10 +1580,10 @@ > * we dont have to call done because the upper > * level should already know its aborted. > */ > - if (hostdata->handle_serials[sts->handle] != Cmnd->serial_number > + if (hostdata->handle_serials[le_hand] != Cmnd->serial_number > || le16_to_cpu(sts->completion_status) == CS_ABORTED){ > - hostdata->handle_serials[sts->handle] = 0; > - hostdata->handle_ptrs[sts->handle] = NULL; > + hostdata->handle_serials[le_hand] = 0; > + hostdata->handle_ptrs[le_hand] = NULL; > outw(out_ptr, host->io_port + MBOX5); > continue; > } > @@ -1589,7 +1604,7 @@ > continue; > } > > - hostdata->handle_ptrs[sts->handle] = NULL; > + hostdata->handle_ptrs[le_hand] = NULL; > > if (sts->completion_status == cpu_to_le16(CS_RESET_OCCURRED) > || (sts->status_flags & cpu_to_le16(STF_BUS_RESET))) > @@ -1912,23 +1927,14 @@ > } > #endif > > -#ifdef __BIG_ENDIAN > - { > - u64 val; > - memcpy(&val, &hostdata->control_block.node_name, sizeof(u64)); > - hostdata->wwn = ((val & 0xff00ff00ff00ff00ULL) >> 8) > - | ((val & 0x00ff00ff00ff00ffULL) << 8); > - } > -#else > - hostdata->wwn = (u64) (hostdata->control_block.node_name[0]) << 56; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[0] & 0xff00) << 48; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[1] & 0xff00) << 24; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[1] & 0x00ff) << 48; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[2] & 0x00ff) << 24; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[2] & 0xff00) << 8; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[3] & 0x00ff) << 8; > - hostdata->wwn |= (u64) (hostdata->control_block.node_name[3] & 0xff00) >> 8; > -#endif > + hostdata->wwn = (u64) (cpu_to_le16(hostdata->control_block.node_name[0])) << 56; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[0]) & 0xff00) << 48; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[1]) & 0xff00) << 24; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[1]) & 0x00ff) << 48; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[2]) & 0x00ff) << 24; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[2]) & 0xff00) << 8; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[3]) & 0x00ff) << 8; > + hostdata->wwn |= (u64) (cpu_to_le16(hostdata->control_block.node_name[3]) & 0xff00) >> 8; > > /* FIXME: If the DMA transfer goes one way only, this should use PCI_DMA_TODEVICE and below as well. */ > busaddr = pci64_map_single(hostdata->pci_dev, &hostdata->control_block, sizeof(hostdata->control_block), > diff -urN --exclude=CVS --exclude=.cvsignore linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.h linux-sgi/drivers/scsi/qlogicfc.h > --- linux-2.4.0-test1-ac21/drivers/scsi/qlogicfc.h Wed Feb 23 22:37:35 2000 > +++ linux-sgi/drivers/scsi/qlogicfc.h Fri Mar 31 03:50:09 2000 > @@ -62,7 +62,7 @@ > * determined for each queue request anew. > */ > > -#if PCI64_DMA_BITS > 32 > +#if BITS_PER_LONG > 32 > #define DATASEGS_PER_COMMAND 2 > #define DATASEGS_PER_CONT 5 > #else >-- End of excerpt from Ralf Baechle -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Mon Jun 19 14:53:57 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 14:53:37 -0700 Received: from [62.180.18.37] ([62.180.18.37]:13572 "EHLO lappi") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 14:53:12 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 19 Jun 2000 23:52:38 +0200 Date: Mon, 19 Jun 2000 23:52:38 +0200 From: Ralf Baechle To: Leo Dagum Cc: linux-origin@oss.sgi.com Subject: Re: Qlogicfc driver Message-ID: <20000619235238.A27454@bacchus.dhis.org> References: <20000619185338.A8852@bacchus.dhis.org> <10006191415.ZM24367@barrel.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <10006191415.ZM24367@barrel.engr.sgi.com>; from dagum@barrel.engr.sgi.com on Mon, Jun 19, 2000 at 02:15:29PM -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, Jun 19, 2000 at 02:15:29PM -0700, Leo Dagum wrote: > On Jun 19, 6:53pm, Ralf Baechle wrote: > > Subject: Qlogicfc driver > > Currently we've got below patch for the qlogicfc driver in the CVS. > > Could whoever is responsible for this drivers either > > > > - submit it to the maintainer > > - tell me that this patch is ok to submit to Linus > > Yes, please submit it to Linus. I tried a couple times but got > ignored. Without this patch qlogicfc simply will not work (on > *any* machine, not just mips64.) Ok, will do. Btw, Alan just dumped my whole bundle of over 20 patches into the bit bucket. He is merging with Linus who apparently returned from his Finland trip. Once that is finished I'll make another run at completly merging with him. Most of the interfaces which we need for a clean merge of the MIPS kernel with him do now exist. The only thing which I'm missing is a revers mapping for translating physical to virtual addresses which is of interest for virtual aliases of R4000-style caches. Ralf From owner-linux-origin@oss.sgi.com Mon Jun 19 16:42:16 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 16:42:06 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:14705 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 16:41:42 -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 QAA29956; Mon, 19 Jun 2000 16:36:46 -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 QAA49318; Mon, 19 Jun 2000 16:40:44 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006192340.QAA49318@google.engr.sgi.com> Subject: Re: Qlogicfc driver To: ralf@oss.sgi.com (Ralf Baechle) Date: Mon, 19 Jun 2000 16:40:44 -0700 (PDT) Cc: dagum@barrel.engr.sgi.com (Leo Dagum), linux-origin@oss.sgi.com In-Reply-To: <20000619235238.A27454@bacchus.dhis.org> from "Ralf Baechle" at Jun 19, 2000 11:52:38 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 > > Btw, Alan just dumped my whole bundle of over 20 patches into the bit bucket. > He is merging with Linus who apparently returned from his Finland trip. > Once that is finished I'll make another run at completly merging with him. > Most of the interfaces which we need for a clean merge of the MIPS kernel > with him do now exist. The only thing which I'm missing is a revers mapping > for translating physical to virtual addresses which is of interest for > virtual aliases of R4000-style caches. > > Ralf > Ralf, Why are you trying to merge up with Alan? Let Linus and Alan sort out their patch sets. Once that's done, lets just get into Linus' tree, and Alan will pick that up. I would much rather see the oss mips64 tree in sync with Linus' tree, than Alan's tree (I don't have an opinion about the mips tree though). Kanoj From owner-linux-origin@oss.sgi.com Mon Jun 19 16:45:57 2000 Received: by oss.sgi.com id ; Mon, 19 Jun 2000 16:45:47 -0700 Received: from [62.180.18.37] ([62.180.18.37]:27396 "EHLO lappi") by oss.sgi.com with ESMTP id ; Mon, 19 Jun 2000 16:45:33 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 20 Jun 2000 01:45:20 +0200 Date: Tue, 20 Jun 2000 01:45:20 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: Leo Dagum , linux-origin@oss.sgi.com Subject: Re: Qlogicfc driver Message-ID: <20000620014520.A28629@bacchus.dhis.org> References: <20000619235238.A27454@bacchus.dhis.org> <200006192340.QAA49318@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006192340.QAA49318@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Mon, Jun 19, 2000 at 04:40:44PM -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, Jun 19, 2000 at 04:40:44PM -0700, Kanoj Sarcar wrote: > Why are you trying to merge up with Alan? Let Linus and Alan sort out > their patch sets. Once that's done, lets just get into Linus' tree, and > Alan will pick that up. I would much rather see the oss mips64 tree in > sync with Linus' tree, than Alan's tree (I don't have an opinion about > the mips tree though). Alan is the other way to get things to Linus and he tends to be somewhat less lossy and move responsive than Linus. Ralf From owner-linux-origin@oss.sgi.com Tue Jun 20 09:53:46 2000 Received: by oss.sgi.com id ; Tue, 20 Jun 2000 09:53:37 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:24866 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 20 Jun 2000 09:53:28 -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 JAA06941; Tue, 20 Jun 2000 09:48:32 -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 JAA42460; Tue, 20 Jun 2000 09:51:44 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id JAA65939; Tue, 20 Jun 2000 09:49:32 -0700 (PDT) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200006201649.JAA65939@google.engr.sgi.com> Subject: Re: CVS Update@oss.sgi.com: linux To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 20 Jun 2000 09:49:32 -0700 (PDT) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000620154457Z42328-29270+86@oss.sgi.com> from "Ralf Baechle" at Jun 20, 2000 08:44:53 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 > > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 00/06/20 08:44:53 > > Modified files: > arch/mips64/kernel: linux32.c scall_o32.S > drivers/char : Makefile > include/asm-mips: stat.h > include/asm-mips64: stat.h > > Log message: > Fix struct stat64 in the 32-bit kernel and struct stat in the 64-bit > kernel to match each other and the the glibc definition. The glibc > part of this change has been sent to Andreas. > Will the top of trunk kernel still work with whatever libraries we are using for the mips64 port? If not, do you have a pointer to the new glibc that should be used with the kernel? Kanoj From owner-linux-origin@oss.sgi.com Tue Jun 20 12:33:49 2000 Received: by oss.sgi.com id ; Tue, 20 Jun 2000 12:33:39 -0700 Received: from u-204.karlsruhe.ipdial.viaginterkom.de ([62.180.10.204]:17157 "EHLO u-204.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 20 Jun 2000 12:33:16 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 20 Jun 2000 21:32:43 +0200 Date: Tue, 20 Jun 2000 21:32:43 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20000620213243.A6716@bacchus.dhis.org> References: <20000620154457Z42328-29270+86@oss.sgi.com> <200006201649.JAA65939@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006201649.JAA65939@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Tue, Jun 20, 2000 at 09:49:32AM -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, Jun 20, 2000 at 09:49:32AM -0700, Kanoj Sarcar wrote: > > Log message: > > Fix struct stat64 in the 32-bit kernel and struct stat in the 64-bit > > kernel to match each other and the the glibc definition. The glibc > > part of this change has been sent to Andreas. > > Will the top of trunk kernel still work with whatever libraries we > are using for the mips64 port? If not, do you have a pointer to the > new glibc that should be used with the kernel? This patch won't break anything because we didn't have native 64-bit software nor were stat64 & Co. ever usable on the 32-bit kernel. Ralf From owner-linux-origin@oss.sgi.com Wed Jun 21 09:40:06 2000 Received: by oss.sgi.com id ; Wed, 21 Jun 2000 09:39:56 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:58900 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 21 Jun 2000 09:39:43 -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 JAA07143 for ; Wed, 21 Jun 2000 09:34:46 -0700 (PDT) mail_from (hawkes@cthulhu.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 JAA73388 for ; Wed, 21 Jun 2000 09:39:13 -0700 (PDT) Received: from ppphawkeswa ([169.238.112.29]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id JAA30443; Wed, 21 Jun 2000 09:37:26 -0700 (PDT) mail_from (hawkes@engr.sgi.com) Message-ID: <003601bfdb9f$192373a0$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: , "linux-origin" Cc: "Nancy Bigham" , "Simon Patience" Subject: I'm on sabbatical and I'm moving Date: Wed, 21 Jun 2000 09:38:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I'm officially on a 3-week sabbatical, as of today. And since I'm moving my household, too, that means I'm really going to be incommunicado starting sometime this weekend and lasting for a few weeks. I might be accessible, from time to time, through jrhawkes@yahoo.com , but I can't guarantee how frequently I'll check that mailbox. I don't have access through the SGI firewall from the outside to be able to check my SGI mail. I would otherwise be using a "vacation" message, but I haven't wanted to do this because it would spam several mailing lists that I'm on, including some that include non-SGI people who care even less that I'm on sabbatical. John Hawkes From owner-linux-origin@oss.sgi.com Sun Jun 25 03:14:07 2000 Received: by oss.sgi.com id ; Sun, 25 Jun 2000 03:13:57 -0700 Received: from Cantor.suse.de ([194.112.123.193]:17933 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sun, 25 Jun 2000 03:13:35 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 06EE91E079; Sun, 25 Jun 2000 12:13:04 +0200 (MEST) Received: from arthur.inka.de (Galois.suse.de [10.0.0.1]) by Hermes.suse.de (Postfix) with ESMTP id 2FCE210A05F; Sun, 25 Jun 2000 12:13:03 +0200 (MEST) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 1369Oq-0001a6-00; Sun, 25 Jun 2000 12:12:24 +0200 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 877C91821; Sun, 25 Jun 2000 12:12:23 +0200 (CEST) To: ralf@oss.sgi.com (Ralf Baechle), linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux References: <200006201649.JAA65939@google.engr.sgi.com> From: Andreas Jaeger Date: 25 Jun 2000 12:12:23 +0200 In-Reply-To: kanoj@google.engr.sgi.com's message of "Tue, 20 Jun 2000 09:49:32 -0700 (PDT)" Message-ID: Lines: 41 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) 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 > > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 00/06/20 08:44:53 > > Modified files: > arch/mips64/kernel: linux32.c scall_o32.S > drivers/char : Makefile > include/asm-mips: stat.h > include/asm-mips64: stat.h > > Log message: > Fix struct stat64 in the 32-bit kernel and struct stat in the 64-bit > kernel to match each other and the the glibc definition. The glibc > part of this change has been sent to Andreas. > Ralf, this change is wrong (as also pointed out by Maciej). You removed the following fields from struct stat64: char st_fstype[16]; /* Filesystem type name */ long st_pad4[8]; /* Linux specific fields */ unsigned int st_flags; unsigned int st_gen; But if we compile user level programs with -D_FILE_OFFSET_BITS=64, struct stat is renamed to struct stat64 - making st_fstype, st_flags and st_gen mandatory for struct stat64. Could you please either add st_fstype, st_flags and st_gen to struct stat64 - or remove them from both structures? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de From owner-linux-origin@oss.sgi.com Sun Jun 25 08:48:58 2000 Received: by oss.sgi.com id ; Sun, 25 Jun 2000 08:48:49 -0700 Received: from u-202.karlsruhe.ipdial.viaginterkom.de ([62.180.10.202]:5380 "EHLO u-202.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Sun, 25 Jun 2000 08:48:19 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sun, 25 Jun 2000 17:47:20 +0200 Date: Sun, 25 Jun 2000 17:47:20 +0200 From: Ralf Baechle To: Andreas Jaeger Cc: "Maciej W. Rozycki" , linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20000625174719.B893@bacchus.dhis.org> References: <200006201649.JAA65939@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 aj@suse.de on Sun, Jun 25, 2000 at 12:12:23PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Sun, Jun 25, 2000 at 12:12:23PM +0200, Andreas Jaeger wrote: > this change is wrong (as also pointed out by Maciej). You removed the > following fields from struct stat64: > > char st_fstype[16]; /* Filesystem type name */ > long st_pad4[8]; > /* Linux specific fields */ > unsigned int st_flags; > unsigned int st_gen; > > But if we compile user level programs with -D_FILE_OFFSET_BITS=64, > struct stat is renamed to struct stat64 - making st_fstype, st_flags > and st_gen mandatory for struct stat64. > > Could you please either add st_fstype, st_flags and st_gen to struct > stat64 - or remove them from both structures? Do you know of any users for those fields? I don't and we don't even properly initialize them, so I'd prefer to remove them - before some autoconf scripts detects and and uses them. My prefered solution would be to remove those fields, too. Ralf From owner-linux-origin@oss.sgi.com Sun Jun 25 11:49:29 2000 Received: by oss.sgi.com id ; Sun, 25 Jun 2000 11:49:19 -0700 Received: from Cantor.suse.de ([194.112.123.193]:60427 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Sun, 25 Jun 2000 11:48:59 -0700 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 308B31E0F0; Sun, 25 Jun 2000 20:48:28 +0200 (MEST) Received: from arthur.inka.de (Galois.suse.de [10.0.0.1]) by Hermes.suse.de (Postfix) with ESMTP id 8453310A106; Sun, 25 Jun 2000 20:48:26 +0200 (MEST) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 136HMb-0002Xe-00; Sun, 25 Jun 2000 20:42:37 +0200 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 123611821; Sun, 25 Jun 2000 20:42:35 +0200 (CEST) To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux References: <200006201649.JAA65939@google.engr.sgi.com> <20000625174719.B893@bacchus.dhis.org> From: Andreas Jaeger Date: 25 Jun 2000 20:42:35 +0200 In-Reply-To: Ralf Baechle's message of "Sun, 25 Jun 2000 17:47:20 +0200" Message-ID: Lines: 49 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) 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 >>>>> Ralf Baechle writes: Ralf> On Sun, Jun 25, 2000 at 12:12:23PM +0200, Andreas Jaeger wrote: >> this change is wrong (as also pointed out by Maciej). You removed the >> following fields from struct stat64: >> >> char st_fstype[16]; /* Filesystem type name */ >> long st_pad4[8]; >> /* Linux specific fields */ >> unsigned int st_flags; >> unsigned int st_gen; >> >> But if we compile user level programs with -D_FILE_OFFSET_BITS=64, >> struct stat is renamed to struct stat64 - making st_fstype, st_flags >> and st_gen mandatory for struct stat64. >> >> Could you please either add st_fstype, st_flags and st_gen to struct >> stat64 - or remove them from both structures? Ralf> Do you know of any users for those fields? I don't and we don't even Ralf> properly initialize them, so I'd prefer to remove them - before some Ralf> autoconf scripts detects and and uses them. My prefered solution would Ralf> be to remove those fields, too. Maciej commented in a separate mail on this as: Maciej> Hmm, st_fstype is set in arch/mips/kernel/sysirix.c and Maciej> arch/sparc64/solaris/fs.c. I'm not sure what it might be useful for, Maciej> though. Maybe some broken Irix or Solaris programs refuse to work under Maciej> emulation when there is no st_fstype set to an appropriate string. OK, Maciej> both the i386 ABI and the MIPS one (I don't have any other ABIs) define it Maciej> so better leave it intact. Maciej> Maciej> There is no single reference in the 2.4.0-test1 kernel for either Maciej> st_flags or st_gen beside headers (I suppose they should be removed to Maciej> preserve memory). Therefore I vote for removal or at least renaming to Maciej> something like __unused?. Why are they in glibc 2.1.90 anyway, especially Maciej> as they are not defined in glibc 2.1.3? The comment about being Maciej> Linux-specific is confusing, too. I agree with him - we can remove st_flags and st_gen without problems. We need to check st_fstype. In all cases should the size of struct stat not change (struct stat64 might shrink, but not struct stat). Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de From owner-linux-origin@oss.sgi.com Mon Jun 26 09:27:37 2000 Received: by oss.sgi.com id ; Mon, 26 Jun 2000 09:27:27 -0700 Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32909 "EHLO delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id ; Mon, 26 Jun 2000 09:27:13 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA17062; Mon, 26 Jun 2000 18:26:22 +0200 (MET DST) Date: Mon, 26 Jun 2000 18:26:22 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: Andreas Jaeger , linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20000625174719.B893@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk 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 Sun, 25 Jun 2000, Ralf Baechle wrote: > Do you know of any users for those fields? I don't and we don't even > properly initialize them, so I'd prefer to remove them - before some > autoconf scripts detects and and uses them. My prefered solution would > be to remove those fields, too. Hmm, I just noticed GNU tar uses st_fstype whenever available to check for nfs filesystems. Ralf, we still need to change kernel's struct stat64. If we want it be the same as mips64's struct stat, given the port's immaturity it might still be the right time to change the latter one. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-origin@oss.sgi.com Fri Jun 30 21:45:18 2000 Received: by oss.sgi.com id ; Fri, 30 Jun 2000 21:44:58 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48425 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 30 Jun 2000 21:44:29 -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 VAA07060 for ; Fri, 30 Jun 2000 21:49:59 -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 VAA82132 for ; Fri, 30 Jun 2000 21:44:00 -0700 (PDT) mail_from (ulfc@calypso.engr.sgi.com) Received: by calypso.engr.sgi.com (Postfix, from userid 37984) id 2C76BA7875; Fri, 30 Jun 2000 21:42:58 -0700 (PDT) From: Ulf Carlsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14685.30418.120988.639450@calypso.engr.sgi.com> Date: Fri, 30 Jun 2000 21:42:58 -0700 (PDT) To: ananth@calypso.engr.sgi.com Cc: linux-origin@oss.sgi.com Subject: ksymoops 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 Ananth, It should be possible to get call traces with ksymoops now. I have checked in another small patch that truncates the sign extended 32-bit addresses in the call trace so that ksymoops will understand them. I linked ksymoops against a BFD compiled for MIPS on dbear. The location is /usr/local/bin/mips-linux-ksymoops (it is actually just a wrapper around the real thing). You need the oops message itself and the System.map. mips-linux-ksymoops /path/to/system.map < oops-message Ulf