From owner-linux-origin@oss.sgi.com Wed Mar 1 14:36:10 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 14:36:00 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:24714 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 14:35:54 -0800 Received: from cacc-8.uni-koblenz.de (cacc-8.uni-koblenz.de [141.26.131.8]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA15699 for ; Wed, 1 Mar 2000 23:35:51 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 1 Mar 2000 23:35:20 +0100 Date: Wed, 1 Mar 2000 23:35:20 +0100 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: The hidden secrets ... Message-ID: <20000301233520.A4663@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Thought somebody of you might also have a use for this patch. It's my hack that makes printk() over the serial interface usable from immediately after kernel entry even before console_init(). It's a dirty hack, so I don't want to see this going into CVS. Enjoy, Ralf Index: kernel/printk.c =================================================================== RCS file: /usr/src/cvs/linux/kernel/printk.c,v retrieving revision 1.25 diff -u -r1.25 printk.c --- printk.c 1999/10/07 16:20:50 1.25 +++ printk.c 2000/01/17 20:47:49 @@ -304,6 +304,11 @@ c = c->next; } } +#if 1 + /* HACK: Enable printing during early bootup */ + if (!console_drivers) + prom_printf(msg); +#endif if (line_feed) msg_level = -1; } Index: arch/mips64/arc/console.c =================================================================== RCS file: /usr/src/cvs/linux/arch/mips64/arc/console.c,v retrieving revision 1.3 diff -u -r1.3 console.c --- console.c 1999/10/19 20:51:44 1.3 +++ console.c 2000/01/13 16:34:25 @@ -11,12 +11,32 @@ #include #include +#include +#include +#include +#include + +static void inline ip27_putchar(char c) +{ + struct ioc3 *ioc3; + struct ioc3_uartregs *uart; + nasid_t nid; + + nid = get_nasid(); + ioc3 = (struct ioc3 *) KL_CONFIG_CH_CONS_INFO(nid)->memory_base; + uart = &ioc3->sregs.uarta; + + while ((uart->iu_lsr & 0x20) == 0); + uart->iu_thr = c; +} + void __init prom_putchar(char c) { ULONG cnt; CHAR it = c; - ArcWrite(1, &it, 1, &cnt); + //ArcWrite(1, &it, 1, &cnt); + ip27_putchar(c); } char __init prom_getchar(void) From owner-linux-origin@oss.sgi.com Wed Mar 1 14:58:10 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 14:58:00 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:23955 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 14:57:48 -0800 Received: from cacc-8.uni-koblenz.de (cacc-8.uni-koblenz.de [141.26.131.8]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA17713; Wed, 1 Mar 2000 23:57:42 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Wed, 1 Mar 2000 23:57:21 +0100 Date: Wed, 1 Mar 2000 23:57:21 +0100 From: Ralf Baechle To: Ulf Carlsson , Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: My sys32_execve(). Message-ID: <20000301235720.A4434@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing As per our phone conference from yesterday, this is my variant of sys32_execve which compiles and works fine. It's very similar to the Sparc64 code, just derived from more recent code than it. Ralf /* 4011 execve */ /* * count() counts the number of arguments/envelopes * * We must use access_ok() and __get_user(), not get_user() or gcc 1.1.2 * will die with an internal error. */ static int count32(u32 *argv, int max) { int i = 0; if (argv != NULL) { for (;;) { int error; u32 p; if (!access_ok(VERIFY_READ, argv, sizeof(*argv))) return -EFAULT; error = __get_user(p, argv); if (error) return error; if (!p) break; argv++; if (++i > max) return -E2BIG; } } return i; } /* * 'copy_strings()' copies argument/envelope strings from user * memory to free pages in kernel mem. These are in a format ready * to be put directly into the top of new user memory. */ int copy_strings32(int argc, u32 * argv, struct linux_binprm *bprm) { while (argc-- > 0) { s32 str; int len; unsigned long pos; if (get_user(str, argv+argc) || !str || !(len = strnlen_user((char *)(long)str, bprm->p))) return -EFAULT; if (bprm->p < len) return -E2BIG; bprm->p -= len; pos = bprm->p; while (len>0) { char *pag; int offset, bytes_to_copy; offset = pos % PAGE_SIZE; if (!(pag = (char *) bprm->page[pos/PAGE_SIZE]) && !(pag = (char *) bprm->page[pos/PAGE_SIZE] = (unsigned long *) get_free_page(GFP_USER))) return -ENOMEM; bytes_to_copy = PAGE_SIZE - offset; if (bytes_to_copy > len) bytes_to_copy = len; if (copy_from_user(pag + offset, str, bytes_to_copy)) return -EFAULT; pos += bytes_to_copy; str += bytes_to_copy; len -= bytes_to_copy; } } return 0; } /* * sys_execve() executes a new program. */ static int do_execve32(char * filename, u32 *argv, u32 *envp, struct pt_regs *regs) { struct linux_binprm bprm; struct dentry * dentry; int retval; int i; bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *); memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0])); dentry = open_namei(filename, 0, 0); retval = PTR_ERR(dentry); if (IS_ERR(dentry)) return retval; bprm.dentry = dentry; bprm.filename = filename; bprm.sh_bang = 0; bprm.loader = 0; bprm.exec = 0; if ((bprm.argc = count32(argv, bprm.p / sizeof(void *))) < 0) { dput(dentry); return bprm.argc; } if ((bprm.envc = count32(envp, bprm.p / sizeof(void *))) < 0) { dput(dentry); return bprm.envc; } retval = prepare_binprm(&bprm); if (retval < 0) goto out; retval = copy_strings_kernel(1, &bprm.filename, &bprm); if (retval < 0) goto out; bprm.exec = bprm.p; retval = copy_strings32(bprm.envc, envp, &bprm); if (retval < 0) goto out; retval = copy_strings32(bprm.argc, argv, &bprm); if (retval < 0) goto out; retval = search_binary_handler(&bprm,regs); if (retval >= 0) /* execve success */ return retval; out: /* Something went wrong, return the inode and free the argument pages*/ if (bprm.dentry) dput(bprm.dentry); /* Assumes that free_page() can take a NULL argument. */ /* I hope this is ok for all architectures */ for (i=0 ; i; Wed, 1 Mar 2000 15:02:51 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20277 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 15:02:48 -0800 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 PAA01750; Wed, 1 Mar 2000 15:05:56 -0800 (PST) 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 PAA25878; Wed, 1 Mar 2000 15:06:37 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003012306.PAA25878@google.engr.sgi.com> Subject: Re: My sys32_execve(). To: ralf@oss.sgi.com (Ralf Baechle) Date: Wed, 1 Mar 2000 15:06:37 -0800 (PST) Cc: ulfc@cthulhu.engr.sgi.com (Ulf Carlsson), kanoj@cthulhu.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com In-Reply-To: <20000301235720.A4434@uni-koblenz.de> from "Ralf Baechle" at Mar 01, 2000 11:57:21 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 Umm, didn't I just check this in a couple of days back? Look at sys32_execve() in arch/mips64/kernel/linux32.c. Its a variant of the ia64 ia32-support code. Kanoj From owner-linux-origin@oss.sgi.com Wed Mar 1 15:20:21 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 15:20:11 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:56733 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 15:19:48 -0800 Received: from cacc-8.uni-koblenz.de (cacc-8.uni-koblenz.de [141.26.131.8]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA20326; Thu, 2 Mar 2000 00:19:43 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 2 Mar 2000 00:19:22 +0100 Date: Thu, 2 Mar 2000 00:19:22 +0100 From: Ralf Baechle To: Kanoj Sarcar Cc: Ralf Baechle , Ulf Carlsson , Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: My sys32_execve(). Message-ID: <20000302001922.A4992@uni-koblenz.de> References: <20000301235720.A4434@uni-koblenz.de> <200003012306.PAA25878@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003012306.PAA25878@google.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Mar 01, 2000 at 03:06:37PM -0800, Kanoj Sarcar wrote: > Umm, didn't I just check this in a couple of days back? Not unless you are better at hacking than the NSA because this code has never reached a machine connected to the net :-) The similarity is natural, I just sent this for your interest because of yesterday's phone discussion about the egcs bug and workaround. Ralf From owner-linux-origin@oss.sgi.com Wed Mar 1 15:30:51 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 15:30:41 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:46092 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 15:30:26 -0800 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 PAA15072; Wed, 1 Mar 2000 15:25:52 -0800 (PST) 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 PAA75414; Wed, 1 Mar 2000 15:34:15 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003012334.PAA75414@google.engr.sgi.com> Subject: Re: My sys32_execve(). To: ralf@oss.sgi.com (Ralf Baechle) Date: Wed, 1 Mar 2000 15:34:15 -0800 (PST) Cc: ralf@oss.sgi.com (Ralf Baechle), ulfc@cthulhu.engr.sgi.com (Ulf Carlsson), kanoj@cthulhu.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com In-Reply-To: <20000302001922.A4992@uni-koblenz.de> from "Ralf Baechle" at Mar 02, 2000 12:19:22 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 Wed, Mar 01, 2000 at 03:06:37PM -0800, Kanoj Sarcar wrote: > > > Umm, didn't I just check this in a couple of days back? > > Not unless you are better at hacking than the NSA because this code has > never reached a machine connected to the net :-) No no, I meant a version of sys32_execve, not the exact code that you sent. Actually, if you look at the checked in version of sys32_execve, it is quite different from the sparc version (_much_ less code). Seeing that there are probably more people working on the ia32 compatibility issues for ia64, I have decided I am going to look at how they have converted a system call first, then look at the sparc implementation, and decide which one I want to pick. While we are at it, maybe its time we came up with rules for determining which system calls need to be 32bitized. Other things like TASK_SIZE also probably need to be 32bitized (similar to TASK_UNMAPPED_BASE). Kanoj > > The similarity is natural, I just sent this for your interest because of > yesterday's phone discussion about the egcs bug and workaround. > > Ralf > From owner-linux-origin@oss.sgi.com Wed Mar 1 16:21:51 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 16:21:42 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:58033 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 16:21:40 -0800 Received: from cacc-8.uni-koblenz.de (cacc-8.uni-koblenz.de [141.26.131.8]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA23615; Thu, 2 Mar 2000 01:21:36 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 2 Mar 2000 01:21:15 +0100 Date: Thu, 2 Mar 2000 01:21:15 +0100 From: Ralf Baechle To: Kanoj Sarcar Cc: Ralf Baechle , Ulf Carlsson , Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: My sys32_execve(). Message-ID: <20000302012115.A5607@uni-koblenz.de> References: <20000302001922.A4992@uni-koblenz.de> <200003012334.PAA75414@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003012334.PAA75414@google.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Mar 01, 2000 at 03:34:15PM -0800, Kanoj Sarcar wrote: > While we are at it, maybe its time we came up with rules for > determining which system calls need to be 32bitized. Other things > like TASK_SIZE also probably need to be 32bitized (similar to > TASK_UNMAPPED_BASE). The rules that I've been using is ``shit in, shit out'', that is I never try to catch arguments that aren't valid for 32-bit syscalls like passing addresses that aren't valid in a 32-bit world. That means that many system calls don't need wrappers. TASK_SIZE is the size of a native, that is 64-bit process in our case. We only need to consider the size of a 32-bit process for TASK_UNMAPPED_BASE which we do already. Ralf From owner-linux-origin@oss.sgi.com Wed Mar 1 16:28:11 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 16:28:02 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49468 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 16:27:54 -0800 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 QAA03970; Wed, 1 Mar 2000 16:31:02 -0800 (PST) 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 QAA54655; Wed, 1 Mar 2000 16:31:44 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003020031.QAA54655@google.engr.sgi.com> Subject: Re: My sys32_execve(). To: ralf@oss.sgi.com (Ralf Baechle) Date: Wed, 1 Mar 2000 16:31:43 -0800 (PST) Cc: ralf@oss.sgi.com (Ralf Baechle), ulfc@cthulhu.engr.sgi.com (Ulf Carlsson), kanoj@cthulhu.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com In-Reply-To: <20000302012115.A5607@uni-koblenz.de> from "Ralf Baechle" at Mar 02, 2000 01:21:15 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 > TASK_SIZE is the size of a native, that is 64-bit process in our case. > We only need to consider the size of a 32-bit process for > TASK_UNMAPPED_BASE which we do already. > > Ralf > We are probably ages away from when TASK_SIZE will be a problem, but get_unmapped_area() will return success for 32 bit programs when it really should not, in certain cases. Tweaking TASK_UNMAPPED_BASE itself is not enough. I think the Sparc guys take care of this, in their HAVE_ARCH_UNMAPPED_AREA get_unmapped_area() declaration. We do not need such a heavyweight solution though, certainly not soon. Kanoj From owner-linux-origin@oss.sgi.com Wed Mar 1 16:34:31 2000 Received: by oss.sgi.com id ; Wed, 1 Mar 2000 16:34:21 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:38838 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Wed, 1 Mar 2000 16:34:10 -0800 Received: from cacc-8.uni-koblenz.de (cacc-8.uni-koblenz.de [141.26.131.8]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA24725; Thu, 2 Mar 2000 01:34:06 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Thu, 2 Mar 2000 01:33:43 +0100 Date: Thu, 2 Mar 2000 01:33:43 +0100 From: Ralf Baechle To: Kanoj Sarcar Cc: Ralf Baechle , Ulf Carlsson , Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: My sys32_execve(). Message-ID: <20000302013343.B5607@uni-koblenz.de> References: <20000302012115.A5607@uni-koblenz.de> <200003020031.QAA54655@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003020031.QAA54655@google.engr.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Mar 01, 2000 at 04:31:43PM -0800, Kanoj Sarcar wrote: > We are probably ages away from when TASK_SIZE will be a problem, > but get_unmapped_area() will return success for 32 bit programs > when it really should not, in certain cases. Tweaking TASK_UNMAPPED_BASE > itself is not enough. > > I think the Sparc guys take care of this, in their HAVE_ARCH_UNMAPPED_AREA > get_unmapped_area() declaration. We do not need such a heavyweight > solution though, certainly not soon. On MIPS we also want our private get_unmapped_area, even though for other reasons that don't apply to the R10000. We want it because carefully placing of mappings in the virtual address space is part of a virtual coherence avoidance solution. Ralf From owner-linux-origin@oss.sgi.com Mon Mar 6 11:36:08 2000 Received: by oss.sgi.com id ; Mon, 6 Mar 2000 11:35:58 -0800 Received: from animaniacs.conectiva.com.br ([200.250.58.146]:38905 "EHLO lappi") by oss.sgi.com with ESMTP id ; Mon, 6 Mar 2000 11:35:42 -0800 Received: by lappi.waldorf-gmbh.de id ; Mon, 6 Mar 2000 16:35:36 -0300 Date: Mon, 6 Mar 2000 16:35:36 -0300 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Penguin machines Message-ID: <20000306163536.A2492@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Hi, could anybody tell me where again which are the tftp/bootp servers for the Origin 200 test machines in Mountain View that I have to place my test kernels on? Thanks, Ralf From owner-linux-origin@oss.sgi.com Mon Mar 6 11:42:49 2000 Received: by oss.sgi.com id ; Mon, 6 Mar 2000 11:42:39 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:32333 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 6 Mar 2000 11:42:37 -0800 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 LAA09857; Mon, 6 Mar 2000 11:45:51 -0800 (PST) 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 LAA75104; Mon, 6 Mar 2000 11:42:21 -0800 (PST) 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 LAA22144; Mon, 6 Mar 2000 11:41:43 -0800 From: "Leo Dagum" Message-Id: <10003061141.ZM22142@barrel.engr.sgi.com> Date: Mon, 6 Mar 2000 11:41:43 -0800 In-Reply-To: Ralf Baechle "Penguin machines" (Mar 6, 4:35pm) References: <20000306163536.A2492@uni-koblenz.de> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Ralf Baechle , linux-origin@oss.sgi.com Subject: Re: Penguin machines 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 Mar 6, 4:35pm, Ralf Baechle wrote: > Subject: Penguin machines > Hi, > > could anybody tell me where again which are the tftp/bootp servers > for the Origin 200 test machines in Mountain View that I have to > place my test kernels on? > Ulf has set up annie.engr as an nfs root server for penguin[2-4]. Root passwd for it is 'linux1'. You'll see penguin* subdirs under /tftpboot. The config expects the kernel to be called 'vmlinux.64', put your kernel in the appropriate subdir. If you want to bootp just a kernel and use the local disk, I've been using sqlcon.engr as a bootp server. No root passwd. Just create a ralf subdir in /usr/local/boot. - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Wed Mar 8 12:02:32 2000 Received: by oss.sgi.com id ; Wed, 8 Mar 2000 12:02:22 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54839 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 8 Mar 2000 12:02:13 -0800 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 MAA03476; Wed, 8 Mar 2000 12:05:29 -0800 (PST) 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 MAA76701; Wed, 8 Mar 2000 12:01:55 -0800 (PST) mail_from (hawkes@engr.sgi.com) Message-ID: <001f01bf8939$567f7cc0$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "Ralf Baechle" , "Ulf Carlsson" , "Leo Dagum" , "Kanoj Sarcar" Cc: Subject: Linux/MIPS64/O2000 Date: Wed, 8 Mar 2000 12:03:12 -0800 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 Simon has asked me to try to get my hands around the Linux-MIPS64-on-O2000 (or is it O200?) project to understand its status. The premise is that early Linux experience with the SN architecture translates to a faster bringup of Linux-IA64-SN1 and the hope of a real headstart on exploiting the architectural capabilities of SN1 and SN2. It is my understanding that each of you has been involved in various aspects of Linux-MIPS64-O2000. I understand that up to now, the project has been viewed by Engineering as a low-priority, almost off-the-books effort, but I believe that view is changing, at least from the view of higher management. I would appreciate greatly if each of you would give me a brief summary of what you've been doing, personally and as a project, and where the current roadblocks are. Simon is especially interested in having a visible list of bugworks PV bugs. And yes, I do understand that some of the roadblocks are in the compilers. We need to clarify exactly what the problems are before we can motivate that part of the Engineering organization to fix them. As far as which bugworks project to use, it seems to me that it's easiest to use sgi.bugs.linux-mips64, rather than create a new project like sgi.bugs.o2000-linux or sgi.bugs.origin-linux. What do you think? Yes, some of the bugs (or feature enhancements, or PV "issues") are platform-specific and some are MIPS64-specific, but I think it complicates matters to have multiple bugworks projects. Let's start a dialog here. Thanks! John Hawkes From owner-linux-origin@oss.sgi.com Wed Mar 8 12:24:21 2000 Received: by oss.sgi.com id ; Wed, 8 Mar 2000 12:24:12 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:56121 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 8 Mar 2000 12:24:01 -0800 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 MAA03950; Wed, 8 Mar 2000 12:27:17 -0800 (PST) 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 MAA28889; Wed, 8 Mar 2000 12:21:34 -0800 (PST) From: sprasad@sprasad.engr.sgi.com (Srinivasa Prasad Thirumalachar) Message-Id: <200003082021.MAA28889@sprasad.engr.sgi.com> Subject: Re: Linux/MIPS64/O2000 To: hawkes@cthulhu.engr.sgi.com (John Hawkes) Date: Wed, 8 Mar 2000 12:21:33 -0800 (PST) Cc: ralf@oss.sgi.com (Ralf Baechle), ulfc@cthulhu.engr.sgi.com (Ulf Carlsson), dagum@cthulhu.engr.sgi.com (Leo Dagum), kanoj@cthulhu.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com In-Reply-To: <001f01bf8939$567f7cc0$1d70eea9@seattle.sgi.com> from "John Hawkes" at Mar 08, 2000 12:03:12 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 John Hawkes ... > > Simon has asked me to try to get my hands around the > Linux-MIPS64-on-O2000 (or is it O200?) project to understand its status. > The premise is that early Linux experience with the SN architecture > translates to a faster bringup of Linux-IA64-SN1 and the hope of a real > headstart on exploiting the architectural capabilities of SN1 and SN2. I have been trying to push this view point along when we started the linux port to o200 in Fall 98. I am glad that the view points are converging here. > > It is my understanding that each of you has been involved in various > aspects of Linux-MIPS64-O2000. I understand that up to now, the project > has been viewed by Engineering as a low-priority, almost off-the-books > effort, but I believe that view is changing, at least from the view of > higher management. > > I would appreciate greatly if each of you would give me a brief summary > of what you've been doing, personally and as a project, and where the > current roadblocks are. Simon is especially interested in having a Ported 2.1.100 to o200 to single user. The major roadblock was the tool set which was gcc frontend hosted on irix and the mongoose backend. This would not work for asm code with .section attributes in between and one of the mongoose releases fixed only this. There were other problems with front end and back end. > visible list of bugworks PV bugs. And yes, I do understand that some of > the roadblocks are in the compilers. We need to clarify exactly what > the problems are before we can motivate that part of the Engineering > organization to fix them. > We talked to the compilers group at that time (Jan 99) to make this a proper product release. At that time, (Bean Anderson) and others wanted a full ABI story for them to produce the mips 64 bit tools for linux apps. The wanted to know the o32/n32/64 details. So, at that time we decided that we would not build 64 bit apps and just use the existing mips o32 apps. One of the important things that needs to be done to help sn1ia64 is for Simon's group to get a multinode multi io SN1 mips box and test the current release on that. If this can be done asap, the IO part of sn1ia64 can try out the devfs/hwgraph, PCI infrastructure and distributed IO discovery and other portions of code on final hardware. Our current medusa simulator may not be sufficient. For VM/NUMA only an o2000 port which can come up to multi user should be sufficient. > As far as which bugworks project to use, it seems to me that it's > easiest to use sgi.bugs.linux-mips64, rather than create a new project > like sgi.bugs.o2000-linux or sgi.bugs.origin-linux. What do you think? > Yes, some of the bugs (or feature enhancements, or PV "issues") are > platform-specific and some are MIPS64-specific, but I think it > complicates matters to have multiple bugworks projects. I dont know if we are at the bug filing stage yet. We need to get the base code in place first. Or if we want to treat the work as bugs I would like to file the first one :-) Need 2.3.47 to work multi user on SN1 and SN0-o2000 Thanks srinivasa > > Let's start a dialog here. Thanks! > > John Hawkes > > From owner-linux-origin@oss.sgi.com Wed Mar 8 13:55:22 2000 Received: by oss.sgi.com id ; Wed, 8 Mar 2000 13:55:12 -0800 Received: from animaniacs.conectiva.com.br ([200.250.58.146]:3572 "EHLO lappi") by oss.sgi.com with ESMTP id ; Wed, 8 Mar 2000 13:54:54 -0800 Received: by lappi.waldorf-gmbh.de id ; Wed, 8 Mar 2000 18:31:05 -0300 Date: Wed, 8 Mar 2000 18:31:05 -0300 From: Ralf Baechle To: John Hawkes Cc: Ulf Carlsson , Leo Dagum , Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: Linux/MIPS64/O2000 Message-ID: <20000308183105.E6399@uni-koblenz.de> References: <001f01bf8939$567f7cc0$1d70eea9@seattle.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <001f01bf8939$567f7cc0$1d70eea9@seattle.sgi.com> X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Wed, Mar 08, 2000 at 12:03:12PM -0800, John Hawkes wrote: > I would appreciate greatly if each of you would give me a brief summary > of what you've been doing, personally and as a project, and where the > current roadblocks are. Simon is especially interested in having a > visible list of bugworks PV bugs. And yes, I do understand that some of > the roadblocks are in the compilers. We need to clarify exactly what > the problems are before we can motivate that part of the Engineering > organization to fix them. Binutils are our worst problem at this point. Binutils are very complex and it's been very hard for Ulf Carlsson to fix one thing without breaking something else. Due to the linker issues we're still stuck with glibc 2.0 and cannot get various programs like many C++ programs or libg++ working. At the same time we've run into problems with the kernel also due to the linker. So our compiler problem is mostly a binutils problem, except one egcs bug which we've got a workaround for we have no problems with the mips64-linux-gcc egcs 1.1.2 deriver compiler we're using. As for the kernel, I'm currently working on SMP support even though the UP kernel is still more than fragile. Ralf From owner-linux-origin@oss.sgi.com Mon Mar 13 09:45:57 2000 Received: by oss.sgi.com id ; Mon, 13 Mar 2000 09:45:37 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6220 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 13 Mar 2000 09:45:17 -0800 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 JAA08617 for ; Mon, 13 Mar 2000 09:47:05 -0800 (PST) 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 JAA77969 for ; Mon, 13 Mar 2000 09:43:26 -0800 (PST) mail_from (hawkes@engr.sgi.com) Message-ID: <003701bf8d13$e7a4de60$1d70eea9@seattle.sgi.com> From: "John Hawkes" To: "linux-origin" Subject: who is subscribed? Date: Mon, 13 Mar 2000 09:45:20 -0800 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 Who is subscribed to this mailing list? I'd like to be able to send email to everyone who is working on Linux/mips64/Origin without duplications. Unless there are serious objections, I've taken Joan's suggestion and have gotten bugworks to create a group "linux-origin" and am waiting for them to also create a project with the same name. That ought to result in the creation a newsgroup sgi.bugs.linux-origin. At that point, it would be great if people would start filing specific bug reports on known problems. John Hawkes From owner-linux-origin@oss.sgi.com Tue Mar 14 07:53:56 2000 Received: by oss.sgi.com id ; Tue, 14 Mar 2000 07:53:46 -0800 Received: from [200.250.58.146] ([200.250.58.146]:16887 "EHLO lappi") by oss.sgi.com with ESMTP id ; Tue, 14 Mar 2000 07:53:23 -0800 Received: by lappi.waldorf-gmbh.de id ; Tue, 14 Mar 2000 12:52:18 -0300 Date: Tue, 14 Mar 2000 12:52:18 -0300 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: Fwd: Linux-2.3.x cache coherency issues, proposed new architecture Message-ID: <20000314125217.A882@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing David Miller wants to rework the cache coherence stuff for 2.3. This below is an email which he sent to all of us port maintainers. I forward it to you linux-origin in the hope to get some input on the non-obvious issues. While it's not too probable that we'll ever going to see a Linux port to the R8000 this might also be the occassion to think about getting the interfaces right for it. More important is of course getting more efficient interfaces for more common hardware like the Origin. What we currently have is not overly efficient; i.e. some of the code paths may flush a page multiple times. Or how to use some of the Origin specific features like cache poisoning most efficiently. One of the changes that already went into vger-2.3 is passing an additional vaddr argument to copy_page / clear_page which will allow a few optimizations. Ralf ----- Forwarded message from "David S. Miller" ----- Subject: Linux-2.3.x cache coherency issues, proposed new architecture Hello port maintainers, Now that the page cache is really unified in 2.3.x I would like to properly deal with some cache coherency issues and kill a lot of old and poorly designed cruft we have in the architecture-defined VM interfaces. First, we have to start from what the issues are for various architectures. I list what I am decently aware of below. If your port is missing or your port is listed but questions appear in it's section, _please_ fill me in so I can be more knowledgable about your port for the purposes of the proposed changes below. IA64: I-cache aparently cannot see DMA activity? Or is it blind only to local cpu stores? Sparc64: I-cache cannot see local cpu stores. D-cache is virtually indexed, and the most significant indexing bit is (1 << PAGE_SHIFT). This creates a situation where illegal aliases can enter the cache if multiple mappings of a physical page are not all mapped at virtual addresses with bit "(1 << PAGE_SHIFT)" being the same. Sparc: sun4c: Cpu has shared I/D cache which is virtually indexed and virtually tagged (with mmu context info as well). It is 64K (which is > PAGE_SIZE) and thus has the same cache alias issues as sparc64's D-cache. When mmu/tlb mappings are removed, all cache entries referring to that mapping must be removed first. The cpu will take an exception otherwise. The reason is that in order to perform a write-back properly, the cpu must be able to get a virt->phys translation from the tlb since the cache does not use physical addresses in it's tags. sun4m: So many combinations of virtually indexed, physically indexed, split I/D, split I/D + combined L2, coherent with DMA, not coherent with DMA, etc. cache setups that I don't even want to list them all. MIPS: Most R4x00 variants have the virtually indexed cache illegal alias issue. In fact, many of the r4x00 chips will actually signal an exception if you create an illegal alias situation (ie. 2 lines exist in the cache at the same time which refer to the same physical data) Below I outline the first set of interfaces I'd like to put into the kernel to definitively catch all kernel side cpu accesses to page cache pages. They are designed such that you can do whatever you want, to deal with whatever problem you have wrt. user vs. kernel views of physical pages wrt. cache coherency or whatever. Also, they are designed such that ports which have totally coherent caches pay no performance penalty whatsoever. All other data transfers not caught by these interfaces below are assumed to be done via "DMA". And in such a case you need to be aware of and deal with two cases: 1) CPU is not coherent with DMA activity, in which case your {pci,sbus,zorro,etc}_{map,unmap}_{single,sg}() implementation must take care of it. 2) PIO data transfers. In this case you must make your {in,out}s{b,w,l}() implementation do whatever cache flushing is needed. This, along with a proper setting of SHMLBA in asm/shmparam.h should take care of all cache coherency issues imaginable to mankind :-) ============================================================ /* Suggested page cache data transfer interfaces. */ /* Copy LEN bytes from kernel address KADDR to * kernel address (TO_PAGE + OFFSET). */ copy_page_cache_fromkernel(to_page, offset, kaddr, len); /* Copy LEN bytes from kernel address (FROM_PAGE + OFFSET) * to kernel address KADDR. */ copy_page_cache_fromkernel(kaddr, from_page, offset, len); /* Copy LEN bytes of data from user-space address UADDR * to kernel address (TO_PAGE + OFFSET). */ copy_page_cache_fromuser(to_page, offset, uaddr, len); /* Copy LEN bytes of data from kernel address (FROM_PAGE + OFFSET) * to user-space address UADDR. */ copy_page_cache_touser(uaddr, from_page, offset, len); /* Clear all PAGE_CACHE_SIZE bytes of kernel page PAGE. */ clear_page_cache(page); /* Clear LEN bytes at kernel address (PAGE + OFFSET). */ clear_page_cache_partial(page, offset, len); /* If local processor stores into a page cache page have * been via some mechanism _other_ than the above copy/clear * interfaces, the following must be invoked on PAGE before * it is marked "uptodate" by the kernel. */ flush_page_cache_page(page); ============================================================ Also, I have just submitted a patch to Linus which adds a "vaddr" user virtual address argument to clear_page() and copy_page(). (BTW, this allows a performance optimization as well as a way to assist in virtual cache alias prevention, since you know the user space virtual address you can create a temporary local-cpu mmu mapping of the pages involved such that the address at which you perform the copy loads and stores is congruent to the cache lines the user space mapping will reference them by, and if you have a clever software replacable tlb you can just load these mappings by hand before the copy, save away the tlb entries which were there before you started, and restore the original mappings after the copy. This allows to handle page copy and clear operations with zero tlb activity around the operations. Sparc64 does just this in arch/sparc64/lib/blockops.S and I intend to make various flavors of sparc32 do something similar very soon.) The above interfaces should allow a complete kill of flush_page_to_ram() from the set of public interfaces. I believe with some care it can also allow flush_icache_page() to die. The two interfaces mentioned in this paragraph are very vague, and most people don't know what they even do anymore or where the proper place is to make use of them. Furthermore they can lead to inefficient ports, for cases where one only needs to flush (certain) caches in some cases but not everywhere flush_page_to_ram or flush_icache_page are actually invoked. Please send me commentary and suggestions as soon as possible so that I can whip up the implementation of these ideas and submit them to Linus "very soon". :-) Thanks. Later, David S. Miller davem@redhat.com ----- End forwarded message ----- Ralf From owner-linux-origin@oss.sgi.com Wed Mar 15 13:22:03 2000 Received: by oss.sgi.com id ; Wed, 15 Mar 2000 13:21:54 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:10502 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 15 Mar 2000 13:21:38 -0800 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 NAA19291 for ; Wed, 15 Mar 2000 13:17:00 -0800 (PST) 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 NAA24569 for ; Wed, 15 Mar 2000 13:21:37 -0800 (PST) Received: from wrlarun (wrlarun.seattle.sgi.com [169.238.112.27]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id NAA98398; Wed, 15 Mar 2000 13:19:52 -0800 (PST) mail_from (hawkes@engr.sgi.com) Message-ID: <021801bf8ec4$12751360$1b70eea9@seattle.sgi.com> Reply-To: "John Hawkes" From: "John Hawkes" To: Cc: , , , References: <200003152059.MAA74849@info.engr.sgi.com> Subject: Re: ADD 784584 - BugWorks Request: Create a new Project. Date: Wed, 15 Mar 2000 13:18:53 -0800 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > Normally, not long but I've been waiting for the dust to settle > on the proposed reorganization of the linux bug groups and projects > being spearheaded by Paul Jackson and Craig Dunwoody. If you > haven't seen it, I believe the current proposal is at: > /hosts/sam.engr/usr/people/pj/etc/linux-bugs/linux-bugs > > Notice there already is a bug group called > linux-mips64 linux on o200 > which apparently is not currently being used and being proposed > to be deleted; the bug group's leader is currently > Srinivasa Thirumalachar (sprasad) in Steve Neuener's group. > There is also a linux-mips64 project and sgi.bugs.linux-mips64 > news group ("track all issues related to mips64 linux"), none > of which seem to being used right now. > > Sounds like these might overlap or cover exactly the same > area? John, can you use these existing ones? Or should they > be renamed? I am cc'ing the "linux-origin" mailing list. We've had prior email discussions about what project/group/newsgroup names to use. What we are searching for is the optimum catch-all newsgroup for: Linux on Mips64 on O200 and O2000 (aka Origin) platforms. The intention is to capture bugs/RFEs/Issues/Tasks that are both Linux/mips64 (pure software) and Linux/Origin (platform-specific issues, like drivers). The feeling was that linux-mips64 had the appearance of being too pure-software in nature, despite the group's description of "linux on o200". And the final rationale is that we have a mailing list, linux-origin@oss.sgi.com, that purports to discuss these matters. Not everyone in the Linux/Mips64/Origin project are inside the SGI firewall. That's the rationale for a linux-origin project. As for what to do about linux-mips64, who created that group/project? John Hawkes From owner-linux-origin@oss.sgi.com Fri Mar 17 14:49:47 2000 Received: by oss.sgi.com id ; Fri, 17 Mar 2000 14:49:37 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:3408 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 17 Mar 2000 14:49:25 -0800 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 OAA10631 for ; Fri, 17 Mar 2000 14:44:48 -0800 (PST) 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 OAA19518 for linux-origin@oss.sgi.com; Fri, 17 Mar 2000 14:48:09 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003172248.OAA19518@google.engr.sgi.com> Subject: Little progress To: linux-origin@oss.sgi.com Date: Fri, 17 Mar 2000 14:48:08 -0800 (PST) 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 With the last checkin, I can now get to where the following output shows. Ulf, please look at the hack I put into sys32_wait, it might be related to the waitqueue problem you found before. So, emergency (static) shell works now somewhat, we need to move on towards emergency dynamic shell, then bash, then single user. Kanoj >> bootp()annie.engr.sgi.com:/tftpboot/penguin3/vmlinux.64 init=/bin/ash Setting $netaddr to 163.154.10.23 (from server annie.engr.sgi.com) Obtaining /tftpboot/penguin3/vmlinux.64 from server annie.engr.sgi.com 1243188+318320+699612 entry: 0xa800000000150000 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Total memory probed : 0x20000 pages Linux version 2.3.51 (kanoj@dbear.engr.sgi.com) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #68 Fri Mar 17 14:22:05 PST 2000 Loading R10000 MMU routines. CPU revision is: 00000927 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has a secondary CPU, CPU is running. Machine is in M mode. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Entering 64-bit mode. CPU clock is 180MHz. Calibrating delay loop... 179.81 BogoMIPS Memory: 124112k/131072k available (1214k kernel code, 6960k reserved, 110k data, 184k init) Buffer-cache hash table entries: 8192 (order: 4, 65536 bytes) Page-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX PCI: Probing PCI hardware on host bus 0, node 0. PCI: Fixing base addresses for device 00:02.0 Linux NET4.0 for Linux 2.3 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 8Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.6 Serial driver version 4.92 (2000-1-27) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabledttyS00 at 0x0000 (irq = 0) is a 16550A ttyS01 at 0x0000 (irq = 0) is a 16550A qlogicisp : new isp1020 revision ID (5) qlogicisp : new isp1020 revision ID (5) scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 00 irq 0 I/O base 0x8200000 scsi1 : QLogic ISP1020 SCSI on PCI bus 00 device 08 irq 1 I/O base 0x8400000 scsi : 2 hosts. Vendor: SGI Model: IBM DCHS04Y Rev: 3232 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 1, lun 0 Vendor: SGI Model: IBM DCHS04Y Rev: 3232 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 4, lun 0 scsi : detected 2 SCSI disks total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 8888543 [4340 MB] [4.3 GB] Partition check: sda: sda1 sda2 sda3 sda4 SCSI device sdb: hdwr sector= 512 bytes. Sectors= 8888543 [4340 MB] [4.3 GB] sdb: sdb1 sdb2 sdb3 sdb4 Ok, using PHY 31, vendor 0x20005c0, model 0, rev 1. eth0: MII transceiver found at MDIO address 31, config 3100 status 786f. IOC3 SSRAM has 64 kbyte. Found DS1981U NIC, registration number 70:ad:01:00:70:5e, CRC eb. Ethernet address is 08:00:69:05:31:cd. Sending BOOTP requests....... OK IP-Config: Got BOOTP answer from 163.154.10.27, my address is 163.154.10.23 Looking up port of RPC 100003/2 on 163.154.10.27 Looking up port of RPC 100005/1 on 163.154.10.27 Looking up port of RPC 100005/1 on 163.154.10.27 VFS: Mounted root (NFS filesystem) readonly. Freeing unused kernel memory: 184k freed # ls a.out dev lib mnt sbin var bin etc lost+found proc tmp vmlinux.64 boot home ls root usr # whoami root # uid uid: not found # id uid=0(root) gid=0(root) # pwd / # cd /tmp # ls linuxconf-rpminstall.log # ls -l total 1 -rw-r--r-- 1 root root 309 Oct 30 10:28 linuxconf-rpminstall.log # pwd /tmp # touch x touch: x: Read-only file system From owner-linux-origin@oss.sgi.com Fri Mar 17 17:17:27 2000 Received: by oss.sgi.com id ; Fri, 17 Mar 2000 17:17:18 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:28695 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 17 Mar 2000 17:16:56 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA00972 for ; Fri, 17 Mar 2000 17:12:18 -0800 (PST) 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 RAA87490 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Fri, 17 Mar 2000 17:16:39 -0800 (PST) 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 RAA29215 for linux-origin@oss.sgi.com; Fri, 17 Mar 2000 17:16:19 -0800 From: "Leo Dagum" Message-Id: <10003171716.ZM29213@barrel.engr.sgi.com> Date: Fri, 17 Mar 2000 17:16:18 -0800 In-Reply-To: kanoj@google (Kanoj Sarcar) "Little progress" (Mar 17, 2:48pm) References: <200003172248.OAA19518@google.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: linux-origin@oss.sgi.com Subject: Re: Little progress 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 Mar 17, 2:48pm, Kanoj Sarcar wrote: > Subject: Little progress > With the last checkin, I can now get to where the following output shows. > Ulf, please look at the hack I put into sys32_wait, it might be related > to the waitqueue problem you found before. > > So, emergency (static) shell works now somewhat, we need to move on towards > emergency dynamic shell, then bash, then single user. > Awesome! I just tried it with one of the internal ext2 drives and it boots to a working shell also! - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Mon Mar 20 15:05:26 2000 Received: by oss.sgi.com id ; Mon, 20 Mar 2000 15:05:06 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49266 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 20 Mar 2000 15:05:05 -0800 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 PAA00798 for ; Mon, 20 Mar 2000 15:08:34 -0800 (PST) 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 PAA64443 for ; Mon, 20 Mar 2000 15:05:04 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA01464 for linux-origin@oss.sgi.com; Mon, 20 Mar 2000 15:02:32 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003202302.PAA01464@google.engr.sgi.com> Subject: Whee!! To: linux-origin@oss.sgi.com Date: Mon, 20 Mar 2000 15:02:32 -0800 (PST) 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 Ulf fixed a couple of system calls to get bash working, and now it seems we can get up to single user mode! Kanoj >> bootp()annie.engr.sgi.com:/tftpboot/penguin3/vmlinux.64 Setting $netaddr to 163.154.10.23 (from server annie.engr.sgi.com) Obtaining /tftpboot/penguin3/vmlinux.64 from server annie.engr.sgi.com 1250008+318400+717028 entry: 0xa800000000154000 ARCH: SGI-IP27 PROMLIB: ARC firmware Version 64 Revision 0 Total memory probed : 0x20000 pages Linux version 2.3.99-pre1 (kanoj@dbear.engr.sgi.com) (gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)) #6 Mon Mar 20 14:47:16 PST 2000 Loading R10000 MMU routines. CPU revision is: 00000927 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 IP27: Running on node 0. Node 0 has a primary CPU, CPU is running. Node 0 has a secondary CPU, CPU is running. Machine is in M mode. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Entering 64-bit mode. CPU clock is 180MHz. Calibrating delay loop... 179.81 BogoMIPS Memory: 124080k/131072k available (1220k kernel code, 6992k reserved, 110k data, 184k init) Buffer-cache hash table entries: 8192 (order: 4, 65536 bytes) Page-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX PCI: Probing PCI hardware on host bus 0, node 0. PCI: Fixing base addresses for device 00:02.0 Linux NET4.0 for Linux 2.3 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 8Kbytes TCP: Hash tables configured (established 4096 bind 4096) Starting kswapd v1.6 Serial driver version 4.92 (2000-1-27) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x0000 (irq = 0) is a 16550A ttyS01 at 0x0000 (irq = 0) is a 16550A qlogicisp : new isp1020 revision ID (5) qlogicisp : new isp1020 revision ID (5) scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 00 irq 0 I/O base 0x8200000 scsi1 : QLogic ISP1020 SCSI on PCI bus 00 device 08 irq 1 I/O base 0x8400000 scsi : 2 hosts. Vendor: SGI Model: IBM DCHS04Y Rev: 3232 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 1, lun 0 Vendor: SGI Model: IBM DCHS04Y Rev: 3232 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sdb at scsi0, channel 0, id 4, lun 0 scsi : detected 2 SCSI disks total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 8888543 [4340 MB] [4.3 GB] Partition check: sda: sda1 sda2 sda3 sda4 SCSI device sdb: hdwr sector= 512 bytes. Sectors= 8888543 [4340 MB] [4.3 GB] sdb: sdb1 sdb2 sdb3 sdb4 Ok, using PHY 31, vendor 0x20005c0, model 0, rev 1. eth0: MII transceiver found at MDIO address 31, config 3100 status 786f. IOC3 SSRAM has 64 kbyte. Found DS1981U NIC, registration number 70:ad:01:00:70:5e, CRC eb. Ethernet address is 08:00:69:05:31:cd. Sending BOOTP requests....... OK IP-Config: Got BOOTP answer from 163.154.10.27, my address is 163.154.10.23 Looking up port of RPC 100003/2 on 163.154.10.27 Looking up port of RPC 100005/1 on 163.154.10.27 VFS: Mounted root (NFS filesystem) readonly. Freeing unused kernel memory: 184k freed kmod: failed to exec /sbin/modprobe -s -k char-major-4, errno = 2 INIT: version 2.74 booting Activating swap partitions hostname: ulf2.engr.sgi.com Checking root filesystems. WARNING: Your /etc/fstab does not contain the fsck passno field. I will kludge around things for you, but you should fix your /etc/fstab file as soon as you can. Parallelizing fsck version 1.10 (24-Apr-97) [/sbin/fsck.ext2] fsck.ext2 -a /dev/sda1 Warning... fsck.ext2 for device /dev/sda1 exited with signal 11. *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance (or type Control-D for normal startup): [root@ulf2 /root]# pwd /root [root@ulf2 /root]# ls -l total 237 -rw------- 1 root root 241664 Oct 30 10:22 core [root@ulf2 /root]# cd .. [root@ulf2 /]# ls a.out dev lib mnt sbin var bin etc lost+found proc tmp vmlinux.64 boot home ls root usr [root@ulf2 /]# pwd / [root@ulf2 /]# ls -l total 4571 -rwxr-xr-x 1 root root 572249 Mar 17 18:13 a.out drwxr-xr-x 2 37984 wheel 2048 Mar 16 22:18 bin drwxr-xr-x 2 37984 wheel 1024 Feb 6 1996 boot drwxr-xr-x 2 37984 wheel 21504 Feb 20 01:39 dev drwxr-xr-x 17 37984 wheel 2048 Nov 2 00:47 etc drwxr-xr-x 3 37984 wheel 1024 Oct 30 08:48 home drwxr-xr-x 4 37984 wheel 2048 Oct 30 08:43 lib drwxr-xr-x 2 37984 wheel 1024 Oct 30 07:44 lost+found -rwxr-xr-x 1 root root 1338092 Mar 14 01:02 ls drwxr-sr-x 2 37984 wheel 1024 Nov 2 00:23 mnt drwxr-sr-x 2 37984 wheel 1024 Nov 2 00:21 proc drwxr-xr-x 2 37984 wheel 1024 Oct 31 04:22 root drwxr-xr-x 3 37984 wheel 1024 Oct 30 10:28 sbin drwxr-xr-t 2 37984 wheel 1024 Nov 1 04:02 tmp drwxr-xr-x 18 37984 wheel 1024 Oct 30 08:08 usr drwxr-xr-x 12 37984 wheel 1024 Oct 30 10:21 var -rwxrwxrwx 1 37984 wheel 2706622 Mar 20 22:51 vmlinux.64 [root@ulf2 /]# date Mon Mar 20 22:59:10 /etc/localtime 2000 [root@ulf2 /]# whoami root [root@ulf2 /]# ping usage: ping [-LRdfnqrv] [-c count] [-i wait] [-l preload] [-p pattern] [-s packetsize] [-t ttl] [-I interface address] host [root@ulf2 /]# ping 163.154.10.144 PING 163.154.10.144 (163.154.10.144): 56 data bytes 64 bytes from 163.154.10.144: icmp_seq=0 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=1 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=2 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=3 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=4 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=5 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=6 ttl=254 time=0.0 ms 64 bytes from 163.154.10.144: icmp_seq=7 ttl=254 time=0.0 ms --- 163.154.10.144 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms From owner-linux-origin@oss.sgi.com Mon Mar 20 15:36:56 2000 Received: by oss.sgi.com id ; Mon, 20 Mar 2000 15:36:46 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:55878 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 20 Mar 2000 15:36:36 -0800 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 PAA06501 for ; Mon, 20 Mar 2000 15:31:57 -0800 (PST) mail_from (ulfc@cthulhu.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 PAA15578; Mon, 20 Mar 2000 15:36:19 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 2F765105016; Mon, 20 Mar 2000 15:33:59 -0800 (PST) Date: Mon, 20 Mar 2000 15:33:59 -0800 (PST) From: Ulf Carlsson To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: Whee!! In-Reply-To: <200003202302.PAA01464@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > Ulf fixed a couple of system calls to get bash working, and now it > seems we can get up to single user mode! It seems to work now with the new 2.3.99pre1 CVS although it didn't work with 2.3.51 for some reason. Good news! I'll try to get some more programs working... Ulf From owner-linux-origin@oss.sgi.com Mon Mar 20 16:45:09 2000 Received: by oss.sgi.com id ; Mon, 20 Mar 2000 16:44:59 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:48011 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Mon, 20 Mar 2000 16:44:53 -0800 Received: from cacc-1.uni-koblenz.de (cacc-1.uni-koblenz.de [141.26.131.1]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA19388; Tue, 21 Mar 2000 01:44:48 +0100 (MET) Received: by lappi.waldorf-gmbh.de id ; Tue, 21 Mar 2000 01:44:23 +0100 Date: Tue, 21 Mar 2000 01:44:23 +0100 From: Ralf Baechle To: Ulf Carlsson Cc: Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: Whee!! Message-ID: <20000321014423.A2201@uni-koblenz.de> References: <200003202302.PAA01464@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Mar 20, 2000 at 03:33:59PM -0800, Ulf Carlsson wrote: > > Ulf fixed a couple of system calls to get bash working, and now it > > seems we can get up to single user mode! > > It seems to work now with the new 2.3.99pre1 CVS although it didn't work with > 2.3.51 for some reason. Good news! I'll try to get some more programs > working... Aside of the obvious random factor there is also a number of fixes in 2.3.99 that may have made the difference. Tomorrow I'll merge with 2.3.99-pre2. In any case, congrats! Ralf From owner-linux-origin@oss.sgi.com Tue Mar 21 11:18:53 2000 Received: by oss.sgi.com id ; Tue, 21 Mar 2000 11:18:43 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:26693 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 21 Mar 2000 11:18:30 -0800 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 LAA29863 for ; Tue, 21 Mar 2000 11:13:51 -0800 (PST) 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 LAA72621 for ; Tue, 21 Mar 2000 11:18:29 -0800 (PST) Received: from wrlarun (wrlarun.seattle.sgi.com [169.238.112.27]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA32351 for ; Tue, 21 Mar 2000 11:16:53 -0800 (PST) mail_from (hawkes@engr.sgi.com) Message-ID: <035101bf9369$de313840$1b70eea9@seattle.sgi.com> Reply-To: "John Hawkes" From: "John Hawkes" To: Subject: sgi.bugs.linux-origin now exists Date: Tue, 21 Mar 2000 11:15:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 sgi.bugs.linux-origin now exists (at least it does on fido.engr). Please feel free to submit bugs, though (in my mind) the preferable way to do this is to use bugworks, though posting to sgi.bugs.linux-origin or sending email to that newsgroup will also work. I'll do whatever fixups to the bug reports that make sense in that case. John Hawkes From owner-linux-origin@oss.sgi.com Wed Mar 22 22:12:48 2000 Received: by oss.sgi.com id ; Wed, 22 Mar 2000 22:12:38 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50993 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Wed, 22 Mar 2000 22:12:11 -0800 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 WAA05396 for ; Wed, 22 Mar 2000 22:15:42 -0800 (PST) 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 WAA72664 for linux-origin@oss.sgi.com; Wed, 22 Mar 2000 22:10:54 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003230610.WAA72664@google.engr.sgi.com> Subject: Re: o2000 (fwd) To: linux-origin@oss.sgi.com Date: Wed, 22 Mar 2000 22:10:54 -0800 (PST) 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 From ulfc@cthulhu Wed Mar 22 21:32:49 2000 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA75328 for ; Wed, 22 Mar 2000 21:32:49 -0800 (PST) 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 VAA06552 for ; Wed, 22 Mar 2000 21:32:48 -0800 (PST) mail_from (ulfc@engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 8D790105016 for ; Wed, 22 Mar 2000 21:30:22 -0800 (PST) Date: Wed, 22 Mar 2000 21:30:22 -0800 (PST) From: Ulf Carlsson To: Kanoj Sarcar Subject: Re: o2000 (fwd) In-Reply-To: <200003220629.WAA05695@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If there's more setup needed, let me know what, or if you have the > time, just go ahead and do it. Maybe we can put a pointer to the > nfsroot setup directions from my reality web page, if you can write > something up ... http://oss.sgi.com/~ulfc/linuxmips64.html Ulf From owner-linux-origin@oss.sgi.com Thu Mar 23 09:48:51 2000 Received: by oss.sgi.com id ; Thu, 23 Mar 2000 09:48:42 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:27761 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 23 Mar 2000 09:48:28 -0800 Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA24151 for ; Thu, 23 Mar 2000 09:43:48 -0800 (PST) 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 JAA47612 for <@cthulhu.engr.sgi.com:linux-origin@oss.sgi.com>; Thu, 23 Mar 2000 09:48:10 -0800 (PST) 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 JAA10829; Thu, 23 Mar 2000 09:47:34 -0800 From: "Leo Dagum" Message-Id: <10003230947.ZM10827@barrel.engr.sgi.com> Date: Thu, 23 Mar 2000 09:47:33 -0800 In-Reply-To: kanoj@google (Kanoj Sarcar) "Re: o2000 (fwd)" (Mar 22, 10:10pm) References: <200003230610.WAA72664@google.engr.sgi.com> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: kanoj@google.engr.sgi.com (Kanoj Sarcar), linux-origin@oss.sgi.com Subject: Re: o2000 (fwd) 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 Mar 22, 10:10pm, Kanoj Sarcar wrote: > > http://oss.sgi.com/~ulfc/linuxmips64.html > > Ulf Hi Ulf, You can add 'hubbard' to the list of systems: O2000 hubbard slab-annex1 5021 5058 /dev/sdb1 --- - leo -- Leo Dagum SGI Mountain View, CA 94043 (650-933-2179) From owner-linux-origin@oss.sgi.com Tue Mar 28 09:03:18 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 09:02:59 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:64717 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 09:02:42 -0800 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 TAA15608; Tue, 28 Mar 2000 19:02:34 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Tue, 28 Mar 2000 18:22:01 +0200 Date: Tue, 28 Mar 2000 18:22:01 +0200 From: Ralf Baechle To: Ulf Carlsson Cc: linux-origin@oss.sgi.com Subject: scall_o32 Message-ID: <20000328182201.A9155@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Ulf, your patch for scall_o32 reminded me of another bug that we still have in that file. The SAVE_SOME macro saves only a0-a3 but not a4-a7. These however should also be accessible via ptrace(2), so you'll also have to save a6 / a7 at scall_o32.S:trace_a_syscall. I'll commit a fix for this into CVS. Ralf From owner-linux-origin@oss.sgi.com Tue Mar 28 12:32:59 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 12:32:42 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:37907 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 12:32:11 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05678 for ; Tue, 28 Mar 2000 12:35:49 -0800 (PST) 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 MAA07486 for ; Tue, 28 Mar 2000 12:32:10 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA25142 for linux-origin@oss.sgi.com; Tue, 28 Mar 2000 12:29:38 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003282029.MAA25142@google.engr.sgi.com> Subject: broken compiler? To: linux-origin@oss.sgi.com Date: Tue, 28 Mar 2000 12:29:38 -0800 (PST) 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 Basically, test_and_set_bit() is broken. A reduced test case is this: static __inline__ unsigned long value_bit2(void *addr) { unsigned long *m = (unsigned long *) addr; unsigned long temp; __asm__ __volatile__( ".set\tnoreorder\n" "ld\t%0, %2\n\t" ".set\treorder\n" :"=&r" (temp), "=m" (*m) :"m" (*m)); return temp; } void test4(void) { printk("test4 : 0x%x\n", value_bit2(&test_lock)); } void test5(void) { printk("test5 : 0x%x\n", test_lock); } test5() prints the right value, test4() does not. Here's some disas'ed code: (dbx) test4/10i [test4, 0x800e0974] daddiu sp,sp,-16 [test4, 0x800e0978] lui a0,0x8015 [test4, 0x800e097c] daddiu a0,a0,8920 [test4, 0x800e0980] sd ra,0(sp) [test4, 0x800e0984] lui a1,0x801c [test4, 0x800e0988] ld a1,-19064(a1) [test4, 0x800e098c] jal printk (0x8003530c) [test4, 0x800e0990] nop [test4, 0x800e0994] ld ra,0(sp) [test4, 0x800e0998] jr ra [test4, 0x800e099c] daddiu sp,sp,16 (dbx) test5/10i [test5, 0x800e09a0] daddiu sp,sp,-16 [test5, 0x800e09a4] lui v0,0x801c [test5, 0x800e09a8] daddiu v0,v0,-19064 [test5, 0x800e09ac] sd ra,0(sp) [test5, 0x800e09b0] lw a1,0(v0) [test5, 0x800e09b4] lui a0,0x8015 [test5, 0x800e09b8] jal printk (0x8003530c) [test5, 0x800e09bc] daddiu a0,a0,8936 [test5, 0x800e09c0] ld ra,0(sp) [test5, 0x800e09c4] jr ra [test5, 0x800e09c8] daddiu sp,sp,16 Right away, you can see that the way test5() loads the value is lui v0,0x801c daddiu v0,v0,-19064 lw a1,0(v0) whereas test4() loads it using lui a1,0x801c ld a1,-19064(a1) Now, I don't see any problems with the test4() code, but I would like to change the code to something like lui X,0x801c ld a1,-19064(X) where X != a1 and see whether that makes a difference. In any case, from the asm inline constraints in value_bit2(), the test4() generated code is _unexpected_, a1 should not have been used both for %0 and %2. (The fact that I have =m in the output like is irrelevant, since in this case, memory is not really being written to.) Comments? Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 12:43:29 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 12:43:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:8499 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 12:42:58 -0800 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 MAA11043 for ; Tue, 28 Mar 2000 12:38:17 -0800 (PST) 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 MAA57689; Tue, 28 Mar 2000 12:42:40 -0800 (PST) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 8E623A7838; Tue, 28 Mar 2000 12:42:27 -0800 (PST) Date: Tue, 28 Mar 2000 12:42:27 -0800 (PST) From: Ulf Carlsson To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? In-Reply-To: <200003282029.MAA25142@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > Right away, you can see that the way test5() loads the value is > > lui v0,0x801c > daddiu v0,v0,-19064 > lw a1,0(v0) > > whereas test4() loads it using > > lui a1,0x801c > ld a1,-19064(a1) It looks good except that you're using lw in the first case and ld in the second case. That has been a common problem in the mips64 port. > Now, I don't see any problems with the test4() code, but I would like > to change the code to something like > > lui X,0x801c > ld a1,-19064(X) This is ok, you can use the same register as base and target. Ulf From owner-linux-origin@oss.sgi.com Tue Mar 28 12:50:09 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 12:49:59 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:39734 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 12:49:52 -0800 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 MAA11854 for ; Tue, 28 Mar 2000 12:45:12 -0800 (PST) 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 MAA98380; Tue, 28 Mar 2000 12:48:34 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003282048.MAA98380@google.engr.sgi.com> Subject: Re: broken compiler? To: ulfc@calypso.engr.sgi.com (Ulf Carlsson) Date: Tue, 28 Mar 2000 12:48:34 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: from "Ulf Carlsson" at Mar 28, 2000 12:42:27 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 > > > Now, I don't see any problems with the test4() code, but I would like > > to change the code to something like > > > > lui X,0x801c > > ld a1,-19064(X) > > This is ok, you can use the same register as base and target. > > Ulf > Not okay. Here's the code again: static __inline__ unsigned long value_bit2(void *addr) { unsigned long *m = (unsigned long *) addr; unsigned long temp; __asm__ __volatile__( ".set\tnoreorder\n" "ld\t%0, %2\n\t" "#there may be more instructions here" ".set\treorder\n" :"=&r" (temp), "=m" (*m) :"m" (*m)); return temp; } By the output/input specs, I am explicitly saying to gcc: look, you pick the register to hold the variable temp, but make sure you do not use that same register to compute the address, or hold, any of the input variables, because this is an "earlyclobber" register (the & indicates that). Obviously, gcc is not listening and has used a1 to hold temp, as well as use it for address computation of the memory input. Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 14:38:21 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 14:38:01 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:48986 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 14:37:37 -0800 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 OAA26266 for ; Tue, 28 Mar 2000 14:32:57 -0800 (PST) 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 OAA58828; Tue, 28 Mar 2000 14:36:19 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003282236.OAA58828@google.engr.sgi.com> Subject: Re: broken compiler? To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Tue, 28 Mar 2000 14:36:19 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <200003282029.MAA25142@google.engr.sgi.com> from "Kanoj Sarcar" at Mar 28, 2000 12:29: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 Seems like for the mips64 port, though we have big endian format within a word, when we do double word operations, the lower addressed word holds the contents of the most significant word ... ie, the significance is swapped. Is this architecture defined, or is there a register that needs to be programmed somewhere? Kanoj Ps: Example volatile unsigned int test_lock = 0xabc; volatile unsigned int test_lock3 = 0x789; If I load the dword at address &test_lock (which is a dword aligned addr), I get 0x78900000abc From owner-linux-origin@oss.sgi.com Tue Mar 28 14:45:01 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 14:44:51 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:49244 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 14:44:30 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA27112 for ; Tue, 28 Mar 2000 14:39:50 -0800 (PST) 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 OAA42956 for ; Tue, 28 Mar 2000 14:44:29 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA10526; Tue, 28 Mar 2000 14:41:57 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003282241.OAA10526@google.engr.sgi.com> Subject: Re: broken compiler? To: kanoj@google.engr.sgi.com (Kanoj Sarcar) Date: Tue, 28 Mar 2000 14:41:57 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <200003282236.OAA58828@google.engr.sgi.com> from "Kanoj Sarcar" at Mar 28, 2000 02:36:19 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 > > Seems like for the mips64 port, though we have big endian format within > a word, when we do double word operations, the lower addressed word > holds the contents of the most significant word ... ie, the significance > is swapped. > > Is this architecture defined, or is there a register that needs to be > programmed somewhere? > > Kanoj > > Ps: Example > > volatile unsigned int test_lock = 0xabc; > volatile unsigned int test_lock3 = 0x789; > > If I load the dword at address &test_lock (which is a dword aligned addr), > I get 0x78900000abc > I am going nuts. The above should read: volatile unsigned int test_lock2 = 0x123; volatile unsigned int test_lock = 0xabc; volatile unsigned int test_lock3 = 0x789; If I load the dword at address &test_lock (which is a dword aligned addr), I get 0xabc00000789. I was expecting 0x78900000abc. Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 14:54:51 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 14:54:31 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:54367 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 14:54:09 -0800 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 OAA28651 for ; Tue, 28 Mar 2000 14:49:29 -0800 (PST) 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 OAA08966; Tue, 28 Mar 2000 14:53:51 -0800 (PST) mail_from (ulfc@calypso.engr.sgi.com) Received: from localhost (localhost [127.0.0.1]) by calypso.engr.sgi.com (Postfix) with ESMTP id 9283FA7838; Tue, 28 Mar 2000 14:53:38 -0800 (PST) Date: Tue, 28 Mar 2000 14:53:38 -0800 (PST) From: Ulf Carlsson To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? In-Reply-To: <200003282236.OAA58828@google.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > Seems like for the mips64 port, though we have big endian format within > a word, when we do double word operations, the lower addressed word > holds the contents of the most significant word ... ie, the significance > is swapped. > > Is this architecture defined, or is there a register that needs to be > programmed somewhere? Read ``Data Formats and Addressing'' in Chapter 1 of the MIPS R4000 Microprocessor User's Manual for example. Big endian should be big end first, thus the higher byte has the lower address. Ulf From owner-linux-origin@oss.sgi.com Tue Mar 28 16:04:51 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:04:42 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:63882 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:04:26 -0800 Received: from cacc-28.uni-koblenz.de (cacc-28.uni-koblenz.de [141.26.131.28]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA09855; Wed, 29 Mar 2000 02:04:22 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Wed, 29 Mar 2000 02:03:46 +0200 Date: Wed, 29 Mar 2000 02:03:46 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? Message-ID: <20000329020346.A1451@uni-koblenz.de> References: <200003282236.OAA58828@google.engr.sgi.com> <200003282241.OAA10526@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003282241.OAA10526@google.engr.sgi.com> 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, Mar 28, 2000 at 02:41:57PM -0800, Kanoj Sarcar wrote: > I am going nuts. The above should read: > > volatile unsigned int test_lock2 = 0x123; > volatile unsigned int test_lock = 0xabc; > volatile unsigned int test_lock3 = 0x789; > > If I load the dword at address &test_lock (which is a dword aligned addr), > I get 0xabc00000789. I was expecting 0x78900000abc. Ok, but that's exactly what is expected to happen?!? Ralf From owner-linux-origin@oss.sgi.com Tue Mar 28 16:12:51 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:12:41 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49968 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:12:21 -0800 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 QAA01178; Tue, 28 Mar 2000 16:15:59 -0800 (PST) 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 QAA48210; Tue, 28 Mar 2000 16:11:04 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003290011.QAA48210@google.engr.sgi.com> Subject: Re: broken compiler? To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 28 Mar 2000 16:11:04 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000329020346.A1451@uni-koblenz.de> from "Ralf Baechle" at Mar 29, 2000 02:03:46 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 Tue, Mar 28, 2000 at 02:41:57PM -0800, Kanoj Sarcar wrote: > > > I am going nuts. The above should read: > > > > volatile unsigned int test_lock2 = 0x123; > > volatile unsigned int test_lock = 0xabc; > > volatile unsigned int test_lock3 = 0x789; > > > > If I load the dword at address &test_lock (which is a dword aligned addr), > > I get 0xabc00000789. I was expecting 0x78900000abc. > > Ok, but that's exactly what is expected to happen?!? > > Ralf > Yes, okay, I was wrong. 0xabc00000789 is expected, and that is what happens. Which means, given an arbitrary address (and not the type), you have to do a lw, and not a ld, to access it. Which pretty much means that all the bitops routines need to do ll/sc instead of lld/scd. I will try out some changes and see if it helps. (btw, I don't know what bestiality would occur if you did a lld on a non dword aligned addr anyway). Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 16:18:11 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:18:02 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:43404 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:17:56 -0800 Received: from cacc-28.uni-koblenz.de (cacc-28.uni-koblenz.de [141.26.131.28]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA10592; Wed, 29 Mar 2000 02:17:52 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Wed, 29 Mar 2000 02:17:30 +0200 Date: Wed, 29 Mar 2000 02:17:30 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? Message-ID: <20000329021730.B11023@uni-koblenz.de> References: <20000329020346.A1451@uni-koblenz.de> <200003290011.QAA48210@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003290011.QAA48210@google.engr.sgi.com> 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, Mar 28, 2000 at 04:11:04PM -0800, Kanoj Sarcar wrote: > Which means, given an arbitrary address (and not the type), you have to do > a lw, and not a ld, to access it. Which pretty much means that all the > bitops routines need to do ll/sc instead of lld/scd. I will try out some > changes and see if it helps. (btw, I don't know what bestiality would > occur if you did a lld on a non dword aligned addr anyway). The kernel would try to send a SIGBUS to the current process. Ralf From owner-linux-origin@oss.sgi.com Tue Mar 28 16:23:41 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:23:22 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:24445 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:23:13 -0800 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 QAA09521; Tue, 28 Mar 2000 16:18:33 -0800 (PST) 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 QAA33107; Tue, 28 Mar 2000 16:21:56 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003290021.QAA33107@google.engr.sgi.com> Subject: Re: broken compiler? To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 28 Mar 2000 16:21:56 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000329021730.B11023@uni-koblenz.de> from "Ralf Baechle" at Mar 29, 2000 02:17:30 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > On Tue, Mar 28, 2000 at 04:11:04PM -0800, Kanoj Sarcar wrote: > > > Which means, given an arbitrary address (and not the type), you have to do > > a lw, and not a ld, to access it. Which pretty much means that all the > > bitops routines need to do ll/sc instead of lld/scd. I will try out some > > changes and see if it helps. (btw, I don't know what bestiality would > > occur if you did a lld on a non dword aligned addr anyway). > > The kernel would try to send a SIGBUS to the current process. > > Ralf > Doesn't it also partly depend on the setting of the MF_FIXADE flag? Anyway, this is not expected behavior, so I am downgrading usage of most lld/scd calls to ll/sc unless I can guarantee they are operating on a 8 byte quantity (which will be dword aligned by definition). I will checks that in once I test it, I have asked Ulf to see whether it will help him get to miltiuser too. Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 16:34:41 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:34:22 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:19854 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:34:12 -0800 Received: from cacc-28.uni-koblenz.de (cacc-28.uni-koblenz.de [141.26.131.28]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA11252; Wed, 29 Mar 2000 02:34:08 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Wed, 29 Mar 2000 02:33:43 +0200 Date: Wed, 29 Mar 2000 02:33:43 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? Message-ID: <20000329023343.C11023@uni-koblenz.de> References: <20000329021730.B11023@uni-koblenz.de> <200003290021.QAA33107@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003290021.QAA33107@google.engr.sgi.com> 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, Mar 28, 2000 at 04:21:56PM -0800, Kanoj Sarcar wrote: > Doesn't it also partly depend on the setting of the MF_FIXADE flag? No, because the fixup thing done by the exception handler cannot give the same atomicity guarantees as the silicon, so for ll, sc, lld and scd we always send SIGBUS right away. For all other instructions we do the emulation thing if MF_FIXADE is set, otherwise also send SIGBUS. > Anyway, this is not expected behavior, so I am downgrading usage of > most lld/scd calls to ll/sc unless I can guarantee they are operating > on a 8 byte quantity (which will be dword aligned by definition). I > will checks that in once I test it, I have asked Ulf to see whether > it will help him get to miltiuser too. The bitfield operations are supposed to only be used on objects that are of type long or are arrays of longs. So it seems you want to fix things in the wrong direction? Ralf From owner-linux-origin@oss.sgi.com Tue Mar 28 16:44:12 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:44:02 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:28683 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:43:45 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA11640; Tue, 28 Mar 2000 16:39:05 -0800 (PST) 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 QAA64390; Tue, 28 Mar 2000 16:43:14 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA90554; Tue, 28 Mar 2000 16:40:42 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003290040.QAA90554@google.engr.sgi.com> Subject: Re: broken compiler? To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 28 Mar 2000 16:40:41 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000329023343.C11023@uni-koblenz.de> from "Ralf Baechle" at Mar 29, 2000 02:33:43 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 > > Anyway, this is not expected behavior, so I am downgrading usage of > > most lld/scd calls to ll/sc unless I can guarantee they are operating > > on a 8 byte quantity (which will be dword aligned by definition). I > > will checks that in once I test it, I have asked Ulf to see whether > > it will help him get to miltiuser too. > > The bitfield operations are supposed to only be used on objects that > are of type long or are arrays of longs. So it seems you want to fix > things in the wrong direction? > > Ralf > I can;t say I agree completely. Firstly, the prototype definition is (void *), (which is bad in itself). Secondly, if generic code does have something like long variable = xxxx. test_and_set_bit(N, &variable) it must guarantee that N is less than the size of a long. _Most_ generic code would then pass in a value N <= 31, to be able to work on most architectures. Anyway, I am modifying the code into a state where it will be easy to revert to the current behavior by changing a couple of #defines in bitops.h. I haven't tried the ll/sc to see whether it helps any. Kanoj From owner-linux-origin@oss.sgi.com Tue Mar 28 16:56:12 2000 Received: by oss.sgi.com id ; Tue, 28 Mar 2000 16:55:52 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:10896 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Tue, 28 Mar 2000 16:55:23 -0800 Received: from cacc-28.uni-koblenz.de (cacc-28.uni-koblenz.de [141.26.131.28]) by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA11919; Wed, 29 Mar 2000 02:55:19 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Wed, 29 Mar 2000 02:55:05 +0200 Date: Wed, 29 Mar 2000 02:55:05 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com Subject: Re: broken compiler? Message-ID: <20000329025505.E11023@uni-koblenz.de> References: <20000329023343.C11023@uni-koblenz.de> <200003290040.QAA90554@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: <200003290040.QAA90554@google.engr.sgi.com> 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, Mar 28, 2000 at 04:40:41PM -0800, Kanoj Sarcar wrote: > > The bitfield operations are supposed to only be used on objects that > > are of type long or are arrays of longs. So it seems you want to fix > > things in the wrong direction? > > I can;t say I agree completely. Firstly, the prototype definition is > (void *), (which is bad in itself). Secondly, if generic code does > have something like The prototype is legacy from the dark ages before Linux 1.0. > long variable = xxxx. > test_and_set_bit(N, &variable) > > it must guarantee that N is less than the size of a long. _Most_ > generic code would then pass in a value N <= 31, to be able to > work on most architectures. This is indeed the assumption. > Anyway, I am modifying the code into a state where it will be easy > to revert to the current behavior by changing a couple of #defines > in bitops.h. I haven't tried the ll/sc to see whether it helps any. Reverting to ll / sc is _WRONG_ unless you just want to modify the code to work on objects with 32-bit alignment which will make it unecessarily slow. Ralf PS: Read the comments about atomicity for example in the definition of struct netdevice in include/linux/netdevice.h in 2.2.x. From owner-linux-origin@oss.sgi.com Thu Mar 30 17:54:43 2000 Received: by oss.sgi.com id ; Thu, 30 Mar 2000 17:54:35 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:20752 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 30 Mar 2000 17:54:18 -0800 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 RAA09855 for ; Thu, 30 Mar 2000 17:57:58 -0800 (PST) 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 RAA46521 for ; Thu, 30 Mar 2000 17:54:16 -0800 (PST) Received: (from kanoj@localhost) by google.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA38622; Thu, 30 Mar 2000 17:51:44 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003310151.RAA38622@google.engr.sgi.com> Subject: Re: CVS Update@oss.sgi.com: linux To: dagum@google.engr.sgi.com Date: Thu, 30 Mar 2000 17:51:43 -0800 (PST) Cc: linux-origin@oss.sgi.com In-Reply-To: <20000331013535Z305168-3991+182@oss.sgi.com> from "Leo Dagum" at Mar 30, 2000 05:35:33 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 > > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: dagum@oss.sgi.com 00/03/30 17:35:32 > > Modified files: > drivers/scsi : qlogicfc.c qlogicfc.h > > Log message: > Some minor changes to turn on 64-bittiness. > Please make sure to send in a patch, resend it, resend it ..., till it gets accepted. All the work we are doing outside arch/* and include/asm-mips64/* has very limited benefit if we do not push it into the main tree. Leo, I know you were going to do this anyway :-) Just taking the opportunity to remind everyone else ... Ralf, you mentioned about a 100K patch difference between oss and pre3, I am hoping most of this is in the arch specific stuff? We probably need to look at the generic diffs, and push as much of the mips64 related stuff into 2.3. When 2.4 comes out, we should be able to take that source, the arch/mips64 and include/asm-mips64 from oss, and be able to create a kernel that will work well. Kanoj From owner-linux-origin@oss.sgi.com Fri Mar 31 07:09:27 2000 Received: by oss.sgi.com id ; Fri, 31 Mar 2000 07:09:11 -0800 Received: from mailhost.uni-koblenz.de ([141.26.64.1]:50663 "EHLO mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP id ; Fri, 31 Mar 2000 07:08:59 -0800 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 RAA13032; Fri, 31 Mar 2000 17:08:54 +0200 (MET DST) Received: by lappi.waldorf-gmbh.de id ; Fri, 31 Mar 2000 13:59:40 +0200 Date: Fri, 31 Mar 2000 13:59:40 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: dagum@google.engr.sgi.com, linux-origin@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20000331135939.A5805@uni-koblenz.de> References: <20000331013535Z305168-3991+182@oss.sgi.com> <200003310151.RAA38622@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200003310151.RAA38622@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Thu, Mar 30, 2000 at 05:51:43PM -0800 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, Mar 30, 2000 at 05:51:43PM -0800, Kanoj Sarcar wrote: > Please make sure to send in a patch, resend it, resend it ..., > till it gets accepted. All the work we are doing outside > arch/* and include/asm-mips64/* has very limited benefit if > we do not push it into the main tree. > > Leo, I know you were going to do this anyway :-) Just taking > the opportunity to remind everyone else ... I should not that I'm a bit reluctant to push changes of which I neither know the status in detail nor know that I can blindly the version on oss to be the Only True One (TM) to their upstream maintainers. > Ralf, you mentioned about a 100K patch difference between > oss and pre3, I am hoping most of this is in the arch specific > stuff? Well, this was in the assumption that Linus takes my recent patch. He didn't, so our diff against stock kernel are now more like 400kb most of which are mips / mips64 architecture stuff and related drivers. As you say I'll keep resending ... > We probably need to look at the generic diffs, and push > as much of the mips64 related stuff into 2.3. When 2.4 comes > out, we should be able to take that source, the arch/mips64 > and include/asm-mips64 from oss, and be able to create a kernel > that will work well. Getting the diff down to zero is possible but it will take some more work. Ralf From owner-linux-origin@oss.sgi.com Fri Mar 31 14:18:41 2000 Received: by oss.sgi.com id ; Fri, 31 Mar 2000 14:18:29 -0800 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38764 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 31 Mar 2000 14:18:17 -0800 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 OAA06716 for ; Fri, 31 Mar 2000 14:21:55 -0800 (PST) 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 OAA74819 for linux-origin@oss.sgi.com; Fri, 31 Mar 2000 14:16:57 -0800 (PST) From: kanoj@google.engr.sgi.com (Kanoj Sarcar) Message-Id: <200003312216.OAA74819@google.engr.sgi.com> Subject: progress To: linux-origin@oss.sgi.com Date: Fri, 31 Mar 2000 14:16:57 -0800 (PST) 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 A SMP kernel now boots up the machine on a single cpu. We are going to start working on getting the other cpus from IO6prom into Linux init code next. Oh, and mips64 can grok ext2 now. You can try disk boots instead of nfsroot boots. Kanoj