From best3@ann.to Fri Sep 1 11:51:53 2000 Received: from smtp.livedoor.com (prx2.livedoor.com [203.104.131.4]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id LAA29099; Fri, 1 Sep 2000 11:51:51 +0200 (MET DST) Date: Fri, 1 Sep 2000 11:51:51 +0200 (MET DST) Received-Date: Fri, 1 Sep 2000 11:51:51 +0200 (MET DST) Received: (qmail 9097 invoked from network); 1 Sep 2000 09:51:13 -0000 Received: from unknown (HELO kosugi) (203.104.166.137) by prx2.livedoor.com with SMTP; 1 Sep 2000 09:51:13 -0000 From: best3 collection Subject: =?ISO-2022-JP?B?GyRCIiMiIj1FTVckSiQqQ04kaSQ7IiIiIxsoQg==?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Achi-Kochi Mail Lite ver1.00 Content-Length: 867 Lines: 33 $B$3$N%a!<%k$O%"%@%k%H%5%$%H$N@kEA$G$9!#(B 18$B:PL$K~$NJ}$d6=L#$N$J$$J}$O(B $B:o=|$7$F$/$@$5$$!#$*4j$$!W$7$^$9!#(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B ****************************************** http://m1.phathost.com/members/n-killer/ $B"#""(BADULT BOOKMARK BEST# COLLECTION$B"""#(B ******************************************** $B$3$N$?$S;d6&$O(B ADULT BOOKMARK BEST# COLLECTION$B$H$$$&%5%$%H$r%*!<%W%s$7$^$7$?!#(B $B%$%s%?!<%M%C%H=i?4 Subject: =?ISO-2022-JP?B?GyRCIiMiIj1FTVckSiQqQ04kaSQ7IiIiIxsoQg==?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Achi-Kochi Mail Lite ver1.00 Content-Length: 867 Lines: 33 $B$3$N%a!<%k$O%"%@%k%H%5%$%H$N@kEA$G$9!#(B 18$B:PL$K~$NJ}$d6=L#$N$J$$J}$O(B $B:o=|$7$F$/$@$5$$!#$*4j$$!W$7$^$9!#(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B $B"-(B ****************************************** http://m1.phathost.com/members/n-killer/ $B"#""(BADULT BOOKMARK BEST# COLLECTION$B"""#(B ******************************************** $B$3$N$?$S;d6&$O(B ADULT BOOKMARK BEST# COLLECTION$B$H$$$&%5%$%H$r%*!<%W%s$7$^$7$?!#(B $B%$%s%?!<%M%C%H=i?4 To: linux-arm-kernel@lists.arm.linux.org.uk, linux-m68k@lists.linux-m68k.org, linux-mac68k@mac.linux-m68k.org, linuxppc-dev@lists.linuxppc.org, linux-mips@fnet.fr, sparclinux@vger.kernel.org, ultralinux@vger.kernel.org, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ia64@linuxia64.org, linux-vm@vm.marist.edu, gniibe@chroot.org, kkojima@rr.iij4u.or.jp Subject: 2.4.0 do_fork() change, all architectures Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Sep 2000 12:27:23 +1100 Message-ID: <8124.967858043@ocs3.ocs-net> Content-Length: 18692 Lines: 486 This patch hits every arch so it is being cross mailed to every arch mailing list, apologies for duplicates. Please trim replies to the relevant mailing list. Also please cc: kaos@ocs.com.au on replies, I am not on every list. IA64 needs an extra parameter on do_fork() and copy_thread(), those functions are globally defined but arch local so there are changes to every architecture. For everything except IA64, the extra parameter is unused and is specified as 0. Sparc assembler changes by DaveM, blame me for everything else. If nobody complains, this patch against 2.4.0-test8-pre1 will go to Linus on Monday evening GMT. Index: 0-test8-pre1.1/kernel/fork.c --- 0-test8-pre1.1/kernel/fork.c Tue, 29 Aug 2000 15:22:12 +1100 kaos (linux-2.4/j/35_fork.c 1.1.1.9.1.6 644) +++ 0-test8-pre1.1(w)/kernel/fork.c Sat, 02 Sep 2000 11:34:02 +1100 kaos (linux-2.4/j/35_fork.c 1.1.1.9.1.6 644) @@ -528,10 +528,15 @@ /* * Ok, this is the main fork-routine. It copies the system process - * information (task[nr]) and sets up the necessary registers. It - * also copies the data segment in its entirety. + * information (task[nr]) and sets up the necessary registers. It also + * copies the data segment in its entirety. The "stack_start" and + * "stack_top" arguments are simply passed along to the platform + * specific copy_thread() routine. Most platforms ignore stack_top. + * For an example that's using stack_top, see + * arch/ia64/kernel/process.c. */ -int do_fork(unsigned long clone_flags, unsigned long usp, struct pt_regs *regs) +int do_fork(unsigned long clone_flags, unsigned long stack_start, unsigned long stack_top, + struct pt_regs *regs) { int retval = -ENOMEM; struct task_struct *p; @@ -628,7 +633,7 @@ goto bad_fork_cleanup_fs; if (copy_mm(clone_flags, p)) goto bad_fork_cleanup_sighand; - retval = copy_thread(0, clone_flags, usp, p, regs); + retval = copy_thread(0, clone_flags, stack_start, stack_top, p, regs); if (retval) goto bad_fork_cleanup_sighand; p->semundo = NULL; Index: 0-test8-pre1.1/include/linux/sched.h --- 0-test8-pre1.1/include/linux/sched.h Tue, 29 Aug 2000 15:22:12 +1100 kaos (linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644) +++ 0-test8-pre1.1(w)/include/linux/sched.h Sat, 02 Sep 2000 11:45:41 +1100 kaos (linux-2.4/Z/49_sched.h 1.1.1.7.1.3 644) @@ -708,7 +708,7 @@ extern int expand_fdset(struct files_struct *, int nr); extern void free_fdset(fd_set *, int); -extern int copy_thread(int, unsigned long, unsigned long, struct task_struct *, struct pt_regs *); +extern int copy_thread(int, unsigned long, unsigned long, unsigned long, struct task_struct *, struct pt_regs *); extern void flush_thread(void); extern void exit_thread(void); @@ -719,7 +719,7 @@ extern void daemonize(void); extern int do_execve(char *, char **, char **, struct pt_regs *); -extern int do_fork(unsigned long, unsigned long, struct pt_regs *); +extern int do_fork(unsigned long, unsigned long, unsigned long, struct pt_regs *); extern void FASTCALL(add_wait_queue(wait_queue_head_t *q, wait_queue_t * wait)); extern void FASTCALL(add_wait_queue_exclusive(wait_queue_head_t *q, wait_queue_t * wait)); Index: 0-test8-pre1.1/arch/s390/kernel/smp.c --- 0-test8-pre1.1/arch/s390/kernel/smp.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/Y/b/24_smp.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/s390/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/Y/b/24_smp.c 1.2 644) @@ -528,7 +528,7 @@ /* don't care about the psw and regs settings since we'll never reschedule the forked task. */ memset(®s,sizeof(pt_regs),0); - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } static void __init do_boot_cpu(int cpu) Index: 0-test8-pre1.1/arch/s390/kernel/process.c --- 0-test8-pre1.1/arch/s390/kernel/process.c Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/Y/b/35_process.c 1.2.1.1 644) +++ 0-test8-pre1.1(w)/arch/s390/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/Y/b/35_process.c 1.2.1.1 644) @@ -264,6 +264,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long new_stackp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct stack_frame @@ -313,7 +314,7 @@ int ret; lock_kernel(); - ret = do_fork(SIGCHLD, regs.gprs[15], ®s); + ret = do_fork(SIGCHLD, regs.gprs[15], 0, ®s); unlock_kernel(); return ret; } @@ -329,7 +330,7 @@ newsp = regs.gprs[2]; if (!newsp) newsp = regs.gprs[15]; - ret = do_fork(clone_flags, newsp, ®s); + ret = do_fork(clone_flags, newsp, 0, ®s); unlock_kernel(); return ret; } @@ -347,7 +348,7 @@ asmlinkage int sys_vfork(struct pt_regs regs) { return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, - regs.gprs[15], ®s); + regs.gprs[15], 0, ®s); } /* Index: 0-test8-pre1.1/arch/mips64/kernel/syscall.c --- 0-test8-pre1.1/arch/mips64/kernel/syscall.c Tue, 01 Aug 2000 16:55:46 +1000 kaos (linux-2.4/a/c/16_syscall.c 1.1.1.4 644) +++ 0-test8-pre1.1(w)/arch/mips64/kernel/syscall.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/a/c/16_syscall.c 1.1.1.4 644) @@ -77,7 +77,7 @@ int res; save_static(®s); - res = do_fork(SIGCHLD, regs.regs[29], ®s); + res = do_fork(SIGCHLD, regs.regs[29], 0, ®s); return res; } @@ -92,7 +92,7 @@ newsp = regs.regs[5]; if (!newsp) newsp = regs.regs[29]; - res = do_fork(clone_flags, newsp, ®s); + res = do_fork(clone_flags, newsp, 0, ®s); return res; } Index: 0-test8-pre1.1/arch/mips64/kernel/process.c --- 0-test8-pre1.1/arch/mips64/kernel/process.c Thu, 13 Jul 2000 18:35:31 +1000 kaos (linux-2.4/a/c/31_process.c 1.5 644) +++ 0-test8-pre1.1(w)/arch/mips64/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/a/c/31_process.c 1.5 644) @@ -69,6 +69,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/sh/kernel/process.c --- 0-test8-pre1.1/arch/sh/kernel/process.c Sat, 22 Jul 2000 18:25:55 +1000 kaos (linux-2.4/d/c/21_process.c 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/sh/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/d/c/21_process.c 1.1.1.3 644) @@ -211,6 +211,7 @@ asmlinkage void ret_from_fork(void); int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct pt_regs *childregs; @@ -292,7 +293,7 @@ unsigned long r6, unsigned long r7, struct pt_regs regs) { - return do_fork(SIGCHLD, regs.regs[15], ®s); + return do_fork(SIGCHLD, regs.regs[15], 0, ®s); } asmlinkage int sys_clone(unsigned long clone_flags, unsigned long newsp, @@ -301,7 +302,7 @@ { if (!newsp) newsp = regs.regs[15]; - return do_fork(clone_flags, newsp, ®s); + return do_fork(clone_flags, newsp, 0, ®s); } /* @@ -318,7 +319,7 @@ unsigned long r6, unsigned long r7, struct pt_regs regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.regs[15], ®s); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.regs[15], 0, ®s); } /* Index: 0-test8-pre1.1/arch/arm/kernel/process.c --- 0-test8-pre1.1/arch/arm/kernel/process.c Tue, 15 Aug 2000 17:59:12 +1000 kaos (linux-2.4/f/c/43_process.c 1.1.1.5 644) +++ 0-test8-pre1.1(w)/arch/arm/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/f/c/43_process.c 1.1.1.5 644) @@ -291,6 +291,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long esp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/arm/kernel/sys_arm.c --- 0-test8-pre1.1/arch/arm/kernel/sys_arm.c Wed, 19 Jul 2000 17:53:13 +1000 kaos (linux-2.4/f/c/50_sys_arm.c 1.4 644) +++ 0-test8-pre1.1(w)/arch/arm/kernel/sys_arm.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/f/c/50_sys_arm.c 1.4 644) @@ -203,7 +203,7 @@ */ asmlinkage int sys_fork(struct pt_regs *regs) { - return do_fork(SIGCHLD, regs->ARM_sp, regs); + return do_fork(SIGCHLD, regs->ARM_sp, 0, regs); } /* Clone a task - this clones the calling program thread. @@ -213,12 +213,12 @@ { if (!newsp) newsp = regs->ARM_sp; - return do_fork(clone_flags, newsp, regs); + return do_fork(clone_flags, newsp, 0, regs); } asmlinkage int sys_vfork(struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->ARM_sp, regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->ARM_sp, 0, regs); } /* sys_execve() executes a new program. Index: 0-test8-pre1.1/arch/sparc64/kernel/entry.S --- 0-test8-pre1.1/arch/sparc64/kernel/entry.S Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/i/c/20_entry.S 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/sparc64/kernel/entry.S Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/i/c/20_entry.S 1.1.1.3 644) @@ -911,7 +911,7 @@ mov SIGCHLD, %o0 sys_clone: flushw movrz %o1, %fp, %o1 - nop + mov 0, %o3 ba,pt %xcc, do_fork add %sp, STACK_BIAS + REGWIN_SZ, %o2 ret_from_syscall: Index: 0-test8-pre1.1/arch/sparc64/kernel/process.c --- 0-test8-pre1.1/arch/sparc64/kernel/process.c Thu, 24 Aug 2000 03:13:10 +1000 kaos (linux-2.4/i/c/25_process.c 1.6 644) +++ 0-test8-pre1.1(w)/arch/sparc64/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/i/c/25_process.c 1.6 644) @@ -573,6 +573,7 @@ * do_fork(). */ int copy_thread(int nr, unsigned long clone_flags, unsigned long sp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct thread_struct *t = &p->thread; Index: 0-test8-pre1.1/arch/m68k/kernel/process.c --- 0-test8-pre1.1/arch/m68k/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/l/c/42_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/m68k/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/l/c/42_process.c 1.2 644) @@ -181,12 +181,12 @@ asmlinkage int m68k_fork(struct pt_regs *regs) { - return do_fork(SIGCHLD, rdusp(), regs); + return do_fork(SIGCHLD, rdusp(), 0, regs); } asmlinkage int m68k_vfork(struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), 0, regs); } asmlinkage int m68k_clone(struct pt_regs *regs) @@ -199,10 +199,11 @@ newsp = regs->d2; if (!newsp) newsp = rdusp(); - return do_fork(clone_flags, newsp, regs); + return do_fork(clone_flags, newsp, 0, regs); } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/ppc/kernel/smp.c --- 0-test8-pre1.1/arch/ppc/kernel/smp.c Fri, 14 Jul 2000 19:35:46 +1000 kaos (linux-2.4/q/c/36_smp.c 1.1.1.3 644) +++ 0-test8-pre1.1(w)/arch/ppc/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/q/c/36_smp.c 1.1.1.3 644) @@ -347,7 +347,7 @@ /* create a process for the processor */ /* we don't care about the values in regs since we'll never reschedule the forked task. */ - if (do_fork(CLONE_VM|CLONE_PID, 0, ®s) < 0) + if (do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s) < 0) panic("failed fork for CPU %d", i); p = init_task.prev_task; if (!p) Index: 0-test8-pre1.1/arch/ppc/kernel/process.c --- 0-test8-pre1.1/arch/ppc/kernel/process.c Wed, 21 Jun 2000 12:24:29 +1000 kaos (linux-2.4/r/c/11_process.c 1.1.1.1 644) +++ 0-test8-pre1.1(w)/arch/ppc/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/r/c/11_process.c 1.1.1.1 644) @@ -315,6 +315,7 @@ */ int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { unsigned long msr; @@ -446,7 +447,7 @@ unsigned long clone_flags = p1; int res; lock_kernel(); - res = do_fork(clone_flags, regs->gpr[1], regs); + res = do_fork(clone_flags, regs->gpr[1], 0, regs); #ifdef CONFIG_SMP /* When we clone the idle task we keep the same pid but * the return value of 0 for both causes problems. @@ -465,7 +466,7 @@ int res; - res = do_fork(SIGCHLD, regs->gpr[1], regs); + res = do_fork(SIGCHLD, regs->gpr[1], 0, regs); #ifdef CONFIG_SMP /* When we clone the idle task we keep the same pid but * the return value of 0 for both causes problems. @@ -480,7 +481,7 @@ asmlinkage int sys_vfork(int p1, int p2, int p3, int p4, int p5, int p6, struct pt_regs *regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->gpr[1], regs); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs->gpr[1], 0, regs); } asmlinkage int sys_execve(unsigned long a0, unsigned long a1, unsigned long a2, Index: 0-test8-pre1.1/arch/mips/kernel/syscall.c --- 0-test8-pre1.1/arch/mips/kernel/syscall.c Tue, 11 Jul 2000 00:21:05 +1000 kaos (linux-2.4/u/c/17_syscall.c 1.3 644) +++ 0-test8-pre1.1(w)/arch/mips/kernel/syscall.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/u/c/17_syscall.c 1.3 644) @@ -97,7 +97,7 @@ int res; save_static(®s); - res = do_fork(SIGCHLD, regs.regs[29], ®s); + res = do_fork(SIGCHLD, regs.regs[29], 0, ®s); return res; } @@ -112,7 +112,7 @@ newsp = regs.regs[5]; if (!newsp) newsp = regs.regs[29]; - res = do_fork(clone_flags, newsp, ®s); + res = do_fork(clone_flags, newsp, 0, ®s); return res; } Index: 0-test8-pre1.1/arch/mips/kernel/process.c --- 0-test8-pre1.1/arch/mips/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/u/c/26_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/mips/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/u/c/26_process.c 1.2 644) @@ -72,6 +72,7 @@ } int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; Index: 0-test8-pre1.1/arch/sparc/kernel/process.c --- 0-test8-pre1.1/arch/sparc/kernel/process.c Wed, 12 Jul 2000 11:58:08 +1000 kaos (linux-2.4/w/c/50_process.c 1.4 644) +++ 0-test8-pre1.1(w)/arch/sparc/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/w/c/50_process.c 1.4 644) @@ -462,6 +462,7 @@ #endif int copy_thread(int nr, unsigned long clone_flags, unsigned long sp, + unsigned long unused, struct task_struct *p, struct pt_regs *regs) { struct pt_regs *childregs; Index: 0-test8-pre1.1/arch/sparc/kernel/entry.S --- 0-test8-pre1.1/arch/sparc/kernel/entry.S Wed, 21 Jun 2000 12:24:29 +1000 kaos (linux-2.4/x/c/6_entry.S 1.1.1.1 644) +++ 0-test8-pre1.1(w)/arch/sparc/kernel/entry.S Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/x/c/6_entry.S 1.1.1.1 644) @@ -1391,6 +1391,7 @@ mov %fp, %o1 ! arg1: usp std %g4, [%curptr + AOFF_task_thread + AOFF_thread_fork_kpsr] add %sp, REGWIN_SZ, %o2 ! arg2: pt_regs ptr + mov 0, %o3 call C_LABEL(do_fork) mov %l5, %o7 @@ -1413,6 +1414,7 @@ 1: std %g4, [%curptr + AOFF_task_thread + AOFF_thread_fork_kpsr] add %sp, REGWIN_SZ, %o2 ! arg2: pt_regs ptr + mov 0, %o3 call C_LABEL(do_fork) mov %l5, %o7 @@ -1430,6 +1432,7 @@ mov %fp, %o1 or %o0, %lo(0x4000 | 0x0100 | SIGCHLD), %o0 sethi %hi(C_LABEL(do_fork)), %l1 + mov 0, %o3 jmpl %l1 + %lo(C_LABEL(do_fork)), %g0 add %sp, REGWIN_SZ, %o2 Index: 0-test8-pre1.1/arch/alpha/kernel/smp.c --- 0-test8-pre1.1/arch/alpha/kernel/smp.c Sat, 05 Aug 2000 13:33:35 +1000 kaos (linux-2.4/y/c/9_smp.c 1.1.1.2.1.2 644) +++ 0-test8-pre1.1(w)/arch/alpha/kernel/smp.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/y/c/9_smp.c 1.1.1.2.1.2 644) @@ -420,7 +420,7 @@ * don't care about the regs settings since * we'll never reschedule the forked task. */ - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } /* Index: 0-test8-pre1.1/arch/alpha/kernel/process.c --- 0-test8-pre1.1/arch/alpha/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/y/c/13_process.c 1.2 644) +++ 0-test8-pre1.1(w)/arch/alpha/kernel/process.c Sat, 02 Sep 2000 11:30:29 +1100 kaos (linux-2.4/y/c/13_process.c 1.2 644) @@ -276,14 +276,14 @@ { if (!usp) usp = rdusp(); - return do_fork(clone_flags, usp, (struct pt_regs *) (swstack+1)); + return do_fork(clone_flags, usp, 0, (struct pt_regs *) (swstack+1)); } int alpha_vfork(struct switch_stack * swstack) { return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, rdusp(), - (struct pt_regs *) (swstack+1)); + 0, (struct pt_regs *) (swstack+1)); } /* @@ -299,6 +299,7 @@ int copy_thread(int nr, unsigned long clone_flags, unsigned long usp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { extern void ret_from_sys_call(void); Index: 0-test8-pre1.1/arch/i386/kernel/smpboot.c --- 0-test8-pre1.1/arch/i386/kernel/smpboot.c Thu, 24 Aug 2000 03:13:10 +1000 kaos (linux-2.4/z/c/29_smpboot.c 1.1.1.2 644) +++ 0-test8-pre1.1(w)/arch/i386/kernel/smpboot.c Sat, 02 Sep 2000 11:30:30 +1100 kaos (linux-2.4/z/c/29_smpboot.c 1.1.1.2 644) @@ -497,7 +497,7 @@ * don't care about the eip and regs settings since * we'll never reschedule the forked task. */ - return do_fork(CLONE_VM|CLONE_PID, 0, ®s); + return do_fork(CLONE_VM|CLONE_PID, 0, 0, ®s); } #if APIC_DEBUG Index: 0-test8-pre1.1/arch/i386/kernel/process.c --- 0-test8-pre1.1/arch/i386/kernel/process.c Tue, 11 Jul 2000 11:25:12 +1000 kaos (linux-2.4/z/c/47_process.c 1.1.2.3.1.1.1.2 644) +++ 0-test8-pre1.1(w)/arch/i386/kernel/process.c Sat, 02 Sep 2000 11:31:25 +1100 kaos (linux-2.4/z/c/47_process.c 1.1.2.3.1.1.1.2 644) @@ -525,6 +525,7 @@ asm volatile("movl %%" #seg ",%0":"=m" (*(int *)&(value))) int copy_thread(int nr, unsigned long clone_flags, unsigned long esp, + unsigned long unused, struct task_struct * p, struct pt_regs * regs) { struct pt_regs * childregs; @@ -686,7 +687,7 @@ asmlinkage int sys_fork(struct pt_regs regs) { - return do_fork(SIGCHLD, regs.esp, ®s); + return do_fork(SIGCHLD, regs.esp, 0, ®s); } asmlinkage int sys_clone(struct pt_regs regs) @@ -698,7 +699,7 @@ newsp = regs.ecx; if (!newsp) newsp = regs.esp; - return do_fork(clone_flags, newsp, ®s); + return do_fork(clone_flags, newsp, 0, ®s); } /* @@ -713,7 +714,7 @@ */ asmlinkage int sys_vfork(struct pt_regs regs) { - return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.esp, ®s); + return do_fork(CLONE_VFORK | CLONE_VM | SIGCHLD, regs.esp, 0, ®s); } /* From kaos@ocs.com.au Sat Sep 2 04:18:59 2000 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id EAA09156; Sat, 2 Sep 2000 04:18:52 +0200 (MET DST) Received-Date: Sat, 2 Sep 2000 04:18:52 +0200 (MET DST) Received: (qmail 7031 invoked from network); 2 Sep 2000 02:18:47 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 2 Sep 2000 02:18:47 -0000 Date: Sat, 02 Sep 2000 13:18:46 +1100 Message-ID: <8893.967861126@ocs3.ocs-net> From: Keith Owens Subject: 2.4.0 do_fork() change, all architectures - take 2 Content-Length: 2333 Lines: 62 ------- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: linux-kernel@vger.kernel.org Subject: 2.4.0 do_fork() change, all architectures - take 2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Sep 2000 13:18:46 +1100 Message-ID: <8893.967861126@ocs3.ocs-net> DaveM pointed out that my 2.4.0-test8-pre1 do_fork patch would generate better sparc assembler if the extra parameter to do_fork was added at the end instead of in the middle. So change all do_fork(flags,sp,0,®s) to do_fork(flags,sp,®s,0); I'm not going to mail the complete patch again, you can get it from ftp://ftp.ocs.com.au/pub/do_fork-2.4.0-test8-take2.gz. The only significant difference is this bit to IA64, untested. Index: 0-test8-pre1.1/arch/ia64/kernel/entry.S - --- 0-test8-pre1.1/arch/ia64/kernel/entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos (linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644) +++ 0-test8-pre1.2(w)/arch/ia64/kernel/entry.S Sat, 02 Sep 2000 12:49:16 +1100 kaos (linux-2.4/c/c/16_entry.S 1.3.1.1.1.2 644) @@ -68,8 +68,8 @@ mov loc1=r16 // save ar.pfs across do_fork UNW(.body) mov out1=in1 - - mov out2=in2 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp // out3 = ®s + mov out3=in2 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s mov out0=in0 // out0 = clone_flags br.call.sptk.few rp=do_fork .ret1: UNW(.restore sp) @@ -87,8 +87,8 @@ mov loc1=r16 // save ar.pfs across do_fork UNW(.body) mov out1=in1 - - mov out2=0 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp // out3 = ®s + mov out3=0 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s mov out0=in0 // out0 = clone_flags br.call.sptk.few rp=do_fork .ret2: UNW(.restore sp) Index: 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S - --- 0-test8-pre1.1/arch/ia64/ia32/ia32_entry.S Tue, 15 Aug 2000 17:50:48 +1000 kaos (linux-2.4/c/c/25_ia32_entry 1.3.1.1 644) +++ 0-test8-pre1.2(w)/arch/ia64/ia32/ia32_entry.S Sat, 02 Sep 2000 12:49:58 +1100 kaos (linux-2.4/c/c/25_ia32_entry 1.3.1.1 644) @@ -91,8 +91,8 @@ UNW(.body) mov out1=0 - - mov out2=0 - - adds out3=IA64_SWITCH_STACK_SIZE+16,sp + mov out3=0 + adds out2=IA64_SWITCH_STACK_SIZE+16,sp // out2 = ®s br.call.sptk.few rp=do_fork .ret3: mov ar.pfs=loc1 UNW(.restore sp) ------- End of Blind-Carbon-Copy From ralf@uni-koblenz.de Sun Sep 3 18:43:46 2000 Received: from u-43.karlsruhe.ipdial.viaginterkom.de (u-43.karlsruhe.ipdial.viaginterkom.de [62.180.19.43]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA23301; Sun, 3 Sep 2000 18:43:45 +0200 (MET DST) Received-Date: Sun, 3 Sep 2000 18:43:45 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sat, 2 Sep 2000 14:04:51 +0200 Date: Sat, 2 Sep 2000 14:04:51 +0200 From: Ralf Baechle To: Keith Owens Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: 2.4.0 do_fork() change, all architectures Message-ID: <20000902140451.B560@bacchus.dhis.org> References: <8124.967858043@ocs3.ocs-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <8124.967858043@ocs3.ocs-net>; from kaos@ocs.com.au on Sat, Sep 02, 2000 at 12:27:23PM +1100 X-Accept-Language: de,en,fr Content-Length: 744 Lines: 17 On Sat, Sep 02, 2000 at 12:27:23PM +1100, Keith Owens wrote: > This patch hits every arch so it is being cross mailed to every arch > mailing list, apologies for duplicates. Please trim replies to the > relevant mailing list. Also please cc: kaos@ocs.com.au on replies, I > am not on every list. > > IA64 needs an extra parameter on do_fork() and copy_thread(), those > functions are globally defined but arch local so there are changes to > every architecture. For everything except IA64, the extra parameter is > unused and is specified as 0. Sparc assembler changes by DaveM, blame > me for everything else. If nobody complains, this patch against > 2.4.0-test8-pre1 will go to Linus on Monday evening GMT. MIPS bits are ok. Ralf From misuzuchan@every-mail.com Mon Sep 4 18:34:34 2000 Received: from sweet.ocn.ne.jp (sweet.ocn.ne.jp [210.232.239.114]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08572; Mon, 4 Sep 2000 18:34:32 +0200 (MET DST) Received-Date: Mon, 4 Sep 2000 18:34:32 +0200 (MET DST) Received: from misuzu (p05-dna02arikawa.nagasaki.ocn.ne.jp [210.190.217.69]) by sweet.ocn.ne.jp (8.9.1a/OCN/) with SMTP id BAA26753; Tue, 5 Sep 2000 01:34:11 +0900 (JST) Date: Tue, 5 Sep 2000 01:34:11 +0900 (JST) Message-Id: <200009041634.BAA26753@sweet.ocn.ne.jp> From: misuzu Subject: =?ISO-2022-JP?B?GyRCJE8kOCRhJF4kNyRGGyhC?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Achi-Kochi Mail Lite ver1.00 Content-Length: 5407 Lines: 108 $B$O$8$a$^$7$F(B $BFMA3$N%a!<%k$G<:NiCW$7$^$9!#(B $B@hF|!!;d$N$b$H$X2<5-$N$h$&$J%a!<%k$,FO$-$^$7$?!#(B $BFI$s$G$_$k$H!!$*$b$7$m$=$&$G$7$?$N$G(B $B$"$J$?MM$X$b!!$40FFb$5$7$"$2$^$7$?!#(B $B$b$7$4LBOG$G$7$?$i!!0J8eAw$j$^$;$s$N$G(B $B$*/;qK\$GG|Bg$JMx1W;O$a$^$;$s$+!*(B $B@hF|!"2<5-$N$h$&$Je$N?69~$"$j!K(B $BM7$S?4$r8f;}$A$NJ}$@$1!"@'Hs;22C$7$F2<$5$$!#(B $B4JC1$KBg6b$,F~$C$F$/$k!"$H$$$&e$NBg6b!J!o#1#0#0K|1_0J>e!K$r?.H>5?$GBT$C$F$$$k$H!"MbF|$K#1(B,000$B1_$N?69~$,#17o$"$j$^$7$?!#e$N?69~$,!"KhF|!"B+$K$J$C$FMh$k$h$&$K$J$j$^$7$?!#(B $BGO/$J$/$H$b5.J}$NG/<}$h$j$bB?$/$J$kH&(B...$B!#(B $B$^$"!!Hi;;MQ$r$7$F$$$F$b;EJ}$"$j$^$;$s$,(B...$B!#(B $B!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!]!](B $B!!"#;22CJ}K!"#(B 1)$B@h$:!"$3$NMQ;f$K=q$$$F$"$k%j%9%H$N#4?M$N6d9T8}:B$K!o#1!$#0#0#01_$E$D?69~$_$^$9!#(B 2)$B2<5-$N%j%9%H#4?M$KAw6b$7$?8e!"%j%9%H$N0lHV>e$N?M$r:o=|$7!"2<$N?M$r7+$j>e$2$^$9!#(B $B$=$&$9$k$H!!#4HVL\$,6u$$$F$-$^$9$+$i!"$=$3$K5.J}$N6d9T8}:BHV9f$r5-F~$7$^$9(B $B!J$3$&$7$F=gHV$K>e$N?M$,H4$1$F$$$/$N$G0cK!@-$O$J$$!"$H$$$&J[8n;N$NJ}$N@bL@$,$"$j$^$7$?(B $B!!!!!=M-8BO":?!K!#(B 3)$B$3$3$+$i$,!"5.J}$N3hF0$G$9!#(B $B5.J}$N2C$o$C$??7$7$$%j%9%H$r=PMh$k$@$1B?$/$N?M$K#D#M$7$^$9!#(B $B!!:G=i$N#1=54V$G#1#07o0J>e$N?69~$,L5$$>l9g$O%R%H%U%s%P%j$7$^$9!#(B $B!!!!#D#M$NJ?6QE*@.2L$O(B0.3$B!A(B0.5$B!s0L$G$9!#(B $B!!!!8e$O!"8=6b!o#1!$#0#0#01_$,?69~$^$l$k$N$rBT$D$@$1!#(B $B!!!!#1CJL\$N@.2L!)(B $B!!!!!J!o#1!$#0#0#01_!_#1#0?M!a!o#1K|1_!)!K(B $B!!!!#2CJL\$N@.2L!)(B $B!!!!!J!o#1!$#0#0#01_!_#1#0?M!_#1#0?M!a!o#1#0K|1_!)!K(B $B!!!!#3CJL\$N@.2L!)(B $B!!!!!J!o#1!$#0#0#01_!_#1#0?M!_#1#0?M!_#1#0?M!a!o#1#0#0K|1_!)!K(B $B!!!!#4CJL\$N@.2L!)(B $B!!!!!J!o#1(B,$B#0#0#01_!_#1#0?M!_#1#0?M!_#1#0?M!_#1#0?M!a!o#1(B,$B#0#0#0K|1_!)!K(B $B"($*6b$rAw$i$J$$$G%j%9%H$K<+J,$NL>A0$r:\$;$k$H!"D>$0$K$P$l$^$9$+$i!"$$$m$$$m$J967b$re$N%d%D$r:o=|$7$^$9!#$D$^$j!"(B1$BHV$O>C$7!"(B2$BHV$,(B1$BHV$K!"(B3$BHV$,(B2$BHV$K!"(B4$BHV$,(B3$BHV$K$/$k$H!"(B 4$BHV$,6u$-$^$9!#$=$3$K!"$"$J$?$N8}:B$r=q$-$^$9!#(B $B$"$H$O!"#4$D$N8}:B$K!"HV9f$r>e$+$i=g$K?6$j$J$*$7$^$9!#(B $B$=$l$r!"$G$-$k$@$1$?$/$5$s%$%s%?!<%M%C%H$N7G<(HD$d%a!<%k$G@kEA$7$F2<$5$$!*$=$l$@$1$G$9!*(B $B$=$&$9$l$P!"$"$H$O$=$l$re$N8}:B$r:o=|$9$k$+$i!"K!N'$K?($l$J$$$G:Q$`$N$G$9!#$=$l$@$1$O@dBP$KJ$1$FJXMx$G$9$h!#(B $B$?$H$($P!"%3%s%S%K$r3+6H$9$k$?$a$K$b3+6H;q6b$H$$$&$N$,MW$j$^$9$M!#(B $B$9$J$o$A>&IJ$N$*J[Ev$rGc$C$?$j!"4L%8%e!<%9$rGc$C$?$j!#(B $B$@$+$i!"$I$s$J%S%8%M%9$K$b3+6H;q6b$H$$$&$N$OI,MW$J$N$G$9!#(B $B$"$J$?$,?6$j9~$`;M@i1_$O!"3+6H;q6b$H$*9M$(2<$5$$!#(B $B!c;29M!d(B $B!|8f?4G[$JJ}$N$?$a$K!"4X785-;v$r5-$7$F$*$-$^$9!#(B $B!cJ[8n;N$N0U8+!d(B $B$3$l$O$h$/8@$o$l$k%M%:%_9V$d%^%k%A>&K!$G$O$"$j$^$;$s!#(B $B0J2<$K=q$+$l$F$$$^$9$h$&$K2q0w$rAM;;<0$K3HBg$5$;$k$3$H$r>r7o$H$9$kL58BO":?9V$dO":?HNGde$N?M$,H4$1$F$$$/$N$G!!0cK!@-$O$"$j$^$;$s!#(B **************************************** $B:G8e$^$GFI$s$GD:$-!!$"$j$,$H$&$4$6$$$^$7$?!#(B From rabeeh@galileo.co.il Mon Sep 4 14:22:53 2000 Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA06100; Mon, 4 Sep 2000 14:22:50 +0200 (MET DST) Received-Date: Mon, 4 Sep 2000 14:22:50 +0200 (MET DST) Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id PAA00344 for ; Mon, 4 Sep 2000 15:22:42 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <39B3F79F.FE75788F@galileo.co.il> Date: Mon, 04 Sep 2000 15:27:27 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: mod utils in mipseb Content-Type: multipart/mixed; boundary="------------ECABF706C9E8554A5980B8DD" Content-Length: 791 Lines: 35 This is a multi-part message in MIME format. --------------ECABF706C9E8554A5980B8DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm looking for the mod utils package (insmod and stuff) Does any one know where can I find it ? Regards, Rabeeh --------------ECABF706C9E8554A5980B8DD Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------ECABF706C9E8554A5980B8DD-- From ralf@oss.sgi.com Tue Sep 5 03:11:47 2000 Received: from u-214.karlsruhe.ipdial.viaginterkom.de (u-214.karlsruhe.ipdial.viaginterkom.de [62.180.19.214]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA16004; Tue, 5 Sep 2000 03:11:45 +0200 (MET DST) Received-Date: Tue, 5 Sep 2000 03:11:45 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 5 Sep 2000 00:12:19 +0200 Date: Tue, 5 Sep 2000 00:12:19 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: _syscallX macros ... Message-ID: <20000905001219.A1660@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Content-Length: 1750 Lines: 42 Once more a lesson why you shouldn't use the _syscallX macros from . This is disassembled from modutils which missbehaves royally on MIPS64 which doesn't implement delete_module(2) & friends for the 32-bit compat code: 409240: 3c1c0fc2 lui $gp,0xfc2 409244: 279c9bc0 addiu $gp,$gp,-25664 409248: 0399e021 addu $gp,$gp,$t9 40924c: 27bdffe0 addiu $sp,$sp,-32 409250: afbc0010 sw $gp,16($sp) 409254: afbf001c sw $ra,28($sp) 409258: afbc0018 sw $gp,24($sp) 40925c: 00801021 move $v0,$a0 409260: 00402021 move $a0,$v0 409264: 24021021 li $v0,4129 409268: 0000000c syscall $v0 should now contain either the result or if $a3 is set the error code. 40926c: 10e00008 beqz $a3,409290 409270: 00000000 nop 409274: 8f9980e0 lw $t9,-32544($gp) 409278: 00000000 nop 40927c: 0320f809 jalr $t9 409280: 00000000 nop Whoops - the call did just clobber $a0 ... 409284: 8fbc0010 lw $gp,16($sp) 409288: ac420000 sw $v0,0($v0) 40928c: 2402ffff li $v0,-1 409290: 8fbf001c lw $ra,28($sp) 409294: 00000000 nop 409298: 03e00008 jr $ra 40929c: 27bd0020 addiu $sp,$sp,32 Kernel fix is on it's way into cvs and as usual in such a case - recompile affected apps ... I don't have a list available but in any case modutils is one of them and e2fsprogs should also be affected. Btw, Cobalt's kernel is also affected. Ralf From <@Cologne.DE:karsten@excalibur.cologne.de> Wed Sep 6 23:40:33 2000 Received: from fileserv2.Cologne.DE (fileserv2.cologne.de [195.227.25.6]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id XAA23692; Wed, 6 Sep 2000 23:40:32 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 23:40:32 +0200 (MET DST) Received: from localhost (1147 bytes) by fileserv2.Cologne.DE via rmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Wed, 6 Sep 2000 23:40:21 +0200 (CEST) (Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19) Received: (from karsten@localhost) by excalibur.cologne.de (8.9.3/8.8.7) id TAA15340; Tue, 5 Sep 2000 19:10:29 +0200 Message-ID: <20000905191029.A14965@excalibur.cologne.de> Date: Tue, 5 Sep 2000 19:10:29 +0200 From: Karsten Merker To: linux-mips@fnet.fr Subject: Error in arch/mips/dec/time.c? Mail-Followup-To: linux-mips@fnet.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-No-Archive: yes Content-Length: 557 Lines: 20 Hallo everyone, in the current cvs kernel snapshot from oss.sgi.com I have an undeclared variable real_year in arch/mips/dec/time.c. This should be declared as void __init time_init(void) { unsigned int real_year, year, mon, day, hour, min, sec; int i; [...] Is my checkout broken or is this a bug in the cvs? Greetings, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From rabeeh@galileo.co.il Tue Sep 5 13:35:07 2000 Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA23032; Tue, 5 Sep 2000 13:35:04 +0200 (MET DST) Received-Date: Tue, 5 Sep 2000 13:35:04 +0200 (MET DST) Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id OAA08915 for ; Tue, 5 Sep 2000 14:34:57 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <39B53DF0.80BE4104@galileo.co.il> Date: Tue, 05 Sep 2000 14:39:44 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: modules in kernel 2.2.14 Content-Type: multipart/mixed; boundary="------------3777F7F489B8E60E0D0F1E03" Content-Length: 1391 Lines: 58 This is a multi-part message in MIME format. --------------3777F7F489B8E60E0D0F1E03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm running Kernel 2.2.14 with the Manhatten RPM's I compiled modutils the I took from RedHat 6.1 SRPM and generated insmod I copied the kernel header files to directory /usr/src/linux.2.2.14, then tried the following module : file module.c #define MODULE #include int init_module (void) {printk ("<1>Hello, world\n");return 0;} void cleanup_module(void) {printk ("<1>Goodbye cruel world\n");} gcc -c -I/usr/src/linux.2.2.14/include/ module.c insmod module.o and I get the following errir : module.o: unresolved symbol _gp_disp Where this symbol missing, in the kernel or in the module ??!! Did any one encounter this kind of problem ? or have any alternative solution ? Regards, Rabeeh --------------3777F7F489B8E60E0D0F1E03 Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------3777F7F489B8E60E0D0F1E03-- From jsun@mvista.com Wed Sep 6 00:35:13 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA01740; Wed, 6 Sep 2000 00:35:12 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 00:35:12 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id PAA31766; Tue, 5 Sep 2000 15:34:40 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39B57500.F08575D5@mvista.com> Date: Tue, 05 Sep 2000 15:34:40 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@fnet.fr, linux@engr.sgi.com Subject: infinite loop in default_be_board_handler() Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 707 Lines: 28 I found the following code in arch/mips/kernel/traps.c file, which looks like a hack to me. Is there any reason the infinite loop should be there? Jun static void default_be_board_handler(struct pt_regs *regs) { unsigned long new_epc; unsigned long fixup = search_dbe_table(regs->cp0_epc); if (fixup) { new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); regs->cp0_epc = new_epc; return; } /* * Assume it would be too dangerous to continue ... */ /* XXX */ printk("Got Bus Error at %08x\n", (unsigned int)regs->cp0_epc); show_regs(regs); while(1); force_sig(SIGBUS, current); } From jsun@mvista.com Wed Sep 6 05:43:50 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA05856; Wed, 6 Sep 2000 05:43:45 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 05:43:45 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id UAA07021; Tue, 5 Sep 2000 20:42:12 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39B5BD14.A8D2F467@mvista.com> Date: Tue, 05 Sep 2000 20:42:12 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-fbdev@vuser.vu.union.edu, linux@oss.sgi.com, linux-mips@fnet.fr Subject: mmap() frame buffer causes bus error on MIPS ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 944 Lines: 26 With the help from Attila, I got the latest tdfx framebuffer driver working on my NEC DDB5476 board. I have console working based on this driver. However, when I try to mmap frame buffer into user land, the mapping is succesful, but trying to read the buffer causes a bus error. I tried to trace the kernel using gdb. fb_mmap() seems to do the right thing : 1) it calls fb->fb_get_fix() to get the buffer address, size, etc. The values all look fine. The address is physical address, pointing a mapped PCI memory block. I verified that I can access that address in gdb. 2) for MIPS, fb_mmap() turns off CACHE bit for the page. I would imagine when the app tries to read the buffer, a TLB miss is generated. TLB refill routine probably sets up the right TLB entry, and the app will try to read again, and get the content. I really can't think of where the Bus error might occur. Does anybody have a clue here? Thanks a lot. Jun From jsun@mvista.com Wed Sep 6 07:50:18 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id HAA07818; Wed, 6 Sep 2000 07:50:14 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 07:50:14 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id WAA09387; Tue, 5 Sep 2000 22:48:43 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39B5DABB.7FB85B09@mvista.com> Date: Tue, 05 Sep 2000 22:48:43 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-fbdev@vuser.vu.union.edu, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: mmap() frame buffer causes bus error on MIPS ... References: <39B5BD14.A8D2F467@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3034 Lines: 83 Jun Sun wrote: > > With the help from Attila, I got the latest tdfx framebuffer driver > working on my NEC DDB5476 board. I have console working based on this > driver. > > However, when I try to mmap frame buffer into user land, the mapping is > succesful, but trying to read the buffer causes a bus error. > > I tried to trace the kernel using gdb. fb_mmap() seems to do the right > thing : > > 1) it calls fb->fb_get_fix() to get the buffer address, size, etc. The > values all look fine. The address is physical address, pointing a > mapped PCI memory block. I verified that I can access that address in > gdb. > > 2) for MIPS, fb_mmap() turns off CACHE bit for the page. > > I would imagine when the app tries to read the buffer, a TLB miss is > generated. TLB refill routine probably sets up the right TLB entry, and > the app will try to read again, and get the content. I really can't > think of where the Bus error might occur. > > Does anybody have a clue here? Thanks a lot. > > Jun Did more probing on this. It appears the TLB entry that gets filled is not right, even though the original page entry is generated correctly. See below TLB dump. The original page table still has the same value (not corrupted), and the only explanation is that tlb_refill actually gets the entry from a wrong place. I then tried to decode tlb_refill code but really got lost there. (Is there an explanation about the page table setup?) How could this be? Maybe the pte's are put in the wrong place to begin with? Ralf, please help ... Jun P.S., even though tlb entry is wrong, it does not explain the bus error, because the wrong tlb entry does point to a physical memory area. Hmm, more questions ... ---------------- dump tlb for 0x2ac3d000 : Entry 37 maps address 0x2ac3d000 Index: 37 pgmask=00000000 va=2ac3c000 asid=0000007b [pa=000000 c=0 d=0 v=0 g=0] [pa=2300000 c=2 d=0 v=1 g=0] dump all tlb : Index: 4 pgmask=00000000 va=2abbc000 asid=0000007b [pa=0ff000 c=3 d=0 v=1 g=0] [pa=000000 c=0 d=0 v=0 g=0] Index: 10 pgmask=00000000 va=7fffe000 asid=0000007b [pa=000000 c=0 d=0 v=0 g=0] [pa=0f2000 c=3 d=1 v=1 g=0] Index: 11 pgmask=00000000 va=10052000 asid=0000007b [pa=000000 c=0 d=0 v=0 g=0] [pa=0f0000 c=3 d=1 v=1 g=0] Index: 30 pgmask=00000000 va=00424000 asid=0000007b [pa=0f0000 c=3 d=0 v=1 g=0] [pa=0f0000 c=3 d=0 v=1 g=0] ------------------ Where the pte's are : (gdb) x/32 0x83ca30f0 0x83ca30f0: 0x00000000 0x8c00048f 0x8c001407 0x8c002407 0x83ca3100: 0x8c003407 0x8c004407 0x8c005407 0x8c006407 0x83ca3110: 0x8c007407 0x8c008407 0x8c009407 0x8c00a407 0x83ca3120: 0x8c00b407 0x8c00c407 0x8c00d407 0x8c00e407 0x83ca3130: 0x8c00f407 0x8c010407 0x8c011407 0x8c012407 0x83ca3140: 0x8c013407 0x8c014407 0x8c015407 0x8c016407 0x83ca3150: 0x8c017407 0x8c018407 0x8c019407 0x8c01a407 0x83ca3160: 0x8c01b407 0x8c01c407 0x8c01d407 0x8c01e407 From ralf@oss.sgi.com Wed Sep 6 23:08:37 2000 Received: from u-48.karlsruhe.ipdial.viaginterkom.de (u-48.karlsruhe.ipdial.viaginterkom.de [62.180.20.48]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA18303; Wed, 6 Sep 2000 23:08:33 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 23:08:33 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 6 Sep 2000 10:48:17 +0200 Date: Wed, 6 Sep 2000 10:48:17 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@fnet.fr, linux@engr.sgi.com Subject: Re: infinite loop in default_be_board_handler() Message-ID: <20000906104816.A1246@bacchus.dhis.org> References: <39B57500.F08575D5@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39B57500.F08575D5@mvista.com>; from jsun@mvista.com on Tue, Sep 05, 2000 at 03:34:40PM -0700 X-Accept-Language: de,en,fr Content-Length: 506 Lines: 12 On Tue, Sep 05, 2000 at 03:34:40PM -0700, Jun Sun wrote: > I found the following code in arch/mips/kernel/traps.c file, which looks > like a hack to me. Is there any reason the infinite loop should be > there? Not really. It's debug trash that accidently got checked into CVS. The reason I added this back in time was a bug where returning from the dbe handler did result in more exceptions and screen printout so the debug printout of the original exception would scroll off the screen ... Ralf From ralf@uni-koblenz.de Wed Sep 6 23:08:41 2000 Received: from u-48.karlsruhe.ipdial.viaginterkom.de (u-48.karlsruhe.ipdial.viaginterkom.de [62.180.20.48]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA18306; Wed, 6 Sep 2000 23:08:38 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 23:08:38 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 6 Sep 2000 10:53:29 +0200 Date: Wed, 6 Sep 2000 10:53:29 +0200 From: Ralf Baechle To: Rabeeh Khoury Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: modules in kernel 2.2.14 Message-ID: <20000906105329.B1246@bacchus.dhis.org> References: <39B53DF0.80BE4104@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39B53DF0.80BE4104@galileo.co.il>; from rabeeh@galileo.co.il on Tue, Sep 05, 2000 at 02:39:44PM -0400 X-Accept-Language: de,en,fr Content-Length: 406 Lines: 15 On Tue, Sep 05, 2000 at 02:39:44PM -0400, Rabeeh Khoury wrote: > module.o: unresolved symbol _gp_disp > > Where this symbol missing, in the kernel or in the module ??!! Nowhere - there should be no reference to it. > Did any one encounter this kind of problem ? or have any alternative > solution ? Compile your module with the same flags as the kernel, especially use -fno-pic -mno-abicalls. Ralf From falcon2004@netzero.net Fri Sep 8 22:59:42 2000 Received: from mail9.wlv.netzero.net (mail9.wlv.netzero.net [209.247.163.66]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id WAA13084; Fri, 8 Sep 2000 22:59:41 +0200 (MET DST) Received-Date: Fri, 8 Sep 2000 22:59:41 +0200 (MET DST) Received: (qmail 16920 invoked from network); 8 Sep 2000 20:59:01 -0000 Received: from pppa57-resaletoledo2-1r7241.saturn.bbn.com (HELO iufe7ip0) (4.54.226.86) by mail9.wlv.netzero.net with SMTP; 8 Sep 2000 20:59:01 -0000 Message-ID: <000001c019d6$c5e9bf20$56e23604@iufe7ip0> From: "falcon2004" To: Subject: MIPS R4300i compatibility Date: Wed, 6 Sep 2000 16:44:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C01821.C32D7EE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Length: 2083 Lines: 62 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C01821.C32D7EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Will this work on the R4300i series MIPS proc in the Nintendo 64? If so, that will help alot because i have been trying to develop LIN64 = (LINux for N64) to let me have the fun of creating an OS. Please = respond -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GO d- s+: a---- C++ UL++++ = P+ L++ E W+++ N o K- w O- M-- V-- PS+++ PE+ Y PGP++ t- 5- X R-- tv+ b+ = DI+ D+ G++ e- h! r y ------END GEEK CODE BLOCK------=20 "Pie are not square. Pie are round. Cornbread are square." -Someone on = Slashdot=20 Asylum Software Opening on Christmas ------=_NextPart_000_0005_01C01821.C32D7EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Will this work on the R4300i series = MIPS proc in=20 the Nintendo 64?
 
If so, that will help alot because i = have been=20 trying to develop LIN64 (LINux for N64) to let me have the fun of = creating an=20 OS.  Please respond
 
 
 
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GO d- s+: a---- C++ = UL++++ P+=20 L++ E W+++ N o K- w O- M-- V-- PS+++ PE+ Y PGP++ t- 5- X R-- tv+ b+ DI+ = D+ G++=20 e- h! r y ------END GEEK CODE BLOCK------
"Pie are not square. Pie = are=20 round. Cornbread are square." -Someone on Slashdot
Asylum Software Opening on=20 Christmas
------=_NextPart_000_0005_01C01821.C32D7EE0-- _____NetZero Free Internet Access and Email______ http://www.netzero.net/download/index.html From iceshade2000@icqmail.com Wed Sep 6 23:16:29 2000 Received: from c005.sfo.cp.net (c005-h005.c005.sfo.cp.net [209.228.13.61]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id XAA20268; Wed, 6 Sep 2000 23:16:28 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 23:16:28 +0200 (MET DST) Received: (cpmta 28797 invoked from network); 6 Sep 2000 14:15:51 -0700 Date: 6 Sep 2000 14:15:51 -0700 Message-ID: <20000906211551.28796.cpmta@c005.sfo.cp.net> X-Sent: 6 Sep 2000 21:15:51 GMT Received: from [166.62.37.132] by mail.icqmail.com with HTTP; 06 Sep 2000 14:15:51 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: linux-mips@fnet.fr From: Sean Harlow X-Mailer: Web Mail 3.7.1.4 Subject: MIPS R4300i compatible X-Icq: 86559389 Content-Length: 663 Lines: 15 Will this work on the R4300i series MIPS proc in the Nintendo 64? If so, that will help alot because i have been trying to develop LIN64 (LINux for N64) to let me have the fun of creating an OS. Please respond -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GO d- s+: a---- C++ UL++++ P+ L++ E W+++ N o K- w O- M-- V-- PS+++ PE+ Y PGP++ t- 5- X R-- tv+ b+ DI+ D+ G++ e- h! r y ------END GEEK CODE BLOCK------ "Pie are not square. Pie are round. Cornbread are square." -Someone on Slashdot Asylum Software Opening on Christmas ------------------------------------------------------------- Sign up for ICQmail at http://www.icq.com/icqmail/signup.html From jsun@mvista.com Wed Sep 6 23:31:11 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA22666; Wed, 6 Sep 2000 23:31:10 +0200 (MET DST) Received-Date: Wed, 6 Sep 2000 23:31:10 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA31445; Wed, 6 Sep 2000 14:30:05 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39B6B75D.2501654E@mvista.com> Date: Wed, 06 Sep 2000 14:30:05 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-fbdev@vuser.vu.union.edu, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: mmap() frame buffer causes bus error on MIPS ... References: <39B5BD14.A8D2F467@mvista.com> <39B5DABB.7FB85B09@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2902 Lines: 81 Jun Sun wrote: > > Jun Sun wrote: > > > > With the help from Attila, I got the latest tdfx framebuffer driver > > working on my NEC DDB5476 board. I have console working based on this > > driver. > > > > However, when I try to mmap frame buffer into user land, the mapping is > > succesful, but trying to read the buffer causes a bus error. > > > > I tried to trace the kernel using gdb. fb_mmap() seems to do the right > > thing : > > > > 1) it calls fb->fb_get_fix() to get the buffer address, size, etc. The > > values all look fine. The address is physical address, pointing a > > mapped PCI memory block. I verified that I can access that address in > > gdb. > > > > 2) for MIPS, fb_mmap() turns off CACHE bit for the page. > > > > I would imagine when the app tries to read the buffer, a TLB miss is > > generated. TLB refill routine probably sets up the right TLB entry, and > > the app will try to read again, and get the content. I really can't > > think of where the Bus error might occur. > > > > Does anybody have a clue here? Thanks a lot. > > > > Jun > > Did more probing on this. It appears the TLB entry that gets filled is > not right, even though the original page entry is generated correctly. > See below TLB dump. > This is bogus. The TLB entry is a shifted value (right-shift for 6 bits) of the entry in the page table. That is the reason whe I see two different values. > The original page table still has the same value (not corrupted), and > the only explanation is that tlb_refill actually gets the entry from a > wrong place. I then tried to decode tlb_refill code but really got lost > there. (Is there an explanation about the page table setup?) > > How could this be? Maybe the pte's are put in the wrong place to begin > with? Ralf, please help ... > > Jun > I found the real reason, and had a work-around to make it work for now. However, I am not sure about the right fix. fb_mmap() calls get_fix() to get screen info : fb->fb_get_fix(&fix, PROC_CONSOLE(info), info); fb_mmap() then gets buffer address from fix.smem_start, which is a physical address. It then calls kernel's remap_page_range() with that address, which in turn will generate pte with mk_pte_phys(). In MIPS, mk_pte_phys() is defined as follows : extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot) { return __pte(((physpage & PAGE_MASK) - PAGE_OFFSET) | pgprot_val(pgprot)); } The problematic part is " - PAGE_OFFSET" (where PAGE_OFFSET is 0x80000000). If "physpage" is a physical address, it should not be substracted by PAGE_OFFSET. This is a bug. On the other hand, I wonder why this bug is there without being caught before (it is so fundamental). If this is not a bug in MIPS kernel, then the fix is in the fb_mmap(), where under __mips__ case, we should add PAGE_OFFSET to the start of buffer address. What is the right fix here? Jun From imp@harmony.village.org Thu Sep 7 01:49:51 2000 Received: from rover.village.org (warner@rover.village.org [204.144.255.49]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA28072; Thu, 7 Sep 2000 01:49:49 +0200 (MET DST) Received-Date: Thu, 7 Sep 2000 01:49:49 +0200 (MET DST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA34104; Wed, 6 Sep 2000 17:49:44 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA73093; Wed, 6 Sep 2000 17:48:58 -0600 (MDT) Message-Id: <200009062348.RAA73093@harmony.village.org> To: Sean Harlow Subject: Re: MIPS R4300i compatible Cc: linux-mips@fnet.fr In-reply-to: Your message of "06 Sep 2000 14:15:51 PDT." <20000906211551.28796.cpmta@c005.sfo.cp.net> References: <20000906211551.28796.cpmta@c005.sfo.cp.net> Date: Wed, 06 Sep 2000 17:48:58 -0600 From: Warner Losh Content-Length: 426 Lines: 13 In message <20000906211551.28796.cpmta@c005.sfo.cp.net> Sean Harlow writes: : Will this work on the R4300i series MIPS proc in the Nintendo 64? Not without some work. : If so, that will help alot because i have been trying to develop : LIN64 (LINux for N64) to let me have the fun of creating an OS. : Please respond You might want to do a web search on this. I recall several efforts that were trying to do this. Warner From andy.chang@ite.com.tw Thu Sep 7 08:24:45 2000 Received: from bsd.ite.com.tw (bsd.ite.com.tw [210.208.198.222]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id IAA06775; Thu, 7 Sep 2000 08:24:41 +0200 (MET DST) Received-Date: Thu, 7 Sep 2000 08:24:41 +0200 (MET DST) From: andy.chang@ite.com.tw Received: from itemail.ite.com.tw (itemail.ite.com.tw [210.208.198.203]) by bsd.ite.com.tw (8.8.8/8.8.8) with ESMTP id OAA26626 for ; Thu, 7 Sep 2000 14:26:48 +0800 (CST) (envelope-from andy.chang@ite.com.tw) Received: by itemail.ite.com.tw with Internet Mail Service (5.5.2448.0) id ; Thu, 7 Sep 2000 14:23:03 +0800 Message-ID: <412C066DD818D3118D4300805FD46679B214B1@itemail.ite.com.tw> To: linux-mips@fnet.fr Cc: y.c.guo@ite.com.tw, amy.chung@ite.com.tw Subject: We want to port Linux to our platform Date: Thu, 7 Sep 2000 14:23:00 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="Big5" Content-Length: 344 Lines: 9 Hi We are a IC design house in Taiwan. Recently, we need a Linux soultion on our MIPS platform but we don't know how to start. ( We only have WinCE now) Our platform support both QED 5231 and NEC 5432. Another major chip is the MIPS chip set IT8172, our new product. Would you please give us some hints to start? Thank you very much. Andy From mike-na@interlink.or.jp Thu Sep 7 09:08:08 2000 Received: from po2.interlink.or.jp (po2.interlink.or.jp [203.141.128.45]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA08393; Thu, 7 Sep 2000 09:08:06 +0200 (MET DST) Received-Date: Thu, 7 Sep 2000 09:08:06 +0200 (MET DST) Received: from B4993564 (ppp045.tokyo2.max.interlink.or.jp [210.166.224.172]) by po2.interlink.or.jp (8.9.3/3.7W-(version 99120915)) with SMTP id QAA18797; Thu, 7 Sep 2000 16:06:55 +0900 (JST) Message-ID: <3ec401c0189a$1adb8c40$ace0a6d2@B4993564> From: "michael nakamura" To: Subject: =?iso-2022-jp?B?GyRCJSIlQCVrJUglNSUkJUg+UjJwGyhC?= Date: Thu, 7 Sep 2000 16:06:06 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3EC0_01C018E5.87A6B200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 2887 Lines: 65 This is a multi-part message in MIME format. ------=_NextPart_000_3EC0_01C018E5.87A6B200 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B%"%@%k%H%5%$%H$N>R2p$G$9!"6=L#$,L5$$?M$O>C5n$7$F2<$5$$!#!!(B $B;d$OCfB<$H?=$7$^$9!"/$7$G$b8:$i$9L\E*$G$3$NMM$J(B $B%a!<%k$r>!pJs$KBP$7$F>pJsNA!J#3#0(B $B#0#01_!K$H$7$F$*;YJ'$$D:$1$l$P!";d$,CN$C$F$$$k3$30$N%5%$%H!J%i%$%V!&F02h!&@E(B $B;_2hA|!&l$9$k$b(B $B$N$O2$JF5Z$S%"%8%"7O$NCK=w$G$"$j$^$9!#3$30$N%5%$%H$G$9$N$G$44|BT$K1h$($kFbMF(B $B$G$"$k$H3N?.$7$F$*$j$^$9!#6=L#$N$"$kJ}$O2<5-$N8}:B$K>pJsNA$H$7$F#3#0#0#01_$r(B $B$*?69~$_2<$5$$!#62=L$G$9$,!"?69~$_$H$=$A$i$N%a!<%k%"(B $B%I%l%9$r$*CN$i$;2<$5$$!"3NG'$,
=1B$B%"%@%k%H%5%$%H$N>R2p$G$9!"6=3DL#$,L5$$?M$O>C5n$7$F2<$5$$!#!= !=1B(B
=1B$B;d$OCfB<$H?=3D$7$^$9!"=1B(B=1B$B/$7$G$b8:$i$9L\E*$G$3$NMM$J%a!= <%k$r>!pJs$KBP$7$F>pJsNA!J#3#0= #0#01_!K$H$7$F$*;YJ'$$D:$1$l$P!";d$,CN$C$F$$$k3$30$N%5%$%H!J%i%$%V!&F02h!= &@E;_2hA|!&
=1B$B%5%$%H$NFbMF$OB?4t$KEO$C$F$*$j$^$9$,!"F|K\?M$N2hA|$O8f:B$$$= ^$;$s!"EP>l$9$k$b$N$O2$JF5Z$S%"%8%"7O$NCK=3Dw$G$"$j$^$9!#3$30$N%5%$%H$G$9= $N$G$44|BT$K1h$($kFbMF$G$"$k$H3N?.$7$F$*$j$^$9!#6=3DL#$N$"$kJ}$O2<5-$N8}:= B$K>pJsNA$H$7$F#3#0#0#01_$r$*?69~$_2<$5$$!#62=3DL$G$9$,!"?69~$_
=1B$B?6$j9~$^$l$^$7$?$i$*$= H$=3D$A$i$N%a!<%k%"%I%l%9$r$*CN$i$;2<$5$$!"3NG'$,
=1B$B?69~@h=1B(B
=1B$B!!2&;R?.MQ6b8K!!KL?7=3DI;YE9!!IaDLMB6b!!=1B(B5006103=1B$B!!= =1B(B
=1B$B!!%"%^%s%@5_:Q2q!!=1B(B
------=_NextPart_000_3EC0_01C018E5.87A6B200-- From ralf@oss.sgi.com Fri Sep 8 03:54:31 2000 Received: from u-93.karlsruhe.ipdial.viaginterkom.de (u-93.karlsruhe.ipdial.viaginterkom.de [62.180.21.93]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA26550; Fri, 8 Sep 2000 03:54:29 +0200 (MET DST) Received-Date: Fri, 8 Sep 2000 03:54:29 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 7 Sep 2000 11:20:13 +0200 Date: Thu, 7 Sep 2000 11:20:13 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-fbdev@vuser.vu.union.edu, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: mmap() frame buffer causes bus error on MIPS ... Message-ID: <20000907112013.A6259@bacchus.dhis.org> References: <39B5BD14.A8D2F467@mvista.com> <39B5DABB.7FB85B09@mvista.com> <39B6B75D.2501654E@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39B6B75D.2501654E@mvista.com>; from jsun@mvista.com on Wed, Sep 06, 2000 at 02:30:05PM -0700 X-Accept-Language: de,en,fr Content-Length: 1114 Lines: 34 On Wed, Sep 06, 2000 at 02:30:05PM -0700, Jun Sun wrote: > In MIPS, mk_pte_phys() is defined as follows : > > extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot) > { > return __pte(((physpage & PAGE_MASK) - PAGE_OFFSET) | > pgprot_val(pgprot)); > } > > The problematic part is " - PAGE_OFFSET" (where PAGE_OFFSET is > 0x80000000). If "physpage" is a physical address, it should not be > substracted by PAGE_OFFSET. This is a bug. > > On the other hand, I wonder why this bug is there without being caught > before (it is so fundamental). If this is not a bug in MIPS kernel, > then the fix is in the fb_mmap(), where under __mips__ case, we should > add PAGE_OFFSET to the start of buffer address. The definition should be: extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot) { return __pte(physpage) | pgprot_val(pgprot); } Masking with PAGE_MASK also seemed to be useless. It's really surprising why it never has been caught. Probably people feed it with the addresses that are tweaked such that sich just work. I'll cook up a patch for this bug. Ralf From ralf@oss.sgi.com Fri Sep 8 03:54:33 2000 Received: from u-93.karlsruhe.ipdial.viaginterkom.de (u-93.karlsruhe.ipdial.viaginterkom.de [62.180.21.93]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA26552; Fri, 8 Sep 2000 03:54:31 +0200 (MET DST) Received-Date: Fri, 8 Sep 2000 03:54:31 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 7 Sep 2000 11:58:49 +0200 Date: Thu, 7 Sep 2000 11:58:49 +0200 From: Ralf Baechle To: Jun Sun , linux-fbdev@vuser.vu.union.edu, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: mmap() frame buffer causes bus error on MIPS ... Message-ID: <20000907115849.A6341@bacchus.dhis.org> References: <39B5BD14.A8D2F467@mvista.com> <39B5DABB.7FB85B09@mvista.com> <39B6B75D.2501654E@mvista.com> <20000907112013.A6259@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000907112013.A6259@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, Sep 07, 2000 at 11:20:13AM +0200 X-Accept-Language: de,en,fr Content-Length: 1269 Lines: 48 On Thu, Sep 07, 2000 at 11:20:13AM +0200, Ralf Baechle wrote: > The definition should be: > > extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot) > { > return __pte(physpage) | pgprot_val(pgprot); > } > > Masking with PAGE_MASK also seemed to be useless. > > It's really surprising why it never has been caught. Probably people > feed it with the addresses that are tweaked such that sich just work. > > I'll cook up a patch for this bug. This one has a interesting history in CVS: revision 1.21 date: 1999/07/26 19:42:43; author: harald; state: Exp; lines: +84 -82 The remaining R3000 changes. From now on the CVS will be R3000 aware. R3000 Indigo anyone? :-) which re-establishes a bug which was fixed by: revision 1.16 date: 1998/08/28 23:24:03; author: tsbogend; state: Exp; lines: +2 -2 fixed MAP_NR() second try:-( which I introduced in: revision 1.15 date: 1998/08/25 09:21:59; author: ralf; state: Exp; lines: +148 -70 o Merge with Linux 2.1.116. o New Newport console code. o New G364 console code. which got fixed by: revision 1.13 date: 1998/07/13 23:28:18; author: tsbogend; state: Exp; lines: +1 -1 fixed physical mapping So the original bug is probably as old as the MIPS port itself ... Ouch. Ralf From macro@ds2.pg.gda.pl Thu Sep 7 12:55:22 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA12275; Thu, 7 Sep 2000 12:55:13 +0200 (MET DST) Received-Date: Thu, 7 Sep 2000 12:55:13 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA11624; Thu, 7 Sep 2000 12:54:00 +0200 (MET DST) Date: Thu, 7 Sep 2000 12:53:59 +0200 (MET DST) From: "Maciej W. Rozycki" To: Karsten Merker cc: linux-mips@fnet.fr Subject: Re: Error in arch/mips/dec/time.c? In-Reply-To: <20000905191029.A14965@excalibur.cologne.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 542 Lines: 14 On Tue, 5 Sep 2000, Karsten Merker wrote: > in the current cvs kernel snapshot from oss.sgi.com I have an undeclared > variable real_year in arch/mips/dec/time.c. This should be declared as Parts of a patch got lost somehow and were not applied at one time. This was fixed yesterday, so just update your snapshot. Are you using a DEC? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@uni-koblenz.de Fri Sep 8 03:54:35 2000 Received: from u-93.karlsruhe.ipdial.viaginterkom.de (u-93.karlsruhe.ipdial.viaginterkom.de [62.180.21.93]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA26557; Fri, 8 Sep 2000 03:54:33 +0200 (MET DST) Received-Date: Fri, 8 Sep 2000 03:54:33 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Thu, 7 Sep 2000 14:38:47 +0200 Date: Thu, 7 Sep 2000 14:38:47 +0200 From: Ralf Baechle To: linux-mips@fnet.fr Subject: Re: Error in arch/mips/dec/time.c? Message-ID: <20000907143847.B6580@bacchus.dhis.org> References: <20000905191029.A14965@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000905191029.A14965@excalibur.cologne.de>; from karsten@excalibur.cologne.de on Tue, Sep 05, 2000 at 07:10:29PM +0200 X-Accept-Language: de,en,fr Content-Length: 435 Lines: 16 On Tue, Sep 05, 2000 at 07:10:29PM +0200, Karsten Merker wrote: > in the current cvs kernel snapshot from oss.sgi.com I have an undeclared > variable real_year in arch/mips/dec/time.c. This should be declared as > > void __init time_init(void) > { > unsigned int real_year, year, mon, day, hour, min, sec; > int i; > [...] > > Is my checkout broken or is this a bug in the cvs? CVS now has a fix for this. Ralf From rabeeh@galileo.co.il Thu Sep 7 13:20:39 2000 Received: from galileo5.galileo.co.il (pop3.galileo.co.il [199.203.130.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA14867; Thu, 7 Sep 2000 13:20:37 +0200 (MET DST) Received-Date: Thu, 7 Sep 2000 13:20:37 +0200 (MET DST) Received: from galileo.co.il (rabeeh@linux2.galileo.co.il [10.2.40.2]) by galileo.co.il (8.8.5/8.8.5) with ESMTP id OAA04367 for ; Thu, 7 Sep 2000 14:20:29 +0200 (GMT-2) Sender: rabeeh@galileo.co.il Message-ID: <39B7DD90.83B3B3D5@galileo.co.il> Date: Thu, 07 Sep 2000 14:25:20 -0400 From: Rabeeh Khoury Reply-To: rabeeh@galileo.co.il X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "linux-mips@fnet.fr" Subject: modules in kernel 2.2.14 Content-Type: multipart/mixed; boundary="------------8C5DBA31A37B72ED847F2894" Content-Length: 1364 Lines: 55 This is a multi-part message in MIME format. --------------8C5DBA31A37B72ED847F2894 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All I'm running kernel 2.2.14 and i'm trying inserting modules. In the file kernel/module.c, function sys_create_module calles module_map which is defined as vmalloc. calling vmalloc returns a pointer to a virtual memory address in the memory mapped area (in my case 0xc0000000) and the kernel had an exception for accessing this address. my work around was defining the following in kernel/module.c #define module_map kmalloc #define module_unmap kfree and it worked fine. Is this work around sufficient ? p.s. module_map and module_unmap is defined in include/asm/pgtable.h as the following : #define module_map vmalloc #define module_unmap vfree Regards, Rabeeh --------------8C5DBA31A37B72ED847F2894 Content-Type: text/x-vcard; charset=us-ascii; name="rabeeh.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Rabeeh Khoury Content-Disposition: attachment; filename="rabeeh.vcf" begin:vcard n:Khoury;Rabeeh x-mozilla-html:FALSE org:Galileo Technology;Software Department adr:;;;;;; version:2.1 email;internet:rabeeh@galileo.co.il title:Development Engineer x-mozilla-cpt:;-31712 fn:Rabeeh Khoury end:vcard --------------8C5DBA31A37B72ED847F2894-- From ralf@uni-koblenz.de Fri Sep 8 06:04:30 2000 Received: from u-93.karlsruhe.ipdial.viaginterkom.de (u-93.karlsruhe.ipdial.viaginterkom.de [62.180.21.93]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA02074; Fri, 8 Sep 2000 06:04:27 +0200 (MET DST) Received-Date: Fri, 8 Sep 2000 06:04:27 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 8 Sep 2000 06:04:12 +0200 Date: Fri, 8 Sep 2000 06:04:12 +0200 From: Ralf Baechle To: Rabeeh Khoury Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Re: modules in kernel 2.2.14 Message-ID: <20000908060412.A9991@bacchus.dhis.org> References: <39B7DD90.83B3B3D5@galileo.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39B7DD90.83B3B3D5@galileo.co.il>; from rabeeh@galileo.co.il on Thu, Sep 07, 2000 at 02:25:20PM -0400 X-Accept-Language: de,en,fr Content-Length: 974 Lines: 29 On Thu, Sep 07, 2000 at 02:25:20PM -0400, Rabeeh Khoury wrote: > I'm running kernel 2.2.14 and i'm trying inserting modules. > > In the file kernel/module.c, function sys_create_module calles > module_map which is defined as vmalloc. > > calling vmalloc returns a pointer to a virtual memory address in the > memory mapped area (in my case 0xc0000000) and the kernel had an > exception for accessing this address. Which means that your TLB exception handlers, cache handling or something in that area is busted, I recommend to fix that first. > my work around was defining the following in kernel/module.c > > #define module_map kmalloc > #define module_unmap kfree > > and it worked fine. > > Is this work around sufficient ? It's ok but can be pretty wasteful on memory. It also will only work for modules upto 128kb size. Also if choose this fix you should delete -mlong-calls from MODFLAGS in arch/mips/Makefile as an additional optimization. Ralf From ralf@oss.sgi.com Sat Sep 9 00:30:39 2000 Received: from u-182.karlsruhe.ipdial.viaginterkom.de (u-182.karlsruhe.ipdial.viaginterkom.de [62.180.10.182]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA16099; Sat, 9 Sep 2000 00:30:31 +0200 (MET DST) Received-Date: Sat, 9 Sep 2000 00:30:31 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 8 Sep 2000 20:58:11 +0200 Date: Fri, 8 Sep 2000 20:58:11 +0200 From: Ralf Baechle To: Ulf Carlsson , Keith M Wesolowski , "Maciej W. Rozycki" , Andreas Jaeger Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: One more gcc patch Message-ID: <20000908205810.A11920@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Content-Length: 2360 Lines: 61 Ooops, this fixes a bug in the previous patch for gcc-current. So this patch does: - fix constructors which were not run for shared libs - fix warnings when building the compiler itself - Keith's gcse patch - gcc was generating code which was calling __main from the beginning of main which is wrong for Linux Ralf diff -urN gcc-cygnus/gcc/config/mips/linux.h gcc/gcc/config/mips/linux.h --- gcc-cygnus/gcc/config/mips/linux.h Tue Aug 29 02:46:28 2000 +++ gcc/gcc/config/mips/linux.h Sat Sep 9 17:06:28 2000 @@ -170,3 +170,20 @@ %{mabi=64: -64} \ %{!fno-PIC:%{!fno-pic:-KPIC}} \ %{fno-PIC:-non_shared} %{fno-pic:-non_shared}" + +/* On svr4, we *do* have support for the .init and .fini sections, and we + can put stuff in there to be executed before and after `main'. We let + crtstuff.c and other files know this by defining the following symbols. + The definitions say how to change sections to the .init and .fini + sections. This is the same for all known svr4 assemblers. */ + +#define INIT_SECTION_ASM_OP "\t.section\t.init" +#define FINI_SECTION_ASM_OP "\t.section\t.fini" + +/* Undef junk imported from mips/elf.h. */ +#undef CTOR_LIST_BEGIN +#undef CTOR_LIST_END +#undef DTOR_LIST_BEGIN +#undef DTOR_LIST_END + +#undef INVOKE__main diff -urN gcc-cygnus/gcc/config/mips/mips.h gcc/gcc/config/mips/mips.h --- gcc-cygnus/gcc/config/mips/mips.h Tue Aug 29 02:46:28 2000 +++ gcc/gcc/config/mips/mips.h Sat Sep 9 16:07:28 2000 @@ -1900,7 +1900,7 @@ extern enum reg_class mips_char_to_class[]; -#define REG_CLASS_FROM_LETTER(C) mips_char_to_class[ (C) ] +#define REG_CLASS_FROM_LETTER(C) mips_char_to_class[ (int) (C) ] /* The letters I, J, K, L, M, N, O, and P in a register constraint string can be used to stand for particular ranges of immediate diff -urN gcc-cygnus/gcc/gcse.c gcc/gcc/gcse.c --- gcc-cygnus/gcc/gcse.c Mon Sep 4 03:00:56 2000 +++ gcc/gcc/gcse.c Fri Sep 8 12:37:18 2000 @@ -1924,7 +1924,9 @@ /* Don't GCSE something if we can't do a reg/reg copy. */ && can_copy_p [GET_MODE (dest)] /* Is SET_SRC something we want to gcse? */ - && want_to_gcse_p (src)) + && want_to_gcse_p (src) + /* Copy between modes is prohibited */ + && GET_MODE (src) == GET_MODE (dest)) { /* An expression is not anticipatable if its operands are modified before this insn. */ From annes@elinux.com Sat Sep 9 03:36:28 2000 Received: from ccnt_smtp2.cc-inc.com (smtp2.GovEd.com [209.233.130.56]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA19933; Sat, 9 Sep 2000 03:36:27 +0200 (MET DST) Received-Date: Sat, 9 Sep 2000 03:36:27 +0200 (MET DST) Received: from elinux.com (BABA_K [10.61.100.62]) by ccnt_smtp2.cc-inc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R7XQWA4H; Fri, 8 Sep 2000 18:28:58 -0700 Message-ID: <39B99333.84B93C0A@elinux.com> Date: Fri, 08 Sep 2000 18:32:35 -0700 From: Anne Sharp Organization: eLinux X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: distro@elinux.com Subject: eLinux Distribution List is up Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2057 Lines: 48 eLinux has delivered the distributions! I'm pleased to announce that the eLinux Distribution List is finally up. I originally contacted over 350 distros, and then collected the incoming data-- about 150 replied-- a tremendous response! But unless I'm mistaken, we don't have information for your distribution yet...* Located at , the eLinux Distribution List is definitely one of the Internet’s largest Linux Distribution listings and easily the most comprehensive listing in terms of information about each distribution. This list will be an invaluable tool and resource for Linux users-- so if you'd still like to submit your distro to the list, please email ... All feedback is also welcome. Btw, eLinux is looking for strong Linux writers-- someone who has the technical skills to write for the "IT professional" audience. If you or anyone you know is interested, please contact me directly. Even if you're not the best writer, that's okay, because I'm a good editor :) Kindest regards, Anne Sharp eLinux Internet Marketing Community Content Writer www.eLinux.com "The premier site for the IT professional" Local Tel. (310) 225.5088 x4023 Toll-free Tel. (877) 39-LINUX x4023 ================================= eLinux is a Linux business solutions provider offering the Linux community a one-stop resource for shopping, support and community services. eLinux has one of the largest product offerings of any Linux site, and the expertise to custom configure servers, desktops, and notebooks for a multi-vendor, multi-platform enterprise solution. The eLinux.com site also includes technical support, news, discussion forums, and articles on topics of interest. Are you an IT professional? Sign up for weekly product news and specials geared just for you:< http://www.elinux.com/welcome/weekly.html > ================================= *If you received this email in error, please accept our apologies-- no more emails will be sent to this address. From paiko-linuxmips@paiko.gr Mon Sep 11 07:50:37 2000 Received: from giwtoula.paiko.gr (root@vdp212-the01.cas.internet.gr [62.1.5.212]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id HAA17201; Mon, 11 Sep 2000 07:50:36 +0200 (MET DST) Received-Date: Mon, 11 Sep 2000 07:50:36 +0200 (MET DST) Received: from localhost (paiko-linuxmips@localhost) by giwtoula.paiko.gr (8.8.8/8.8) with ESMTP id IAA06871 for ; Mon, 11 Sep 2000 08:50:27 +0300 Date: Mon, 11 Sep 2000 08:50:27 +0300 (EET DST) From: Christos Ricudis To: linux-mips@fnet.fr Subject: Indy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 938 Lines: 29 I have a rather peculiar beast right here. It's a SNI RW420 - seems like an OEM'd SGI Indigo, upgraded with a R4000 instead of the R3000 Indigo has : rapanaki 2% hinv CPU: MIPS R4000 Processor Chip Revision: 2.2 FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0 1 100 MHZ IP20 Processor Main memory size: 64 Mbytes Secondary unified instruction/data cache size: 1 Mbyte on Processor 0 Instruction cache size: 8 Kbytes Data cache size: 8 Kbytes Integral SCSI controller 0: Version WD33C93B, revision C Disk drive: unit 1 on SCSI controller 0 Disk drive / removable media: unit 3 on SCSI controller 0: 720K/1.44M floppy On-board serial ports: 2 On-board bi-directional parallel port Graphics board: GR2-XS Integral Ethernet: ec0, version 1 Iris Audio Processor: revision 10 What are my chances of Linux ever supporting this thing? Are there possible upgrade paths for this machine? thank you very much, Christos Ricudis From aj@suse.de Tue Sep 12 18:15:41 2000 Received: from Cantor.suse.de (Cantor.suse.de [194.112.123.193]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA11258; Tue, 12 Sep 2000 18:15:40 +0200 (MET DST) Received-Date: Tue, 12 Sep 2000 18:15:40 +0200 (MET DST) Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 8CA671E3CE; Tue, 12 Sep 2000 18:15:08 +0200 (MEST) Received: from arthur.inka.de (Galois.suse.de [10.0.0.1]) by Hermes.suse.de (Postfix) with ESMTP id DFE5410A02A; Tue, 12 Sep 2000 18:15:02 +0200 (MEST) Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.14 #1) id 13YshE-0006Wt-00; Tue, 12 Sep 2000 18:14:08 +0200 Received: by gromit.rhein-neckar.de (Postfix, from userid 207) id 9BD581822; Tue, 12 Sep 2000 18:14:07 +0200 (CEST) Sender: aj@suse.de Mail-Copies-To: never To: Ralf Baechle Cc: Ulf Carlsson , Keith M Wesolowski , "Maciej W. Rozycki" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: One more gcc patch References: <20000908205810.A11920@bacchus.dhis.org> From: Andreas Jaeger Date: 12 Sep 2000 18:14:07 +0200 In-Reply-To: Ralf Baechle's message of "Fri, 8 Sep 2000 20:58:11 +0200" Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 771 Lines: 31 >>>>> Ralf Baechle writes: > Ooops, this fixes a bug in the previous patch for gcc-current. So this > patch does: > - fix constructors which were not run for shared libs > - fix warnings when building the compiler itself > - Keith's gcse patch > - gcc was generating code which was calling __main from the beginning of > main which is wrong for Linux Did you run the testsuite? It doesn't seem to fix C++: === libstdc++ Summary === # of expected passes 9 # of unexpected failures 10 # of expected failures 11 The number for g++ are even worse, I stopped the check Any idea how to get C++ working? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From ralf@oss.sgi.com Wed Sep 13 01:09:17 2000 Received: from u-207.karlsruhe.ipdial.viaginterkom.de (u-207.karlsruhe.ipdial.viaginterkom.de [62.180.18.207]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA16999; Wed, 13 Sep 2000 01:09:16 +0200 (MET DST) Received-Date: Wed, 13 Sep 2000 01:09:16 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 13 Sep 2000 01:08:46 +0200 Date: Wed, 13 Sep 2000 01:08:46 +0200 From: Ralf Baechle To: Andreas Jaeger Cc: Ulf Carlsson , Keith M Wesolowski , "Maciej W. Rozycki" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: One more gcc patch Message-ID: <20000913010846.A5527@bacchus.dhis.org> References: <20000908205810.A11920@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from aj@suse.de on Tue, Sep 12, 2000 at 06:14:07PM +0200 X-Accept-Language: de,en,fr Content-Length: 722 Lines: 26 On Tue, Sep 12, 2000 at 06:14:07PM +0200, Andreas Jaeger wrote: > Did you run the testsuite? No; I tried rebuilding a large number of RH 6.2 packages. A few of them are broken in ways that make me suspect the compiler is broken. Might also be binutils; I did upgrade both in one step. > It doesn't seem to fix C++: > > === libstdc++ Summary === > > # of expected passes 9 > # of unexpected failures 10 > # of expected failures 11 > > The number for g++ are even worse, I stopped the check > > Any idea how to get C++ working? Debugging? I think historically nobody did ever invest time into getting the libg++ to work so we somewhen have to pay that price ... Ralf From elwintro@hotmail.com Wed Sep 13 18:44:31 2000 Received: from hotmail.com (f80.law3.hotmail.com [209.185.241.80]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA24170; Wed, 13 Sep 2000 18:44:30 +0200 (MET DST) Received-Date: Wed, 13 Sep 2000 18:44:30 +0200 (MET DST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Sep 2000 09:43:58 -0700 Received: from 24.112.158.238 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 13 Sep 2000 16:43:58 GMT X-Originating-IP: [24.112.158.238] From: "Chris Winter" To: linux-mips@fnet.fr Subject: Is my machine supported Date: Wed, 13 Sep 2000 16:43:58 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Sep 2000 16:43:58.0280 (UTC) FILETIME=[CFFD5480:01C01DA1] Content-Length: 1161 Lines: 31 Hi there. I recently discovered a MIPS-based machine at work (which was hidden away in our server room). It is a NeTpower FASTseries MP machine with a single R4400 200MHz MIPS processor, 64MB RAM, 1.something Gb hard drive, CD-ROM drive, SCSI controller, ethernet card, sound card, Diamond Stealth 64 PCI graphics card. I have no idea what BIOS this machine runs, but the sticker on the chip says: NeTpower FASTseries FW Rev:2.20 8/29/95 Currently, the machine runs Windows Nt 3.51 at a pretty impressive speed, but I would be very interested in getting a Linux kernel running on it. Having found your site on the internet, I was wondering if you had any made any progress in getting your MIPS-based linux kernel to work on this machine? I have backed up all of the machine's present data to our network, so it is now completely at my disposal. Thanks for your help. Chris Winter elwintro@hotmail.com _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From niessena@natlab.research.philips.com Fri Sep 15 12:01:54 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA12222; Fri, 15 Sep 2000 12:01:53 +0200 (MET DST) Received-Date: Fri, 15 Sep 2000 12:01:53 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id MAA02821; Fri, 15 Sep 2000 12:01:32 +0200 (MEST) (envelope-from niessena@natlab.research.philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma002818; Fri, 15 Sep 00 12:01:32 +0200 Received: from natlab.research.philips.com (prle.natlab.research.philips.com [130.139.161.112]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id MAA11040; Fri, 15 Sep 2000 12:01:31 +0200 (MET DST) Received: by natlab.research.philips.com; Fri, 15 Sep 2000 12:01:28 +0200 Received: by pc4755.natlab.research.philips.com; Fri, 15 Sep 2000 12:01:27 +0200 Date: Fri, 15 Sep 2000 12:01:27 +0200 From: Arnold Niessen To: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-kernel@vger.kernel.org Cc: Evgeni Eskenazi Subject: FPU problems porting 2.4.0 to Algorithmics P4032 MIPS board Message-Id: <20000915120127.A1453@pc4755.natlab.research.philips.com> Reply-To: Arnold Niessen Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Mailer: Mutt http://www.mutt.org/ X-Editor: Vi Content-Length: 1741 Lines: 46 Hello Ralf, others, We are porting the new 2.4.0 series Linux kernel to Algorithmics P4032 board with MIPS processor (QED-RM5230). We ported 2.4.0-test5 kernel. We already succeeded in porting the following code, partly based on the changes made by MIPS Technologies for the 2.2.12/P5064 patch: 1. Memory management & timer related stuff 2. Support for PCI devices 3. Support of the onboard SCSI controller 4. Support of the onboard Ethernet controller 5. Support for the Serial lines We've got a problem with the foating point support. With either soft or hard FP support, some FP operation generate an exception, e.g. cvt.w.d. We tried both with and without support of FPE soft module, compiled for R46xx and R5000 processors (As far as I understand there is no difference in FP support in the kernel for these processor types). We did not have these problems with the (2.2.12 MIPS Technologies based) port we made to this same board. We would appreciate any ideas how to solve the problem. Algorithmics P4032 board consists of: 1. QED - RM5230 (the documentation claims that it fully supports MIPS IV level) 2. V3 V962PBC PCI adapter 3. Onboard Symbios 53c810a SCSI chipset 4. Onboard Tulip 21041 Ethernet controller 5. Combi I/O controller for 2 RS232 serial ports, centronics parallel port and disk drive. Best regards and thanks in advance, Evgeni Eskenazi, Arnold Niessen -- A.J. Niessen | Philips Research Laboratories Building WL 1.613 | Prof. Holstlaan 4 Phone: (+31-40-27)42715 | 5656 AA Eindhoven Fax: (+31-40-27)44004 | The Netherlands E-Mail: arnold.niessen@philips.com E-Mail on mailing lists: niessen@iae.nl From ralf@uni-koblenz.de Fri Sep 15 23:51:52 2000 Received: from u-214.karlsruhe.ipdial.viaginterkom.de (u-214.karlsruhe.ipdial.viaginterkom.de [62.180.19.214]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA19279; Fri, 15 Sep 2000 23:51:45 +0200 (MET DST) Received-Date: Fri, 15 Sep 2000 23:51:45 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 15 Sep 2000 13:45:16 +0200 Date: Fri, 15 Sep 2000 13:45:16 +0200 From: Ralf Baechle To: Chris Winter Cc: linux-mips@fnet.fr Subject: Re: Is my machine supported Message-ID: <20000915134516.A14966@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from elwintro@hotmail.com on Wed, Sep 13, 2000 at 04:43:58PM +0000 X-Accept-Language: de,en,fr Content-Length: 1096 Lines: 24 On Wed, Sep 13, 2000 at 04:43:58PM +0000, Chris Winter wrote: > I recently discovered a MIPS-based machine at work (which was hidden away in > our server room). It is a NeTpower FASTseries MP machine with a single R4400 > 200MHz MIPS processor, 64MB RAM, 1.something Gb hard drive, CD-ROM drive, > SCSI controller, ethernet card, sound card, Diamond Stealth 64 PCI graphics > card. > > I have no idea what BIOS this machine runs, but the sticker on the chip > says: NeTpower FASTseries FW Rev:2.20 8/29/95 > > Currently, the machine runs Windows Nt 3.51 at a pretty impressive speed, > but I would be very interested in getting a Linux kernel running on it. > > Having found your site on the internet, I was wondering if you had any made > any progress in getting your MIPS-based linux kernel to work on this > machine? That machine is probably a Netpower 100 which is an Acer PICA in disguise. Considering the age still not a slow machine. The Linux support for this machine is currently unmaintained and it would probably take some kernel hacking to get it working again. Ralf From dom@mudchute.algor.co.uk Fri Sep 15 14:02:57 2000 Received: from kenton.algor.co.uk (smtp.algor.co.uk [62.254.210.199]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA13302; Fri, 15 Sep 2000 14:02:56 +0200 (MET DST) Received-Date: Fri, 15 Sep 2000 14:02:56 +0200 (MET DST) Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id NAA21576; Fri, 15 Sep 2000 13:02:46 +0100 (GMT/BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id NAA10050; Fri, 15 Sep 2000 13:02:46 +0100 (BST) Date: Fri, 15 Sep 2000 13:02:46 +0100 (BST) Message-Id: <200009151202.NAA10050@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Arnold Niessen Cc: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-kernel@vger.kernel.org, Evgeni Eskenazi Subject: Re: FPU problems porting 2.4.0 to Algorithmics P4032 MIPS board In-Reply-To: <20000915120127.A1453@pc4755.natlab.research.philips.com> References: <20000915120127.A1453@pc4755.natlab.research.philips.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 1111 Lines: 30 Arnold, > We've got a problem with the foating point support. With either > soft or hard FP support, some FP operation generate an exception, > e.g. cvt.w.d. > > We tried both with and without support of FPE soft module, > compiled for R46xx and R5000 processors (As far as I > understand there is no difference in FP support in the kernel > for these processor types). > > We did not have these problems with the (2.2.12 MIPS Technologies > based) port we made to this same board. MIPS CPU floating-point units always give floating point 'unimplemented' exceptions when faced with unpalatable combinations of operation and operand. It's their way of telling you to go calculate it yourself. The 2.2.12 "MIPS Technologies" port incorporated Algorithmics' floating point trap handler and FP emulation code to provide correct IEEE-compatible floating point. You should either move that on to 2.4.0 or find an equivalent solution. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk From jsun@mvista.com Fri Sep 15 23:10:18 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA18587; Fri, 15 Sep 2000 23:10:17 +0200 (MET DST) Received-Date: Fri, 15 Sep 2000 23:10:17 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA22426; Fri, 15 Sep 2000 14:09:45 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39C29018.9389FBCE@mvista.com> Date: Fri, 15 Sep 2000 14:09:44 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: trap handler for unaligned memory read/write Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 757 Lines: 24 I was trying to run some PCI ether drivers and always got bus error, at least when I use ipconfig bootp code. However, the problem seems to be generic. Ethernet device writes a whole packet in the memory. Driver and network stack code often directly dereference a pointer in to the packet. However, the ether header is 14 byte long. If you align packet from the beginning, then IP header will be off-aligned. Any suggestions? If this is a valid problem, I think the long term solution should be in network code, which should not assume they can dereference on an unaligned address. For short-term solutions, we can have trap handler that supports the unaligned read/write. Does anybody know if there is such a trap handler for MIPS? Thanks. Jun From jsun@mvista.com Sat Sep 16 00:31:57 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA21073; Sat, 16 Sep 2000 00:31:56 +0200 (MET DST) Received-Date: Sat, 16 Sep 2000 00:31:56 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id PAA24914; Fri, 15 Sep 2000 15:31:24 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39C2A33C.EF90FFDB@mvista.com> Date: Fri, 15 Sep 2000 15:31:24 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, linux-mips@fnet.fr CC: dan@netx4.com Subject: Re: trap handler for unaligned memory read/write References: <39C29018.9389FBCE@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1229 Lines: 39 As usual, I am replying to my own question. Maybe I was asking to soon ... :-) I found some drivers offer an copy-only-tiny-buffer which will copy small packets (for what purpose?). Apparently after the copying the misalignment disappears. So MIPS, you just set a high copy_break_size so that a copying always happens. In fact this is what is done for other non-x86 architectures in tulip drivers. Jun Jun Sun wrote: > > I was trying to run some PCI ether drivers and always got bus error, at > least when I use ipconfig bootp code. > > However, the problem seems to be generic. > > Ethernet device writes a whole packet in the memory. Driver and network > stack code often directly dereference a pointer in to the packet. > However, the ether header is 14 byte long. If you align packet from the > beginning, then IP header will be off-aligned. > > Any suggestions? > > If this is a valid problem, I think the long term solution should be in > network code, which should not assume they can dereference on an > unaligned address. > > For short-term solutions, we can have trap handler that supports the > unaligned read/write. Does anybody know if there is such a trap handler > for MIPS? > > Thanks. > > Jun From ralf@oss.sgi.com Sat Sep 16 01:29:17 2000 Received: from u-214.karlsruhe.ipdial.viaginterkom.de (u-214.karlsruhe.ipdial.viaginterkom.de [62.180.19.214]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA21913; Sat, 16 Sep 2000 01:29:15 +0200 (MET DST) Received-Date: Sat, 16 Sep 2000 01:29:15 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sat, 16 Sep 2000 01:28:54 +0200 Date: Sat, 16 Sep 2000 01:28:54 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: trap handler for unaligned memory read/write Message-ID: <20000916012853.A16047@bacchus.dhis.org> References: <39C29018.9389FBCE@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39C29018.9389FBCE@mvista.com>; from jsun@mvista.com on Fri, Sep 15, 2000 at 02:09:44PM -0700 X-Accept-Language: de,en,fr Content-Length: 1425 Lines: 38 On Fri, Sep 15, 2000 at 02:09:44PM -0700, Jun Sun wrote: > I was trying to run some PCI ether drivers and always got bus error, at > least when I use ipconfig bootp code. > > However, the problem seems to be generic. > > Ethernet device writes a whole packet in the memory. Driver and network > stack code often directly dereference a pointer in to the packet. > However, the ether header is 14 byte long. If you align packet from the > beginning, then IP header will be off-aligned. > > Any suggestions? The strategy is to get the alignment right for the IP header, that is to make the received packet start on a address with bit 1 set. > If this is a valid problem, I think the long term solution should be in > network code, which should not assume they can dereference on an > unaligned address. It tries to avoid unaligned accesses - if necessary even at the price of wasting some memory. > For short-term solutions, we can have trap handler that supports the > unaligned read/write. Does anybody know if there is such a trap handler > for MIPS? It's right there in your kernel ... You _really_ _really_ want to avoid relying on the unaligned trap handler. Performancewise that's equivalent to a swapping on a floppy disk on the Mars over NFS via avian carriers ... However unaligned accesses will result in an address error exception not bus error therefore I suspect you've got another problem. Ralf From jsun@mvista.com Sat Sep 16 02:03:42 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA22730; Sat, 16 Sep 2000 02:03:40 +0200 (MET DST) Received-Date: Sat, 16 Sep 2000 02:03:40 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id RAA27427; Fri, 15 Sep 2000 17:02:50 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39C2B8AA.9B873EF7@mvista.com> Date: Fri, 15 Sep 2000 17:02:50 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: trap handler for unaligned memory read/write References: <39C29018.9389FBCE@mvista.com> <20000916012853.A16047@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 753 Lines: 23 Ralf Baechle wrote: > > For short-term solutions, we can have trap handler that supports the > > unaligned read/write. Does anybody know if there is such a trap handler > > for MIPS? > > It's right there in your kernel ... > Cool! I found it. > You _really_ _really_ want to avoid relying on the unaligned trap handler. > Performancewise that's equivalent to a swapping on a floppy disk on the > Mars over NFS via avian carriers ... > > However unaligned accesses will result in an address error exception not > bus error therefore I suspect you've got another problem. > I got the error when I use gdb to debug kernel. I suppose the gdb stub intercepted the error and report it as BUS error. We should make gdb-stub a little smarter ... Jun From peeppeep@gw5.gateway.ne.jp Mon Sep 18 11:35:00 2000 Received: from gw5.gateway.ne.jp (gw5.gateway.ne.jp [203.140.47.13]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA13653; Mon, 18 Sep 2000 11:34:55 +0200 (MET DST) Received-Date: Mon, 18 Sep 2000 11:34:55 +0200 (MET DST) Received: from gw5.gateway.ne.jp (d90.AosakaDSI2.harmonix.ne.jp [163.139.192.192]) by gw5.gateway.ne.jp (8.9.3/3.7W-99062714) with SMTP id SAA07409 for ; Mon, 18 Sep 2000 18:34:41 +0900 (JST) Date: Mon, 18 Sep 2000 18:34:41 +0900 (JST) Message-Id: <200009180934.SAA07409@gw5.gateway.ne.jp> From: =?ISO-2022-JP?B?TE9WRUNIQUlO?= To: =?ISO-2022-JP?B??= X-Mailer: Direct Email v0.22 Subject: =?ISO-2022-JP?B?GyRCJSIlQCVrJUglMyVzJUYlcyVEJHI0XiRzJEckKiRqJF4kOSROJEcbKEIxOBskQjpQTCRLfiROSn0kTzMrJCskOiRLOm89fCQ3JEYkLyRAJDUkJBsoQh==?= Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Length: 809 Lines: 21 $B".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".(B http://www.tv-adult.com/chain/$B!!!!!!!!!!!!!!(B $B!z!z(BLOVE$B!!(BCHAIN$B!z!z#O#P#E#N!*!*(B $B".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".(B $B:G6a$N%"%@%k%H%j%s%/=8$O%$%s%?!<%M%C%H=i?4e$2$^$7$?!#(B $B@'Hs$4Mw$K$J$C$F$_$F2<$5$$$M!#(B $BK~B-$5$;$k$3$H@A$19g$$$G$9!*!*(B $B".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".(B http://www.tv-adult.com/chain/$B!!!!!!!!!!!!!!(B $B!z!z(BLOVE$B!!(BCHAIN$B!z!z(B $B".".".".".".".".".".".".".".".".".".".".".".".".".".".".".".(B From nemoto@toshiba-tops.co.jp Tue Sep 19 07:52:50 2000 Received: from fwgate.toshiba-tops.co.jp (fwgate.toshiba-tops.co.jp [202.230.225.20]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id HAA22028; Tue, 19 Sep 2000 07:52:48 +0200 (MET DST) Received-Date: Tue, 19 Sep 2000 07:52:48 +0200 (MET DST) Received: from [172.16.4.3] by fwgate.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 19 Sep 2000 05:52:47 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id OAA55237; Tue, 19 Sep 2000 14:52:09 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id OAA42998; Tue, 19 Sep 2000 14:52:09 +0900 (JST) To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: FPU context management problem From: Atsushi Nemoto X-Mailer: Mew version 1.94.1 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000919145207Q.nemoto@toshiba-tops.co.jp> Date: Tue, 19 Sep 2000 14:52:07 +0900 X-Dispatcher: imput version 990905(IM130) Content-Length: 1358 Lines: 48 I'm running kernel 2.2.14 (based on linux-2.2.14-000715.tar.gz) and found a floating point calculation sometimes results an incorrect value. I think the problem is last 'if' statement in setup_sigcontext(). owned_fp = (current == last_task_used_math); err |= __put_user(owned_fp, &sc->sc_ownedfp); if (current->used_math) { /* fp is active. */ set_cp0_status(ST0_CU1, ST0_CU1); err |= save_fp_context(sc); last_task_used_math = NULL; regs->cp0_status &= ~ST0_CU1; current->used_math = 0; } This code can discard other task's FPU context in certain situations. The scenario is: (-2) Task_A executes FP insns. (-1) Task_B executes FP insns. (0) Task_C executes FP insns. # save Task_B's FPU context. # init Task_C's FPU context. (1) Context switch (Task_C to Task_A). (2) Task_A catch a signal. setup_sigcontext() and restore_sigcontext() is called. # Task_A's used_math was 1 and owned_fp was 0, # so last_task_used_math becomes NULL. (3) Context switch (Task_A to Task_B). (4) Task_B executes FP insns. # restore Task_B's FPU context. (discard Task_C's FPU context) (5) Context switch (Task_B to Task_C). (6) Task_C execute FP insns. (with Task_B's FPU context!) I modified the 'if' statement as follows and the problem seems to be fixed. if (owned_fp) { /* fp is active. */ ... } Is this the right fix? --- Atsushi Nemoto From jscjhwart215@givemymail.com Tue Sep 19 14:51:09 2000 Received: from [172.16.0.3] (custnet-6.142.wam.net [212.113.6.142]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA24819; Tue, 19 Sep 2000 14:51:04 +0200 (MET DST) Date: Tue, 19 Sep 2000 14:51:04 +0200 (MET DST) Received-Date: Tue, 19 Sep 2000 14:51:04 +0200 (MET DST) Received: from LOCALHOST by 172.16.0.3 with SMTP (QuickMail Pro Server for MacOS 1.0.3); 19 SEP 00 13:22:02 UT To: jasonsch324@keepmymail.com From: jscjhwart215@givemymail.com (Jason Schwartz) Comments: Authenticated sender is Reply-to: jscjhwart215@givemymail.com Subject: Your information on Steel Buildings Message-Id: <200009192268LAA36982@dialup69-nc21a.rpm3.co.uk> Content-Length: 1927 Lines: 62 To be removed from our update list, just reply back and in the subject area put the word "remove" *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* NORTHERN STEEL BUILDINGS **World's Leading On-line Manufacturing/ Distribution Center ** All Steel, Easy Do-it-Yourself Systems, 20 Yr. warranty. . ---------------------------------------------------------------------- LOWEST PRICES ON EARTH FOR PRE-ENGINEERED BUILDING SYSTEMS ---------------------------------------------------------------------- **SAVE THOUSANDS ON PRE-DESIGNED UNITS Ready for immediate delivery** 30x40 - 40x60 - 50x100 - 60x125 70x100 - 100x200 - 125x250 - 250x500 =================================================== FOR INFO - VISIT OUR SITE www.norsteel.com =================================================== Reserve your building On-line - Save 30% - 45% Multi-Building discounts available for Dealers/ Contractors. ---------------------------------------------------------------------- **Send your Building Requirements through our site: www.norsteel.com FREE SHIPPING AND STORAGE IS AVAILABLE, ASK US FOR DETAILS... ---------------------------------------------------------------------- Complete packages available, including construction services Nationwide as low as $2.15 sqft. Northern Steel has 13 fully operational production facilities throughout the U.S. We specialize in buildings for: - Commercial - Industrial - Retail - Churches - Manufacturing Centers - Wharehouses FACTORY DIRECT!! - SAVE THOUSANDS!! VISIT US AT - www.norsteel.com Thank you for giving Northern Steel the opportunity to earn your business.... *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To be removed from our update list, just reply back and in the subject area put the word "remove" Thank You ;-n From wayne@dcs.rhbnc.ac.uk Wed Sep 20 11:37:51 2000 Received: from platon.cs.rhbnc.ac.uk (platon.cs.rhbnc.ac.uk [134.219.188.3]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA05735; Wed, 20 Sep 2000 11:37:42 +0200 (MET DST) Received-Date: Wed, 20 Sep 2000 11:37:42 +0200 (MET DST) Received: from platon.cs.rhbnc.ac.uk (platon.cs.rhbnc.ac.uk [134.219.96.1] (may be forged)) by platon.cs.rhbnc.ac.uk (8.9.1a/8.9.1) with ESMTP id KAA10157; Wed, 20 Sep 2000 10:37:31 +0100 (BST) Date: Wed, 20 Sep 2000 10:37:31 +0100 (BST) From: Wayne Allen X-Sender: wayne@platon.cs.rhbnc.ac.uk To: Jason Schwartz cc: jasonsch324@keepmymail.com, linux-mips@fnet.fr Subject: remove In-Reply-To: <200009192268LAA36982@dialup69-nc21a.rpm3.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2695 Lines: 78 On Tue, 19 Sep 2000, Jason Schwartz wrote: > To be removed from our update list, just reply back > and in the subject area put the word "remove" > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > NORTHERN STEEL BUILDINGS > > **World's Leading On-line Manufacturing/ Distribution Center ** > > All Steel, Easy Do-it-Yourself Systems, 20 Yr. warranty. . > > ---------------------------------------------------------------------- > LOWEST PRICES ON EARTH FOR PRE-ENGINEERED BUILDING SYSTEMS > ---------------------------------------------------------------------- > > **SAVE THOUSANDS ON PRE-DESIGNED UNITS Ready for immediate delivery** > > 30x40 - 40x60 - 50x100 - 60x125 > 70x100 - 100x200 - 125x250 - 250x500 > > =================================================== > FOR INFO - VISIT OUR SITE www.norsteel.com > =================================================== > > Reserve your building On-line - Save 30% - 45% > Multi-Building discounts available for Dealers/ Contractors. > > ---------------------------------------------------------------------- > **Send your Building Requirements through our site: www.norsteel.com > > FREE SHIPPING AND STORAGE IS AVAILABLE, ASK US FOR DETAILS... > ---------------------------------------------------------------------- > > Complete packages available, including construction services Nationwide as > low as $2.15 sqft. > > Northern Steel has 13 fully operational production facilities throughout > the U.S. > > We specialize in buildings for: > > - Commercial > - Industrial > - Retail > - Churches > - Manufacturing Centers > - Wharehouses > > FACTORY DIRECT!! - SAVE THOUSANDS!! > > VISIT US AT - www.norsteel.com > > Thank you for giving Northern Steel the opportunity to earn your > business.... > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > To be removed from our update list, just reply back > and in the subject area put the word "remove" > > > Thank You > > ;-n > > ********************************************************** * Wayne Allen, * * Chairman RHBNC Micromouse Design Group * * Dept of Computer Science * * Royal Holloway, University of London * * Egham Surrey TW20 0EX * * * * Wayne@dcs.rhbnc.ac.uk * * RHMDG webpage : www.dcs.rhbnc.ac.uk/eca/micromouse * ********************************************************** From si@picsinfo.com Thu Sep 21 06:29:52 2000 Received: from viola.ocn.ne.jp (viola.ocn.ne.jp [210.190.142.45]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA13135; Thu, 21 Sep 2000 06:29:50 +0200 (MET DST) Received-Date: Thu, 21 Sep 2000 06:29:50 +0200 (MET DST) Received: from viola.ocn.ne.jp (p0233-ip02higasisibu.tokyo.ocn.ne.jp [211.11.18.235]) by viola.ocn.ne.jp (8.9.1a/OCN/) with SMTP id NAA08822 for ; Thu, 21 Sep 2000 13:29:45 +0900 (JST) Date: Thu, 21 Sep 2000 13:29:45 +0900 (JST) Message-Id: <200009210429.NAA08822@viola.ocn.ne.jp> From: =?ISO-2022-JP?B?GyRCN0NNfTtSGyhC?= To: =?ISO-2022-JP?B??= X-Mailer: Direct Email v0.22 Subject: =?ISO-2022-JP?B?GyRCQmdKUTw6TmkkJCQ/JDckXiQ5GyhC?= Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Length: 955 Lines: 29 $B$*K;$7$$$H$3$m<:Ni$$$?$7$^$9!#(B $B%"%@%k%H>pJs$K6=L#$NL5$$J}!"(B18$B:PL$K~$NJ}!"I,MW$N$J$$J}$O$*l9g$O!"$=$N$^$^JV?.D:(B $B$1$^$7$?$iEvJ}$N%j%9%H$h$jD>$A$K:o=|$$$?$7$^$9!#(B $B!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""(B $B!!!!!!!!!!!!!!!!(B $BL5NA$N%[!<%`%Z!<%8(B $B!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""!|!{"%"$"#""(B $BAG?MC#$N; Fri, 22 Sep 2000 15:26:04 +0200 Date: Fri, 22 Sep 2000 15:26:04 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: libc upgrade Message-ID: <20000922152604.A2627@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Content-Length: 860 Lines: 26 I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com. The rpm package filenames are: glibc-2.0.6-6lm.src.rpm, glibc-2.0.6-6lm.mips.rpm, glibc-devel-2.0.6-6lm.mips.rpm, glibc-profile-2.0.6-6lm.mips.rpm, glibc-debug-2.0.6-6lm.mips.rpm This release fix a number of bug that have been hanging in the dynamic linker basically forever and is urgently recommended to install. Once more rpm in it's stupidity being a static linked program breaks. I therefore also provide new rpm binaries: rpm-3.0-6.0lm.mips.rpm rpm-devel-3.0-6.0lm.mips.rpm No new source package for rpm since this is just a recompile of the package. Not that also other software which has been statically linked against libdl needs to be rebuilt against this library release. IMPORTANT: you must install these new rpm binaries before you upgrade glibc! Ralf From flo@rfc822.org Mon Sep 25 11:30:59 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA20030; Mon, 25 Sep 2000 11:30:58 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 11:30:58 +0200 (MET DST) Received: by noose.gt.owl.de (Postfix, from userid 10) id D3B457FD; Mon, 25 Sep 2000 11:37:09 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3023A9014; Mon, 25 Sep 2000 11:24:13 +0200 (CEST) Date: Mon, 25 Sep 2000 11:24:13 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925112413.B3247@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000922152604.A2627@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, Sep 22, 2000 at 03:26:04PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 1859 Lines: 22 On Fri, Sep 22, 2000 at 03:26:04PM +0200, Ralf Baechle wrote: > I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com. The > rpm package filenames are: > > glibc-2.0.6-6lm.src.rpm, Build fails on mipsel ... gcc rpcinfo.c -c -O2 -g -w -I. -I.. -I../libio -I../sysdeps/mips/elf -I../crypt/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips -I../linuxthreads/sysdeps/pthread/cmpxchg -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel -I../sysdeps/mips -I../sysdeps/wordsize-32 -I../sysdeps/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic -I../sysdeps/stub -D_LIBC_REENTRANT -D_PATH_RPC='"/etc/rpc"' -include ../libc-symbols.h -o rpcinfo.o gcc -nostdlib -nostartfiles -o rpcinfo -Wl,-dynamic-linker=/lib/ld.so.1 -g ../csu/start.o ../csu/crti.o `gcc --print-file-name=crtbegin.o` rpcinfo.o -Wl,-rpath-link=..:../elf:../nss ../libc.so.6 ../elf/ld.so.1 ../libc.a -lgcc `gcc --print-file-name=crtend.o` ../csu/crtn.o /bin/sh: invalid character 45 in exportstr for full-config-sysdirs LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T /bin/sh: invalid character 45 in exportstr for full-config-sysdirs make[1]: *** [xbootparam.stmp] Segmentation fault make[1]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.0.6/sunrpc' make: *** [sunrpc/others] Error 2 Bad exit status from /var/tmp/rpm-tmp.29023 (%build) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From ralf@oss.sgi.com Mon Sep 25 13:23:18 2000 Received: from u-194.karlsruhe.ipdial.viaginterkom.de (u-194.karlsruhe.ipdial.viaginterkom.de [62.180.10.194]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA22507; Mon, 25 Sep 2000 13:23:03 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 13:23:03 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 25 Sep 2000 13:20:57 +0200 Date: Mon, 25 Sep 2000 13:20:56 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925132056.A7598@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000925112413.B3247@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Sep 25, 2000 at 11:24:13AM +0200 X-Accept-Language: de,en,fr Content-Length: 220 Lines: 8 On Mon, Sep 25, 2000 at 11:24:13AM +0200, Florian Lohoff wrote: > Build fails on mipsel ... These messages look like file corruption. Maybe one of the `features' of the 2.4.0-test kernels and not libc at all? Ralf From flo@rfc822.org Mon Sep 25 16:20:54 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA24738; Mon, 25 Sep 2000 16:20:53 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 16:20:53 +0200 (MET DST) Received: by noose.gt.owl.de (Postfix, from userid 10) id 4477D801; Mon, 25 Sep 2000 16:27:07 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8F1DA9014; Mon, 25 Sep 2000 16:15:00 +0200 (CEST) Date: Mon, 25 Sep 2000 16:15:00 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925161500.A4773@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000925132056.A7598@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, Sep 25, 2000 at 01:20:56PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 772 Lines: 19 On Mon, Sep 25, 2000 at 01:20:56PM +0200, Ralf Baechle wrote: > On Mon, Sep 25, 2000 at 11:24:13AM +0200, Florian Lohoff wrote: > > > Build fails on mipsel ... > > These messages look like file corruption. Maybe one of the `features' > of the 2.4.0-test kernels and not libc at all? I dont think so - I succeeded to compile ~2000 Packages of debian on this kernel and its noticeably the first execution with the "new" ld.so LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T /bin/sh: invalid character 45 in exportstr for full-config-sysdirs make[1]: *** [xbootparam.stmp] Segmentation fault Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From jsun@mvista.com Mon Sep 25 20:49:32 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA27939; Mon, 25 Sep 2000 20:49:31 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 20:49:31 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id e8PIlwx18947; Mon, 25 Sep 2000 11:47:58 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39CF9DFC.F30B302B@mvista.com> Date: Mon, 25 Sep 2000 11:48:28 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: load_unaligned() and "uld" instruction Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 352 Lines: 11 The USB sub-system uses "unaligned.h" file to access unaligned data. All the unaligned data access functions depend on "uld" and "usw" instructions, which are not available on many CPUs. I wonder if there is a version of unaligned access functions which do not depend on those instructions. If not, I can probably write one. Any suggestions? Jun From ralf@oss.sgi.com Mon Sep 25 22:14:56 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.20.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA29166; Mon, 25 Sep 2000 22:14:53 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 22:14:53 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 25 Sep 2000 22:14:15 +0200 Date: Mon, 25 Sep 2000 22:14:14 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925221414.A6190@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000925161500.A4773@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Sep 25, 2000 at 04:15:00PM +0200 X-Accept-Language: de,en,fr Content-Length: 985 Lines: 23 On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > > Build fails on mipsel ... > > > > These messages look like file corruption. Maybe one of the `features' > > of the 2.4.0-test kernels and not libc at all? > > I dont think so - I succeeded to compile ~2000 Packages of debian > on this kernel and its noticeably the first execution with the "new" ld.so I week of CPU time on an Origin building packages: No problems ... I'm actually fairly close to get a RH 6.2 built - as far as that is possible with glibc 2.0. > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > make[1]: *** [xbootparam.stmp] Segmentation fault Ok, second theory. What linker where you using to build all this programs? The new ld.so needs to know what ld has built programs due to some pretty stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. Ralf From dom@algor.co.uk Mon Sep 25 23:06:25 2000 Received: from kenton.algor.co.uk (root@smtp.algor.co.uk [62.254.210.199]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA29996; Mon, 25 Sep 2000 23:06:24 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 23:06:24 +0200 (MET DST) Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [192.168.5.75]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id WAA21144; Mon, 25 Sep 2000 22:05:45 +0100 (GMT/BST) Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.8.5/8.8.5) id WAA01137; Mon, 25 Sep 2000 22:16:33 +0100 (GMT/BST) Date: Mon, 25 Sep 2000 22:16:33 +0100 (GMT/BST) Message-Id: <200009252116.WAA01137@gladsmuir.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun Sun Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction In-Reply-To: <39CF9DFC.F30B302B@mvista.com> References: <39CF9DFC.F30B302B@mvista.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 1123 Lines: 38 Jun Sun (jsun@mvista.com) writes: > The USB sub-system uses "unaligned.h" file to access unaligned data. > All the unaligned data access functions depend on "uld" and "usw" > instructions, which are not available on many CPUs. You won't find the instruction 'uld' in *any* MIPS CPU. uld is an assembler macro-instruction translating into a ldl ldr pair (the instructions are called load-double-left and load-double-right). The exact translation depends on whether you're running big-endian or little-endian... but the 32-bit version on a big-endian CPU is that ulw $1,
is assembled as lwl $1,
lwr $1, The way that the load-left and load-right work together is kind of tricky to get your head round. So far as I know, all 64-bit MIPS CPUs implement ldl/ldr and the store equivalents. MIPS patented these instructions, so clones like Lexra's don't implement the 32-bit versions (lwl, lwr etc). -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk From jsun@mvista.com Mon Sep 25 23:38:03 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA00820; Mon, 25 Sep 2000 23:38:01 +0200 (MET DST) Received-Date: Mon, 25 Sep 2000 23:38:01 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id e8PLa9x24119; Mon, 25 Sep 2000 14:36:09 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39CFC567.DD66BC56@mvista.com> Date: Mon, 25 Sep 2000 14:36:39 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Sweetman CC: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2191 Lines: 66 Dominic Sweetman wrote: > > Jun Sun (jsun@mvista.com) writes: > > > The USB sub-system uses "unaligned.h" file to access unaligned data. > > All the unaligned data access functions depend on "uld" and "usw" > > instructions, which are not available on many CPUs. > > You won't find the instruction 'uld' in *any* MIPS CPU. > > uld is an assembler macro-instruction translating into a > > ldl > ldr > > pair (the instructions are called load-double-left and > load-double-right). The exact translation depends on whether you're > running big-endian or little-endian... but the 32-bit version on a > big-endian CPU is that > > ulw $1,
> > is assembled as > > lwl $1,
> lwr $1, > > The way that the load-left and load-right work together is kind of > tricky to get your head round. > > So far as I know, all 64-bit MIPS CPUs implement ldl/ldr and the store > equivalents. MIPS patented these instructions, so clones like Lexra's > don't implement the 32-bit versions (lwl, lwr etc). > > -- > Dominic Sweetman > Algorithmics Ltd > The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND > phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk Dominic, Thanks for the clarification. I looked at my problem again, and it turns out that it was caused by "-mips2" compiler option. If I use "-mips3", the complain goes away, which seems to make sense - assuming "uld" and "usw" are introduced in mips III. This actually brings another question (which I thought I have posted before). Take a look of arch/mips/Makefile, you will find most CPUS uses -mips2 compiler option. While -mips2 is safe, it cannot take advantages of "uld" etc. Is there any reason that we don't want to use -mips3, at least for some of the later CPUs? If we have to use "-mips2" option, is there a clean way which allows us to "uld/usw" instructions (instead of manually twicking the compilation for each file that uses them)? Another question is that in the same file most CPUs will take another compiler option such as "-mcpu=r8000", in which case the cpu model usually does NOT correspond to the actual CPU. Why is that? Thanks. Jun From flo@rfc822.org Tue Sep 26 01:32:42 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA03267; Tue, 26 Sep 2000 01:32:41 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 01:32:41 +0200 (MET DST) Received: by noose.gt.owl.de (Postfix, from userid 10) id B685E812; Tue, 26 Sep 2000 01:38:50 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D5B5F9014; Tue, 26 Sep 2000 01:04:16 +0200 (CEST) Date: Tue, 26 Sep 2000 01:04:16 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926010416.B3761@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000925221414.A6190@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, Sep 25, 2000 at 10:14:14PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 758 Lines: 16 On Mon, Sep 25, 2000 at 10:14:14PM +0200, Ralf Baechle wrote: > On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > > make[1]: *** [xbootparam.stmp] Segmentation fault > > Ok, second theory. What linker where you using to build all this programs? > The new ld.so needs to know what ld has built programs due to some pretty > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. egcs 1.0.3a binutils 2.8.1 (Very conservative) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From ralf@oss.sgi.com Tue Sep 26 01:30:25 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.20.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA03225; Tue, 26 Sep 2000 01:30:02 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 01:30:02 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 26 Sep 2000 01:29:22 +0200 Date: Tue, 26 Sep 2000 01:29:22 +0200 From: Ralf Baechle To: Jun Sun Cc: Dominic Sweetman , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction Message-ID: <20000926012922.A7639@bacchus.dhis.org> References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> <39CFC567.DD66BC56@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39CFC567.DD66BC56@mvista.com>; from jsun@mvista.com on Mon, Sep 25, 2000 at 02:36:39PM -0700 X-Accept-Language: de,en,fr Content-Length: 1811 Lines: 37 On Mon, Sep 25, 2000 at 02:36:39PM -0700, Jun Sun wrote: > I looked at my problem again, and it turns out that it was caused by > "-mips2" compiler option. If I use "-mips3", the complain goes away, > which seems to make sense - assuming "uld" and "usw" are introduced in > mips III. > > This actually brings another question (which I thought I have posted > before). Take a look of arch/mips/Makefile, you will find most CPUS > uses -mips2 compiler option. While -mips2 is safe, it cannot take > advantages of "uld" etc. Is there any reason that we don't want to use > -mips3, at least for some of the later CPUs? You cannot use any kind of 64-bit operation for the 32-bit kernel except for the $zero register. This is because all exceptions as far as they store / restore the integer registers at all will only deal with the lower 32-bit of the registers. In other word any interrupt will corrupt the upper 32-bit bit of gp registers. Back in history I tried to enable the use of the full 64-bit register in the kernel - it ended up ugly as hell, especially because we still want to be able to share most of the code with the R3000. > If we have to use "-mips2" option, is there a clean way which allows us > to "uld/usw" instructions (instead of manually twicking the compilation > for each file that uses them)? > > Another question is that in the same file most CPUs will take another > compiler option such as "-mcpu=r8000", in which case the cpu model > usually does NOT correspond to the actual CPU. Why is that? -mcpu= chooses what CPU gcc will schedule instructions for. No matter what value you choose for the code will run on all CPUs. -mips chooses which ISA level gcc will generate code for; that code won't run on CPUs with a ISA level less than . Ralf From ralf@oss.sgi.com Tue Sep 26 02:48:04 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.20.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA04681; Tue, 26 Sep 2000 02:47:38 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 02:47:38 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 26 Sep 2000 02:46:56 +0200 Date: Tue, 26 Sep 2000 02:46:56 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926024656.A8306@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000926010416.B3761@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Sep 26, 2000 at 01:04:16AM +0200 X-Accept-Language: de,en,fr Content-Length: 826 Lines: 18 On Tue, Sep 26, 2000 at 01:04:16AM +0200, Florian Lohoff wrote: > On Mon, Sep 25, 2000 at 10:14:14PM +0200, Ralf Baechle wrote: > > On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > > > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > > > make[1]: *** [xbootparam.stmp] Segmentation fault > > > > Ok, second theory. What linker where you using to build all this programs? > > The new ld.so needs to know what ld has built programs due to some pretty > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > egcs 1.0.3a binutils 2.8.1 (Very conservative) That's actually the one combination I haven't tested. Looking into it and don't hold your breath :-(. Ralf From kevink@mips.com Tue Sep 26 08:20:27 2000 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id IAA07235; Tue, 26 Sep 2000 08:20:22 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 08:20:22 +0200 (MET DST) Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id XAA22345; Mon, 25 Sep 2000 23:19:34 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA22160; Mon, 25 Sep 2000 23:19:46 -0700 (PDT) Message-ID: <000d01c02782$32d31560$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Jun Sun" , "Dominic Sweetman" Cc: , References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> <39CFC567.DD66BC56@mvista.com> Subject: Re: load_unaligned() and "uld" instruction Date: Tue, 26 Sep 2000 08:22:36 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 2451 Lines: 56 > Dominic, > > Thanks for the clarification. I'll second that - he beat me to it! > I looked at my problem again, and it turns out that it was caused by > "-mips2" compiler option. If I use "-mips3", the complain goes away, > which seems to make sense - assuming "uld" and "usw" are > introduced in mips III. The "load word left/right" and "store word left/right" instructions are part of the original MIPS I ISA. On the other hand, "uld" represents a load of an unalgined quad or "doubleword" of 64-bits, and uses 64-bit load double right/left instructions that are part of the 64-bit MIPS III ISA. > This actually brings another question (which I thought I have posted > before). Take a look of arch/mips/Makefile, you will find most CPUS > uses -mips2 compiler option. While -mips2 is safe, it cannot take > advantages of "uld" etc. Is there any reason that we don't want to use > -mips3, at least for some of the later CPUs? > > If we have to use "-mips2" option, is there a clean way which allows us > to "uld/usw" instructions (instead of manually twicking the compilation > for each file that uses them)? This is a general problem that I've had to fight with the "main line" MIPS/Linux distribution. Most of the work being done is being done on SGI platforms, and all SGI systems since the Crimson have had 64-bit CPUs. Older DECStations use R3000s, and more importantly, many of the new embedded MIPS designs use "MIPS32" processors that have R4000-like system coprocessors, but only 32-bit data paths. I had to do a fairly complete redesign of the 2.2 semaphore support code, for example, in order to get it to rely only on the 32-bit forms of load locked and store conditional. It's clear that I'll have to do something similar with the unaligned accesses in the USB support code before it will run on the MIPS 4Kc and similar CPUs. > Another question is that in the same file most CPUs will take another > compiler option such as "-mcpu=r8000", in which case the cpu model > usually does NOT correspond to the actual CPU. Why is that? The -mcpu tells the compiler and assembler for what kind of pipeline it should optimise, which is independent of the ISA level. "-mcpu=r8000", for example, tells the tools that the CPU is superscalar. Thus one sees that option selected for the R5000 platforms, even though the R5000 and R8000 pipelines are otherwise very dissimilar. Regards, Kevin K. From raiko@niisi.msk.ru Tue Sep 26 10:20:33 2000 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA08301; Tue, 26 Sep 2000 10:20:14 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 10:20:14 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA06351; Wed, 1 Jan 1997 13:42:26 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id LAA10418; Tue, 26 Sep 2000 11:51:43 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA15053; Tue, 26 Sep 2000 12:16:48 +0300 (MSK) Message-ID: <39D05E8B.A7F4A2D9@niisi.msk.ru> Date: Tue, 26 Sep 2000 12:30:03 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ralf Baechle CC: Florian Lohoff , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 654 Lines: 18 Ralf, BTW, what should we use as system headers with glibc nowadays ? Should it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ? > I week of CPU time on an Origin building packages: No problems ... I'm > actually fairly close to get a RH 6.2 built - as far as that is possible > with glibc 2.0. > Do you have the packages somewhere on the net ? I am personally interested in disk packages (fdisk, msdostools &co.) and the packages required in order to run 2.2 kernels. Old HardHat cfdisk, for example, seems to create partitions in the big endian format. At least, the rest see garbage after cfdisk creates a partition table. Regards, Gleb. From raiko@niisi.msk.ru Tue Sep 26 10:30:19 2000 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA08845; Tue, 26 Sep 2000 10:30:10 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 10:30:10 +0200 (MET DST) Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA06412; Wed, 1 Jan 1997 13:52:26 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA10527; Tue, 26 Sep 2000 12:00:39 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA15222; Tue, 26 Sep 2000 12:24:45 +0300 (MSK) Message-ID: <39D06065.FC00C7A0@niisi.msk.ru> Date: Tue, 26 Sep 2000 12:37:57 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Florian Lohoff CC: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 636 Lines: 15 > > Ok, second theory. What linker where you using to build all this programs? > > The new ld.so needs to know what ld has built programs due to some pretty > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > egcs 1.0.3a binutils 2.8.1 (Very conservative) > Well, another question. Ralf uploaded cross tools rpms year ago. Does anybody have native rmps for big endian ? Also, does anybody have cross tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile cross gcc on my Ultra, it seems like a bug in the sparc compiler, the process fails in parsing an enum decl in a header. Regards, Gleb. From dom@algor.co.uk Tue Sep 26 10:58:00 2000 Received: from kenton.algor.co.uk (root@smtp.algor.co.uk [62.254.210.199]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA10062; Tue, 26 Sep 2000 10:57:57 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 10:57:57 +0200 (MET DST) Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [192.168.5.75]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id JAA24255; Tue, 26 Sep 2000 09:57:19 +0100 (GMT/BST) Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.8.5/8.8.5) id KAA00259; Tue, 26 Sep 2000 10:08:15 +0100 (GMT/BST) Date: Tue, 26 Sep 2000 10:08:15 +0100 (GMT/BST) Message-Id: <200009260908.KAA00259@gladsmuir.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kevin D. Kissell" Cc: "Jun Sun" , "Dominic Sweetman" , , Subject: Re: load_unaligned() and "uld" instruction In-Reply-To: <000d01c02782$32d31560$0deca8c0@Ulysses> References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> <39CFC567.DD66BC56@mvista.com> <000d01c02782$32d31560$0deca8c0@Ulysses> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Length: 3036 Lines: 72 Kevin D. Kissell (kevink@mips.com) writes: > > Another question is that in the same file most CPUs will take another > > compiler option such as "-mcpu=r8000", in which case the cpu model > > usually does NOT correspond to the actual CPU. Why is that? > > The -mcpu tells the compiler and assembler for what kind > of pipeline it should optimise, which is independent of the > ISA level. "-mcpu=r8000", for example, tells the tools that > the CPU is superscalar. Thus one sees that option selected > for the R5000 platforms, even though the R5000 and R8000 > pipelines are otherwise very dissimilar. Hmm. I wish it was that simple. But some MIPS CPUs have instruction set additions which are not related to the mips1, mips2, etc. For example, a whole collection of parts with a vaguely "embedded" orientation has integer multiply/accumulate instructions. Algorithmics' version of GCC (and, I'm sure, others) picks up on the -mcpu=xxx flag to do that. In fact, I don't think there's any other way to allow the compiler to warn you of some bizarre omissions from one or two rogue CPUs. But until compiler support for MIPS Linux is more systematic, you'd be better being conservative. And you don't want to unnecessarily multiply kernel versions - so in general, don't say "-mcpu=" anything for kernel builds. The Linux convention is "-mips2"; which is quite odd, because the MIPS-II ISA was incarnate in just one CPU (the R6000). A few units were made around 1990 and even fewer worked; the project was overtaken by the (-mips3, 64-bit) R4000. Subsequently, and confusingly, "-mips2" has been re-used to mean "-mips3 but don't assume 64-bit registers". Except for floating point. Maybe. (it's sometimes not a good idea to re-use a term). Ralf wrote: > You cannot use any kind of 64-bit operation for the 32-bit kernel... Outside SGI circles, I believe, "32-bit kernels" are all that are likely to work... > ... except for the $zero register. This is because all exceptions > as far as they store / restore the integer registers at all will > only deal with the lower 32-bit of the registers. In other word any > interrupt will corrupt the upper 32-bit bit of gp registers. Even calling a subroutine compiled 32-bit may corrupt one of the registers which are supposed to be preserved. As Kevin indicates, it would probably be worth some effort to converge on a kernel which would: 1. build for either 32-bit ("MIPS32" and near-miss) and 64-bit (MIPS3, MIPS4 and MIPS64) CPUs. 2. Allow 64-bit operations on 64-bit CPUs, without insisting that C data types grow. Need to save the whole of registers and compile "long long" and "double" data types... This is possible, but needs some thought. AFAIK, the GCC currently used for Linux changes the whole calling convention when -mips3 is selected, which makes (2) pretty difficult. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk From flo@rfc822.org Tue Sep 26 12:38:41 2000 Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA10574; Tue, 26 Sep 2000 12:38:40 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 12:38:40 +0200 (MET DST) Received: by noose.gt.owl.de (Postfix, from userid 10) id A77B77F3; Tue, 26 Sep 2000 12:44:58 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8F1FB9014; Tue, 26 Sep 2000 12:36:00 +0200 (CEST) Date: Tue, 26 Sep 2000 12:36:00 +0200 From: Florian Lohoff To: "Gleb O. Raiko" Cc: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926123600.A413@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39D06065.FC00C7A0@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:37:57PM +0400 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 1038 Lines: 23 On Tue, Sep 26, 2000 at 12:37:57PM +0400, Gleb O. Raiko wrote: > > > Ok, second theory. What linker where you using to build all this programs? > > > The new ld.so needs to know what ld has built programs due to some pretty > > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > > > egcs 1.0.3a binutils 2.8.1 (Very conservative) > > > > Well, another question. Ralf uploaded cross tools rpms year ago. Does > anybody have native rmps for big endian ? Also, does anybody have cross > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > process fails in parsing an enum decl in a header. I tried to compile cross gcc/binutils from CVS a couple of times for Linux/Sparc (Ultra) which didnt work as somewhere in the middle the beast meant to use the native "as" instead of mipsel-linux-as Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From jarmar@vega.wsm.gdynia.pl Tue Sep 26 17:58:56 2000 Received: from vega.wsm.gdynia.pl (vega.wsm.gdynia.pl [153.19.112.230]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA17038; Tue, 26 Sep 2000 17:58:55 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 17:58:55 +0200 (MET DST) Received: from localhost (jarmar@localhost) by vega.wsm.gdynia.pl (8.8.8+Sun/8.8.8) with ESMTP id RAA22780 for ; Tue, 26 Sep 2000 17:59:49 +0200 (MET DST) Date: Tue, 26 Sep 2000 17:59:49 +0200 (MET DST) From: Jarek Mrozek To: linux-mips@fnet.fr Subject: Bad console baud rate 8 In-Reply-To: <200009241250.OAA13375@guadalquivir.fnet.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 276 Lines: 12 I'm new. Where I may find faq this group, or archive. I have one big problem. I can't install Linux on SGI. I set up bootp and tftp on anoder linux machine. When I try boot():vmlinux I get message: Bad console baud rate 8. (I have PC as console for SGI) Best regards Jarek From wesolows@rotor.chem.unr.edu Tue Sep 26 19:54:07 2000 Received: from rotor.chem.unr.edu (root@rotor.chem.unr.edu [134.197.32.176]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA17711; Tue, 26 Sep 2000 19:54:05 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 19:54:05 +0200 (MET DST) Received: (from wesolows@localhost) by rotor.chem.unr.edu (8.9.3/8.9.3) id KAA16855; Tue, 26 Sep 2000 10:48:05 -0700 Date: Tue, 26 Sep 2000 10:48:05 -0700 From: Keith M Wesolowski To: "Gleb O. Raiko" Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926104805.C15401@chem.unr.edu> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39D06065.FC00C7A0@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:37:57PM +0400 X-Complaints-To: postmaster@chem.unr.edu Content-Length: 1241 Lines: 24 On Tue, Sep 26, 2000 at 12:37:57PM +0400, Gleb O. Raiko wrote: > Well, another question. Ralf uploaded cross tools rpms year ago. Does > anybody have native rmps for big endian ? Also, does anybody have cross > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > process fails in parsing an enum decl in a header. Native rpms, no. Native tarballs that "work," yes. I do have cross tools (again, not RPMs) for sparc glibc 2.1 - it's my main devel environment. I also have a script that builds an entire cross toolchain and kernel for any versions of gcc/binutils/glibc/kernel that you supply, and it's tested mainly on sparc glibc 2.1. I have not yet had any problems building such a cross toolchain, with a mainly stock RH6.2 system (make has to be upgraded to build recent glibc). Information on how I'm doing this is at http://foobazco.org/~wesolows/mips-cross.html. I recommend using the make-cross tools, however, located at ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/. HTH. -- Keith M Wesolowski wesolows@chem.unr.edu University of Nevada http://www.chem.unr.edu Chemistry Department Systems and Network Administrator From jsun@mvista.com Tue Sep 26 20:06:11 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA17876; Tue, 26 Sep 2000 20:06:09 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 20:06:09 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id e8QI3fx19179; Tue, 26 Sep 2000 11:03:41 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39D0E51C.79A0BE50@mvista.com> Date: Tue, 26 Sep 2000 11:04:12 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" , ralf@oss.sgi.com CC: Dominic Sweetman , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> <39CFC567.DD66BC56@mvista.com> <000d01c02782$32d31560$0deca8c0@Ulysses> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2389 Lines: 83 "Kevin D. Kissell" wrote: > > > > If we have to use "-mips2" option, is there a clean way which allows us > > to "uld/usw" instructions (instead of manually twicking the compilation > > for each file that uses them)? > Ralf, before the perfect solution is found, the following patch makes the gcc complain go away. It just use ".set mips3" pragma. > It's clear that I'll have to do > something similar with the unaligned accesses in the USB > support code before it will run on the MIPS 4Kc and > similar CPUs. > I am pretty close to get USB running with the v2.4-test5. The unaligned access is the minor problem. The bigger problem I am fighting with now is bus_to_virt()/virt_to_bus() and USB interrupt. Jun ===================================== --- linux/include/asm-mips/unaligned.h.orig Mon Sep 25 14:02:52 2000 +++ linux/include/asm-mips/unaligned.h Tue Sep 26 10:53:31 2000 @@ -19,7 +19,7 @@ { unsigned long long __res; - __asm__("uld\t%0,(%1)" + __asm__(".set\tmips3\n\tuld\t%0,(%1)" :"=&r" (__res) :"r" (__addr)); @@ -33,7 +33,7 @@ { unsigned long __res; - __asm__("ulw\t%0,(%1)" + __asm__(".set\tmips3\n\tulw\t%0,(%1)" :"=&r" (__res) :"r" (__addr)); @@ -47,7 +47,7 @@ { unsigned long __res; - __asm__("ulh\t%0,(%1)" + __asm__(".set\tmips3\n\tulh\t%0,(%1)" :"=&r" (__res) :"r" (__addr)); @@ -60,7 +60,7 @@ extern __inline__ void stq_u(unsigned long __val, unsigned long long * __addr) { __asm__ __volatile__( - "usd\t%0,(%1)" + ".set\tmips3\n\tusd\t%0,(%1)" : /* No results */ :"r" (__val), "r" (__addr)); @@ -72,7 +72,7 @@ extern __inline__ void stl_u(unsigned long __val, unsigned int * __addr) { __asm__ __volatile__( - "usw\t%0,(%1)" + ".set\tmips3\n\tusw\t%0,(%1)" : /* No results */ :"r" (__val), "r" (__addr)); @@ -84,7 +84,7 @@ extern __inline__ void stw_u(unsigned long __val, unsigned short * __addr) { __asm__ __volatile__( - "ush\t%0,(%1)" + ".set\tmips3\n\tush\t%0,(%1)" : /* No results */ :"r" (__val), "r" (__addr)); From spock@mgnet.de Tue Sep 26 20:41:44 2000 Received: from scotty.mgnet.de (muedi4-145-253-102-049.arcor-ip.net [145.253.102.49]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id UAA18560; Tue, 26 Sep 2000 20:41:42 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 20:41:42 +0200 (MET DST) Received: (qmail 369 invoked from network); 26 Sep 2000 17:32:45 -0000 Received: from spock.mgnet.de (HELO scotty.mgnet.de) (192.168.1.4) by scotty.mgnet.de with SMTP; 26 Sep 2000 17:32:45 -0000 Date: Tue, 26 Sep 2000 20:41:31 +0200 From: Klaus Naumann To: Jarek Mrozek Cc: linux-mips@fnet.fr Subject: Re: Bad console baud rate 8 Message-ID: <20000926204131.A17270@spock> Reply-To: spock@mgnet.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from jarmar@wsm.gdynia.pl on Tue, Sep 26, 2000 at 17:59:49 +0200 X-Mailer: Balsa 0.8.0 Content-Length: 928 Lines: 29 On Tue, 26 Sep 2000 17:59:49 Jarek Mrozek wrote: > I'm new. Many ppl are ;) > Where I may find faq this group, or archive. You can find the most things at http://oss.sgi.com/mips/ or at www.linux-mips.org . > I have one big problem. > I can't install Linux on SGI. > I set up bootp and tftp on anoder linux machine. > When I try boot():vmlinux I get message: Bad console baud rate 8. > (I have PC as console for SGI) The first guess I have is, that you have a wrong setting for the dbaud variable in your PROM. You need to enter the command monitor and type "setenv dbaud 9600" . If it then doesn't work you should mail again and tell us which kernel you are trying to boot. CU, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From ralf@oss.sgi.com Tue Sep 26 23:07:18 2000 Received: from u-146.karlsruhe.ipdial.viaginterkom.de (u-146.karlsruhe.ipdial.viaginterkom.de [62.180.10.146]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA20326; Tue, 26 Sep 2000 23:07:16 +0200 (MET DST) Received-Date: Tue, 26 Sep 2000 23:07:16 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 26 Sep 2000 23:06:50 +0200 Date: Tue, 26 Sep 2000 23:06:50 +0200 From: Ralf Baechle To: Florian Lohoff Cc: "Gleb O. Raiko" , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926230650.B10991@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> <20000926123600.A413@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000926123600.A413@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Sep 26, 2000 at 12:36:00PM +0200 X-Accept-Language: de,en,fr Content-Length: 912 Lines: 19 On Tue, Sep 26, 2000 at 12:36:00PM +0200, Florian Lohoff wrote: > > Well, another question. Ralf uploaded cross tools rpms year ago. Does > > anybody have native rmps for big endian ? Also, does anybody have cross > > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > > process fails in parsing an enum decl in a header. > > I tried to compile cross gcc/binutils from CVS a couple of times > for Linux/Sparc (Ultra) which didnt work as somewhere in the > middle the beast meant to use the native "as" instead of > mipsel-linux-as gcc tries to run as on /lib/gcc-lib///as, then //bin/as, then the native as from $PATH. So check if you were using the same target configuration name (mips-linux and mips-unknown-linux-gnu are different!) for both gcc and binutils. Ralf From ralf@oss.sgi.com Wed Sep 27 00:47:40 2000 Received: from u-146.karlsruhe.ipdial.viaginterkom.de (u-146.karlsruhe.ipdial.viaginterkom.de [62.180.10.146]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA24026; Wed, 27 Sep 2000 00:47:38 +0200 (MET DST) Received-Date: Wed, 27 Sep 2000 00:47:38 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 27 Sep 2000 00:47:23 +0200 Date: Wed, 27 Sep 2000 00:47:22 +0200 From: Ralf Baechle To: "Gleb O. Raiko" Cc: Florian Lohoff , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000927004722.B8644@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <39D05E8B.A7F4A2D9@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39D05E8B.A7F4A2D9@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:30:03PM +0400 X-Accept-Language: de,en,fr Content-Length: 1508 Lines: 30 On Tue, Sep 26, 2000 at 12:30:03PM +0400, Gleb O. Raiko wrote: > BTW, what should we use as system headers with glibc nowadays ? Should > it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ? Definately not the old hardhat kernel headers. I'm using 2.2 header and recommend doing the same for best success with packages for current distributions based on this kernel. Building some packages may actually require a newer version but in general the lastest 2.2 headers are the best. > > I week of CPU time on an Origin building packages: No problems ... I'm > > actually fairly close to get a RH 6.2 built - as far as that is possible > > with glibc 2.0. > > Do you have the packages somewhere on the net ? I am personally > interested in disk packages (fdisk, msdostools &co.) and the packages > required in order to run 2.2 kernels. Old HardHat cfdisk, for example, > seems to create partitions in the big endian format. At least, the rest > see garbage after cfdisk creates a partition table. I've got a hacked utils-linux package, I think it's in the redhat-6.0 packages that are on oss. I don't really intend to upload all the stuff to oss, they're just a big test for the changed compile environment which I'm using, that is binutils-current and gcc-current. Before I even fiddle with stuff like glibc 2.2 etc. I want to know that the tools are reasonably solid. So far they seem to be good after applying a few minor but essential patches. Still need to test building a kernel. Ralf From macro@ds2.pg.gda.pl Wed Sep 27 12:11:24 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA29443; Wed, 27 Sep 2000 12:11:22 +0200 (MET DST) Received-Date: Wed, 27 Sep 2000 12:11:22 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA26405; Wed, 27 Sep 2000 12:06:32 +0200 (MET DST) Date: Wed, 27 Sep 2000 12:06:31 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: "Kevin D. Kissell" , ralf@oss.sgi.com, Dominic Sweetman , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction In-Reply-To: <39D0E51C.79A0BE50@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1199 Lines: 32 On Tue, 26 Sep 2000, Jun Sun wrote: > --- linux/include/asm-mips/unaligned.h.orig Mon Sep 25 14:02:52 2000 > +++ linux/include/asm-mips/unaligned.h Tue Sep 26 10:53:31 2000 > @@ -19,7 +19,7 @@ > { > unsigned long long __res; > > - __asm__("uld\t%0,(%1)" > + __asm__(".set\tmips3\n\tuld\t%0,(%1)" > :"=&r" (__res) > :"r" (__addr)); > [etc.] Please don't. Gcc already has means to generate proper unaligned accesses. See include/asm-alpha/unaligned.h for how to achieve them in a portable way (i.e. using packed structs) without the problematic inline asm. And please use ".set mips0" (or ".set push" and ".set pop", appropriately) after using any ".set mips*" directive (or any other ".set" directive to that matter) not to adversly affect any other code. Improper coding of such constructs bites R3K people badly. Better yet, configure your compiler appropriately and avoid switching ISA levels in the code if at all possible. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From smuff@samsung.com Thu Sep 28 03:47:36 2000 Received: from ms.samsung.com ([211.45.29.136]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA06727; Thu, 28 Sep 2000 03:47:34 +0200 (MET DST) Received-Date: Thu, 28 Sep 2000 03:47:34 +0200 (MET DST) Received: from SMUFF ([203.244.218.35]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id G1KQ9500.PNT for ; Thu, 28 Sep 2000 10:46:17 +0900 Message-ID: <001601c028ee$466b79b0$e7acd5a5@SMUFF> From: "Seok Hyun Ryu" To: Subject: unsubscribe Date: Thu, 28 Sep 2000 10:49:00 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C02939.B5F152A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Length: 733 Lines: 21 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C02939.B5F152A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_0013_01C02939.B5F152A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4mbmJzcDs8L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0013_01C02939.B5F152A0-- From glonnon@ridgerun.com Fri Sep 29 04:35:26 2000 Received: from ridgerun-lx.ridgerun.cxm ([206.207.108.63]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id EAA18170; Fri, 29 Sep 2000 04:35:24 +0200 (MET DST) Received-Date: Fri, 29 Sep 2000 04:35:24 +0200 (MET DST) Received: (qmail 23506 invoked from network); 28 Sep 2000 20:35:17 -0600 Received: from glonnon-lx.ridgerun.cxm (HELO ridgerun.com) (glonnon@192.168.1.16) by ridgerun-lx.ridgerun.cxm with SMTP; 28 Sep 2000 20:35:17 -0600 Sender: glonnon@fnet.fr Message-ID: <39D3FFE4.35E83599@ridgerun.com> Date: Thu, 28 Sep 2000 20:35:16 -0600 From: Greg Lonnon Reply-To: glonnon@ridgerun.com Organization: RidgeRun, Inc X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: problems execve("/sbin/init",...) Content-Type: multipart/mixed; boundary="------------3E5CEB9855DD8FC5A1452D82" Content-Length: 2825 Lines: 82 This is a multi-part message in MIME format. --------------3E5CEB9855DD8FC5A1452D82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am trying to port linux-2.2.14/MIPS to a new board containing a QED R5271 MIPS processor. I am having problems with execve("/sbin/init,...) in init/main.c. The "/sbin/init" is not being called by the kernel. I am nfs root mounting the "simple" filesystem during the kernel boot, and the network and nfs mount seem to be working (I have read and printk'ed /etc/rc at the end of main.c::init()). Things I have tried to debug with: 1) Have written a small tcp/ip server to accept a socket connection, have execve this instead of "/sbin/init". The server will not accept connections. Thus, I believe it's not running. 2) Have statically linked the server and have instrumented binfmt_elf.c and fs/exec.c with debug. The loader seems be working correctly, and arch/mips/kernel/process.c::start_thread(...) is called with the corrected pc and sp. The pc is the entry point in the elf file and the sp is 0x7ffff90. Some printk debug from binfmt_elf.c: (start_brk) 10004e04 (end_code) 4782a0 (start_code) 400000 (end_data) 10003dbc (start_stack) 7fffff90 (brk) 10004e04 start theard pc 400140 sp 7fffff90 3) Have been trying to get printk support into system calls by rewriting read_write.c::sys_write (and friends) to do a printk() at the start of the call. I have written a statically linked program that calls write(0,"here",4). This didn't result in printk output. I would suspect that the program is not being correctly execve. So, my questions are: 1) Does anyone have a good way to debug in this small window going between kernel mode and user mode for the first time? 2) Is there anything else I could try to prove out that the kernel is going into user mode? 3) Has anyone else had these issues? My command_line is: console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.12:/projects/mips/fs ip=192.168.1.211:192.168.1.1::::: Also, My /dev/console is pointing to /dev/ttyS0 and it seems to be dead, I can't printf() to stdout. Thanks, Greg -- Greg Lonnon mailto:glonnon@ridgerun.com --------------3E5CEB9855DD8FC5A1452D82 Content-Type: text/x-vcard; charset=us-ascii; name="glonnon.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Greg Lonnon Content-Disposition: attachment; filename="glonnon.vcf" begin:vcard n:Lonnon;Greg tel;fax:208-331-2227 tel;home:208-323-1724 tel;work:208-331-2226 ext 18 x-mozilla-html:FALSE url:www.ridgerun.com org:RidgeRun, Inc version:2.1 email;internet:glonnon@ridgerun.com title:Senior Kernel Developer adr;quoted-printable:;;200 N. 4th Street =0D=0ASuite 101;Boise;ID;83702;USA x-mozilla-cpt:;-7104 fn:Greg Lonnon end:vcard --------------3E5CEB9855DD8FC5A1452D82-- From macro@ds2.pg.gda.pl Fri Sep 29 16:06:38 2000 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [153.19.144.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA21231; Fri, 29 Sep 2000 16:06:18 +0200 (MET DST) Received-Date: Fri, 29 Sep 2000 16:06:18 +0200 (MET DST) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA24396; Fri, 29 Sep 2000 16:05:20 +0200 (MET DST) Date: Fri, 29 Sep 2000 16:05:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: RPM packages available Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1885 Lines: 38 Hi, For anyone interested: I've made a few MIPS/Linux-related RPM packages available. Included, there are mipsel-linux native development tools, libraries, as well as certain programs sort-of needed for a machine to run interactively. There are cross-development tools for the i386-linux host and the mipsel-linux target. Finally, there are host-independent cross-development libraries for the mipsel-linux target. The binary packages expect glibc-2.1.3 or newer for the i386-linux system and glibc-2.1.90 or newer for the mipsel-linux system to be available. Source packages generally expect glibc-2.1 or newer but were only built using the versions mentioned above. Exact requirements are provided in every package separately. Rpm-3.0 or newer is required to rebuild any of them. Also available are rpm rc and macro files which I use for both native builds and cross-compilations -- rpm doesn't support cross-compilations directly (i.e. via a command line option) but might be configured appropriately via macros provided spec files can handle them. All the above stuff is available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'. The server operates continuously, but during off-peak hours foreign hosts receive greater bandwidth. Off-peak hours are since 10pm till 8am, local time, which is now CEST, i.e. UTC+0200. During this time, the bottleneck link has bandwidth of 10Mb/s. The whole repository consumes about 170MB at the moment but the size may vary as updates are uploaded. If you find a package is missing (e.g. there is a binary package, but no corresponding source one) please let me know. Any comments, updates and fixes are welcomed as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@oss.sgi.com Sat Sep 30 00:03:45 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.19.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA23950; Sat, 30 Sep 2000 00:03:43 +0200 (MET DST) Received-Date: Sat, 30 Sep 2000 00:03:43 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 29 Sep 2000 18:26:41 +0200 Date: Fri, 29 Sep 2000 18:26:40 +0200 From: Ralf Baechle To: Greg Lonnon Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: problems execve("/sbin/init",...) Message-ID: <20000929182640.F16050@bacchus.dhis.org> References: <39D3FFE4.35E83599@ridgerun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39D3FFE4.35E83599@ridgerun.com>; from glonnon@ridgerun.com on Thu, Sep 28, 2000 at 08:35:16PM -0600 X-Accept-Language: de,en,fr Content-Length: 2113 Lines: 55 On Thu, Sep 28, 2000 at 08:35:16PM -0600, Greg Lonnon wrote: > Some printk debug from binfmt_elf.c: > (start_brk) 10004e04 > (end_code) 4782a0 > (start_code) 400000 > (end_data) 10003dbc > (start_stack) 7fffff90 > (brk) 10004e04 > start theard pc 400140 sp 7fffff90 Looks sane. > 3) Have been trying to get printk support into system calls by rewriting > read_write.c::sys_write (and friends) to do a printk() at the start of > the call. I have written a statically linked program that calls > write(0,"here",4). This didn't result in printk output. I would > suspect that the program is not being correctly execve. I suggest you check that your program actually gets paged into memory by enabling the debug printf near the start of do_page_fault() in arch/mips/mm/fault.c. One thing which may happend and will freeze the process in question is if you take recursive page faults, that is the page fault handler will re-enter itself and down() in do_page_fault() will be called a second time for the same process before a match up() call for the previous invocation. > So, my questions are: > 1) Does anyone have a good way to debug in this small window going > between kernel mode and user mode for the first time? > 2) Is there anything else I could try to prove out that the kernel is > going into user mode? > 3) Has anyone else had these issues? I don't have any reports like this. Many of the obscure bug reports like this are caused by the usage of inapropriate tools to build the kernel. The recommended versions are egcs 1.0.3a and binutils 2.8.1 with the latest patches from oss.sgi.com applied. To make live easier for you there are also source and binary rpms available there somewhere under /pub/linux/mips. > My command_line is: > console=ttyS0,115200 root=/dev/nfs > nfsroot=192.168.1.12:/projects/mips/fs ip=192.168.1.211:192.168.1.1::::: > > Also, My /dev/console is pointing to /dev/ttyS0 and it seems to be dead, > I can't printf() to stdout. /dev/console should a character device with major 5 and minor 1. Everything else is either outdated, hackish or even broken. Ralf From ralf@oss.sgi.com Sat Sep 30 00:03:48 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.19.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA23952; Sat, 30 Sep 2000 00:03:45 +0200 (MET DST) Received-Date: Sat, 30 Sep 2000 00:03:45 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 29 Sep 2000 19:22:54 +0200 Date: Fri, 29 Sep 2000 19:22:54 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: "Kevin D. Kissell" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: load_unaligned() and "uld" instruction Message-ID: <20000929192254.G16050@bacchus.dhis.org> References: <39CF9DFC.F30B302B@mvista.com> <200009252116.WAA01137@gladsmuir.algor.co.uk> <39CFC567.DD66BC56@mvista.com> <000d01c02782$32d31560$0deca8c0@Ulysses> <200009260908.KAA00259@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009260908.KAA00259@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Tue, Sep 26, 2000 at 10:08:15AM +0100 X-Accept-Language: de,en,fr Content-Length: 4826 Lines: 101 On Tue, Sep 26, 2000 at 10:08:15AM +0100, Dominic Sweetman wrote: > Hmm. I wish it was that simple. But some MIPS CPUs have > instruction set additions which are not related to the mips1, mips2, > etc. For example, a whole collection of parts with a vaguely > "embedded" orientation has integer multiply/accumulate instructions. > > Algorithmics' version of GCC (and, I'm sure, others) picks up on the > -mcpu=xxx flag to do that. In fact, I don't think there's any other > way to allow the compiler to warn you of some bizarre omissions from > one or two rogue CPUs. Ouch. The gcc documentation says this: `-mcpu=CPU TYPE' Assume the defaults for the machine type CPU TYPE when scheduling instructions. The choices for CPU TYPE are `r2000', `r3000', `r4000', `r4400', `r4600', and `r6000'. While picking a specific CPU TYPE will schedule things appropriately for that particular chip, the compiler will not generate any code that does not meet level 1 of the MIPS ISA (instruction set architecture) without the `-mips2' or `-mips3' switches being used. So in other words I wouldn't expect anything like mmad to be used unless -mmad is also being choosen. -mcpu not influencing the set of instructions being used to build a program is a general gcc convention, not only for MIPS. So if the Algorithmics compiler does things different I'd consider it to be off the track. > But until compiler support for MIPS Linux is more systematic, you'd be > better being conservative. And you don't want to unnecessarily > multiply kernel versions - so in general, don't say "-mcpu=" anything > for kernel builds. > The Linux convention is "-mips2"; which is quite odd, because the > MIPS-II ISA was incarnate in just one CPU (the R6000). A few units > were made around 1990 and even fewer worked; the project was overtaken > by the (-mips3, 64-bit) R4000. > > Subsequently, and confusingly, "-mips2" has been re-used to mean > "-mips3 but don't assume 64-bit registers". Except for floating > point. Maybe. (it's sometimes not a good idea to re-use a term). In the kernel we actually don't care very much about floating point. > Outside SGI circles, I believe, "32-bit kernels" are all that are > likely to work... Currently. Some embedded people are actually asking for more than the 512mb memory supported by the 32-bit kernel. So expect the 64-bit kernel to become the predominant race in the not to distant future. Also expect embedded SMP kernels in the not to far future. No, I don't feel at all like adding highmem support to the 32-bit kernel. > > ... except for the $zero register. This is because all exceptions > > as far as they store / restore the integer registers at all will > > only deal with the lower 32-bit of the registers. In other word any > > interrupt will corrupt the upper 32-bit bit of gp registers. > > Even calling a subroutine compiled 32-bit may corrupt one of the > registers which are supposed to be preserved. Sure, but that's kind of expected and obvious when following the instruction sequence as it gets executed while the corruption by an exception was pretty unobvious when I first ran into it ... > As Kevin indicates, it would probably be worth some effort to converge > on a kernel which would: > > 1. build for either 32-bit ("MIPS32" and near-miss) and 64-bit > (MIPS3, MIPS4 and MIPS64) CPUs. > > 2. Allow 64-bit operations on 64-bit CPUs, without insisting that > C data types grow. Need to save the whole of registers and compile > "long long" and "double" data types... I was thinking about moving all the 64-bit CPUs over to the mips64 kernel and leave the `mips' kernel to the true 32-bit stuff. If you go and download a 2.0.14 tarball you'll see that I already once tried to support full 64-bit operation but only 32-bit address space altogether with real 32-bit CPUs in the `mips' architecture. The result was fairly ugly, so having learned form that I would prefer to keep 32-bit and 64-bit stuff separate. Most users will currently still not want to use a 64-bit address space for apps. That's ok, we can add support for 2-level page tables to `mips64'. That's already been done for example for x86 and looks fairly sane and maintainable. > This is possible, but needs some thought. AFAIK, the GCC currently > used for Linux changes the whole calling convention when -mips3 is > selected, which makes (2) pretty difficult. The calling conventions used by -mips3 are slight confusing, if not even dangerous. Older gccs use a non-standard calling convention which essentially is a blind extension of the 32-bit ABI to 64-bit. Newer gccs support the N32 and 64 ABIs. Unfortunately currently gcc does not support building a single compiler that supports all three 32, N32 and 64 ABIs. Ralf From jsun@mvista.com Sat Sep 30 01:06:50 2000 Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA25312; Sat, 30 Sep 2000 01:06:49 +0200 (MET DST) Received-Date: Sat, 30 Sep 2000 01:06:49 +0200 (MET DST) Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id e8TN57x15668; Fri, 29 Sep 2000 16:05:07 -0700 Sender: jsun@hermes.mvista.com Message-ID: <39D5204A.8BE1E357@mvista.com> Date: Fri, 29 Sep 2000 16:05:46 -0700 From: Jun Sun X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586) X-Accept-Language: en MIME-Version: 1.0 To: glonnon@ridgerun.com CC: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: problems execve("/sbin/init",...) References: <39D3FFE4.35E83599@ridgerun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1081 Lines: 36 Greg Lonnon wrote: > > So, my questions are: > 1) Does anyone have a good way to debug in this small window going > between kernel mode and user mode for the first time? Not really. One time I had similar problem. I was able to figure out the problem by setting breakpoints in fault handlers. > 2) Is there anything else I could try to prove out that the kernel is > going into user mode? Try to set breakpoint in fault handlers. > 3) Has anyone else had these issues? > I found one bug in arch/mm/r4xx0.c, where cache invalidation causes recursive page faults. See the page below. Not sure if it is fixed in the tree yet. diff -Nru linux/arch/mips/mm/r4xx0.c.orig linux/arch/mips/mm/r4xx0.c --- linux/arch/mips/mm/r4xx0.c.orig Sun Jul 30 20:39:50 2000 +++ linux/arch/mips/mm/r4xx0.c Thu Aug 10 16:08:20 2000 @@ -1972,7 +1972,8 @@ if (!(vma->vm_flags & VM_EXEC)) return; - blast_icache32_page(address); + address = KSEG0 + (address & PAGE_MASK & (dcache_size - 1)); + blast_icache32_page_indexed(address); } /* Jun From ralf@oss.sgi.com Sat Sep 30 02:26:53 2000 Received: from u-53.karlsruhe.ipdial.viaginterkom.de (u-53.karlsruhe.ipdial.viaginterkom.de [62.180.19.53]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA25786; Sat, 30 Sep 2000 02:26:44 +0200 (MET DST) Received-Date: Sat, 30 Sep 2000 02:26:44 +0200 (MET DST) Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sat, 30 Sep 2000 02:25:27 +0200 Date: Sat, 30 Sep 2000 02:25:27 +0200 From: Ralf Baechle To: Jun Sun Cc: glonnon@ridgerun.com, linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: problems execve("/sbin/init",...) Message-ID: <20000930022527.C29860@bacchus.dhis.org> References: <39D3FFE4.35E83599@ridgerun.com> <39D5204A.8BE1E357@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39D5204A.8BE1E357@mvista.com>; from jsun@mvista.com on Fri, Sep 29, 2000 at 04:05:46PM -0700 X-Accept-Language: de,en,fr Content-Length: 288 Lines: 9 On Fri, Sep 29, 2000 at 04:05:46PM -0700, Jun Sun wrote: > I found one bug in arch/mm/r4xx0.c, where cache invalidation causes > recursive page faults. See the page below. Not sure if it is fixed in > the tree yet. This bug doesn't affect 2.2 which is the kernel in question. Ralf