From owner-linux-mips@oss.sgi.com Thu Nov 1 04:43:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1ChUS07752 for linux-mips-outgoing; Thu, 1 Nov 2001 04:43:30 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1ChM007746 for ; Thu, 1 Nov 2001 04:43:23 -0800 Received: (qmail 1628 invoked from network); 1 Nov 2001 12:43:20 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Nov 2001 12:43:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 5F4D8300090; Thu, 1 Nov 2001 23:43:15 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id E4E2E98; Thu, 1 Nov 2001 23:43:15 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Daniel Jacobowitz Cc: gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Stabs and discarded functions (was Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging...) In-reply-to: Your message of "Wed, 31 Oct 2001 17:47:49 CDT." <20011031174749.A28985@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Nov 2001 23:43:10 +1100 Message-ID: <30951.1004618590@ocs3.intra.ocs.com.au> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 31 Oct 2001 17:47:49 -0500, Daniel Jacobowitz wrote: >Now, there's two things wrong here. One of them is the bad value. I >think that I've already seen this problem, and that it has something to >do with the way stabs are and used to be emitted. packet_exit is >presumably in the .text.exit section, which is presumably the problem. >Before linking, the stab looked like: > >2971 FUN 0 1870 0000000000000000 159366 packet_exit:f(0,20) > >and had a relocation: >0000000000008b58 R_MIPS_32 .text.exit >unless I miss my guess. > >So it looks like binutils did not relocate the stabs for .text.exit properly. > >Why? It's pretty simple; there was nothing to relocate it to. From the >kernel's linker script: > > /* Sections to be discarded */ > /DISCARD/ : > { > *(.text.exit) > *(.data.exit) > *(.exitcall.exit) > } > >So instead of the subtle error we get in objfiles containing multiple >sections, which we'll still need to deal with for the kernel for >.text.init, we have a completely bogus result. > >We need to discard the stabs records for discarded symbols. The problem is worse than stabs. If a function is marked __exit _and_ some code in another section refers to that function then :- * ld resolves the reference as offset xxx from the start of section .text.exit which is expected to get a decent start address. * Section .text.exit is discarded, giving it a zero start address. * The function call ends up as a branch to _address_ xxx. This is a silent bug on many architectures, it only bites when the __exit function is called, usually on a rarely tested error path. On architectures that use PC relative branches (such as IA64), the linker may not be able to fit a PC relative branch from the high kernel address to the low (and incorrect) xxx address into an instruction so it gets an error during link. Section .data.exit is even worse, most references to data are via full word pointers and the bug is silent again. ld should probably discard sections and all symbols in those sections before resolving external references. From owner-linux-mips@oss.sgi.com Thu Nov 1 06:31:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1EVXF10499 for linux-mips-outgoing; Thu, 1 Nov 2001 06:31:33 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1EVK010495 for ; Thu, 1 Nov 2001 06:31:20 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15zIsD-0003dc-00 for ; Thu, 01 Nov 2001 08:31:13 -0600 Message-ID: <3BE15781.73CE64DD@cotw.com> Date: Thu, 01 Nov 2001 09:09:05 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: [Fwd: Kernel panic: Caught reserved exception - should not happen.] Content-Type: multipart/mixed; boundary="------------ADB0632E565DF3CC166F4D23" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------ADB0632E565DF3CC166F4D23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Scott A. McConnell --------------ADB0632E565DF3CC166F4D23 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3BE156C0.BD98845D@cotw.com> Date: Thu, 01 Nov 2001 09:05:52 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun Subject: Re: Kernel panic: Caught reserved exception - should not happen. References: <3BE07787.5FF7DB8A@cotw.com> <3BE08194.35FBCB82@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jun Sun wrote: > > Scott A McConnell wrote: > > > > I have been getting a fair amount of the above type of errors when > > compiling on a mipsel box. > > > > 2.4.5 kernel on a NEC VR5432 box. Anyone aware of known problems? > > > > What is the exception vector? Is it the "watch exception"? No it is not a watch exception it appears to always be an Interrupt exception. I am running the ltp tests. Status is always 9001f003 and the cause is always 00002000. epc always points to 80014570 which is in: ffffffff8001451c T pgd_init ffffffff80014560 T update_mmu_cache <------------ ffffffff800146d0 T show_regs Sometimes my kernel reboots and sometimes it continues on. I get the error when compiling and also when doing make clean. So just about anything will make it happen make[4]: Entering directory `/opt/ltp/testcases/kernel/syscalls/getpgrp' cc -o getpgrp01 getpgrp01.c -I../../../../include -L../../../../lib -lltpGot reserved at 80014570. $0 : 00000000 2ab042cc 81f83ca0 81f83ca0 $4 : 81a23720 2aaae734 2aaae734 00000000 $8 : 802a3510 1000001f 6ffffdff 70000053 $12: 6fffffff 00000063 2ab04268 7fff7510 $16: 8107d6c0 ffffffff 81a23720 81f86260 $20: 81e23ab8 2aaae734 81f83ca0 00000000 $24: 00000000 2aaae734 $28: 812f6000 812f7df8 7fff7420 8002a19c epc : 80014570 Status: 9001f003 Cause : 00002000 Kernel panic: Caught reserved exception - should not happen. Rebooting in 180 seconds.. make[4]: Entering directory `/opt/ltp/testcases/kernel/syscalls/select' cc -o select01 select01.c -I.Unhandled kernel unaligned access or invalid instruction:$0 : 00000000 7fff7784 81f94da0 81f94da0 $4 : 813493e0 2aab59bc 2aab59bc 00000000 $8 : 802a3510 1000001f 7fff7720 2aaa84ac $12: 7fff79f8 7fff79fc ffffffff 00000003 $16: 8107d940 ffffffff 813493e0 81f97260 $20: 81f7dad4 2aab59bc 81f94da0 00000000 $24: 7fff7a10 2aab59bc $28: 812da000 812dbdf8 7fff76d8 8002a19c epc : 80014574 Status: 9001f003 Cause : 00002000 Process cc (pid: 5022, stackpage=812da000) Stack: 813493e0 00000000 00000000 00000000 2ab041a8 1000001f 7fff7720 7fff7a9c 01f65603 812dbe68 00000000 81f94da0 00000000 813493e0 2aab59bc 00000000 00000000 00000097 8002a364 00000097 7fff7a10 2aaa9bc0 812dbe68 8001dd94 81f7dad4 812dbe80 7fff5b98 8000fd98 812da000 81f94da0 81f94dbc 2aab59bc 812dbf30 80012f8c 00000000 00000000 8118ab60 00000000 8001dc3c 00030002 00000000 ... Call Trace: [<8002a364>] [<8001dd94>] [<8000fd98>] [<80012f8c>] [<8001dc3c>] [<8001da]Code: 14620055 00a03021 40025000 <00000000> 304700ff 40086000 00000000 35010001 ./../../../include -L../../../../lib -lltp make[4]: *** [select01] Segmentation fault cc -o write01 write01.c -I../../../../include -L../../../../lib -lltp Unhandled kernel unaligned access or invalid instruction in unaligned.c:emulate_load_:$0 : 00000000 81ac1000 81f94e20 81f94e20 $4 : 819fc660 2ae55000 2ae55000 00000001 $8 : 1fffffff 1000001f 00000000 00000020 $12: 0000007e 2adfe0cc 00007000 10003b7c $16: 8106b000 81f94e20 819fc660 81854954 $20: 2ae55000 2ae55000 81f94e20 00000001 $24: 00000000 2ace1c90 $28: 812e2000 812e3dc0 7fff7530 8002a03c epc : 80014574 Status: b001f003 Cause : 00008010 Process as (pid: 6081, stackpage=812e2000) Stack: 00000000 00419cd0 81f9f460 00000089 01083603 01ac0717 01ac0613 8002a140 00000000 81f94e20 819fc660 00000000 81854954 8002a230 819fc420 00008000 00000000 806778c0 2ae55000 10002b7c 812e3eb0 80851ad8 0155f603 8002e184 00000000 81f94e20 00000001 819fc660 2ae55000 00000001 100029ec 00000020 8002a364 00989680 00000048 1000a3d0 14003fff 00000001 81854954 0007f000 2ae07000 ... Call Trace: [<8002a140>] [<8002a230>] [<8002e184>] [<8002a364>] [<8002b6d8>] [<80012f]Code: 14620055 00a03021 40025000 <00000000> 304700ff 40086000 00000000 35010001 cc: Internal error: Segmentation fault (program as) Please submit a full bug report. See for instructions. make[4]: *** [write01] Error 1 -- Scott A. McConnell --------------ADB0632E565DF3CC166F4D23-- From owner-linux-mips@oss.sgi.com Thu Nov 1 08:24:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1GOKR14015 for linux-mips-outgoing; Thu, 1 Nov 2001 08:24:20 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1GOD013967 for ; Thu, 1 Nov 2001 08:24:13 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15zKct-0003ga-00; Thu, 01 Nov 2001 10:23:31 -0600 Message-ID: <3BE182FB.2B8D8F8B@cotw.com> Date: Thu, 01 Nov 2001 11:14:35 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Stabs and discarded functions (was Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging...) References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> <20011031113208.A1882@nevyn.them.org> <3BE03ECD.5060904@cygnus.com> <20011031174749.A28985@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Daniel Jacobowitz wrote: [snip] > So it looks like binutils did not relocate the stabs for .text.exit properly. > > Why? It's pretty simple; there was nothing to relocate it to. From the > kernel's linker script: > > /* Sections to be discarded */ > /DISCARD/ : > { > *(.text.exit) > *(.data.exit) > *(.exitcall.exit) > } > > So instead of the subtle error we get in objfiles containing multiple > sections, which we'll still need to deal with for the kernel for > .text.init, we have a completely bogus result. > > We need to discard the stabs records for discarded symbols. Of course, > we're just reading the psymtab in when we get here. We don't have > symbols yet. We could do this by a second pass after reading, instead > of the hack with textlow, but that's gross. > > This makes it impossible to debug at least MIPS kernels with stabs and > gdb, so I very much want to fix it. I'm not sure how this works on > x86, but I'd guess it had to do with differences in relocation types. > Anyone have an example handy? > > Meanwhile, Steven, as a quick hack - try removing the /DISCARD/ bit > from your linker script and relinking. What happens? Does everything > else seem to work? > Success! Yes, leaving those sections in allows for the debugger to work properly. Here is output from a fresh gdb checked out of cvs this morning: GNU gdb 2001-11-01-cvs Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-linux-elf"... (gdb) target remote /dev/ttyS1 Remote debugging using /dev/ttyS1 0x80012c88 in breakinst () at gdb-stub.c:907 907 __asm__ __volatile__(" (gdb) bt #0 0x80012c88 in breakinst () at gdb-stub.c:907 #1 0x8020aabc in brcm_irq_setup () at irq.c:421 #2 0x8020aaf0 in init_IRQ () at irq.c:434 #3 0x801fc83c in start_kernel () at init/main.c:524 #4 0x801fd6f8 in init_arch (argc=160, argv=0xb3000000, envp=0x2, prom_vec=0xbf) at setup.c:425 (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x80012c88 in breakinst () at gdb-stub.c:907 907 __asm__ __volatile__(" (gdb) bt #0 0x80012c88 in breakinst () at gdb-stub.c:907 #1 0x8001a554 in sys_create_module (name_user=0x10001dc8 "brcmdrv", size=713264) at module.c:305 (gdb) c Continuing. So, it would seem according to you and Keith, we have a linker bug that is specific to MIPS and other architectures that do not use PC relative branches that needs to be resolved? I also tried a fresh checkout of the insight debugger from cvs this morning and it works great too. Thanks for the interim solution. I would like to be copied on remaining discussions including the design of the fix/patch. Thank you everyone. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Nov 1 08:51:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Gprp14438 for linux-mips-outgoing; Thu, 1 Nov 2001 08:51:53 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Gpo014435 for ; Thu, 1 Nov 2001 08:51:51 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id E871E125C9; Thu, 1 Nov 2001 08:51:49 -0800 (PST) Date: Thu, 1 Nov 2001 08:51:49 -0800 From: "H . J . Lu" To: Colin Burgess Cc: binutils@sourceware.cygnus.com, linux-mips@oss.sgi.com, gcc@gcc.gnu.org Subject: Re: Mozilla on MIPS Message-ID: <20011101085149.A19298@lucon.org> References: <200111011554.KAA196739151@node109.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111011554.KAA196739151@node109.ott.qnx.com>; from cburgess@qnx.com on Thu, Nov 01, 2001 at 10:54:42AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 01, 2001 at 10:54:42AM -0500, Colin Burgess wrote: > Hi H.J, > > We're hitting the problem with getting Mozilla to run on MIPS (GOT overflow). > I read the thread on binutils about it, and the gp_overflow manpage of the > IRIX linker which has the multigot option. > > Do you know of anyone that has successfully linked Mozilla on MIPS with the > GNU ld? Is anyone looking into implementing multigot functionality? I think some platforms use 32bit GOT by default or something like that such that Mozilla is not a problem. I don't know if it is a good idea for Linux. As for the -multigot option for ld, I have an impression from the man page that it is a linker feature and you don't need to modify the compiler. If it is true, we should investigate the possibility. Unfortunately, I don't know how -multigot works on mips. H.J. From owner-linux-mips@oss.sgi.com Thu Nov 1 08:53:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1GrtU14508 for linux-mips-outgoing; Thu, 1 Nov 2001 08:53:55 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Gro014504 for ; Thu, 1 Nov 2001 08:53:50 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 15zL67-0008Ja-00; Thu, 01 Nov 2001 11:53:43 -0500 Date: Thu, 1 Nov 2001 11:53:43 -0500 From: Daniel Jacobowitz To: "Steven J. Hill" Cc: gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Stabs and discarded functions (was Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging...) Message-ID: <20011101115343.A31822@nevyn.them.org> Mail-Followup-To: "Steven J. Hill" , gdb@sources.redhat.com, linux-mips@oss.sgi.com References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> <20011031113208.A1882@nevyn.them.org> <3BE03ECD.5060904@cygnus.com> <20011031174749.A28985@nevyn.them.org> <3BE182FB.2B8D8F8B@cotw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BE182FB.2B8D8F8B@cotw.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 01, 2001 at 11:14:35AM -0600, Steven J. Hill wrote: > GNU gdb 2001-11-01-cvs > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "--host=i686-pc-linux-gnu > --target=mips-linux-elf"... > (gdb) target remote /dev/ttyS1 > Remote debugging using /dev/ttyS1 > 0x80012c88 in breakinst () at gdb-stub.c:907 > 907 __asm__ __volatile__(" > (gdb) bt > #0 0x80012c88 in breakinst () at gdb-stub.c:907 > #1 0x8020aabc in brcm_irq_setup () at irq.c:421 > #2 0x8020aaf0 in init_IRQ () at irq.c:434 > #3 0x801fc83c in start_kernel () at init/main.c:524 > #4 0x801fd6f8 in init_arch (argc=160, argv=0xb3000000, envp=0x2, > prom_vec=0xbf) at setup.c:425 > (gdb) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x80012c88 in breakinst () at gdb-stub.c:907 ... I wonder why you get a second SIGTRAP. Never happens to me. Quirk of your hardware? > 907 __asm__ __volatile__(" > (gdb) bt > #0 0x80012c88 in breakinst () at gdb-stub.c:907 > #1 0x8001a554 in sys_create_module (name_user=0x10001dc8 "brcmdrv", > size=713264) at module.c:305 > (gdb) c > Continuing. > > So, it would seem according to you and Keith, we have a linker bug that > is specific to MIPS and other architectures that do not use PC relative > branches that needs to be resolved? No, I think that what Keith was saying described a worse side effect of the removed sections. I've no idea why this doesn't manifest on other platforms. So can we work around this in GDB, or can we get the .stabs removed? Does ld edit the .stabs? I'll enquire over on that list. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Nov 1 09:08:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1H8cx15835 for linux-mips-outgoing; Thu, 1 Nov 2001 09:08:38 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1H8a015832 for ; Thu, 1 Nov 2001 09:08:36 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15zLJz-0003if-00; Thu, 01 Nov 2001 11:08:04 -0600 Message-ID: <3BE18D69.147DEAFE@cotw.com> Date: Thu, 01 Nov 2001 11:59:05 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com, linux-mips@oss.sgi.com Subject: Re: Stabs and discarded functions (was Re: Old bug with 'gdb/dbxread.c' and screwed up MIPS symbolic debugging...) References: <3BDF7F79.6050205@cygnus.com> <3BE02E31.3B2CA5FC@cotw.com> <20011031113208.A1882@nevyn.them.org> <3BE03ECD.5060904@cygnus.com> <20011031174749.A28985@nevyn.them.org> <3BE182FB.2B8D8F8B@cotw.com> <20011101115343.A31822@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Daniel Jacobowitz wrote: > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x80012c88 in breakinst () at gdb-stub.c:907 > > ... I wonder why you get a second SIGTRAP. Never happens to me. Quirk > of your hardware? > My bad. I have breakpoint instructions set inside 'kernel/module.c' so that I can single step through module insertions. I should have added a 'bt' output in gdb so you could see that. Everything is working great. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Nov 1 09:32:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1HWLX16482 for linux-mips-outgoing; Thu, 1 Nov 2001 09:32:21 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1HWB016467 for ; Thu, 1 Nov 2001 09:32:11 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id JAA26171; Thu, 1 Nov 2001 09:31:58 -0800 Date: Thu, 1 Nov 2001 09:31:58 -0800 From: Jun Sun To: Scott A McConnell Cc: linux-mips@oss.sgi.com Subject: Re: [Fwd: Kernel panic: Caught reserved exception - should not happen.] Message-ID: <20011101093158.C26148@mvista.com> References: <3BE15781.73CE64DD@cotw.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BE15781.73CE64DD@cotw.com>; from samcconn@cotw.com on Thu, Nov 01, 2001 at 09:09:05AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Nov 01, 2001 at 09:09:05AM -0500, Scott A McConnell wrote: > > -- > Scott A. McConnell > X-Mozilla-Status2: 00000000 > Date: Thu, 01 Nov 2001 09:05:52 -0500 > From: Scott A McConnell > X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) > X-Accept-Language: en > To: Jun Sun > Subject: Re: Kernel panic: Caught reserved exception - should not happen. > > Jun Sun wrote: > > > > Scott A McConnell wrote: > > > > > > I have been getting a fair amount of the above type of errors when > > > compiling on a mipsel box. > > > > > > 2.4.5 kernel on a NEC VR5432 box. Anyone aware of known problems? > > > > > > > What is the exception vector? Is it the "watch exception"? > > No it is not a watch exception it appears to always be an Interrupt > exception. > Try the following patch. It is outdated, and it may not apply cleanly. But you should get an idea about the intention of the fix. Please let me know the result. Jun --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="R5432-cp0-interrupt-bug-workaround.X.010626.patch" This is a possible fix for the R5432 cp0/interrupt bug. Not tested or verified by NEC engineers. Not checked in yet. Pending on more info on this bug. Jun diff -Nru linux/arch/mips/kernel/head.S.orig linux/arch/mips/kernel/head.S --- linux/arch/mips/kernel/head.S.orig Tue Jun 26 16:15:26 2001 +++ linux/arch/mips/kernel/head.S Tue Jun 26 16:27:49 2001 @@ -59,6 +59,12 @@ .set noat LEAF(except_vec0_r4000) .set mips3 +#if defined(CONFIG_CPU_R5432) + la k0, 1f + jr k0 + nop +1: +#endif mfc0 k0, CP0_BADVADDR # Get faulting address srl k0, k0, 22 # get pgd only bits lw k1, current_pgd # get pgd pointer @@ -329,6 +335,12 @@ /* Register saving is delayed as long as we don't know * which registers really need to be saved. */ +#if defined(CONFIG_CPU_R5432) + la k0, 1f + jr k0 + nop +1: +#endif mfc0 k1, CP0_CONTEXT dsra k1, 1 lwu k0, (k1) # May cause another exception @@ -357,6 +369,12 @@ * in the cache, we may not be able to recover. As a * first-order desperate measure, turn off KSEG0 cacheing. */ +#if defined(CONFIG_CPU_R5432) + la k0, 1f + jr k0 + nop +1: +#endif mfc0 k0,CP0_CONFIG li k1,~CONF_CM_CMASK and k0,k0,k1 @@ -374,6 +392,12 @@ /* General exception vector R4000 version. */ NESTED(except_vec3_r4000, 0, sp) .set noat +#if defined(CONFIG_CPU_R5432) + la k0, 1f + jr k0 + nop +1: +#endif mfc0 k1, CP0_CAUSE andi k1, k1, 0x7c li k0, 31<<2 @@ -427,6 +451,12 @@ NESTED(except_vec3_generic, 0, sp) .set noat .set mips0 +#if defined(CONFIG_CPU_R5432) + la k0, 1f + jr k0 + nop +1: +#endif mfc0 k1, CP0_CAUSE la k0, exception_handlers andi k1, k1, 0x7c --HcAYCG3uE/tztfnV-- From owner-linux-mips@oss.sgi.com Thu Nov 1 10:54:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1IswL18654 for linux-mips-outgoing; Thu, 1 Nov 2001 10:54:58 -0800 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Isq018647 for ; Thu, 1 Nov 2001 10:54:52 -0800 Received: from 63.70.210.4 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Thu, 01 Nov 2001 10:54:41 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from postal.sibyte.com (IDENT:postfix@[10.21.128.60]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA13143; Thu, 1 Nov 2001 10:54:50 -0800 (PST) Received: from broadcom.com (dt-sj3-158 [10.21.64.158]) by postal.sibyte.com (Postfix) with ESMTP id 3464F1595F; Thu, 1 Nov 2001 10:54:51 -0800 (PST) Message-ID: <3BE19A7B.79F7982@broadcom.com> Date: Thu, 01 Nov 2001 10:54:51 -0800 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com cc: kwalker@broadcom.com Subject: DO_FAULT patch X-WSS-ID: 17FF45FB439391-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I noticed that the BadVaddr in Oops info from do_fault didn't match the faulting VA in the early part of the message: --- vvvvvvvv Unable to handle kernel paging request at virtual address 0000000c, epc == 801c883c, ra == 801c8ae0 Oops in fault.c:do_page_fault, line 170: $0 : 00000000 14001f00 8fde6a6c 8fde6a60 (zero,at,v0,v1) $4 : 8fddb400 00000003 8fddc000 8d7a53e0 (a0-a3) $8 : 00000003 00000000 8fe67810 8fde9a40 (t0-t3) $12: 0000003c 8fe67820 8d7a5340 00000000 (t4-t7) $16: 8d7a5340 8fddc000 00000001 8d7a5340 (s0-s3) $20: 8fde2b50 8fde2ba8 8fde2940 8fde2bac (s4-s7) $24: 8fde4000 2abb5340 8d7a5340 8fde2000 (t8,t9,k0,k1) $28: 80106000 80107dd8 0000000d 801c8ae0 (gp,sp,fp,ra) epc : 00000000801c883c Status : 14001f03 Cause : 00808008 BadAddr: 000000008d7a5340 Process swapper (pid: 0, stackpage=80106000) ^^^^^^^^^^^^^^^^ --- Seems that the BadVaddr doesn't currently get stuffed into the pt_regs on the stack for TLB exceptions. The following patches might be reasonable: --- tlbex-r3k.S.orig Thu Nov 1 10:50:29 2001 +++ tlbex-r3k.S Thu Nov 1 10:50:17 2001 @@ -92,6 +92,7 @@ .set macro; \ SAVE_ALL; \ mfc0 a2, CP0_BADVADDR; \ + REG_S a2, PT_BVADDR(sp); \ STI; \ .set at; \ move a0, sp; \ --- tlbex-r4k.S.orig Thu Nov 1 10:50:44 2001 +++ tlbex-r4k.S Thu Nov 1 10:50:08 2001 @@ -337,6 +337,7 @@ .set noat; \ SAVE_ALL; \ mfc0 a2, CP0_BADVADDR; \ + REG_S a2, PT_BVADDR(sp); \ STI; \ .set at; \ move a0, sp; \ --kip From owner-linux-mips@oss.sgi.com Thu Nov 1 14:35:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1MZYY23357 for linux-mips-outgoing; Thu, 1 Nov 2001 14:35:34 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1MZU023354 for ; Thu, 1 Nov 2001 14:35:31 -0800 Received: from dsl73.cedar-rapids.net ([208.242.241.39] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15zQQf-0003wp-00; Thu, 01 Nov 2001 16:35:17 -0600 Message-ID: <3BE1C8F4.ECEDC840@cotw.com> Date: Thu, 01 Nov 2001 17:13:08 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-xfs-1.0.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: [Fwd: Kernel panic: Caught reserved exception - should not happen.] References: <3BE15781.73CE64DD@cotw.com> <20011101093158.C26148@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > Try the following patch. It is outdated, and it may not apply cleanly. > But you should get an idea about the intention of the fix. > > Please let me know the result. It looks like a winner to me. I applied the patch compiled, ran and cleaned up the ltp tests twice. I was getting between 2-6 (exception errors) for each cycle I did not have a single failure. You wouldn't happen to have knowledge of some patches that fix pthreads? Thanks very much! -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Thu Nov 1 14:50:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA1Mopt23700 for linux-mips-outgoing; Thu, 1 Nov 2001 14:50:51 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA1Mon023697 for ; Thu, 1 Nov 2001 14:50:49 -0800 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 fA1MqSB08371; Thu, 1 Nov 2001 14:52:28 -0800 Message-ID: <3BE1D1C0.E32905BA@mvista.com> Date: Thu, 01 Nov 2001 14:50:40 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Scott A McConnell CC: linux-mips@oss.sgi.com Subject: Re: [Fwd: Kernel panic: Caught reserved exception - should not happen.] References: <3BE15781.73CE64DD@cotw.com> <20011101093158.C26148@mvista.com> <3BE1C8F4.ECEDC840@cotw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Scott A McConnell wrote: > > Jun Sun wrote: > > > Try the following patch. It is outdated, and it may not apply cleanly. > > But you should get an idea about the intention of the fix. > > > > Please let me know the result. > > It looks like a winner to me. *sigh* We need another ugly #ifdef in the head.S file. > You wouldn't happen to have knowledge of some patches that fix pthreads? glibc 2.2 does not have pthread problems, at least not the one in monta vista journeyman distribution. There are several problems in glibc 2.0.6. But I hope you are not looking for them. :-) Jun From owner-linux-mips@oss.sgi.com Thu Nov 1 16:25:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA20PbD26812 for linux-mips-outgoing; Thu, 1 Nov 2001 16:25:37 -0800 Received: from dark-past (h117n1fls20o53.telia.com [213.64.214.117]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA20PW026791 for ; Thu, 1 Nov 2001 16:25:33 -0800 Received: from yog-sothoth.dark-past.mine.nu (yog-sothoth [192.168.1.7]) by dark-past (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA01207 for ; Fri, 2 Nov 2001 03:37:04 -0800 Message-Id: <5.1.0.14.0.20011102023002.00a65c90@192.168.1.5> X-Sender: peter@192.168.1.5 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 02 Nov 2001 03:04:18 +0100 To: linux-mips@oss.sgi.com From: Peter Andersson Subject: Re: Mozilla on MIPS In-Reply-To: <20011101085149.A19298@lucon.org> References: <200111011554.KAA196739151@node109.ott.qnx.com> <200111011554.KAA196739151@node109.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have now managed to compile Mozilla on my mips-linux machine but only by "cheating". As it turned out when i compiled it with the -Wa,-xgot flags i did not get any errors from the mozilla source files. The thing is that, as Ryan Murray pointed out, that gcc has to be compiled with the -Wa,-xgot flags as well (because of "relocation truncated errors" in crtibeginS.o and probably the other .o files included with gcc). I did not manage to compile a working version of gcc for some reason. Also glibc had to be compiled with the same flags (otherwise crti.o returned the "relocation" error). Because of my own lack of competence i did not manage to pass the -Wa,-xgot arguments automatically during the making of the crt*.o-files. I could not find the file used for creating those particular files and i could not find them in any makefile. This meant that i had to wait for those files to "get made" and then stop the compilation and pass the arguments manually to gcc. These two factors resulted in me "cheating" to get it to compile. I just replaced the files from the glibc/gcc rpms (crti.o from glibc and crtibeginS.o from gcc) with the ones i had compiled and then i managed to compile mozilla without any trouble. This, of course, did not produce a working binary but if someone, a bit more knowledgeable about these things than i, recompiled gcc and glibc they probably would get it to work... I hope this will shed some light on the "mozilla problem". Perhaps i should mention that i got the web browser galeon (http://galeon.sourceforge.net/) working using the mozilla libs i compiled... Peter From owner-linux-mips@oss.sgi.com Fri Nov 2 05:36:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2DalN08138 for linux-mips-outgoing; Fri, 2 Nov 2001 05:36:47 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2Dae008135 for ; Fri, 2 Nov 2001 05:36:43 -0800 Received: from [192.168.1.170] (192.168.1.170 [192.168.1.170]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNXXF; Fri, 2 Nov 2001 08:36:31 -0500 Subject: BE Toolchain From: Marc Karasek To: Linux MIPS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 02 Nov 2001 08:37:28 -0500 Message-Id: <1004708261.31067.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Has anyone got the toolchain (binutils, gcc, glibc) to compile under BE? I followed the instructions at Bradley D. LaRonde has put together and got the LE to work w/o a prolem. I then proceeded to try the BE. Binutils compiled ok, gcc says that mipseb-linux is not a valid target. Looking in config.sub I saw a mips-linux, is this the BE option? Thanks, -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Fri Nov 2 06:06:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2E6d008614 for linux-mips-outgoing; Fri, 2 Nov 2001 06:06:39 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2E6Z008610 for ; Fri, 2 Nov 2001 06:06:35 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA06704; Fri, 2 Nov 2001 06:06:15 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA02594; Fri, 2 Nov 2001 06:06:13 -0800 (PST) Received: from mips.com (copsun14 [192.168.205.24]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fA2E6Ba13695; Fri, 2 Nov 2001 15:06:11 +0100 (MET) Message-ID: <3BE2A852.AFF0D905@mips.com> Date: Fri, 02 Nov 2001 15:06:10 +0100 From: Dan Temple X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Marc Karasek CC: Linux MIPS Subject: Re: BE Toolchain References: <1004708261.31067.6.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Marc Karasek wrote: > > Has anyone got the toolchain (binutils, gcc, glibc) to compile under > BE? I followed the instructions at Bradley D. LaRonde has put together > and got the LE to work w/o a prolem. I then proceeded to try the BE. > Binutils compiled ok, gcc says that mipseb-linux is not a valid target. > Looking in config.sub I saw a mips-linux, is this the BE option? If you can wait a day, here's what we use - which is compilable both BE and LE: We are going to release a complete RH7.1/MIPS installation image for the Atlas/Malta board on our FTP site, identical to what we use in MIPS engineering.All of our compiles for Linux/MIPS (except the kernel, which is probably irrelevant here) are done natively on Malta boards running Linux. We are using the compiler from the RedHat 7.1/MIPS Linux distribution. The toolchains on this distribution are (all commands run natively on the installation on a Malta board): > uname -a Linux copmld07.mips.com 2.4.3-MIPS-01.02 > gcc -v Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) > rpm -qf /usr/bin/ld binutils-2.11.92.0.10-1 > rpm -qa | grep glibc glibc-2.2.4-19.4 glibc-common-2.2.4-19.4 glibc-devel-2.2.4-19.4 glibc-profile-2.2.4-19.4 Dan Temple MIPS Denmark From owner-linux-mips@oss.sgi.com Fri Nov 2 06:39:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Edjm09420 for linux-mips-outgoing; Fri, 2 Nov 2001 06:39:45 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2Ede009417 for ; Fri, 2 Nov 2001 06:39:40 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA08819 for ; Fri, 2 Nov 2001 06:39:39 -0800 (PST) mail_from (marc_karasek@ivivity.com) Received: from [192.168.1.170] (192.168.1.170 [192.168.1.170]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCNXX8; Fri, 2 Nov 2001 09:17:32 -0500 Subject: Re: BE Toolchain From: Marc Karasek To: Dan Temple Cc: Linux MIPS In-Reply-To: <3BE2A852.AFF0D905@mips.com> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 02 Nov 2001 09:18:31 -0500 Message-Id: <1004710722.31067.20.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I should have been more specific, I should have said cross-toolchain. x86 -> MIPS. I will check out the packages you mentioned below, and will investigate them as an option. But as of right now, our build enviroment is still x86 Linux (RH 7.1). We will be targeting a MIPS processor of our own, I cannot get into too many details. We are using the Malta board right now for some testing/eval work. But will be quickly moving to our own platform in the near future. At that time the Malta will prob be put aside. On Fri, 2001-11-02 at 09:06, Dan Temple wrote: > Marc Karasek wrote: > > > > Has anyone got the toolchain (binutils, gcc, glibc) to compile under > > BE? I followed the instructions at Bradley D. LaRonde has put together > > and got the LE to work w/o a prolem. I then proceeded to try the BE. > > Binutils compiled ok, gcc says that mipseb-linux is not a valid target. > > Looking in config.sub I saw a mips-linux, is this the BE option? > > If you can wait a day, here's what we use - which is compilable both BE and LE: > > We are going to release a complete RH7.1/MIPS installation image for the Atlas/Malta board on our FTP site, identical to what we use in MIPS engineering.All of our compiles for Linux/MIPS (except the kernel, which is probably irrelevant here) are done natively on Malta boards running Linux. We are using the compiler from the RedHat 7.1/MIPS Linux distribution. > > The toolchains on this distribution are (all commands run natively on > the installation on a Malta board): > > > uname -a > Linux copmld07.mips.com 2.4.3-MIPS-01.02 > > > gcc -v > Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) > > > rpm -qf /usr/bin/ld > binutils-2.11.92.0.10-1 > > > rpm -qa | grep glibc > glibc-2.2.4-19.4 > glibc-common-2.2.4-19.4 > glibc-devel-2.2.4-19.4 > glibc-profile-2.2.4-19.4 > > Dan Temple > MIPS Denmark -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Fri Nov 2 07:36:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2Fa6C10637 for linux-mips-outgoing; Fri, 2 Nov 2001 07:36:06 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2Fa2010634 for ; Fri, 2 Nov 2001 07:36:02 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 24C99125C9; Fri, 2 Nov 2001 07:36:00 -0800 (PST) Date: Fri, 2 Nov 2001 07:36:00 -0800 From: "H . J . Lu" To: Marc Karasek Cc: Dan Temple , Linux MIPS Subject: Re: BE Toolchain Message-ID: <20011102073600.B7208@lucon.org> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1004710722.31067.20.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1004710722.31067.20.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Fri, Nov 02, 2001 at 09:18:31AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 02, 2001 at 09:18:31AM -0500, Marc Karasek wrote: > I should have been more specific, I should have said cross-toolchain. > x86 -> MIPS. I will check out the packages you mentioned below, and > will investigate them as an option. But as of right now, our build > enviroment is still x86 Linux (RH 7.1). We will be targeting a MIPS > processor of our own, I cannot get into too many details. We are using > the Malta board right now for some testing/eval work. But will be > quickly moving to our own platform in the near future. At that time the > Malta will prob be put aside. > See #1 below. H.J. ---- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You may need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Fri Nov 2 07:49:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA2FngF10822 for linux-mips-outgoing; Fri, 2 Nov 2001 07:49:42 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA2Fnc010819 for ; Fri, 2 Nov 2001 07:49:38 -0800 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id CF3D6590A9; Fri, 2 Nov 2001 06:45:59 -0500 (EST) Message-ID: <00dd01c163b6$064a39d0$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Marc Karasek" , "Linux MIPS" References: <1004708261.31067.6.camel@localhost.localdomain> Subject: Re: BE Toolchain Date: Fri, 2 Nov 2001 10:49:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I think it should be mips-linux, not mipseb-linux. Regards, Brad ----- Original Message ----- From: "Marc Karasek" To: "Linux MIPS" Sent: Friday, November 02, 2001 8:37 AM Subject: BE Toolchain > Has anyone got the toolchain (binutils, gcc, glibc) to compile under > BE? I followed the instructions at Bradley D. LaRonde has put together > and got the LE to work w/o a prolem. I then proceeded to try the BE. > Binutils compiled ok, gcc says that mipseb-linux is not a valid target. > Looking in config.sub I saw a mips-linux, is this the BE option? > > Thanks, > > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > (770) 986-8925 > (770) 986-8926 Fax > *************************/ > From owner-linux-mips@oss.sgi.com Sun Nov 4 12:19:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4KJpg28903 for linux-mips-outgoing; Sun, 4 Nov 2001 12:19:51 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4KJn028900 for ; Sun, 4 Nov 2001 12:19:50 -0800 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id 841A8590A9 for ; Sun, 4 Nov 2001 11:15:57 -0500 (EST) Message-ID: <067801c1656e$1f5274b0$3501010a@ltc.com> From: "Bradley D. LaRonde" To: Subject: hz_to_std Date: Sun, 4 Nov 2001 15:20:03 -0500 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What is the intent and purpose of the hz_to_std stuff? Regards, Brad From owner-linux-mips@oss.sgi.com Sun Nov 4 14:32:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA4MWAI31814 for linux-mips-outgoing; Sun, 4 Nov 2001 14:32:10 -0800 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA4MVa031805 for ; Sun, 4 Nov 2001 14:31:36 -0800 Received: (qmail 27779 invoked by uid 0); 4 Nov 2001 22:31:28 -0000 Received: from pd953a76d.dip.t-dialin.net (HELO bogon.ms20.nix) (217.83.167.109) by mail.gmx.net (mp005-rz3) with SMTP; 4 Nov 2001 22:31:28 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id B80E0B807; Sun, 4 Nov 2001 23:32:19 +0100 (CET) Date: Sun, 4 Nov 2001 23:32:19 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: ralf@gnu.org Subject: arcboot patches Message-ID: <20011104233218.A15847@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com, ralf@gnu.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline attached is a first set of patches to make arcboot somewhat work for big endian mips, mostly: - compile with -fno-pic, since the IP22 PROMs can't handle this - IP22 uses ARCS not ARC (MEMORYTYPE) - IP22 is big endian (LARGEINTEGER) - move everything into KSEG0 - make function prototypes same as in libc - remove i386 references - convert some ARCS errorcodes to EXT2_ET_ errors, since ARCS errorcodes let ext2fs_strerror crash. It does still not boot the kernel correctly, but it's quiet close... Regards, -- Guido --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="arcboot-2001-11-04.diff" Index: arclib/Makefile =================================================================== RCS file: /cvs/arcboot/arclib/Makefile,v retrieving revision 1.1 diff -u -u -r1.1 Makefile --- arclib/Makefile 2001/03/20 02:44:56 1.1 +++ arclib/Makefile 2001/11/04 22:06:28 @@ -1,7 +1,9 @@ # # Copyright 1999 Silicon Graphics, Inc. # -CFLAGS = -O +CFLAGS = -O -Werror -Wall -mno-abicalls -G 0 -fno-pic +ASFLAGS= -mno-abicalls -G 0 -fno-pic + OBJECTS = arc.o stdio.o stdlib.o string.o all: libarc.a Index: arclib/arc.h =================================================================== RCS file: /cvs/arcboot/arclib/arc.h,v retrieving revision 1.2 diff -u -u -r1.2 arc.h --- arclib/arc.h 2001/03/20 02:55:56 1.2 +++ arclib/arc.h 2001/11/04 22:06:28 @@ -1,5 +1,6 @@ /* * Copyright 1999 Silicon Graphics, Inc. + * 2001 Guido Guenther */ #ifndef _ARC_H_ #define _ARC_H_ @@ -109,15 +110,16 @@ UCHAR ProductId[8]; } SYSTEMID; +/* This is ARCS not ARC */ typedef enum { ExceptionBlock, SystemParameterBlock, + FreeContiguous, FreeMemory, BadMemory, LoadedProgram, FirmwareTemporary, FirmwarePermanent, - FreeContiguous } MEMORYTYPE; typedef struct { @@ -157,8 +159,13 @@ } OPENMODE; typedef struct { +#ifdef __MIPSEL__ ULONG LowPart; + *LONG HighPart; +#else /* !(__MIPSEL__) */ LONG HighPart; + ULONG LowPart; +#endif } LARGEINTEGER; typedef enum { Index: arclib/spb.h =================================================================== RCS file: /cvs/arcboot/arclib/spb.h,v retrieving revision 1.2 diff -u -u -r1.2 spb.h --- arclib/spb.h 2001/03/20 02:55:56 1.2 +++ arclib/spb.h 2001/11/04 22:06:28 @@ -90,7 +90,7 @@ ADAPTER Adapters[1]; } SPB; -#define SystemParameterBlock ((SPB *) 0x1000) +#define SystemParameterBlock ((SPB *) 0xA0001000UL) #define FVector (SystemParameterBlock->FirmwareVector) #endif /* _SPB_H_ */ Index: arclib/stdlib.c =================================================================== RCS file: /cvs/arcboot/arclib/stdlib.c,v retrieving revision 1.2 diff -u -u -r1.2 stdlib.c --- arclib/stdlib.c 2001/03/20 02:55:56 1.2 +++ arclib/stdlib.c 2001/11/04 22:06:29 @@ -2,6 +2,7 @@ * Copyright 1999 Silicon Graphics, Inc. */ #include "stdlib.h" +#include "string.h" #include "arc.h" @@ -43,7 +44,7 @@ } -void *free(void *ptr) +void free(void *ptr) { if (ptr != NULL) { Node *mem = ((Node *) ptr) - 1; Index: arclib/stdlib.h =================================================================== RCS file: /cvs/arcboot/arclib/stdlib.h,v retrieving revision 1.2 diff -u -u -r1.2 stdlib.h --- arclib/stdlib.h 2001/03/20 02:55:56 1.2 +++ arclib/stdlib.h 2001/11/04 22:06:29 @@ -8,7 +8,7 @@ #include "types.h" extern void *malloc(size_t size); -extern void *free(void *ptr); +extern void free(void *ptr); extern void *realloc(void *ptr, size_t size); extern void arclib_malloc_add(ULONG start, ULONG size); Index: arclib/string.c =================================================================== RCS file: /cvs/arcboot/arclib/string.c,v retrieving revision 1.2 diff -u -u -r1.2 string.c --- arclib/string.c 2001/03/20 02:55:56 1.2 +++ arclib/string.c 2001/11/04 22:06:29 @@ -101,6 +101,7 @@ while (n-- > 0) *(mem++) = (char) c; + return s; } void __bzero(char *p, int len) Index: ext2load/Makefile =================================================================== RCS file: /cvs/arcboot/ext2load/Makefile,v retrieving revision 1.2 diff -u -u -r1.2 Makefile --- ext2load/Makefile 2001/03/20 02:55:56 1.2 +++ ext2load/Makefile 2001/11/04 22:06:29 @@ -1,33 +1,37 @@ # # Copyright 1999 Silicon Graphics, Inc. +# 2001 Guido Guenther # EXT2_OBJS = loader.o ext2io.o run.o -LARC_OBJS = larc.o +LARC_OBJS = larc.o run.o OBJECTS = $(EXT2_OBJS) $(LARC_OBJS) ARCLIBDIR = ../arclib ARCLIB = $(ARCLIBDIR)/libarc.a -EXT2LIB = /usr/lib/libext2fs.a +#EXT2LIB = /usr/lib/libext2fs.a +EXT2LIB = ../../e2fslib/e2fsprogs-1.25/lib/libext2fs.a -CFLAGS = -O -I$(ARCLIBDIR) -# LD must be a an i386pe-capable ld -# LD = /home/bh/bu291/bin/ld -m i386pe -#LD = /gnu/bin/ld -m i386pe +CFLAGS = -O -I$(ARCLIBDIR) -Wall -mno-abicalls -G 0 -fno-pic +ASFLAGS= -mno-abicalls -G 0 -fno-pic + +# uncomment for debugging +CFLAGS+=-DDEBUG + LD = ld -LDFLAGS = -e _start +LDFLAGS = -T ld.script -TARGETS = ext2load.exe larc.exe +TARGETS = ext2load larc all: $(TARGETS) -larc.exe: larc.o run.o $(ARCLIB) +larc: $(LARC_OBJS) $(ARCLIB) rm -f $@ - $(LD) $(LDFLAGS) -o $@ larc.o run.o $(ARCLIB) + $(LD) $(LDFLAGS) -o $@ $(LARC_OBJS) $(ARCLIB) -ext2load.exe: $(EXT2_OBJS) $(ARCLIB) +ext2load: $(EXT2_OBJS) $(ARCLIB) rm -f $@ $(LD) $(LDFLAGS) -o $@ $(EXT2_OBJS) $(EXT2LIB) $(ARCLIB) clean: - rm -f $(TARGETS) $(OBJECTS) + rm -f $(TARGETS) $(OBJECTS) tags Index: ext2load/ext2io.c =================================================================== RCS file: /cvs/arcboot/ext2load/ext2io.c,v retrieving revision 1.2 diff -u -u -r1.2 ext2io.c --- ext2load/ext2io.c 2001/03/20 02:55:56 1.2 +++ ext2load/ext2io.c 2001/11/04 22:06:29 @@ -2,6 +2,7 @@ * extio.c * * Copyright 1999 Silicon Graphics, Inc. + * 2001 Guido Guenther * * Derived from e2fsprogs lib/ext2fs/unix_io.c * Copyright (C) 1993, 1994, 1995 Theodore Ts'o. @@ -91,6 +92,9 @@ status = ArcOpen((char *) name, priv->mode, &priv->fileID); + if( status ) { + status = EXT2_ET_BAD_DEVICE_NAME; + } } } } @@ -163,7 +167,6 @@ { struct arc_private_data *priv; LARGEINTEGER position; - errcode_t status; priv = (struct arc_private_data *) channel->private_data; mul64(block, channel->block_size, &position); @@ -196,8 +199,9 @@ status = (channel->read_error) (channel, block, count, buf, length, nread, status); } + } else { + status = EXT2_ET_BAD_BLOCK_NUM; } - return status; } @@ -277,6 +281,7 @@ list = list->next; } + return NULL; } Index: ext2load/loader.c =================================================================== RCS file: /cvs/arcboot/ext2load/loader.c,v retrieving revision 1.2 diff -u -u -r1.2 loader.c --- ext2load/loader.c 2001/03/20 02:55:56 1.2 +++ ext2load/loader.c 2001/11/04 22:06:30 @@ -1,6 +1,7 @@ /* * Copyright 1999, 2001 Silicon Graphics, Inc. * Copyright 2001 Ralf Baechle + * 2001 Guido Guenther */ #include #include @@ -15,6 +16,8 @@ #include #include +#include + #define ANSI_CLEAR "\033[2J" #define PAGE_SIZE 4096 @@ -29,7 +32,7 @@ * Reserve this memory for loading kernel * Don't put loader structures there because they would be overwritten */ -ULONG reserve_base = 0x0100000; +ULONG reserve_base = 0x88002000; ULONG reserve_size = 0x0200000; extern const char *ext2fs_strerror(long error); @@ -68,20 +71,30 @@ { MEMORYDESCRIPTOR *current = NULL; ULONG stack = (ULONG) & current; +#ifdef DEBUG + printf("stack starts at: 0x%x\n", stack); +#endif current = ArcGetMemoryDescriptor(current); + if(! current ) { + Fatal("Can't find any valid memory descriptors!\n"); + } while (current != NULL) { /* * The spec says we should have an adjacent FreeContiguous * memory area that includes our stack. It would be much * easier to just look for that and give it to malloc, but - * the 320 only shows FreeMemory areas, no FreeContiguous. + * the Indy only shows FreeMemory areas, no FreeContiguous. * Oh well. */ if (current->Type == FreeMemory) { - ULONG start = current->BasePage * PAGE_SIZE; + ULONG start = KSEG0ADDR(current->BasePage * PAGE_SIZE); ULONG end = start + (current->PageCount * PAGE_SIZE); +#if DEBUG + printf("Free Memory(%u) segment found at (0x%x,0x%x).\n", + current->Type, start, end); +#endif /* Leave some space for our stack */ if ((stack >= start) && (stack < end)) @@ -89,7 +102,6 @@ (stack - (STACK_PAGES * PAGE_SIZE)) & ~(PAGE_SIZE - 1); - /* Don't use memory from reserved region */ if ((start >= reserve_base) && (start < (reserve_base + reserve_size))) @@ -98,11 +110,14 @@ && (end <= (reserve_base + reserve_size))) end = reserve_base; - - if (end > start) + if (end > start) { +#ifdef DEBUG + printf("Adding %u bytes at 0x%x to the list of available memory\n", + end-start, start); +#endif arclib_malloc_add(start, end - start); + } } - current = ArcGetMemoryDescriptor(current); } } @@ -263,8 +279,8 @@ if (header.e_ident[EI_CLASS] != ELFCLASS32) Fatal("Not a 32-bit file\n"); - if (header.e_ident[EI_DATA] != ELFDATA2LSB) - Fatal("Not a little-endian file\n"); + if (header.e_ident[EI_DATA] != ELFDATA2MSB) + Fatal("Not a big-endian file\n"); if (header.e_ident[EI_VERSION] != EV_CURRENT) Fatal("Wrong ELF version\n"); @@ -290,7 +306,7 @@ { extern io_manager arc_io_manager; ext2_filsys fs; - ino_t file_inode; + ext2_ino_t file_inode; ext2_file_t file; errcode_t status; @@ -322,7 +338,7 @@ void _start(LONG argc, CHAR * argv[], CHAR * envp[]) { /* Print identification */ - printf(ANSI_CLEAR "\nARC Linux ext2fs loader, 07jun99\n\n"); + printf(ANSI_CLEAR "\narcboot: ARC Linux ext2fs loader, 2001-11-03\n\n"); InitMalloc(); --Q68bSM7Ycu6FN28Q-- From owner-linux-mips@oss.sgi.com Sun Nov 4 20:32:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA54Win08196 for linux-mips-outgoing; Sun, 4 Nov 2001 20:32:44 -0800 Received: from ns1.ltc.com (ns1.ltc.com [38.149.17.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA54Wd008193 for ; Sun, 4 Nov 2001 20:32:40 -0800 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id F30EF590A9; Sun, 4 Nov 2001 19:28:45 -0500 (EST) Message-ID: <07b401c165b2$f981ec30$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Green" , "Linux-mips" , "MipsMailList" References: <008701c165ac$1a49a9a0$4c0c5c8c@trd.iii.org.tw> Subject: Re: do_ri( ) Date: Sun, 4 Nov 2001 23:33:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've seen the same thing but on a different processor (VR5432). gcc 3.0.1, glibc 2.2.3. I suspect stack/register corruption. Regards, Brad ----- Original Message ----- From: Green To: Linux-mips ; MipsMailList Sent: Sunday, November 04, 2001 10:43 PM Subject: do_ri( ) Dear all, I often get into trouble executing multithread application. Sometimes it will appear the message " Illegal instruction = 0xXXXX " in do_ri() function in /arch/mips/kernel/traps.c. It happened randomly. Up to now, I still didn't know how to fix bug. If any one know how to fix it, please reply me. Appreciate in sincerely. P.S My mips bos is R3912. ~~ Green greeen@iii.org.tw From owner-linux-mips@oss.sgi.com Mon Nov 5 00:10:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA58A7111917 for linux-mips-outgoing; Mon, 5 Nov 2001 00:10:07 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA58A0011903 for ; Mon, 5 Nov 2001 00:10:00 -0800 Received: from hcdong11752a ([10.105.28.74]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GMBGV800.C8L for ; Mon, 5 Nov 2001 15:30:45 +0800 Message-ID: <013301c165cc$5d030fa0$4a1c690a@huawei.com> From: "machael" To: Subject: vmalloc bugs in 2.4.5??? Date: Mon, 5 Nov 2001 15:34:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hello: I use linux-2.4.5 and I think VMALLOC may have some bugs which i don't know how to fixup. I try to replace some kernel functions with my own implementations.I will explain it in the following: Let's say: void (*my_func)(void)=func1; where "my_func" is a function pointer defined in kernel, and "func1" is a function(void func1(void)) implemented in kernel.And "my_func" is an EXPORTED SYMBOL in mips_ksyms.c. Now I want to replace "func1" with my own "func2" in a module my_module.o: extern void (*my_func)(void); my_func = func2; where "func2" is a function (void fun2(void)) implemented in "my_module.o". If I do "insmod my_module.o", the kernel should run OK. In fact, it is often met an "unhandled kernel unaligned access" or "do_page_fault" exception and then panics. We know "func1" should be in KSEG0(unmapped , cached) ,So it's address should be 0x8XXXXXXX.And "my_func" should also pointed to this same address before inserting my_module.o. "func2" should be in KSEG2(mapped, cached) since it is implemented in module, So it's address should be 0xCXXXXXXX.After inserting my_module.o, "my_func" should be changed to pointed to this new address in KSEG2. But kernel panics...... If I change "module_map()" in include/asm/module.h from vmalloc to kmalloc, kernel runs ok after inserting my module. So I think vmalloc may have some bugs. Anyone knows how to fixup it? machael From owner-linux-mips@oss.sgi.com Mon Nov 5 09:18:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA5HIbc13407 for linux-mips-outgoing; Mon, 5 Nov 2001 09:18:37 -0800 Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA5HIM013403 for ; Mon, 5 Nov 2001 09:18:22 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel1.hp.com (Postfix) with ESMTP id 80CE051F; Mon, 5 Nov 2001 12:18:21 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id C9C7D1F510; Mon, 5 Nov 2001 12:18:19 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 12:18:19 -0500 Message-ID: From: "TWEDE,ROGER (HP-Boise,ex1)" To: "'Bradley D. LaRonde'" , Green , Linux-mips , MipsMailList Subject: RE: do_ri( ) Date: Mon, 5 Nov 2001 12:18:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've seen the same with glibc 2.2.4 on the QED RM5261 processor (Mips 5000). I can take a multi-threaded application that runs without fail using glibc 2.2.2 and reproduce the failure using glibc 2.2.3 and glibc 2.2.4. A small test app I wrote to exhibit the problem is included below. I was using gcc 3.0 at the time. I question whether gcc 2.96 might help since the glibc variants at sgi.com were compiled using 2.96. Regards, Roger // CODE STARTS BELOW #include #include #include #include #include #include #include struct ThreadStartInfo { pthread_mutex_t InitCompleteMutex; pthread_cond_t InitCompleteCond; void * (*Func)(void *); void * Arg; int Priority; char * ThreadName; unsigned char InitCompleteCount; }; static void * StartFunction(void * Arg) { struct ThreadStartInfo * StartInfo = (struct ThreadStartInfo *) Arg; int result; void * retVal = 0; assert(Arg != NULL); result = pthread_mutex_lock(&(StartInfo->InitCompleteMutex)); assert(result == 0); printf("pid=%d thread mutex locked at x%x\n", getpid(), &(StartInfo->InitCompleteMutex)); StartInfo->InitCompleteCount = 1; result = pthread_cond_signal(&(StartInfo->InitCompleteCond)); assert(result == 0); printf("pid=%d thread cond signal sent, unlocking at 0x%x\n", getpid(), &(StartInfo->InitCompleteMutex)); result = pthread_mutex_unlock(&(StartInfo->InitCompleteMutex)); assert(result == 0); printf("pid=%d thread unlocked\n", getpid()); sched_yield(); printf("pid=%d yielded and back again\n", getpid()); return(retVal); } int main(void) { pthread_t ThreadObject; struct ThreadStartInfo StartInfo; pthread_mutexattr_t mutexAttr; pthread_attr_t threadAttr; pthread_condattr_t condAttr; int result = 0; StartInfo.ThreadName = "mythread"; result = pthread_mutexattr_init(&mutexAttr); assert(result == 0); printf("pid=%d Init mutex\n", getpid()); result = pthread_mutex_init(&(StartInfo.InitCompleteMutex), &mutexAttr); assert(result == 0); result = pthread_condattr_init(&condAttr); assert(result == 0); result = pthread_cond_init(&(StartInfo.InitCompleteCond), &condAttr); assert(result == 0); StartInfo.InitCompleteCount = 0; pthread_mutex_lock(&(StartInfo.InitCompleteMutex)); printf("pid=%d About to create thread: %s\n", getpid(), StartInfo.ThreadName); result = pthread_attr_init(&threadAttr); assert(result == 0); result = pthread_create(&ThreadObject, &threadAttr, &StartFunction, (void *)&StartInfo); assert(result == 0); while ((result == 0) && (StartInfo.InitCompleteCount == 0)) { do { printf("pid=%d about to cond_wait for %s init 1.\n", getpid(), StartInfo.ThreadName); result = pthread_cond_wait(&(StartInfo.InitCompleteCond), &(StartInfo.InitCompleteMutex)); printf("pid=%d back from cond_wait for %s init 1. result=%d\n", getpid(), StartInfo.ThreadName, result); } while (result == EINTR); } result = pthread_mutex_unlock(&(StartInfo.InitCompleteMutex)); assert(result == 0); getchar(); return 0; } // CODE ABOVE -----Original Message----- From: Bradley D. LaRonde [mailto:brad@ltc.com] Sent: Sunday, November 04, 2001 9:33 PM To: Green; Linux-mips; MipsMailList Subject: Re: do_ri( ) I've seen the same thing but on a different processor (VR5432). gcc 3.0.1, glibc 2.2.3. I suspect stack/register corruption. Regards, Brad ----- Original Message ----- From: Green To: Linux-mips ; MipsMailList Sent: Sunday, November 04, 2001 10:43 PM Subject: do_ri( ) Dear all, I often get into trouble executing multithread application. Sometimes it will appear the message " Illegal instruction = 0xXXXX " in do_ri() function in /arch/mips/kernel/traps.c. It happened randomly. Up to now, I still didn't know how to fix bug. If any one know how to fix it, please reply me. Appreciate in sincerely. P.S My mips bos is R3912. ~~ Green greeen@iii.org.tw From owner-linux-mips@oss.sgi.com Mon Nov 5 17:09:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6196O31757 for linux-mips-outgoing; Mon, 5 Nov 2001 17:09:06 -0800 Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6194031753 for ; Mon, 5 Nov 2001 17:09:04 -0800 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id RAA01276 for ; Mon, 5 Nov 2001 17:09:01 -0800 (PST) (envelope-from rh@matriplex.com) Date: Mon, 5 Nov 2001 17:09:01 -0800 (PST) From: Richard Hodges To: linux-mips@oss.sgi.com Subject: Arguments for kernel_entry? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Would anyone be able to provide information on the arguments to kernel_entry (in head.S)? The first two look pretty straightforward, argument count and string vectors. I assume that argument zero is actually the first argument, and not "vmlinux"? What are the third (ulong) and fourth (int *) arguments? I have read head.S and searched for days trying to find this info :-( I thought PMON would be a decent reference, but run_target() only seems to set $4 and $5, before calling _go(). Thanks! -Richard From owner-linux-mips@oss.sgi.com Mon Nov 5 17:21:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA61L0B32073 for linux-mips-outgoing; Mon, 5 Nov 2001 17:21:00 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA61Kv032070 for ; Mon, 5 Nov 2001 17:20:57 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fA61LvB28782; Mon, 5 Nov 2001 17:21:57 -0800 Subject: Re: Arguments for kernel_entry? From: Pete Popov To: Richard Hodges Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.01.15.16 (Preview Release) Date: 05 Nov 2001 17:21:17 -0800 Message-Id: <1005009677.27128.300.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 17:09, Richard Hodges wrote: > Would anyone be able to provide information on the arguments > to kernel_entry (in head.S)? > > The first two look pretty straightforward, argument count and > string vectors. I assume that argument zero is actually the > first argument, and not "vmlinux"? > > What are the third (ulong) and fourth (int *) arguments? I have > read head.S and searched for days trying to find this info :-( > > I thought PMON would be a decent reference, but run_target() only > seems to set $4 and $5, before calling _go(). That's boot code specific. MIPS Tech's yamon passes: 0: number of arguments 1: pointer to first arg 2: pointer to environment variables 3: pointer to prom routines you can call Pete From owner-linux-mips@oss.sgi.com Mon Nov 5 17:45:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA61j1w32651 for linux-mips-outgoing; Mon, 5 Nov 2001 17:45:01 -0800 Received: from mail.matriplex.com (ns1.matriplex.com [208.131.42.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA61iv032636 for ; Mon, 5 Nov 2001 17:44:57 -0800 Received: from mail.matriplex.com (mail.matriplex.com [208.131.42.9]) by mail.matriplex.com (8.9.2/8.9.2) with ESMTP id RAA01352; Mon, 5 Nov 2001 17:44:53 -0800 (PST) (envelope-from rh@matriplex.com) Date: Mon, 5 Nov 2001 17:44:53 -0800 (PST) From: Richard Hodges To: Pete Popov cc: linux-mips Subject: Re: Arguments for kernel_entry? In-Reply-To: <1005009677.27128.300.camel@zeus> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 5 Nov 2001, Pete Popov wrote: > On Mon, 2001-11-05 at 17:09, Richard Hodges wrote: > > Would anyone be able to provide information on the arguments > > to kernel_entry (in head.S)? > > > > The first two look pretty straightforward, argument count and > > string vectors. I assume that argument zero is actually the > > first argument, and not "vmlinux"? > > > > What are the third (ulong) and fourth (int *) arguments? I have > > read head.S and searched for days trying to find this info :-( > > > > I thought PMON would be a decent reference, but run_target() only > > seems to set $4 and $5, before calling _go(). > That's boot code specific. MIPS Tech's yamon passes: > > 0: number of arguments > 1: pointer to first arg > 2: pointer to environment variables > 3: pointer to prom routines you can call Okay, I think I have it now. It looks like _only_ prom_init() is interested in these arguments. 1. kernel_entry() gives them to init_arch(), 2. init_arch gives them to prom_init(), 3. prom_init() does whatever it wants (eg, builds arcs_cmdline) 4. init_arch ends with a call to start_kernel(), and the original arguments are effectively thrown away. Or put more simply, the kernel_entry arguments are only used by prom_init(). Is this right? Thanks! -Richard From owner-linux-mips@oss.sgi.com Mon Nov 5 17:50:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA61o3H00383 for linux-mips-outgoing; Mon, 5 Nov 2001 17:50:03 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA61nv000375; Mon, 5 Nov 2001 17:49:57 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 659267DD; Tue, 6 Nov 2001 02:49:55 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D546D4741; Mon, 5 Nov 2001 17:46:39 -0800 (PST) Date: Mon, 5 Nov 2001 17:46:39 -0800 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20011105174639.A11942@paradigm.rfc822.org> References: <200111060055.fA60tX331454@oss.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <200111060055.fA60tX331454@oss.sgi.com> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 05, 2001 at 04:55:33PM -0800, Ralf Baechle wrote: > CVSROOT: /home/pub/cvs > Module name: linux > Changes by: ralf@oss.sgi.com 01/11/05 16:55:33 [...] > Log message: > Merge with Linux 2.1.13. =20 I felt we are going back to stone age ;9 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE750D/Uaz2rXW+gJcRAmzkAJ9UiV34FOKpTK1bEI2EsWGQnlxgqQCgyPFj PKR3BGLWi9V2Aaz4IfSp5vw= =xbYF -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-linux-mips@oss.sgi.com Mon Nov 5 18:07:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA627ZV00953 for linux-mips-outgoing; Mon, 5 Nov 2001 18:07:35 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA627V000950 for ; Mon, 5 Nov 2001 18:07:31 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fA628XB30954; Mon, 5 Nov 2001 18:08:33 -0800 Subject: Re: Arguments for kernel_entry? From: Pete Popov To: Richard Hodges Cc: linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.100+cvs.2001.11.01.15.16 (Preview Release) Date: 05 Nov 2001 18:07:54 -0800 Message-Id: <1005012474.27128.306.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 2001-11-05 at 17:44, Richard Hodges wrote: > On 5 Nov 2001, Pete Popov wrote: > > > On Mon, 2001-11-05 at 17:09, Richard Hodges wrote: > > > Would anyone be able to provide information on the arguments > > > to kernel_entry (in head.S)? > > > > > > The first two look pretty straightforward, argument count and > > > string vectors. I assume that argument zero is actually the > > > first argument, and not "vmlinux"? > > > > > > What are the third (ulong) and fourth (int *) arguments? I have > > > read head.S and searched for days trying to find this info :-( > > > > > > I thought PMON would be a decent reference, but run_target() only > > > seems to set $4 and $5, before calling _go(). > > > That's boot code specific. MIPS Tech's yamon passes: > > > > 0: number of arguments > > 1: pointer to first arg > > 2: pointer to environment variables > > 3: pointer to prom routines you can call > > Okay, I think I have it now. It looks like _only_ prom_init() is > interested in these arguments. > > 1. kernel_entry() gives them to init_arch(), > 2. init_arch gives them to prom_init(), > 3. prom_init() does whatever it wants (eg, builds arcs_cmdline) > 4. init_arch ends with a call to start_kernel(), and the original > arguments are effectively thrown away. > > Or put more simply, the kernel_entry arguments are only used by > prom_init(). Is this right? I believe that's correct. arch/mips/kernel/setup.c saves arcs_cmdline in command_line and that's the end of arcs_cmdline. Pete From owner-linux-mips@oss.sgi.com Mon Nov 5 23:54:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA67s8607701 for linux-mips-outgoing; Mon, 5 Nov 2001 23:54:08 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA67s6007697 for ; Mon, 5 Nov 2001 23:54:06 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA67rTH28179; Mon, 5 Nov 2001 23:53:29 -0800 Date: Mon, 5 Nov 2001 23:53:29 -0800 From: Ralf Baechle To: "Bradley D. LaRonde" Cc: linux-mips@oss.sgi.com Subject: Re: hz_to_std Message-ID: <20011105235329.C18038@dea.linux-mips.net> References: <067801c1656e$1f5274b0$3501010a@ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <067801c1656e$1f5274b0$3501010a@ltc.com>; from brad@ltc.com on Sun, Nov 04, 2001 at 03:20:03PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Nov 04, 2001 at 03:20:03PM -0500, Bradley D. LaRonde wrote: > From: "Bradley D. LaRonde" > To: > Subject: hz_to_std > Date: Sun, 4 Nov 2001 15:20:03 -0500 > > What is the intent and purpose of the hz_to_std stuff? DECstation needs to be built with HZ != 100 but we have to keep the API uninfluenced by this. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 6 04:06:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6C6wC14029 for linux-mips-outgoing; Tue, 6 Nov 2001 04:06:58 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6C6s014024 for ; Tue, 6 Nov 2001 04:06:55 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA21886 for ; Tue, 6 Nov 2001 04:06:48 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA22737 for ; Tue, 6 Nov 2001 04:06:47 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fA6C6lA10821 for ; Tue, 6 Nov 2001 13:06:47 +0100 (MET) Message-ID: <3BE7D256.8E763AC3@mips.com> Date: Tue, 06 Nov 2001 13:06:46 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: RedHat7.1 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have made a CD-ROM images for easy CD-ROM installation of a RedHat7.1 distribution on a MIPS Atlas or Malta board. The image contains both a little and bigendian distribution. You can download the images from the FTP site: ftp://ftp.mips.com/pub/linux/mips/installation/ Burn the image to a CD-ROM and follow the INSTALL guide for installation on a harddisk attached to either a Atlas or Malta board. You can also download the tar-ball for NFS installation. Hope that people with a Atlas or a Malta board find it useful. /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Nov 6 06:08:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6E85Q18699 for linux-mips-outgoing; Tue, 6 Nov 2001 06:08:05 -0800 Received: from web12302.mail.yahoo.com (web12302.mail.yahoo.com [216.136.173.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6E81018694 for ; Tue, 6 Nov 2001 06:08:01 -0800 Message-ID: <20011106140801.54737.qmail@web12302.mail.yahoo.com> Received: from [192.35.17.233] by web12302.mail.yahoo.com via HTTP; Tue, 06 Nov 2001 06:08:01 PST Date: Tue, 6 Nov 2001 06:08:01 -0800 (PST) From: amit lubovsky Subject: boot Linux kernel on MIPS 5kc - Malta board To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I work with the MIPS5kc on the Malta board and looking for information on how to boot the kernel (2.4.2) from the on board flash??? Any help will be welcomed. Amit. __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com From owner-linux-mips@oss.sgi.com Tue Nov 6 08:17:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6GHFa24600 for linux-mips-outgoing; Tue, 6 Nov 2001 08:17:15 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6GHC024594 for ; Tue, 6 Nov 2001 08:17:12 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA03037; Tue, 6 Nov 2001 17:14:40 +0100 (MET) Date: Tue, 6 Nov 2001 17:14:39 +0100 (MET) From: "Maciej W. Rozycki" To: Jun Sun cc: Scott A McConnell , linux-mips@oss.sgi.com Subject: Re: [Fwd: Kernel panic: Caught reserved exception - should not happen.] In-Reply-To: <3BE1D1C0.E32905BA@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 1 Nov 2001, Jun Sun wrote: > *sigh* We need another ugly #ifdef in the head.S file. A better approach would be to define a macro in a header file and only expand it in head.S. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 6 11:20:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6JK1407946 for linux-mips-outgoing; Tue, 6 Nov 2001 11:20:01 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6JJx007941 for ; Tue, 6 Nov 2001 11:19:59 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA6JJtjV030200 for ; Tue, 6 Nov 2001 11:19:55 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA6JJt3w030196 for ; Tue, 6 Nov 2001 11:19:55 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 6 Nov 2001 11:19:54 -0800 (PST) From: James Simmons To: linux-mips@oss.sgi.com Subject: 1$ clobber bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I believe the ITE generic time code has a 1$ clobber bug in it. Here is a patch to fix this. --- time.c Fri Oct 5 10:01:22 2001 +++ /usr/src/linux/arch/mips/ite-boards/generic/time.c Tue Nov 6 11:38:00 2001 @@ -303,7 +303,8 @@ :"r" (timerhi), "m" (timerlo), "r" (tmp), - "r" (USECS_PER_JIFFY)); + "r" (USECS_PER_JIFFY) + :"$1"); cached_quotient = quotient; } From owner-linux-mips@oss.sgi.com Tue Nov 6 11:35:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6JZuU08335 for linux-mips-outgoing; Tue, 6 Nov 2001 11:35:56 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA6JZp008332 for ; Tue, 6 Nov 2001 11:35:51 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA6JZIi01957; Tue, 6 Nov 2001 11:35:18 -0800 Date: Tue, 6 Nov 2001 11:35:18 -0800 From: Ralf Baechle To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: arcboot patches Message-ID: <20011106113517.F1524@dea.linux-mips.net> References: <20011104233218.A15847@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011104233218.A15847@bogon.ms20.nix>; from agx@sigxcpu.org on Sun, Nov 04, 2001 at 11:32:19PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Nov 04, 2001 at 11:32:19PM +0100, Guido Guenther wrote: > typedef struct { > +#ifdef __MIPSEL__ > ULONG LowPart; > + *LONG HighPart; > +#else /* !(__MIPSEL__) */ > LONG HighPart; > + ULONG LowPart; > +#endif > } LARGEINTEGER; Why not simply defining LARGEINTEGER as long long? > Index: arclib/spb.h > =================================================================== > RCS file: /cvs/arcboot/arclib/spb.h,v > retrieving revision 1.2 > diff -u -u -r1.2 spb.h > --- arclib/spb.h 2001/03/20 02:55:56 1.2 > +++ arclib/spb.h 2001/11/04 22:06:28 > @@ -90,7 +90,7 @@ > ADAPTER Adapters[1]; > } SPB; > > -#define SystemParameterBlock ((SPB *) 0x1000) > +#define SystemParameterBlock ((SPB *) 0xA0001000UL) That should be 0x80001000UL I think. > -EXT2LIB = /usr/lib/libext2fs.a > +#EXT2LIB = /usr/lib/libext2fs.a > +EXT2LIB = ../../e2fslib/e2fsprogs-1.25/lib/libext2fs.a That needs to be a non-pic library which nobody has installed on his system so I suggest we just put a copy of libext2fs into the arcboot sources. That would alos make arcboot selfcontained and eleminate build problems. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 6 11:44:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6JiSm08524 for linux-mips-outgoing; Tue, 6 Nov 2001 11:44:28 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6JiO008520 for ; Tue, 6 Nov 2001 11:44:24 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA6JiKjV031581 for ; Tue, 6 Nov 2001 11:44:20 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA6JiKSq031572 for ; Tue, 6 Nov 2001 11:44:20 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 6 Nov 2001 11:44:20 -0800 (PST) From: James Simmons To: linux-mips@oss.sgi.com Subject: RE: 1$ clobber bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sorry I got the patch backwards. It seems that the standard 2.4.14 tree some how missed the $1 clobber fixes but it merged alot of other things. Strange. I believe the ITE generic time code has a 1$ clobber bug in it. Here is a patch to fix this. --- time.c Fri Oct 5 10:01:22 2001 +++ /usr/src/linux/arch/mips/ite-boards/generic/time.c Tue Nov 6 11:38:00 2001 @@ -303,7 +303,8 @@ :"r" (timerhi), "m" (timerlo), "r" (tmp), - "r" (USECS_PER_JIFFY)); + "r" (USECS_PER_JIFFY) + :"$1"); cached_quotient = quotient; } From owner-linux-mips@oss.sgi.com Tue Nov 6 13:06:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6L65B11778 for linux-mips-outgoing; Tue, 6 Nov 2001 13:06:05 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA6L64011775 for ; Tue, 6 Nov 2001 13:06:04 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA6L5VR30553; Tue, 6 Nov 2001 13:05:31 -0800 Date: Tue, 6 Nov 2001 13:05:31 -0800 From: Ralf Baechle To: James Simmons Cc: linux-mips@oss.sgi.com Subject: Re: 1$ clobber bug Message-ID: <20011106130531.A30219@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Tue, Nov 06, 2001 at 11:44:20AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 06, 2001 at 11:44:20AM -0800, James Simmons wrote: > Sorry I got the patch backwards. It seems that the standard 2.4.14 tree > some how missed the $1 clobber fixes but it merged alot of other things. > Strange. > > I believe the ITE generic time code has a 1$ clobber bug in it. Here is a > patch to fix this. There is no point in a "$1" clobber. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 6 13:09:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6L9D013070 for linux-mips-outgoing; Tue, 6 Nov 2001 13:09:13 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA6L9C013067 for ; Tue, 6 Nov 2001 13:09:12 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA6L8dn30589; Tue, 6 Nov 2001 13:08:39 -0800 Date: Tue, 6 Nov 2001 13:08:39 -0800 From: Ralf Baechle To: machael Cc: linux-mips@oss.sgi.com Subject: Re: vmalloc bugs in 2.4.5??? Message-ID: <20011106130839.B30219@dea.linux-mips.net> References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <013301c165cc$5d030fa0$4a1c690a@huawei.com>; from dony.he@huawei.com on Mon, Nov 05, 2001 at 03:34:44PM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 05, 2001 at 03:34:44PM +0800, machael wrote: > I use linux-2.4.5 and I think VMALLOC may have some bugs which i don't > know how to fixup. Vmalloc is probably innocent I'd rather guess cache flushing is broken on your platform. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 6 13:58:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LwYq14466 for linux-mips-outgoing; Tue, 6 Nov 2001 13:58:34 -0800 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6LwO014439 for ; Tue, 6 Nov 2001 13:58:24 -0800 Message-ID: <20011106215824.52382.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com via HTTP; Tue, 06 Nov 2001 13:58:24 PST Date: Tue, 6 Nov 2001 13:58:24 -0800 (PST) From: Wayne Gowcher Subject: _MIPS_SIM and others not defined by specs file warning To: linux-mips Cc: linux-mips In-Reply-To: <1005012474.27128.306.camel@zeus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am attempting to compile X using egcs-2.91.66 and I am getting the following warnings which eventually lead to the build failing. #warning "Macro _MIPS_ISA has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 24: #warning "Macro _MIPS_SIM has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 28: #warning "Macro _MIPS_SZINT has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 32: #warning "Macro _MIPS_SZLONG has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 36: #warning "Macro _MIPS_SZPTR has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 44: #warning "Please update your GCC to GCC 2.7.2-4 or newer" I have previously successfully compiled X using egcs-2.90.29. Could someone tell me what I may be doing wrong ? Or what I need to pas into the compiler in order for it to read the specs file correctly. Would also be grateful if someone could point to me a document or something explaining what the specs file is and how it is used. By looking at it, I figure it to be a file that sets integer lengths, procesor type etc. But it sure would be nice to get a bigger picture explanation. TIA Wayne __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com From owner-linux-mips@oss.sgi.com Tue Nov 6 13:58:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6LwUX14445 for linux-mips-outgoing; Tue, 6 Nov 2001 13:58:30 -0800 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6LwO014438 for ; Tue, 6 Nov 2001 13:58:24 -0800 Message-ID: <20011106215824.52382.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com via HTTP; Tue, 06 Nov 2001 13:58:24 PST Date: Tue, 6 Nov 2001 13:58:24 -0800 (PST) From: Wayne Gowcher Subject: _MIPS_SIM and others not defined by specs file warning To: linux-mips Cc: linux-mips In-Reply-To: <1005012474.27128.306.camel@zeus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am attempting to compile X using egcs-2.91.66 and I am getting the following warnings which eventually lead to the build failing. #warning "Macro _MIPS_ISA has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 24: #warning "Macro _MIPS_SIM has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 28: #warning "Macro _MIPS_SZINT has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 32: #warning "Macro _MIPS_SZLONG has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 36: #warning "Macro _MIPS_SZPTR has not been defined by specs file" ../../../../config/makedepend/makedepend: warning: vga.c: 44: #warning "Please update your GCC to GCC 2.7.2-4 or newer" I have previously successfully compiled X using egcs-2.90.29. Could someone tell me what I may be doing wrong ? Or what I need to pas into the compiler in order for it to read the specs file correctly. Would also be grateful if someone could point to me a document or something explaining what the specs file is and how it is used. By looking at it, I figure it to be a file that sets integer lengths, procesor type etc. But it sure would be nice to get a bigger picture explanation. TIA Wayne __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com From owner-linux-mips@oss.sgi.com Tue Nov 6 14:49:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA6Mn6k15935 for linux-mips-outgoing; Tue, 6 Nov 2001 14:49:06 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA6Mn2015928 for ; Tue, 6 Nov 2001 14:49:02 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 51B482B331; Tue, 6 Nov 2001 22:48:55 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 695B8C8CA; Tue, 6 Nov 2001 22:48:54 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 57150E8C3; Tue, 6 Nov 2001 22:48:54 +0000 (GMT) Date: Tue, 6 Nov 2001 22:48:54 +0000 (GMT) From: Dave Airlie X-X-Sender: To: Cc: , Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Since I'll be away till Tuesday, expect an update in the middle of the > next week. I'm assuming ELF loading works, right? > not sure the VAX is handling this too well.. if I boot the vmlinux ELF file our build system produces it won't boot it but I think this is due to our vmlinux file being linked for running with VM switched on, and the mop loads it into memory that doesn't exist.. Dave. > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Tue Nov 6 16:17:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA70HAQ17823 for linux-mips-outgoing; Tue, 6 Nov 2001 16:17:10 -0800 Received: from i01sv4107.ids1.intelonline.com (i01sv4107-p.ids1.intelonline.com [147.208.166.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA70H8017820 for ; Tue, 6 Nov 2001 16:17:08 -0800 Received: from i01sv0637 (unverified [10.81.26.22]) by i01sv4107.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Wed, 7 Nov 2001 00:17:00 +0000 Message-ID: From: Guo-Rong Koh To: "linux-mips@oss.sgi.com" X-Originating-IP: [203.14.96.34] Date: Wed, 07 Nov 2001 10:17:00 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: DECStation framebuffer support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I have just decided to try getting Linux running on my DECStation 5000/25 (currently running NetBSD). I succeeded in cross-compiling a 2.4.12 kernel from an i686 Linux box. My main aim is to get the framebuffer working. To test the kernel I dumped it on the NetBSD root and hit "boot 3/rz0/vmlinux". This gets me to "This is a Personal DECStation 5000/xx" then stops. Any suggestions as to what I should do next? Framebuffer support for all the framebuffers has been compiled in. The question is: To what extent does the kernel support console on framebuffer? Thanks, Guo-Rong __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Tue Nov 6 16:54:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA70sE218744 for linux-mips-outgoing; Tue, 6 Nov 2001 16:54:14 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA70s9018740; Tue, 6 Nov 2001 16:54:09 -0800 Received: from hcdong11752a ([10.105.28.74]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GMENBT00.B7E; Wed, 7 Nov 2001 08:43:05 +0800 Message-ID: <001101c16725$c0a6eae0$4a1c690a@huawei.com> From: "machael" To: "Ralf Baechle" Cc: References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> <20011106130839.B30219@dea.linux-mips.net> Subject: Re: vmalloc bugs in 2.4.5??? Date: Wed, 7 Nov 2001 08:47:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > I use linux-2.4.5 and I think VMALLOC may have some bugs which i don't > > know how to fixup. > > Vmalloc is probably innocent I'd rather guess cache flushing is broken on > your platform. Yes, It is possible. But I don't know how to fixup this broken cache flushing? And when and where should I flush cache (icache and dcache) manually?I am really know little things about cache. Can you help me? Thank you very much. machael From owner-linux-mips@oss.sgi.com Tue Nov 6 17:11:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA71BYD19208 for linux-mips-outgoing; Tue, 6 Nov 2001 17:11:34 -0800 Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA71BW019205 for ; Tue, 6 Nov 2001 17:11:32 -0800 Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id TAA29484 for ; Tue, 6 Nov 2001 19:11:31 -0600 (CST) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma029481; Tue, 6 Nov 01 19:11:31 -0600 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA14579 for ; Tue, 6 Nov 2001 19:11:35 -0600 (CST) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id TAA02639 for ; Tue, 6 Nov 2001 19:11:34 -0600 (CST) Subject: kernel bug in linux2.4.3 To: linux-mips@oss.sgi.com Date: Tue, 6 Nov 2001 17:12:08 -0800 Message-ID: X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 06/11/2001 19:15:38 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, I took the linux kernel 2.4.3 from ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/src/. This kernel was ported for MIPS32 ISA and its supposed to work with all the mips 4kc core. I took the kernel and ported for our Philips processor PR3950, which is based on a mips 4kc core. I have some issues in the reserve_bootmem() & the paging_init() in the arch/mips/kernel/setup.c. Itseems that they fail in the alloc_bootmem (). I commented these functions and got till console_init() to get the print messages on my screen. I got the message as Kernel Bug in bootmem.c Itseems that the functions BUG() has been executed. So is this a kernel bug? I mean is there some problem in the kernel which has been ported or is it something related to improper memory initialization?. regards, Balaji From owner-linux-mips@oss.sgi.com Tue Nov 6 17:32:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA71WDD24392 for linux-mips-outgoing; Tue, 6 Nov 2001 17:32:13 -0800 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA71WA024388 for ; Tue, 6 Nov 2001 17:32:11 -0800 Received: (from ex2k [172.19.1.1]) by smtp.psdc.com (NAVGW 2.5.1.13) with SMTP id M2001110617323625328 for ; Tue, 06 Nov 2001 17:32:36 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: parent and child processes share the same stack. X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 6 Nov 2001 17:27:08 -0800 Message-ID: <84CE342693F11946B9F54B18C1AB837B14AD5A@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: parent and child processes share the same stack. Thread-Index: AcFnK1Av0WRceLoAQpK3YiWILOm51A== From: "Steven Liu" To: Cc: "Steven Liu" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA71WB024389 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All: I am porting Linux to my r3000 cpu now and meet with a problem when the init program is running. When the init process (pid=1) forks the first child (pid=7), the parent process called copy_thread( ) which did the following assignment: childregs->regs[29] = usp ( Here, usp is the parent's stack pointer) (see arch/mips/kerenel/process.c). So, the child and the parent share the same stack. After the fork, the parent called write_utmp_wtmp( ) which then called memset(&utmp,0,sizeof(utmp)) and erased the stack. As we know, this stack is shared by the parent and the child, the child will die when the child is scheduled to run because the contents of the stack are all zeros. I think the stack should not be shared by the parent and the child after anyone tries to modify the stack, that is, the child and parent should have separete stacks. I searched the code and could not find the place where the separation is given. Any help would be greatly appreciated. Thanks, Steven Liu From owner-linux-mips@oss.sgi.com Tue Nov 6 17:35:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA71Z8s24519 for linux-mips-outgoing; Tue, 6 Nov 2001 17:35:08 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA71Z1024516; Tue, 6 Nov 2001 17:35:01 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 7 Nov 2001 01:35:01 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 88C46B471; Wed, 7 Nov 2001 10:34:59 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA59722; Wed, 7 Nov 2001 10:34:59 +0900 (JST) Date: Wed, 07 Nov 2001 10:39:47 +0900 (JST) Message-Id: <20011107.103947.74756322.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: dony.he@huawei.com, linux-mips@oss.sgi.com Subject: Re: vmalloc bugs in 2.4.5??? From: Atsushi Nemoto In-Reply-To: <20011106130839.B30219@dea.linux-mips.net> References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> <20011106130839.B30219@dea.linux-mips.net> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Tue, 6 Nov 2001 13:08:39 -0800, Ralf Baechle said: ralf> Vmalloc is probably innocent I'd rather guess cache flushing is ralf> broken on your platform. In 2.4.5, flush_cache_all() (and flush_tlb_all()) is called in vmalloc_area_pages(). I think this call protect us from virtual aliasing problem. By the way, does anybody have any problem with vmalloc on recent kernel? In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all() disappered from vmalloc_area_pages(). I have a data corruption problem in vmalloc()ed area without this call. I think we still need this call. --- linux-sgi-cvs/mm/vmalloc.c Tue Sep 18 05:16:31 2001 +++ linux.new/mm/vmalloc.c Wed Nov 7 10:33:47 2001 @@ -144,6 +144,7 @@ int ret; dir = pgd_offset_k(address); + flush_cache_all(); spin_lock(&init_mm.page_table_lock); do { pmd_t *pmd; @@ -163,6 +164,7 @@ ret = 0; } while (address && (address < end)); spin_unlock(&init_mm.page_table_lock); + flush_tlb_all(); return ret; } --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Nov 6 18:20:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA72KC925470 for linux-mips-outgoing; Tue, 6 Nov 2001 18:20:12 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA72Jv025462; Tue, 6 Nov 2001 18:19:57 -0800 Received: from hcdong11752a ([10.105.28.74]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GMER5C00.34C; Wed, 7 Nov 2001 10:05:36 +0800 Message-ID: <001301c16731$47c473c0$4a1c690a@huawei.com> From: "machael" To: , "Atsushi Nemoto" Cc: References: <013301c165cc$5d030fa0$4a1c690a@huawei.com><20011106130839.B30219@dea.linux-mips.net> <20011107.103947.74756322.nemoto@toshiba-tops.co.jp> Subject: Re: vmalloc bugs in 2.4.5??? Date: Wed, 7 Nov 2001 10:09:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > ralf> Vmalloc is probably innocent I'd rather guess cache flushing is > ralf> broken on your platform. > > In 2.4.5, flush_cache_all() (and flush_tlb_all()) is called in > vmalloc_area_pages(). I think this call protect us from virtual > aliasing problem. > > By the way, does anybody have any problem with vmalloc on recent > kernel? > > In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all() > disappered from vmalloc_area_pages(). I have a data corruption > problem in vmalloc()ed area without this call. I think we still need > this call. > > --- linux-sgi-cvs/mm/vmalloc.c Tue Sep 18 05:16:31 2001 > +++ linux.new/mm/vmalloc.c Wed Nov 7 10:33:47 2001 > @@ -144,6 +144,7 @@ > int ret; > > dir = pgd_offset_k(address); > + flush_cache_all(); > spin_lock(&init_mm.page_table_lock); > do { > pmd_t *pmd; > @@ -163,6 +164,7 @@ > ret = 0; > } while (address && (address < end)); > spin_unlock(&init_mm.page_table_lock); > + flush_tlb_all(); > return ret; > } In 2.4.5, vmalloc has these two lines in vmalloc_area_pages(). So what else may be the problem? Thanks! machael From owner-linux-mips@oss.sgi.com Wed Nov 7 02:42:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7AgPo05531 for linux-mips-outgoing; Wed, 7 Nov 2001 02:42:26 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA7AgN005528 for ; Wed, 7 Nov 2001 02:42:23 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA7AfkZ17355; Wed, 7 Nov 2001 02:41:46 -0800 Date: Wed, 7 Nov 2001 02:41:46 -0800 From: Ralf Baechle To: Atsushi Nemoto Cc: dony.he@huawei.com, linux-mips@oss.sgi.com Subject: Re: vmalloc bugs in 2.4.5??? Message-ID: <20011107024146.A1740@dea.linux-mips.net> References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> <20011106130839.B30219@dea.linux-mips.net> <20011107.103947.74756322.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011107.103947.74756322.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Nov 07, 2001 at 10:39:47AM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 07, 2001 at 10:39:47AM +0900, Atsushi Nemoto wrote: > In 2.4.5, flush_cache_all() (and flush_tlb_all()) is called in > vmalloc_area_pages(). I think this call protect us from virtual > aliasing problem. > > By the way, does anybody have any problem with vmalloc on recent > kernel? > > In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all() > disappered from vmalloc_area_pages(). I have a data corruption > problem in vmalloc()ed area without this call. I think we still need > this call. Entirely correct. I'm just trying to find why this call got removed in 2.4.10. Clearly wrong; I had not noticed that these two lines got removed and thus was assuming the code of those two must somehow be malfunctioning. Ralf From owner-linux-mips@oss.sgi.com Wed Nov 7 03:29:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7BTGG06885 for linux-mips-outgoing; Wed, 7 Nov 2001 03:29:16 -0800 Received: from smtp.huawei.com ([61.144.161.21]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7BTA006880; Wed, 7 Nov 2001 03:29:10 -0800 Received: from hcdong11752a ([10.105.28.74]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GMFH2Y00.NGO; Wed, 7 Nov 2001 19:25:46 +0800 Message-ID: <000f01c1677f$88fd6560$4a1c690a@huawei.com> From: "machael" To: "Ralf Baechle" Cc: References: <013301c165cc$5d030fa0$4a1c690a@huawei.com> <20011106130839.B30219@dea.linux-mips.net> <20011107.103947.74756322.nemoto@toshiba-tops.co.jp> <20011107024146.A1740@dea.linux-mips.net> Subject: Re: vmalloc bugs in 2.4.5??? Date: Wed, 7 Nov 2001 19:29:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On Wed, Nov 07, 2001 at 10:39:47AM +0900, Atsushi Nemoto wrote: > > > In 2.4.5, flush_cache_all() (and flush_tlb_all()) is called in > > vmalloc_area_pages(). I think this call protect us from virtual > > aliasing problem. > > > > By the way, does anybody have any problem with vmalloc on recent > > kernel? > > > > In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all() > > disappered from vmalloc_area_pages(). I have a data corruption > > problem in vmalloc()ed area without this call. I think we still need > > this call. > > Entirely correct. I'm just trying to find why this call got removed > in 2.4.10. Clearly wrong; I had not noticed that these two lines > got removed and thus was assuming the code of those two must somehow > be malfunctioning. I have added these two lines to vmalloc_area_pages in 2.4.10,but the problems still appear. Why? machael From owner-linux-mips@oss.sgi.com Wed Nov 7 04:29:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7CTt308808 for linux-mips-outgoing; Wed, 7 Nov 2001 04:29:55 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7CTn008805; Wed, 7 Nov 2001 04:29:49 -0800 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 161Rpz-0001PR-00; Wed, 07 Nov 2001 13:29:47 +0100 Date: Wed, 7 Nov 2001 13:29:47 +0100 From: Guido Guenther To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: arcboot patches Message-ID: <20011107132947.A5058@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Ralf Baechle , linux-mips@oss.sgi.com References: <20011104233218.A15847@bogon.ms20.nix> <20011106113517.F1524@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011106113517.F1524@dea.linux-mips.net>; from ralf@oss.sgi.com on Tue, Nov 06, 2001 at 11:35:18AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 06, 2001 at 11:35:18AM -0800, Ralf Baechle wrote: > On Sun, Nov 04, 2001 at 11:32:19PM +0100, Guido Guenther wrote: > > > typedef struct { > > +#ifdef __MIPSEL__ > > ULONG LowPart; > > + *LONG HighPart; > > +#else /* !(__MIPSEL__) */ > > LONG HighPart; > > + ULONG LowPart; > > +#endif > > } LARGEINTEGER; > > Why not simply defining LARGEINTEGER as long long? I'm giving the question back to you, since you checked the original version into oss's cvs and started to adapt it for mips I assume. I just added the __MIPSEL__ clobber. > > > Index: arclib/spb.h > > =================================================================== > > RCS file: /cvs/arcboot/arclib/spb.h,v > > retrieving revision 1.2 > > diff -u -u -r1.2 spb.h > > --- arclib/spb.h 2001/03/20 02:55:56 1.2 > > +++ arclib/spb.h 2001/11/04 22:06:28 > > @@ -90,7 +90,7 @@ > > ADAPTER Adapters[1]; > > } SPB; > > > > -#define SystemParameterBlock ((SPB *) 0x1000) > > +#define SystemParameterBlock ((SPB *) 0xA0001000UL) > > That should be 0x80001000UL I think. Both refer to the same physical address. Since I don't want to get into the way of any caches I used the former one(as does the kernel). > > -EXT2LIB = /usr/lib/libext2fs.a > > +#EXT2LIB = /usr/lib/libext2fs.a > > +EXT2LIB = ../../e2fslib/e2fsprogs-1.25/lib/libext2fs.a > > That needs to be a non-pic library which nobody has installed on his > system so I suggest we just put a copy of libext2fs into the arcboot > sources. That would alos make arcboot selfcontained and eleminate > build problems. Someone has to rip the libext2fs specific part out of e2fsutils then. I'll do so, when I have the kernel booting. -- Guido From owner-linux-mips@oss.sgi.com Wed Nov 7 14:19:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7MJXi14261 for linux-mips-outgoing; Wed, 7 Nov 2001 14:19:33 -0800 Received: from host099.momenco.com (IDENT:root@host099.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7MJS014258 for ; Wed, 7 Nov 2001 14:19:29 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.0) with SMTP id fA7MJQi24443; Wed, 7 Nov 2001 14:19:26 -0800 From: "Matthew Dharm" To: "Carsten Langgaard" , Subject: RE: RedHat7.1 Date: Wed, 7 Nov 2001 14:19:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3BE7D256.8E763AC3@mips.com> Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I would be interested in creating similar images for our MIPS-based board. Would you be willing to share your knowledge on how to accomplish this? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Carsten Langgaard > Sent: Tuesday, November 06, 2001 4:07 AM > To: linux-mips@oss.sgi.com > Subject: RedHat7.1 > > > I have made a CD-ROM images for easy CD-ROM installation of > a RedHat7.1 > distribution on a MIPS Atlas or Malta board. > The image contains both a little and bigendian distribution. > > You can download the images from the FTP site: > ftp://ftp.mips.com/pub/linux/mips/installation/ > Burn the image to a CD-ROM and follow the INSTALL guide for > installation > on a harddisk attached to either a Atlas or Malta board. > > You can also download the tar-ball for NFS installation. > > Hope that people with a Atlas or a Malta board find it useful. > /Carsten > > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > From owner-linux-mips@oss.sgi.com Wed Nov 7 15:49:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA7Nnwt16310 for linux-mips-outgoing; Wed, 7 Nov 2001 15:49:58 -0800 Received: from mail.palmchip.com ([63.203.52.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA7Nns016307 for ; Wed, 7 Nov 2001 15:49:54 -0800 Received: from palmchip.com (scarlett.palmchip.com [10.1.10.90]) by mail.palmchip.com (8.11.6/8.11.0) with ESMTP id fA7Mo5r13483; Wed, 7 Nov 2001 14:50:05 -0800 Message-ID: <3BE9D6E6.2010706@palmchip.com> Date: Wed, 07 Nov 2001 16:50:46 -0800 From: Waren Hardy Reply-To: warren.hardy@palmchip.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux-mips , MipsMailList Subject: memory mapping for MIPS 4Kc References: <008701c165ac$1a49a9a0$4c0c5c8c@trd.iii.org.tw> <07b401c165b2$f981ec30$3501010a@ltc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have a small prototype board with a mips 4kc on it and I have linux running. I have to megs of sram mapped how do i map in sdram ? the memory map looks like 0000.0000 - 0001f.ffff 2M SRAM 0020.0000 - 0020.1fff 8K Embedded SRAM CPU 0020.2000 - 002f.fffff reserved 0030.0000 - 0030.ffff 64K Chip registers 0031.0000 - 00ff.ffff reserved 0100.0000 - 01ff.ffff 16M SDRAM 0200.0000 - 1fb0.ffff SDRAM 1fc0.0000 - 1fdf.ffff 2M ROM / FLASH 0060.0000 - ffff.ffff SDRAM how do I get linux to read this 16M SDRAM @ 0100.000 - 01ff.ffff ? Then how do I get linux to read RAM @ 0200.000 - 1fb0.ffff and 0060.000 - ffff.ffff ? We have our own load which is loading linux from ROM, and we can pass arg to linux, can the memory be set as an argument passed ? Thanks for you help Warren Hardy From owner-linux-mips@oss.sgi.com Wed Nov 7 20:23:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA84NA622142 for linux-mips-outgoing; Wed, 7 Nov 2001 20:23:10 -0800 Received: from altrade.nijmegen.internl.net (altrade.nijmegen.internl.net [217.149.192.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA84N7022138 for ; Wed, 7 Nov 2001 20:23:07 -0800 Received: from whale.dutch.mountain by altrade.nijmegen.internl.net via 1Cust153.tnt10.rtm1.nl.uu.net [213.116.114.153] with ESMTP for id FAA13393 (8.8.8/1.3); Thu, 8 Nov 2001 05:22:59 +0100 (MET) Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Wed, 7 Nov 2001 16:53:38 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Wed, 7 Nov 2001 16:53:37 +0100 (MET) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@oss.sgi.com Subject: Re: DECStation framebuffer support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 7 Nov 2001, Guo-Rong Koh wrote: > I have just decided to try getting Linux running on my DECStation > 5000/25 (currently running NetBSD). I succeeded in cross-compiling a > 2.4.12 kernel from an i686 Linux box. My main aim is to get the > framebuffer working. > > To test the kernel I dumped it on the NetBSD root and hit "boot > 3/rz0/vmlinux". > > This gets me to "This is a Personal DECStation 5000/xx" then stops. > > Any suggestions as to what I should do next? > Framebuffer support for all the framebuffers has been compiled in. The > question is: To what extent does the kernel support console on > framebuffer? The kernel should support console on framebuffer, it once did. With the on-board video the kernel needed 'video=maxinefb:on' as a kernel option, dunno if that's still the case. You only have the on-board video, no second video controller? Greetings, Richard From owner-linux-mips@oss.sgi.com Wed Nov 7 21:02:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA852BC22913 for linux-mips-outgoing; Wed, 7 Nov 2001 21:02:11 -0800 Received: from i01sv4107.ids1.intelonline.com (i01sv4107-p.ids1.intelonline.com [147.208.166.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8528022910 for ; Wed, 7 Nov 2001 21:02:08 -0800 Received: from i01sv0648 (unverified [10.81.26.32]) by i01sv4107.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Thu, 8 Nov 2001 05:02:02 +0000 Message-ID: From: Guo-Rong Koh To: "linux-mips@oss.sgi.com" X-Originating-IP: [203.14.96.10] Date: Thu, 08 Nov 2001 15:02:01 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: Re: DECStation framebuffer support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >The kernel should support console on framebuffer, it once did. With the >on-board video the kernel needed 'video=maxinefb:on' as a kernel option, >dunno if that's still the case. You only have the on-board video, no >second video controller? > >Greetings, >Richard I've also got a PMAGB-B installed in the system. Since system detects and uses that as default, I'm guessing the kernel option will be 'video=pmagb-b-fb:on' right? BTW, thanks for responding, none of this documented anywhere. Guo-Rong __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Wed Nov 7 22:42:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA86gNw24299 for linux-mips-outgoing; Wed, 7 Nov 2001 22:42:23 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA86gG024294; Wed, 7 Nov 2001 22:42:17 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 8 Nov 2001 06:42:16 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 56F45B46B; Thu, 8 Nov 2001 15:42:15 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA63589; Thu, 8 Nov 2001 15:42:14 +0900 (JST) Date: Thu, 08 Nov 2001 15:47:02 +0900 (JST) Message-Id: <20011108.154702.74756496.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: i8259.c in big endian From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk arch/mips/kernel/i8259.c seems not working in big endian. Here is a patch to fix this. --- linux-sgi-cvs/arch/mips/kernel/i8259.c Mon Sep 10 02:43:01 2001 +++ linux.new/arch/mips/kernel/i8259.c Thu Nov 8 15:40:03 2001 @@ -70,8 +70,13 @@ static unsigned int cached_irq_mask = 0xffff; #define __byte(x,y) (((unsigned char *)&(y))[x]) +#ifdef __BIG_ENDIAN +#define cached_21 (__byte(1,cached_irq_mask)) +#define cached_A1 (__byte(0,cached_irq_mask)) +#else #define cached_21 (__byte(0,cached_irq_mask)) #define cached_A1 (__byte(1,cached_irq_mask)) +#endif void disable_8259A_irq(unsigned int irq) { --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu Nov 8 00:30:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA88UCc25924 for linux-mips-outgoing; Thu, 8 Nov 2001 00:30:12 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA88U6025921 for ; Thu, 8 Nov 2001 00:30:06 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA07122; Thu, 8 Nov 2001 00:25:41 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA16133; Thu, 8 Nov 2001 00:25:41 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fA88PgA24426; Thu, 8 Nov 2001 09:25:42 +0100 (MET) Message-ID: <3BEA4186.63531335@mips.com> Date: Thu, 08 Nov 2001 09:25:42 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dharm CC: linux-mips@oss.sgi.com Subject: Re: RedHat7.1 References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Matthew Dharm wrote: > I would be interested in creating similar images for our MIPS-based > board. Would you be willing to share your knowledge on how to > accomplish this? Sure, just ask. > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > > -----Original Message----- > > From: owner-linux-mips@oss.sgi.com > > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Carsten Langgaard > > Sent: Tuesday, November 06, 2001 4:07 AM > > To: linux-mips@oss.sgi.com > > Subject: RedHat7.1 > > > > > > I have made a CD-ROM images for easy CD-ROM installation of > > a RedHat7.1 > > distribution on a MIPS Atlas or Malta board. > > The image contains both a little and bigendian distribution. > > > > You can download the images from the FTP site: > > ftp://ftp.mips.com/pub/linux/mips/installation/ > > Burn the image to a CD-ROM and follow the INSTALL guide for > > installation > > on a harddisk attached to either a Atlas or Malta board. > > > > You can also download the tar-ball for NFS installation. > > > > Hope that people with a Atlas or a Malta board find it useful. > > /Carsten > > > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com > > > > > > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Thu Nov 8 03:58:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Bw5K00309 for linux-mips-outgoing; Thu, 8 Nov 2001 03:58:05 -0800 Received: from altrade.nijmegen.internl.net (altrade.nijmegen.internl.net [217.149.192.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Bw2000306 for ; Thu, 8 Nov 2001 03:58:03 -0800 Received: from whale.dutch.mountain by altrade.nijmegen.internl.net via 1Cust60.tnt56.rtm1.nl.uu.net [213.117.30.60] with ESMTP for id MAA15179 (8.8.8/1.3); Thu, 8 Nov 2001 12:57:56 +0100 (MET) Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Thu, 8 Nov 2001 12:57:06 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Thu, 8 Nov 2001 12:57:06 +0100 (MET) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@oss.sgi.com Subject: Re: DECStation framebuffer support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 8 Nov 2001, Guo-Rong Koh wrote: > I've also got a PMAGB-B installed in the system. Since system detects > and uses that as default, I'm guessing the kernel option will be > 'video=pmagb-b-fb:on' right? I didn't succeed in getting that to work, my advise would to try it first with the on-board video. > BTW, thanks for responding, none of this documented anywhere. Oh yes it is, do a grep maxinefb on the 1999 mail archive available from http://home.zonnet.berg56/ and you see it was discussed in june... Greetings, Richard From owner-linux-mips@oss.sgi.com Thu Nov 8 04:50:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8CoTX01110 for linux-mips-outgoing; Thu, 8 Nov 2001 04:50:29 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8CoG001107 for ; Thu, 8 Nov 2001 04:50:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA07628; Thu, 8 Nov 2001 13:48:01 +0100 (MET) Date: Thu, 8 Nov 2001 13:48:00 +0100 (MET) From: "Maciej W. Rozycki" To: Dave Airlie cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, linux-vax@mithra.physics.montana.edu Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 30 Oct 2001, Dave Airlie wrote: > Okay it didn't go so well.. my VAX couldn't boot the file I normally use > with this mopd (I had to rebuild it for a static libelf)... > > I've put a tgz up at > > http://www.skynet.ie/~airlied/vax/mopd_on_the_vax.tgz > > it contains the file I was trying to boot and the tcpdumps of this mopd > and the one I normally use ... I've uploaded updated files -- you should be able to boot your image with this version of mopd. Please report results. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Nov 8 05:12:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8DCxG01830 for linux-mips-outgoing; Thu, 8 Nov 2001 05:12:59 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8DAu001718 for ; Thu, 8 Nov 2001 05:10:57 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA08062; Thu, 8 Nov 2001 14:06:06 +0100 (MET) Date: Thu, 8 Nov 2001 14:06:05 +0100 (MET) From: "Maciej W. Rozycki" To: Dave Airlie cc: linux-vax@mithra.physics.montana.edu, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 6 Nov 2001, Dave Airlie wrote: > > Since I'll be away till Tuesday, expect an update in the middle of the > > next week. I'm assuming ELF loading works, right? > > > not sure the VAX is handling this too well.. > > if I boot the vmlinux ELF file our build system produces it won't boot it > but I think this is due to our vmlinux file being linked for running with > VM switched on, and the mop loads it into memory that doesn't exist.. Do you set segments' p_paddr (physical address) correctly? The current version of ELF support uses p_vaddr (virtual address) for simplicity, as the ELF specification mandates loadable program's segments to be ordered by an ascending value of their p_vaddr. I'll fix the program to use p_paddr instead. The difference is insignificant for the DECstation since its firmware uses virtual addresses -- MIPS never exposes physical addresses to a program (well, almost, but that's irrelevant here). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Nov 8 07:18:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8FIx604121 for linux-mips-outgoing; Thu, 8 Nov 2001 07:18:59 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8FHg004107; Thu, 8 Nov 2001 07:17:43 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA12742; Thu, 8 Nov 2001 16:16:58 +0100 (MET) Date: Thu, 8 Nov 2001 16:16:58 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: Atsushi Nemoto , dony.he@huawei.com, linux-mips@oss.sgi.com Subject: Re: vmalloc bugs in 2.4.5??? In-Reply-To: <20011107024146.A1740@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 7 Nov 2001, Ralf Baechle wrote: > > In somewhere between 2.4.6 and 2.4.9, the call to flush_cache_all() > > disappered from vmalloc_area_pages(). I have a data corruption > > problem in vmalloc()ed area without this call. I think we still need > > this call. > > Entirely correct. I'm just trying to find why this call got removed > in 2.4.10. Clearly wrong; I had not noticed that these two lines > got removed and thus was assuming the code of those two must somehow > be malfunctioning. See a mail titled "flush_tlb_all in vmalloc_area_pages" dated Sep 7th, 2001 sent to the linux-kernel list for the patch in question. There was a discussion on cache flushing wrt to a TLB on the list under "[PATCH] change name of rep_nop" subject later as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Nov 8 09:45:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8HjGx12227 for linux-mips-outgoing; Thu, 8 Nov 2001 09:45:16 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8HjA012221; Thu, 8 Nov 2001 09:45:10 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8Hj4jV015200; Thu, 8 Nov 2001 09:45:04 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8Hj3Vv015196; Thu, 8 Nov 2001 09:45:04 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 8 Nov 2001 09:45:02 -0800 (PST) From: James Simmons To: Atsushi Nemoto cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: i8259.c in big endian In-Reply-To: <20011108.154702.74756496.nemoto@toshiba-tops.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Also I like to see away to pass in a base offset. I have a mips device which has a i8259 chip but its io is offseted by 0xb0000000. On Thu, 8 Nov 2001, Atsushi Nemoto wrote: > arch/mips/kernel/i8259.c seems not working in big endian. > > Here is a patch to fix this. > > --- linux-sgi-cvs/arch/mips/kernel/i8259.c Mon Sep 10 02:43:01 2001 > +++ linux.new/arch/mips/kernel/i8259.c Thu Nov 8 15:40:03 2001 > @@ -70,8 +70,13 @@ > static unsigned int cached_irq_mask = 0xffff; > > #define __byte(x,y) (((unsigned char *)&(y))[x]) > +#ifdef __BIG_ENDIAN > +#define cached_21 (__byte(1,cached_irq_mask)) > +#define cached_A1 (__byte(0,cached_irq_mask)) > +#else > #define cached_21 (__byte(0,cached_irq_mask)) > #define cached_A1 (__byte(1,cached_irq_mask)) > +#endif > > void disable_8259A_irq(unsigned int irq) > { > --- > Atsushi Nemoto > From owner-linux-mips@oss.sgi.com Thu Nov 8 10:01:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8I1jA13009 for linux-mips-outgoing; Thu, 8 Nov 2001 10:01:45 -0800 Received: from altrade.nijmegen.internl.net (altrade.nijmegen.internl.net [217.149.192.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8I1h013006 for ; Thu, 8 Nov 2001 10:01:43 -0800 Received: from whale.dutch.mountain by altrade.nijmegen.internl.net via 1Cust228.tnt11.rtm1.nl.uu.net [213.116.116.228] with ESMTP id TAA22198 (8.8.8/1.3); Thu, 8 Nov 2001 19:01:36 +0100 (MET) Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain via in.smtpd with smtp id for ; Thu, 8 Nov 2001 18:45:56 +0100 (MET) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Thu, 8 Nov 2001 18:45:56 +0100 (MET) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@oss.sgi.com, Schirmer Subject: Re: DECStation framebuffer support In-Reply-To: <3BEAA2E0.8230407A@scara.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Richard van den Berg wrote: > > Oh yes it is, do a grep maxinefb on the 1999 mail archive available from > > http://home.zonnet.berg56/ and you see it was discussed in june... > > I guess .berg56 is a typo ? AT least I cannot locate that. Yep it should be http://home.zonnet.nl/berg56/ Sorry, Richard From owner-linux-mips@oss.sgi.com Thu Nov 8 12:15:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8KFDT26935 for linux-mips-outgoing; Thu, 8 Nov 2001 12:15:13 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA8KFB026927 for ; Thu, 8 Nov 2001 12:15:11 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA8KDmk26299; Thu, 8 Nov 2001 12:13:48 -0800 Date: Thu, 8 Nov 2001 12:13:48 -0800 From: Ralf Baechle To: James Simmons Cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: i8259.c in big endian Message-ID: <20011108121348.A26083@dea.linux-mips.net> References: <20011108.154702.74756496.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Thu, Nov 08, 2001 at 09:45:02AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 09:45:02AM -0800, James Simmons wrote: > Also I like to see away to pass in a base offset. I have a mips device > which has a i8259 chip but its io is offseted by 0xb0000000. Then it's almost certainly an legacy ISA device with it's ports in ISA space, so set mips_io_port_base to an apropriate value or does that not work for you? Ralf From owner-linux-mips@oss.sgi.com Thu Nov 8 12:20:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8KKVD31200 for linux-mips-outgoing; Thu, 8 Nov 2001 12:20:31 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8KKS031178; Thu, 8 Nov 2001 12:20:28 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8KKKjV023111; Thu, 8 Nov 2001 12:20:20 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8KKK49023107; Thu, 8 Nov 2001 12:20:20 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 8 Nov 2001 12:20:20 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: i8259.c in big endian In-Reply-To: <20011108121348.A26083@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Also I like to see away to pass in a base offset. I have a mips device > > which has a i8259 chip but its io is offseted by 0xb0000000. > > Then it's almost certainly an legacy ISA device with it's ports in ISA space, > so set mips_io_port_base to an apropriate value or does that not work for > you? The mips_io_port_base is 0xa0000000. Whereas the i8259 chip is at 0xb0000000. The 0xa000000 value could be wrong. I will give it a try. From owner-linux-mips@oss.sgi.com Thu Nov 8 12:42:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Kg2u04964 for linux-mips-outgoing; Thu, 8 Nov 2001 12:42:02 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fA8Kfx004957 for ; Thu, 8 Nov 2001 12:41:59 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA8KfJg26540; Thu, 8 Nov 2001 12:41:19 -0800 Date: Thu, 8 Nov 2001 12:41:19 -0800 From: Ralf Baechle To: James Simmons Cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: i8259.c in big endian Message-ID: <20011108124119.B26083@dea.linux-mips.net> References: <20011108121348.A26083@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Thu, Nov 08, 2001 at 12:20:20PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 12:20:20PM -0800, James Simmons wrote: > > > which has a i8259 chip but its io is offseted by 0xb0000000. > > > > Then it's almost certainly an legacy ISA device with it's ports in ISA space, > > so set mips_io_port_base to an apropriate value or does that not work for > > you? > > The mips_io_port_base is 0xa0000000. Whereas the i8259 chip is at > 0xb0000000. The 0xa000000 value could be wrong. I will give it a try. As your board must have RAM at physical address zero 0xa0000000 is almost certainly a wrong value. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 8 13:37:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8Lbne08035 for linux-mips-outgoing; Thu, 8 Nov 2001 13:37:49 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Lbk008031; Thu, 8 Nov 2001 13:37:46 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8LbcjV027651; Thu, 8 Nov 2001 13:37:38 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8LbbUm027644; Thu, 8 Nov 2001 13:37:37 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 8 Nov 2001 13:37:36 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: i8259.c in big endian In-Reply-To: <20011108124119.B26083@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > The mips_io_port_base is 0xa0000000. Whereas the i8259 chip is at > > 0xb0000000. The 0xa000000 value could be wrong. I will give it a try. > > As your board must have RAM at physical address zero 0xa0000000 is almost > certainly a wrong value. Your right. The address of 0xb000000 is bogus. This is the value from the old code. I will migrate the code over to the i8259.c stuff now. Thanks. From owner-linux-mips@oss.sgi.com Thu Nov 8 13:53:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8LrLO08684 for linux-mips-outgoing; Thu, 8 Nov 2001 13:53:21 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8LrH008680; Thu, 8 Nov 2001 13:53:17 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8Lr9jV028643; Thu, 8 Nov 2001 13:53:09 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA8Lr8JU028639; Thu, 8 Nov 2001 13:53:08 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 8 Nov 2001 13:53:07 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > The mips_io_port_base is 0xa0000000. Whereas the i8259 chip is at > > > 0xb0000000. The 0xa000000 value could be wrong. I will give it a try. > > > > As your board must have RAM at physical address zero 0xa0000000 is almost > > certainly a wrong value. > > Your right. The address of 0xb000000 is bogus. This is the value from the > old code. I will migrate the code over to the i8259.c stuff now. Thanks. Actually looking threw other mips branches now I see what the 0xb000000 is. It is the isa_port_base. From owner-linux-mips@oss.sgi.com Thu Nov 8 15:07:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8N7vR17790 for linux-mips-outgoing; Thu, 8 Nov 2001 15:07:57 -0800 Received: from i01sv4107.ids1.intelonline.com (i01sv4107-p.ids1.intelonline.com [147.208.166.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8N7s017787 for ; Thu, 8 Nov 2001 15:07:54 -0800 Received: from i01sv0637 (unverified [10.81.26.22]) by i01sv4107.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id ; Thu, 8 Nov 2001 23:07:45 +0000 Message-ID: From: Guo-Rong Koh To: "R.vandenBerg@inter.NL.net" , "linux-mips@oss.sgi.com" X-Originating-IP: [203.14.96.34] Date: Fri, 09 Nov 2001 9:07:45 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: Re: DECStation framebuffer support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I couldn't get it to work either. My problem is that my monitor is fixed sync to support the PMAGB-B card. It can't do the signal from the maxinefb. I also tried an option "video=maxinefb:off" so it wouldn't probe the card that was a no go either. Unless I get a monitor that supports it, I may _have_ to use a serial console ... >I didn't succeed in getting that to work, my advise would to try it first >with the on-board video. > >> BTW, thanks for responding, none of this documented anywhere. > >Oh yes it is, do a grep maxinefb on the 1999 mail archive available from >http://home.zonnet.berg56/ and you see it was discussed in june... Hmm.. you're right! I only searched back to the Jan2000 archives but now I realise that fb support has been around since 1999, my bad. Cheers, Guo-Rong __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Thu Nov 8 15:37:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA8NbBv18480 for linux-mips-outgoing; Thu, 8 Nov 2001 15:37:11 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA8Nb5018473; Thu, 8 Nov 2001 15:37:05 -0800 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 fA8NcVB21430; Thu, 8 Nov 2001 15:38:31 -0800 Message-ID: <3BEB171C.CF7949C2@mvista.com> Date: Thu, 08 Nov 2001 15:37:00 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: [PATCH] wrong EF_CP0_CAUSE offset Content-Type: multipart/mixed; boundary="------------E011AD610D9DDDF09FF10D0F" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------E011AD610D9DDDF09FF10D0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit reg.h has the wrong offset EF_CP0_CAUSE and the wrong pt_regs size. This seems to be a problem only for mips (32bit) tree. Drow found this bug, BTW. Jun --------------E011AD610D9DDDF09FF10D0F Content-Type: text/plain; charset=us-ascii; name="wrong-EF_CP0_CAUSE-offset.011108.011108.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wrong-EF_CP0_CAUSE-offset.011108.011108.patch" diff -Nru linux/include/asm-mips/reg.h.orig linux/include/asm-mips/reg.h --- linux/include/asm-mips/reg.h.orig Wed Aug 18 16:37:49 1999 +++ linux/include/asm-mips/reg.h Thu Nov 8 15:23:32 2001 @@ -59,8 +59,8 @@ #define EF_CP0_EPC 40 #define EF_CP0_BADVADDR 41 #define EF_CP0_STATUS 42 -#define EF_CP0_CAUSE 44 +#define EF_CP0_CAUSE 43 -#define EF_SIZE 180 /* size in bytes */ +#define EF_SIZE 176 /* size in bytes */ #endif /* __ASM_MIPS_REG_H */ --------------E011AD610D9DDDF09FF10D0F-- From owner-linux-mips@oss.sgi.com Thu Nov 8 18:04:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA924aw21108 for linux-mips-outgoing; Thu, 8 Nov 2001 18:04:36 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA924X021104 for ; Thu, 8 Nov 2001 18:04:33 -0800 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 fA925vB28450; Thu, 8 Nov 2001 18:05:57 -0800 Message-ID: <3BEB39AA.5E715AD8@mvista.com> Date: Thu, 08 Nov 2001 18:04:26 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: balaji.ramalingam@philips.com CC: linux-mips@oss.sgi.com Subject: Re: kernel bug in linux2.4.3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk balaji.ramalingam@philips.com wrote: > > Hello, > > I took the linux kernel 2.4.3 from ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/src/. > This kernel was ported for MIPS32 ISA and its supposed to work with all the > mips 4kc core. I took the kernel and ported for our Philips processor PR3950, > which is based on a mips 4kc core. > > I have some issues in the reserve_bootmem() & the paging_init() in the > arch/mips/kernel/setup.c. Itseems that they fail in the alloc_bootmem (). > I commented these functions and got till console_init() to get the print messages > on my screen. I got the message as Kernel Bug in bootmem.c > Does PR3950 have ll/sc instructions? If not, make sure the config file reflects that properly. Otherwise alloc_bootmem() will hang for ever. Commenting them out certainly is not the solution. :-) Jun From owner-linux-mips@oss.sgi.com Thu Nov 8 18:33:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA92XpU21590 for linux-mips-outgoing; Thu, 8 Nov 2001 18:33:51 -0800 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA92Xm021587 for ; Thu, 8 Nov 2001 18:33:48 -0800 Received: (from ex2k [172.19.1.1]) by smtp.psdc.com (NAVGW 2.5.1.13) with SMTP id M2001110818340828042 for ; Thu, 08 Nov 2001 18:34:08 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: bash-1.14.7 could not be built. X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 8 Nov 2001 18:28:38 -0800 Message-ID: <84CE342693F11946B9F54B18C1AB837B14ADF7@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bash-1.14.7 could not be built. Thread-Index: AcFoxjy/IUSNF/gcQfiZHYiqc9i01w== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA92Xm021588 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All: I tried build bash-1.14.7 for my mips r3000 and failed. The major problem was buitlins of bash could not be built. If you ever built it, please let me share you expirence. Thanks, Steven Liu From owner-linux-mips@oss.sgi.com Fri Nov 9 00:14:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA98EVZ27473 for linux-mips-outgoing; Fri, 9 Nov 2001 00:14:31 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA98EP027469; Fri, 9 Nov 2001 00:14:26 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 9 Nov 2001 08:14:25 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 2FC85B46B; Fri, 9 Nov 2001 17:14:23 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id RAA69002; Fri, 9 Nov 2001 17:14:22 +0900 (JST) Date: Fri, 09 Nov 2001 17:19:09 +0900 (JST) Message-Id: <20011109.171909.88468256.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: pci_map_page patch From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk pci_map_page() (added in 2.4.14) ignores offset value. --- linux-sgi-cvs/include/asm-mips/pci.h Thu Nov 8 16:27:01 2001 +++ linux.new/include/asm-mips/pci.h Fri Nov 9 16:54:46 2001 @@ -130,6 +130,7 @@ BUG(); addr = (unsigned long) page_address(page); + addr += offset; #ifndef CONFIG_COHERENT_IO dma_cache_wback_inv(addr, size); #endif --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Fri Nov 9 10:30:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9IUus14284 for linux-mips-outgoing; Fri, 9 Nov 2001 10:30:56 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9IUp014281; Fri, 9 Nov 2001 10:30:51 -0800 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 fA9IWEB02720; Fri, 9 Nov 2001 10:32:14 -0800 Message-ID: <3BEC20D5.AD6ABBA6@mvista.com> Date: Fri, 09 Nov 2001 10:30:45 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Simmons CC: Ralf Baechle , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk James Simmons wrote: > > > > > The mips_io_port_base is 0xa0000000. Whereas the i8259 chip is at > > > > 0xb0000000. The 0xa000000 value could be wrong. I will give it a try. > > > > > > As your board must have RAM at physical address zero 0xa0000000 is almost > > > certainly a wrong value. > > > > Your right. The address of 0xb000000 is bogus. This is the value from the > > old code. I will migrate the code over to the i8259.c stuff now. Thanks. > > Actually looking threw other mips branches now I see what the 0xb000000 > is. It is the isa_port_base. > You are probably referring to isa_slot_offset? isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and send him a patch to get rid of it (as if he can't do it himself :-0) ? Jun From owner-linux-mips@oss.sgi.com Fri Nov 9 10:44:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9IiMw14510 for linux-mips-outgoing; Fri, 9 Nov 2001 10:44:22 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9IiI014506; Fri, 9 Nov 2001 10:44:18 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA9Ii5jV013100; Fri, 9 Nov 2001 10:44:05 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fA9Ii4wm013096; Fri, 9 Nov 2001 10:44:04 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 9 Nov 2001 10:44:04 -0800 (PST) From: James Simmons To: Jun Sun cc: Ralf Baechle , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian In-Reply-To: <3BEC20D5.AD6ABBA6@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > You are probably referring to isa_slot_offset? Yes. I meant isa_slot_offset. > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > send him a patch to get rid of it (as if he can't do it himself :-0) ? Oh. From owner-linux-mips@oss.sgi.com Fri Nov 9 11:44:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9JiT616156 for linux-mips-outgoing; Fri, 9 Nov 2001 11:44:29 -0800 Received: from neurosis.mit.edu (NEUROSIS.MIT.EDU [18.243.0.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9JiP016153; Fri, 9 Nov 2001 11:44:25 -0800 Received: (from jim@localhost) by neurosis.mit.edu (8.11.4/8.11.4) id fA9JiLY30238; Fri, 9 Nov 2001 14:44:21 -0500 Date: Fri, 9 Nov 2001 14:44:21 -0500 From: Jim Paris To: Jun Sun Cc: James Simmons , Ralf Baechle , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian Message-ID: <20011109144421.A30230@neurosis.mit.edu> Reply-To: jim@jtan.com References: <3BEC20D5.AD6ABBA6@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEC20D5.AD6ABBA6@mvista.com>; from jsun@mvista.com on Fri, Nov 09, 2001 at 10:30:45AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > You are probably referring to isa_slot_offset? > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > send him a patch to get rid of it (as if he can't do it himself :-0) ? How should it be properly done? -jim From owner-linux-mips@oss.sgi.com Fri Nov 9 12:21:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KLKA17081 for linux-mips-outgoing; Fri, 9 Nov 2001 12:21:20 -0800 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9KLI017078 for ; Fri, 9 Nov 2001 12:21:18 -0800 Received: (from ex2k [172.19.1.1]) by smtp.psdc.com (NAVGW 2.5.1.13) with SMTP id M2001110912214208218 for ; Fri, 09 Nov 2001 12:21:42 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Which usrland packages should be built for swapon, hostname,and grep? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 9 Nov 2001 12:16:11 -0800 Message-ID: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Which usrland packages should be built for swapon, hostname,and grep? Thread-Index: AcFpW17mJ6c/Rd3lS5uAjvpYG3akJg== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fA9KLI017079 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All: I am porting linux to mips r3000 now and need to build the following files for the target board: /sbin/swapon, /bin/hostname, /bin/mount, /bin/grep. Which usrland packages should I use for the above files? Any help should be greatly appreciated. Thank you. Steven Liu From owner-linux-mips@oss.sgi.com Fri Nov 9 12:25:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KPYQ17235 for linux-mips-outgoing; Fri, 9 Nov 2001 12:25:34 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9KPW017229 for ; Fri, 9 Nov 2001 12:25:32 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id BA58D9F26; Fri, 9 Nov 2001 21:25:27 +0100 (CET) Date: Fri, 9 Nov 2001 21:25:21 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Linux on RM600 Message-ID: <20011109212516.D16534@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi! The howto states that there's currently no linux running on the RM600. Is this information up-to-date? ...or has already some work be done? I could get one of those boxes, but I don't want to only use it as a letter weight... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 http://lug-owl.de/~jbglaw/software/snapshot2cvs/ From owner-linux-mips@oss.sgi.com Fri Nov 9 12:30:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KUJn17390 for linux-mips-outgoing; Fri, 9 Nov 2001 12:30:19 -0800 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9KUH017387 for ; Fri, 9 Nov 2001 12:30:17 -0800 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id MAA51555; Fri, 9 Nov 2001 12:30:01 -0800 (PST) Date: Fri, 9 Nov 2001 12:30:01 -0800 From: Geoffrey Espin To: Steven Liu Cc: linux-mips@oss.sgi.com Subject: Re: Which usrland packages should be built for swapon, hostname,and grep? Message-ID: <20011109123000.A49239@idiom.com> References: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com>; from Steven Liu on Fri, Nov 09, 2001 at 12:16:11PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I am porting linux to mips r3000 now and need to build the following > files for the target board: > /sbin/swapon, > /bin/hostname, > /bin/mount, > /bin/grep. > Which usrland packages should I use for the above files? Go straight to http://busybox.lineo.com/ then search & join the mailing list. Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Fri Nov 9 12:42:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KgJH17806 for linux-mips-outgoing; Fri, 9 Nov 2001 12:42:19 -0800 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9KgE017803 for ; Fri, 9 Nov 2001 12:42:14 -0800 Received: from GS256.SP.CS.CMU.EDU by ux3.sp.cs.cmu.edu id aa25634; 9 Nov 2001 15:41 EST Subject: Re: Which usrland packages should be built for swapon, hostname,and grep? From: Justin Carlson To: Steven Liu Cc: linux-mips@oss.sgi.com In-Reply-To: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> References: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-czYppOnrKYR0jYTBuCiV" X-Mailer: Evolution/0.99.0 (Preview Release) Date: 09 Nov 2001 15:41:49 -0500 Message-Id: <1005338510.8499.3.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-czYppOnrKYR0jYTBuCiV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2001-11-09 at 15:16, Steven Liu wrote: > Hi All: >=20 > I am porting linux to mips r3000 now and need to build the following > files for the target board: > /bin/hostname, In net-tools, here: http://www.tazenda.demon.co.uk/phil/net-tools/ > /bin/mount, > /sbin/swapon, These are in util-linux, which can be found here: ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux > /bin/grep. This is a GNU utility, which can be found at any of the mirrors. A good one for the U.S. west coast is here: ftp://gatekeeper.research.compaq.com/pub/GNU/grep > Which usrland packages should I use for the above files? >=20 In general, rpm -qf on an rpm-based distro will often give you a good idea as to what are the names of the source packages you want. There's probably something similar for debian, but my debian-fu is weak. -Justin --=-czYppOnrKYR0jYTBuCiV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA77D+N47Lg4cGgb74RAuGiAJ9Swl+efUv2L90ysVRboArYsLX9/wCdGunj LKo/N2jFWJtF95G5eHLogBA= =YOD3 -----END PGP SIGNATURE----- --=-czYppOnrKYR0jYTBuCiV-- From owner-linux-mips@oss.sgi.com Fri Nov 9 12:55:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9KtkX18061 for linux-mips-outgoing; Fri, 9 Nov 2001 12:55:46 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9Ktb018056; Fri, 9 Nov 2001 12:55:37 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03989; Fri, 9 Nov 2001 12:55:31 -0800 (PST) mail_from (jsun@mvista.com) 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 fA9KpnB10823; Fri, 9 Nov 2001 12:51:49 -0800 Message-ID: <3BEC418C.DB98CFFB@mvista.com> Date: Fri, 09 Nov 2001 12:50:20 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: jim@jtan.com CC: James Simmons , Ralf Baechle , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian References: <3BEC20D5.AD6ABBA6@mvista.com> <20011109144421.A30230@neurosis.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jim Paris wrote: > > > You are probably referring to isa_slot_offset? > > > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > > send him a patch to get rid of it (as if he can't do it himself :-0) ? > > How should it be properly done? > Use an ax! Jun P.S., I meant "just delete it wherever it appears." From owner-linux-mips@oss.sgi.com Fri Nov 9 13:12:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9LCnw18430 for linux-mips-outgoing; Fri, 9 Nov 2001 13:12:49 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9LCi018427 for ; Fri, 9 Nov 2001 13:12:45 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3EBDB7FA; Fri, 9 Nov 2001 22:12:43 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 26F9C46BC; Fri, 9 Nov 2001 13:12:11 -0800 (PST) Date: Fri, 9 Nov 2001 13:12:11 -0800 From: Florian Lohoff To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011109131211.D8243@paradigm.rfc822.org> References: <20011109212516.D16534@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M38YqGLZlgb6RLPS" Content-Disposition: inline In-Reply-To: <20011109212516.D16534@lug-owl.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --M38YqGLZlgb6RLPS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2001 at 09:25:21PM +0100, Jan-Benedict Glaw wrote: > Hi! >=20 > The howto states that there's currently no linux running on the RM600. > Is this information up-to-date? ...or has already some work be done? I > could get one of those boxes, but I don't want to only use it as a > letter weight... *Cough* You could also kill an Elephant with certain extension steps. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --M38YqGLZlgb6RLPS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77EaqUaz2rXW+gJcRAmLEAJ97F7JIynC7SQM2OmbjQL1oZI2XhACfX0Ri TV30mtKe/IuRnNAarRXCKdc= =l18H -----END PGP SIGNATURE----- --M38YqGLZlgb6RLPS-- From owner-linux-mips@oss.sgi.com Fri Nov 9 13:14:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9LEEN18532 for linux-mips-outgoing; Fri, 9 Nov 2001 13:14:14 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9LE9018528 for ; Fri, 9 Nov 2001 13:14:10 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id E2CFA7FA; Fri, 9 Nov 2001 22:14:08 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 1D4F546BC; Fri, 9 Nov 2001 13:13:34 -0800 (PST) Date: Fri, 9 Nov 2001 13:13:34 -0800 From: Florian Lohoff To: Steven Liu Cc: linux-mips@oss.sgi.com Subject: Re: Which usrland packages should be built for swapon, hostname,and grep? Message-ID: <20011109131334.E8243@paradigm.rfc822.org> References: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bi5JUZtvcfApsciF" Content-Disposition: inline In-Reply-To: <84CE342693F11946B9F54B18C1AB837B14AE21@ex2k.pcs.psdc.com> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --bi5JUZtvcfApsciF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2001 at 12:16:11PM -0800, Steven Liu wrote: > Hi All: >=20 > I am porting linux to mips r3000 now and need to build the following > files for the target board: > /sbin/swapon, > /bin/hostname, > /bin/mount, > /bin/grep. > Which usrland packages should I use for the above files? >=20 A whole userland has been built with debian - You can get it on the next debian mirror beeing found on www.debian.org. One problem though might be that you need to fix "sysmips(MIPS_ATOMIC_SET)" in the kernel to actually run the binarys (glibc 2.2). Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --bi5JUZtvcfApsciF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77Eb9Uaz2rXW+gJcRAqwdAJ4lH3HtWa6oYJ4vEGudKtou7HdD9ACglXhT VUkQKl8c2IChWQ5fnAwj76Y= =yiUe -----END PGP SIGNATURE----- --bi5JUZtvcfApsciF-- From owner-linux-mips@oss.sgi.com Fri Nov 9 13:19:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9LJfZ18719 for linux-mips-outgoing; Fri, 9 Nov 2001 13:19:41 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9LJe018713 for ; Fri, 9 Nov 2001 13:19:40 -0800 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 fA9LL4B12485; Fri, 9 Nov 2001 13:21:04 -0800 Message-ID: <3BEC4866.FEC62378@mvista.com> Date: Fri, 09 Nov 2001 13:19:34 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: preemptible kernel for Linux/MIPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Here is the patch you can try out. Please give me your feedback. http://linux.junsun.net/realtime-linux Note a couple of things: . it is against 2.4.10 . to apply it cleanly you need to check oss CVS tree on 10/30. See readme. . you can only run it on a board that is configured with CONFIG_NEW_IRQ. An updated patch, probably against 2.4.14, will be made soon - hopefully. :-) Jun From owner-linux-mips@oss.sgi.com Fri Nov 9 14:36:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9Ma8a20059 for linux-mips-outgoing; Fri, 9 Nov 2001 14:36:08 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9Ma5020056 for ; Fri, 9 Nov 2001 14:36:05 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 212699DF3; Fri, 9 Nov 2001 23:35:57 +0100 (CET) Date: Fri, 9 Nov 2001 23:35:56 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011109233555.G16534@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011109131211.D8243@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2001-11-09 13:12:11 -0800, Florian Lohoff wrote in message <20011109131211.D8243@paradigm.rfc822.org>: > On Fri, Nov 09, 2001 at 09:25:21PM +0100, Jan-Benedict Glaw wrote: > > The howto states that there's currently no linux running on the RM600. > > Is this information up-to-date? ...or has already some work be done? I > > *Cough* You could also kill an Elephant with certain extension steps. I know:-) But what about the RM600. I've found some announcement for some SAP monitoring system running on "RM600/LINUX" (can be found at http://www.save.de/bereiche/ak_s/sap/sap1000/agenda.html). I found arbitrary texts talking about RM600 and Reliant Unix, but that's not what I want. (Or do I want to have the 2nd exotic O/S running?) MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 http://lug-owl.de/~jbglaw/software/snapshot2cvs/ From owner-linux-mips@oss.sgi.com Fri Nov 9 14:55:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9MtYp20405 for linux-mips-outgoing; Fri, 9 Nov 2001 14:55:34 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9MtT020401 for ; Fri, 9 Nov 2001 14:55:29 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 4CC5D83A; Fri, 9 Nov 2001 23:55:28 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A23E246BF; Fri, 9 Nov 2001 14:54:43 -0800 (PST) Date: Fri, 9 Nov 2001 14:54:43 -0800 From: Florian Lohoff To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011109145443.J8243@paradigm.rfc822.org> References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvznHscUikHnwW2p" Content-Disposition: inline In-Reply-To: <20011109233555.G16534@lug-owl.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --GvznHscUikHnwW2p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2001 at 11:35:56PM +0100, Jan-Benedict Glaw wrote: > I know:-) But what about the RM600. I've found some announcement > for some SAP monitoring system running on "RM600/LINUX" (can be > found at http://www.save.de/bereiche/ak_s/sap/sap1000/agenda.html). I dont think they mean THE RM600 or they mean RM600/Reliant=20 and/or Linux/i386 > I found arbitrary texts talking about RM600 and Reliant Unix, but > that's not what I want. (Or do I want to have the 2nd exotic O/S > running?) The RM600 is big endian only AFAIK and was running Sinix/Reliant only. The RM200 port which existed and which might be completely=20 outdated and non-functional now is for little endian which the RM200 were delivered with for running Windows-NT. Thus - Its a completely new port ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --GvznHscUikHnwW2p Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77F6zUaz2rXW+gJcRAnuLAJ9RlUSTXgeo1lyR3MlsJ1gIjW/wbwCeP1aw 3Da3XbV7ZPirgKOG1qfjtRo= =3eLW -----END PGP SIGNATURE----- --GvznHscUikHnwW2p-- From owner-linux-mips@oss.sgi.com Fri Nov 9 15:02:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fA9N2qu20611 for linux-mips-outgoing; Fri, 9 Nov 2001 15:02:52 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fA9N2n020608 for ; Fri, 9 Nov 2001 15:02:49 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 84B4E9F27; Sat, 10 Nov 2001 00:02:47 +0100 (CET) Date: Sat, 10 Nov 2001 00:02:47 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011110000247.J16534@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011109145443.J8243@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2001-11-09 14:54:43 -0800, Florian Lohoff wrote in message <20011109145443.J8243@paradigm.rfc822.org>: > On Fri, Nov 09, 2001 at 11:35:56PM +0100, Jan-Benedict Glaw wrote: > > > I found arbitrary texts talking about RM600 and Reliant Unix, but > > that's not what I want. (Or do I want to have the 2nd exotic O/S > > running?) > > The RM600 is big endian only AFAIK and was running Sinix/Reliant > only. The RM200 port which existed and which might be completely > outdated and non-functional now is for little endian which > the RM200 were delivered with for running Windows-NT. > > Thus - Its a completely new port ... Shit. Does anybody know something about Siemen's / SNI's / Wincor's documentation policy? Karsten? Any hope to get the box running with linux? MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 http://lug-owl.de/~jbglaw/software/snapshot2cvs/ From owner-linux-mips@oss.sgi.com Fri Nov 9 17:09:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAA19g708015 for linux-mips-outgoing; Fri, 9 Nov 2001 17:09:42 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAA19b007948 for ; Fri, 9 Nov 2001 17:09:37 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 1A74883A; Sat, 10 Nov 2001 02:09:36 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5B69446BC; Fri, 9 Nov 2001 17:09:00 -0800 (PST) Date: Fri, 9 Nov 2001 17:09:00 -0800 From: Florian Lohoff To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011109170900.N8243@paradigm.rfc822.org> References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> <20011110000247.J16534@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p1Od3smaOkJqivj4" Content-Disposition: inline In-Reply-To: <20011110000247.J16534@lug-owl.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --p1Od3smaOkJqivj4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 10, 2001 at 12:02:47AM +0100, Jan-Benedict Glaw wrote: >=20 > Shit. Does anybody know something about Siemen's / SNI's / Wincor's > documentation policy? Karsten? Any hope to get the box running with > linux? >=20 There is no documentation i know of - But we should be able to reactivate a couple of people within SNI/Paderborn (Probably they are even reading on here) which can at least give good answers to intelligent questions. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --p1Od3smaOkJqivj4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77H4sUaz2rXW+gJcRAjziAKDX4jIRQi21F3DPowE54P3ni7oCsgCgvshH bDf5ET/vkw4FGjD0rX04/Tw= =VaRy -----END PGP SIGNATURE----- --p1Od3smaOkJqivj4-- From owner-linux-mips@oss.sgi.com Sat Nov 10 07:21:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAAFLEm24819 for linux-mips-outgoing; Sat, 10 Nov 2001 07:21:14 -0800 Received: from mail.talknet.de (smtp01.talknet.de [195.252.142.71]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAAFLA024816 for ; Sat, 10 Nov 2001 07:21:10 -0800 Received: from chef-host (a1as12-p163.mch.tli.de [195.252.166.163]) by mail.talknet.de (8.11.0/8.11.0) with ESMTP id fAAFL0m12814 for ; Sat, 10 Nov 2001 16:21:02 +0100 (MET) X-Delivered-To: <> Received: from localhost (master@localhost [127.0.0.1]) by chef-host (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA02511 for ; Sat, 10 Nov 2001 17:09:47 +0100 Date: Sat, 10 Nov 2001 17:09:47 +0100 (MET) From: Alexander Reil X-Sender: master@chef-host Reply-To: alexreil@talknet.de To: linux-mips@oss.sgi.com Subject: RM200 and bootp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, i try to run my rm200 with linux. I installed bootpd on my intel-server, but my rm200 can't find my bootp-server. --- schnipp --- Pandora> boot bootp()/vmlinux pandora: kernel file is `bootp()/vmlinux' No server for vmlinux Unable to open kernel file bootp()/vmlinux --- schnapp --- Is the command boot bootp()/vmlinux correct? my /etc/bootptab: .global:sm=255.255.255.0:hd=/tftpboot: mipsel:tc=.global:ht=ethernet:ha=0000e4040ba5:ip=192.168.1.5:bf=vmlinux: bootpd is running. Any hints? Thanks in advance, Alexander From owner-linux-mips@oss.sgi.com Sat Nov 10 17:45:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB1jiM02591 for linux-mips-outgoing; Sat, 10 Nov 2001 17:45:44 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAB1jf002586 for ; Sat, 10 Nov 2001 17:45:42 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA978MI00860; Fri, 9 Nov 2001 18:08:22 +1100 Date: Fri, 9 Nov 2001 18:08:22 +1100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] wrong EF_CP0_CAUSE offset Message-ID: <20011109180821.A655@dea.linux-mips.net> References: <3BEB171C.CF7949C2@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEB171C.CF7949C2@mvista.com>; from jsun@mvista.com on Thu, Nov 08, 2001 at 03:37:00PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 03:37:00PM -0800, Jun Sun wrote: > reg.h has the wrong offset EF_CP0_CAUSE and the wrong pt_regs size. > > This seems to be a problem only for mips (32bit) tree. > > Drow found this bug, BTW. Thanks, patch applied to both 2.2 and 2.4. Fortunately the consequences of this bug should hardly bite any user. Ralf From owner-linux-mips@oss.sgi.com Sat Nov 10 17:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB1jlb02604 for linux-mips-outgoing; Sat, 10 Nov 2001 17:45:47 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAB1ji002598 for ; Sat, 10 Nov 2001 17:45:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA9Hfxp00938; Sat, 10 Nov 2001 04:41:59 +1100 Date: Sat, 10 Nov 2001 04:41:59 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: i8259.c in big endian Message-ID: <20011110044159.A917@dea.linux-mips.net> References: <20011108.154702.74756496.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011108.154702.74756496.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Thu, Nov 08, 2001 at 03:47:02PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 08, 2001 at 03:47:02PM +0900, Atsushi Nemoto wrote: > Date: Thu, 08 Nov 2001 15:47:02 +0900 (JST) > To: linux-mips@oss.sgi.com > Cc: ralf@oss.sgi.com > Subject: i8259.c in big endian > From: Atsushi Nemoto > > arch/mips/kernel/i8259.c seems not working in big endian. Below the fix I'm going to checkin. Highly untested as I'm sitting in a plase 800km northeast of New Zealand :-) Ralf From owner-linux-mips@oss.sgi.com Sat Nov 10 23:18:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAB7IMf07688 for linux-mips-outgoing; Sat, 10 Nov 2001 23:18:22 -0800 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAB7Hp007674 for ; Sat, 10 Nov 2001 23:17:51 -0800 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id XAA04364; Sat, 10 Nov 2001 23:17:46 -0800 Date: Sat, 10 Nov 2001 23:17:46 -0800 From: Jun Sun To: linux-mips@oss.sgi.com Subject: [RFC] generic MIPS RTC driver Message-ID: <20011110231746.B4342@mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="98e8jtXdkpgskNou" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline For many MIPS boards that start to use CONFIG_NEW_TIME_C, two rtc operations are implemented, rtc_get_time() and rtc_set_time(). It is possible to write a simple generic RTC driver that is based on these two ops and can do simple RTC read&write ops. In other words, with such a driver, once you implemented rtc_get_time() and rtc_set_time(), which is required by the kernel anyway, you will automatically get a free /dev/rtc/ driver. This is the idea behind the generic MIPS rtc driver. See the patch below. Right now the feature is rather limited, due to the thin abstraction we are having with rtc ops. But apparently the implementation is good enough to make hwclock program happy. Any comments? Jun /* * A simple generic Real Time Clock interface for Linux/MIPS * * Copyright (C) 1996 Paul Gortmaker * * Copyright (C) 2001 Monta Vista Software * Author Jun Sun, jsun@mvista.com or jsun@junsun.net * * This is a simple generic RTC driver for MIPS boards configured * with CONFIG_NEW_TIME_C. For now, it makes use of the two * abstract kernel RTC functions introduced in include/asm-mips/time.h: * * extern unsigned long (*rtc_get_time)(void); * extern int (*rtc_set_time)(unsigned long); * * It uses the same protocol as the original drivers/char/rtc.c driver, * but only implements two ioctls: RTC_RD_TIME and RTC_SET_TIME. * * TODO : * * 1. we can extend the null rtc ops defined in arch/mips/time.c to * at least record the elapsed time (by recording/checking jiffies) * This way RTC_RD_TIME and RTC_SET_TIME will make more sense. * (Maybe not. A machine without a real RTC is broken anymore. * Just a thought.) * * 2. If we make use of timer bh, we can emulate many RTC functions * such as RTC alarm interrupt, periodic interrupts, etc. * * 3. It is possible to extend the kernel RTC abstractions to more * than two functions, so that perhaps we can implement more * full-featured RTC driver and also have a better abstraction * to support more RTC hardware than the original RTC driver. * It needs to be done very carefully. * * Change Log : * v1.0 - [jsun] initial version */ --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mips-rtc.011110.1900.011110.patch" diff -Nru linux/Documentation/Configure.help.orig linux/Documentation/Configure.help --- linux/Documentation/Configure.help.orig Sat Nov 10 18:48:51 2001 +++ linux/Documentation/Configure.help Sat Nov 10 22:58:23 2001 @@ -15163,6 +15163,17 @@ #EFI Real Time Clock Services #CONFIG_EFI_RTC +Generic MIPS RTC Support +CONFIG_MIPS_RTC + + If your machine is a MIPS machine, this option provides a simple, + generic RTC driver for /dev/rtc device. It only implements two IOCTL + operations of the standard PC RTC driver: RTC_RD_TIME and RTC_SET_TIME. + It is sufficient to run hwclock program. + + You should say Y here if there is no machine-specific RTC driver for your + MIPS machine but you do want a simple RTC driver for your RTC device. + Tadpole ANA H8 Support CONFIG_H8 The Hitachi H8/337 is a microcontroller used to deal with the power diff -Nru linux/drivers/char/Config.in.orig linux/drivers/char/Config.in --- linux/drivers/char/Config.in.orig Sat Nov 10 18:49:31 2001 +++ linux/drivers/char/Config.in Sat Nov 10 22:48:27 2001 @@ -194,6 +194,9 @@ if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then bool 'Tadpole ANA H8 Support' CONFIG_H8 fi +if [ "$CONFIG_MIPS" = "y" -a "$CONFIG_NEW_TIME_C" = "y" ]; then + tristate 'Generic MIPS RTC Support' CONFIG_MIPS_RTC +fi tristate 'Double Talk PC internal speech card support' CONFIG_DTLK tristate 'Siemens R3964 line discipline' CONFIG_R3964 diff -Nru linux/drivers/char/Makefile.orig linux/drivers/char/Makefile --- linux/drivers/char/Makefile.orig Sat Nov 10 18:49:31 2001 +++ linux/drivers/char/Makefile Sat Nov 10 21:54:00 2001 @@ -194,6 +194,7 @@ obj-$(CONFIG_PC110_PAD) += pc110pad.o obj-$(CONFIG_RTC) += rtc.o obj-$(CONFIG_EFI_RTC) += efirtc.o +obj-$(CONFIG_MIPS_RTC) += mips_rtc.o ifeq ($(CONFIG_PPC),) obj-$(CONFIG_NVRAM) += nvram.o endif diff -Nru linux/drivers/char/mips_rtc.c.orig linux/drivers/char/mips_rtc.c --- linux/drivers/char/mips_rtc.c.orig Sat Nov 10 21:03:02 2001 +++ linux/drivers/char/mips_rtc.c Sat Nov 10 23:10:39 2001 @@ -0,0 +1,221 @@ +/* + * A simple generic Real Time Clock interface for Linux/MIPS + * + * Copyright (C) 1996 Paul Gortmaker + * + * Copyright (C) 2001 Monta Vista Software + * Author Jun Sun, jsun@mvista.com or jsun@junsun.net + * + * This is a simple generic RTC driver for MIPS boards configured + * with CONFIG_NEW_TIME_C. For now, it makes use of the two + * abstract kernel RTC functions introduced in include/asm-mips/time.h: + * + * extern unsigned long (*rtc_get_time)(void); + * extern int (*rtc_set_time)(unsigned long); + * + * It uses the same protocol as the original drivers/char/rtc.c driver, + * but only implements two ioctls: RTC_RD_TIME and RTC_SET_TIME. + * + * TODO : + * + * 1. we can extend the null rtc ops defined in arch/mips/time.c to + * at least record the elapsed time (by recording/checking jiffies) + * This way RTC_ALM_READ and RTC_ALM_SET will make more sense. + * (Maybe not. A machine without a real RTC is broken anymore. + * Just a thought.) + * + * 2. If we make use of timer bh, we can emulate many RTC functions + * such as RTC alarm interrupt, periodic interrupts, etc. + * + * 3. It is possible to extend the kernel RTC abstractions to more + * than two functions, so that perhaps we can implement more + * full-featured RTC driver and also have a better abstraction + * to support more RTC hardware than the original RTC driver. + * It needs to be done very carefully. + * + * Change Log : + * v1.0 - [jsun] initial version + */ + +#define RTC_VERSION "1.0" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * Check machine + */ +#if !defined(CONFIG_MIPS) || !defined(CONFIG_NEW_TIME_C) +#error "This driver is for MIPS machines with CONFIG_NEW_TIME_C defined" +#endif + +#include + +static unsigned long rtc_status = 0; /* bitmapped status byte. */ + +static int rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data); + + +#define RTC_IS_OPEN 0x01 /* means /dev/rtc is in use */ + +static spinlock_t rtc_lock; + +static int +rtc_ioctl(struct inode *inode, struct file *file, unsigned int cmd, + unsigned long arg) +{ + struct rtc_time rtc_tm; + ulong curr_time; + + switch (cmd) { + case RTC_RD_TIME: /* Read the time/date from RTC */ + curr_time = rtc_get_time(); + to_tm(curr_time, &rtc_tm); + rtc_tm.tm_year -= 1900; + return copy_to_user((void *) arg, &rtc_tm, sizeof(rtc_tm)) ? + -EFAULT : 0; + case RTC_SET_TIME: /* Set the RTC */ + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + if (copy_from_user(&rtc_tm, + (struct rtc_time *) arg, + sizeof(struct rtc_time))) + return -EFAULT; + + curr_time = mktime(rtc_tm.tm_year + 1900, + rtc_tm.tm_mon + 1, /* tm_mon starts from 0 */ + rtc_tm.tm_mday, + rtc_tm.tm_hour, + rtc_tm.tm_min, + rtc_tm.tm_sec); + return rtc_set_time(curr_time); + default: + return -EINVAL; + } +} + +/* We use rtc_lock to protect against concurrent opens. So the BKL is not + * needed here. Or anywhere else in this driver. */ +static int rtc_open(struct inode *inode, struct file *file) +{ + spin_lock_irq(&rtc_lock); + + if (rtc_status & RTC_IS_OPEN) { + spin_unlock_irq(&rtc_lock); + return -EBUSY; + } + + rtc_status |= RTC_IS_OPEN; + + spin_unlock_irq(&rtc_lock); + return 0; +} + +static int rtc_release(struct inode *inode, struct file *file) +{ + spin_lock_irq(&rtc_lock); + rtc_status &= ~RTC_IS_OPEN; + spin_unlock_irq(&rtc_lock); + return 0; +} + +/* + * The various file operations we support. + */ + +static struct file_operations rtc_fops = { + owner:THIS_MODULE, + llseek:no_llseek, + ioctl:rtc_ioctl, + open:rtc_open, + release:rtc_release, +}; + +static struct miscdevice rtc_dev = { + RTC_MINOR, + "rtc", + &rtc_fops +}; + +static int __init rtc_init(void) +{ + + misc_register(&rtc_dev); + create_proc_read_entry("driver/rtc", 0, 0, rtc_read_proc, NULL); + + printk(KERN_INFO "Generic MIPS RTC Driver v" RTC_VERSION "\n"); + + return 0; +} + +static void __exit rtc_exit(void) +{ + remove_proc_entry("driver/rtc", NULL); + misc_deregister(&rtc_dev); + +} + +module_init(rtc_init); +module_exit(rtc_exit); +EXPORT_NO_SYMBOLS; + +/* + * Info exported via "/proc/driver/rtc". + */ + +static int rtc_proc_output(char *buf) +{ + char *p; + struct rtc_time tm; + unsigned long curr_time; + + curr_time = rtc_get_time(); + to_tm(curr_time, &tm); + + p = buf; + + /* + * There is no way to tell if the luser has the RTC set for local + * time or for Universal Standard Time (GMT). Probably local though. + */ + p += sprintf(p, + "rtc_time\t: %02d:%02d:%02d\n" + "rtc_date\t: %04d-%02d-%02d\n" + "rtc_epoch\t: %04lu\n", + tm.tm_hour, tm.tm_min, tm.tm_sec, + tm.tm_year, tm.tm_mon + 1, tm.tm_mday, 0L); + + return p - buf; +} + +static int rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + int len = rtc_proc_output(page); + if (len <= off + count) + *eof = 1; + *start = page + off; + len -= off; + if (len > count) + len = count; + if (len < 0) + len = 0; + return len; +} + +MODULE_AUTHOR("Jun Sun"); +MODULE_LICENSE("GPL"); --98e8jtXdkpgskNou-- From owner-linux-mips@oss.sgi.com Sun Nov 11 02:14:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABAEec10134 for linux-mips-outgoing; Sun, 11 Nov 2001 02:14:40 -0800 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABAEa010130 for ; Sun, 11 Nov 2001 02:14:36 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA23324; Sun, 11 Nov 2001 11:14:26 +0100 (MET) Date: Sun, 11 Nov 2001 11:14:26 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <20011110231746.B4342@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, 10 Nov 2001, Jun Sun wrote: > For many MIPS boards that start to use CONFIG_NEW_TIME_C, two rtc operations > are implemented, rtc_get_time() and rtc_set_time(). > > It is possible to write a simple generic RTC driver that is based on > these two ops and can do simple RTC read&write ops. > > In other words, with such a driver, once you implemented rtc_get_time() > and rtc_set_time(), which is required by the kernel anyway, you will > automatically get a free /dev/rtc/ driver. > > This is the idea behind the generic MIPS rtc driver. See the patch below. Oh no, don't tell me we now have (at least) _three_ of these floating around :-) - On m68k, we have drivers/char/genrtc.c (not yet merged, check out CVS, see http://linux-m68k-cvs.apia.dhs.org/). - On PPC, we have drivers/macintosh/rtc.c. - On MIPS, we now have your drivers/char/mips_rtc.c. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Sun Nov 11 13:14:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fABLE5i28983 for linux-mips-outgoing; Sun, 11 Nov 2001 13:14:05 -0800 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fABLE2028980 for ; Sun, 11 Nov 2001 13:14:03 -0800 Received: from excalibur.cologne.de (pD9E40D2D.dip.t-dialin.net [217.228.13.45]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id WAA18033 for ; Sun, 11 Nov 2001 22:13:59 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 1631cp-0000LH-00 for ; Sun, 11 Nov 2001 21:54:43 +0100 Date: Sun, 11 Nov 2001 21:54:43 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20011111215443.A404@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> <20011110000247.J16534@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011110000247.J16534@lug-owl.de>; from jbglaw@lug-owl.de on Sat, Nov 10, 2001 at 12:02:47AM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 12:02:47AM +0100, Jan-Benedict Glaw wrote: [RM600] > Shit. Does anybody know something about Siemen's / SNI's / Wincor's > documentation policy? Karsten? Any hope to get the box running with > linux? AFAIK: no chance. 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 owner-linux-mips@oss.sgi.com Sun Nov 11 17:40:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC1ebC04245 for linux-mips-outgoing; Sun, 11 Nov 2001 17:40:37 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC1eY004238 for ; Sun, 11 Nov 2001 17:40:34 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 12 Nov 2001 01:40:34 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 2D035B46B; Mon, 12 Nov 2001 10:40:32 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA77325; Mon, 12 Nov 2001 10:40:31 +0900 (JST) Date: Mon, 12 Nov 2001 10:45:19 +0900 (JST) Message-Id: <20011112.104519.126571085.nemoto@toshiba-tops.co.jp> To: jsun@mvista.com Cc: linux-mips@oss.sgi.com Subject: Re: [RFC] generic MIPS RTC driver From: Atsushi Nemoto In-Reply-To: <20011110231746.B4342@mvista.com> References: <20011110231746.B4342@mvista.com> 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Sat, 10 Nov 2001 23:17:46 -0800, Jun Sun said: jsun> For many MIPS boards that start to use CONFIG_NEW_TIME_C, two jsun> rtc operations are implemented, rtc_get_time() and jsun> rtc_set_time(). jsun> It is possible to write a simple generic RTC driver that is jsun> based on these two ops and can do simple RTC read&write ops. ... jsun> This is the idea behind the generic MIPS rtc driver. See the jsun> patch below. ... jsun> Any comments? Good idea. I hope cvs kernel import this patch. I found two small things to fix. to_tm function sets 1..12 value in tm_mon field, so 1. in rtc_ioctl (case RTC_RD_TIME), subtracting 1 from rtc_tm.tm_mon is needed. 2. in rtc_proc_output, adding 1 to tm.tm_mon is not needed. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Mon Nov 12 00:12:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAC8C3u12981 for linux-mips-outgoing; Mon, 12 Nov 2001 00:12:03 -0800 Received: from wine.digital-digital.com ([210.122.73.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAC8C1012978 for ; Mon, 12 Nov 2001 00:12:01 -0800 Received: from khs ([210.122.73.37]) by wine.digital-digital.com (8.11.0/8.11.0) with SMTP id fAC8BhQ29820; Mon, 12 Nov 2001 17:11:45 +0900 Reply-To: From: "Han-Seong Kim" To: , Subject: Power MGMT on mips Date: Mon, 12 Nov 2001 17:13:40 +0900 Message-ID: <000001c16b51$f05f6070$cbadfea9@khs> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id fAC8C2012979 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I want to ask about Power-Mnagement on mips. 1. Is it possible to use power mgnt (ex. apm,acpi) features of linux kernel? 2.If no, how can manage CPU and Bidge chips for power mgnt ? Han-Seong From owner-linux-mips@oss.sgi.com Mon Nov 12 04:02:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACC2SM18110 for linux-mips-outgoing; Mon, 12 Nov 2001 04:02:28 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACC2C018105 for ; Mon, 12 Nov 2001 04:02:13 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27640; Mon, 12 Nov 2001 13:00:02 +0100 (MET) Date: Mon, 12 Nov 2001 13:00:02 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Steven Liu , linux-mips@oss.sgi.com Subject: Re: Which usrland packages should be built for swapon, hostname,and grep? In-Reply-To: <20011109131334.E8243@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 9 Nov 2001, Florian Lohoff wrote: > One problem though might be that you need to fix "sysmips(MIPS_ATOMIC_SET)" > in the kernel to actually run the binarys (glibc 2.2). It seems to be fixed to the point of working. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 12 04:16:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACCGg018524 for linux-mips-outgoing; Mon, 12 Nov 2001 04:16:42 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fACCGd018519 for ; Mon, 12 Nov 2001 04:16:40 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fACCFSv04426; Mon, 12 Nov 2001 23:15:28 +1100 Date: Mon, 12 Nov 2001 23:15:28 +1100 From: Ralf Baechle To: Jun Sun Cc: James Simmons , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian Message-ID: <20011112231528.D3949@dea.linux-mips.net> References: <3BEC20D5.AD6ABBA6@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BEC20D5.AD6ABBA6@mvista.com>; from jsun@mvista.com on Fri, Nov 09, 2001 at 10:30:45AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 09, 2001 at 10:30:45AM -0800, Jun Sun wrote: > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > send him a patch to get rid of it (as if he can't do it himself :-0) ? Nope. Somebody could fix isa_{read,write}[bwl] to use isa_slot_offset. Right now all the ISA functions are broken. So in case you're ISA drivers seem to work that's the proof that they're broken *evil grin* :-) Ralf From owner-linux-mips@oss.sgi.com Mon Nov 12 04:31:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACCVhd18806 for linux-mips-outgoing; Mon, 12 Nov 2001 04:31:43 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fACCVf018803 for ; Mon, 12 Nov 2001 04:31:41 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fACCUV409976; Mon, 12 Nov 2001 23:30:31 +1100 Date: Mon, 12 Nov 2001 23:30:31 +1100 From: Ralf Baechle To: Han-Seong Kim Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Power MGMT on mips Message-ID: <20011112233031.A6493@dea.linux-mips.net> References: <000001c16b51$f05f6070$cbadfea9@khs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c16b51$f05f6070$cbadfea9@khs>; from khs@digital-digital.com on Mon, Nov 12, 2001 at 05:13:40PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 05:13:40PM +0900, Han-Seong Kim wrote: > I want to ask about Power-Mnagement on mips. > 1. Is it possible to use power mgnt (ex. apm,acpi) features of linux kernel? Both are PC stuff, so no. > 2.If no, how can manage CPU and Bidge chips for power mgnt ? Right now Linux/MIPS will only use the CPU's power managment features, that is the wait instruction or similar. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 12 05:03:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACD3hK19391 for linux-mips-outgoing; Mon, 12 Nov 2001 05:03:43 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACD3a019385 for ; Mon, 12 Nov 2001 05:03:37 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA29614; Mon, 12 Nov 2001 13:59:12 +0100 (MET) Date: Mon, 12 Nov 2001 13:59:11 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Jun Sun , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, 11 Nov 2001, Geert Uytterhoeven wrote: > > In other words, with such a driver, once you implemented rtc_get_time() > > and rtc_set_time(), which is required by the kernel anyway, you will > > automatically get a free /dev/rtc/ driver. > > > > This is the idea behind the generic MIPS rtc driver. See the patch below. > > Oh no, don't tell me we now have (at least) _three_ of these floating around > :-) > > - On m68k, we have drivers/char/genrtc.c (not yet merged, check out CVS, see > http://linux-m68k-cvs.apia.dhs.org/). > - On PPC, we have drivers/macintosh/rtc.c. > - On MIPS, we now have your drivers/char/mips_rtc.c. Agreed, what's wrong with drivers/char/rtc.c? It even works for the DECstation which maps its RTC in an unusual (but nice) way -- it's just a matter of initializing rtc_ops appropriately. See arch/mips/dec/rtc-dec.c for an example. Unless you use a non-MC146818 RTC, which you need to write a separate driver for anyway. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 12 05:13:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACDDuS19630 for linux-mips-outgoing; Mon, 12 Nov 2001 05:13:56 -0800 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACDDp019627 for ; Mon, 12 Nov 2001 05:13:51 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA29043; Mon, 12 Nov 2001 14:11:27 +0100 (MET) Date: Mon, 12 Nov 2001 14:11:26 +0100 (MET) From: Geert Uytterhoeven To: "Maciej W. Rozycki" cc: Jun Sun , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Maciej W. Rozycki wrote: > On Sun, 11 Nov 2001, Geert Uytterhoeven wrote: > > > In other words, with such a driver, once you implemented rtc_get_time() > > > and rtc_set_time(), which is required by the kernel anyway, you will > > > automatically get a free /dev/rtc/ driver. > > > > > > This is the idea behind the generic MIPS rtc driver. See the patch below. > > > > Oh no, don't tell me we now have (at least) _three_ of these floating around > > :-) > > > > - On m68k, we have drivers/char/genrtc.c (not yet merged, check out CVS, see > > http://linux-m68k-cvs.apia.dhs.org/). > > - On PPC, we have drivers/macintosh/rtc.c. > > - On MIPS, we now have your drivers/char/mips_rtc.c. > > Agreed, what's wrong with drivers/char/rtc.c? It even works for the It's for MC146818 RTCs only. > DECstation which maps its RTC in an unusual (but nice) way -- it's just a > matter of initializing rtc_ops appropriately. See arch/mips/dec/rtc-dec.c > for an example. > > Unless you use a non-MC146818 RTC, which you need to write a separate > driver for anyway. Yep, so that's why both m68k and PPC have common routines to read/write the RTC, with a /dev/rtc-compatible abstraction on top of it. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Nov 12 05:30:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACDUxc20036 for linux-mips-outgoing; Mon, 12 Nov 2001 05:30:59 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACDUr020033 for ; Mon, 12 Nov 2001 05:30:54 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA00860; Mon, 12 Nov 2001 14:29:15 +0100 (MET) Date: Mon, 12 Nov 2001 14:29:14 +0100 (MET) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Jun Sun , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > Unless you use a non-MC146818 RTC, which you need to write a separate > > driver for anyway. > > Yep, so that's why both m68k and PPC have common routines to read/write the > RTC, with a /dev/rtc-compatible abstraction on top of it. OK, then you need an RTC chipset-specific driver and not a CPU architecture-specific one. Otherwise we'll end with a zillion of similar RTC drivers like we already have for LANCE and SCC chips. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 12 05:42:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACDgAp20299 for linux-mips-outgoing; Mon, 12 Nov 2001 05:42:10 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fACDg7020296 for ; Mon, 12 Nov 2001 05:42:07 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fACDex702940; Tue, 13 Nov 2001 00:40:59 +1100 Date: Tue, 13 Nov 2001 00:40:59 +1100 From: Ralf Baechle To: alexreil@talknet.de Cc: linux-mips@oss.sgi.com Subject: Re: RM200 and bootp Message-ID: <20011113004059.A32504@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from master@talknet.de on Sat, Nov 10, 2001 at 05:09:47PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Nov 10, 2001 at 05:09:47PM +0100, Alexander Reil wrote: > i try to run my rm200 with linux. I installed bootpd on my > intel-server, but my rm200 can't find my bootp-server. > > --- schnipp --- > Pandora> boot bootp()/vmlinux > pandora: kernel file is `bootp()/vmlinux' > No server for vmlinux > Unable to open kernel file bootp()/vmlinux > --- schnapp --- > > Is the command > boot bootp()/vmlinux > correct? No, the syntax is bootp(): where each of and is allowed to be missing. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 12 08:13:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACGDp524932 for linux-mips-outgoing; Mon, 12 Nov 2001 08:13:51 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACGDm024929 for ; Mon, 12 Nov 2001 08:13:48 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fACGDgB04379; Mon, 12 Nov 2001 08:13:42 -0800 Subject: Re: [RFC] generic MIPS RTC driver From: Pete Popov To: "Maciej W. Rozycki" Cc: Geert Uytterhoeven , Jun Sun , Linux/MIPS Development , Linux/m68k , Linux/PPC Development In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 12 Nov 2001 08:14:39 -0800 Message-Id: <1005581679.459.4.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote: > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > driver for anyway. > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > OK, then you need an RTC chipset-specific driver and not a CPU > architecture-specific one. Otherwise we'll end with a zillion of similar > RTC drivers like we already have for LANCE and SCC chips. I agree. We don't have arch specific network drivers so why have arch specific rtc drivers. Pete From owner-linux-mips@oss.sgi.com Mon Nov 12 10:20:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIKiL01878 for linux-mips-outgoing; Mon, 12 Nov 2001 10:20:44 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACIKe001874 for ; Mon, 12 Nov 2001 10:20:40 -0800 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 fACILGB11153; Mon, 12 Nov 2001 10:21:16 -0800 Message-ID: <3BF012CA.287A76A@mvista.com> Date: Mon, 12 Nov 2001 10:19:54 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Geert Uytterhoeven CC: "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Geert Uytterhoeven wrote: > > On Mon, 12 Nov 2001, Maciej W. Rozycki wrote: > > On Sun, 11 Nov 2001, Geert Uytterhoeven wrote: > > > > In other words, with such a driver, once you implemented rtc_get_time() > > > > and rtc_set_time(), which is required by the kernel anyway, you will > > > > automatically get a free /dev/rtc/ driver. > > > > > > > > This is the idea behind the generic MIPS rtc driver. See the patch below. > > > > > > Oh no, don't tell me we now have (at least) _three_ of these floating around > > > :-) > > > > > > - On m68k, we have drivers/char/genrtc.c (not yet merged, check out CVS, see > > > http://linux-m68k-cvs.apia.dhs.org/). > > > - On PPC, we have drivers/macintosh/rtc.c. > > > - On MIPS, we now have your drivers/char/mips_rtc.c. > > > > Agreed, what's wrong with drivers/char/rtc.c? It even works for the > > It's for MC146818 RTCs only. > > > DECstation which maps its RTC in an unusual (but nice) way -- it's just a > > matter of initializing rtc_ops appropriately. See arch/mips/dec/rtc-dec.c > > for an example. > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > driver for anyway. > > Yep, so that's why both m68k and PPC have common routines to read/write the > RTC, with a /dev/rtc-compatible abstraction on top of it. > Geert, what is the abstraction they used? The /dev/rtc interface is highly influenced by MC146818 chip, which not all RTC devices are alike. The only fundamental thing in the driver is really the read and write time. If their abstraction is reasonable, perhaps they can all converge to a better, more generic rtc interface. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 10:28:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIShq02157 for linux-mips-outgoing; Mon, 12 Nov 2001 10:28:43 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACISe002154 for ; Mon, 12 Nov 2001 10:28:40 -0800 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 fACIRwB11557; Mon, 12 Nov 2001 10:27:58 -0800 Message-ID: <3BF0145C.9795C8CC@mvista.com> Date: Mon, 12 Nov 2001 10:26:36 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov CC: "Maciej W. Rozycki" , Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: <1005581679.459.4.camel@zeus> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Pete Popov wrote: > > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote: > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > > driver for anyway. > > > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > > > OK, then you need an RTC chipset-specific driver and not a CPU > > architecture-specific one. Otherwise we'll end with a zillion of similar > > RTC drivers like we already have for LANCE and SCC chips. > > I agree. We don't have arch specific network drivers so why have arch > specific rtc drivers. > Because we can have a free RTC driver working once you get kernel working. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 10:30:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIU9U02261 for linux-mips-outgoing; Mon, 12 Nov 2001 10:30:09 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACIU5002258 for ; Mon, 12 Nov 2001 10:30:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA09529 for ; Mon, 12 Nov 2001 10:30:05 -0800 (PST) mail_from (jsun@mvista.com) 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 fACIPvB11448; Mon, 12 Nov 2001 10:25:57 -0800 Message-ID: <3BF013E3.52F45AE9@mvista.com> Date: Mon, 12 Nov 2001 10:24:35 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > driver for anyway. > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > OK, then you need an RTC chipset-specific driver and not a CPU > architecture-specific one. You *can* write a chip specific driver in addition to this generic one if you want. Presumably the chip-specific one provides more operations than just read/write date. > Otherwise we'll end with a zillion of similar > RTC drivers like we already have for LANCE and SCC chips. > Don't quite understand this statement. If everybody uses the generic rtc driver, there will be only one copy of it. It will prevent zillions copies of similar thing. Note that hardware specifics are already abstracted by rtc_set_time() and rtc_get_time() routines. The generic RTC driver makes use of them and has no RTC chip or machine dependent code. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 10:32:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIW3c02359 for linux-mips-outgoing; Mon, 12 Nov 2001 10:32:03 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACIVx002356; Mon, 12 Nov 2001 10:31:59 -0800 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 fACIXGB11827; Mon, 12 Nov 2001 10:33:16 -0800 Message-ID: <3BF0159A.D5DAF75B@mvista.com> Date: Mon, 12 Nov 2001 10:31:54 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: James Simmons , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian References: <3BEC20D5.AD6ABBA6@mvista.com> <20011112231528.D3949@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Fri, Nov 09, 2001 at 10:30:45AM -0800, Jun Sun wrote: > > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > > send him a patch to get rid of it (as if he can't do it himself :-0) ? > > Nope. Somebody could fix isa_{read,write}[bwl] to use isa_slot_offset. > Right now all the ISA functions are broken. So in case you're ISA drivers > seem to work that's the proof that they're broken *evil grin* :-) I doubt if there is any MIPS machine using standard PC ISA bus that is *not* on a PCI bus ... Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 10:51:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACIpOE03169 for linux-mips-outgoing; Mon, 12 Nov 2001 10:51:24 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACIpL003166 for ; Mon, 12 Nov 2001 10:51:21 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fACIqcB12961; Mon, 12 Nov 2001 10:52:38 -0800 Subject: compiler problem From: Pete Popov To: linux-mips , sforge Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 12 Nov 2001 10:53:36 -0800 Message-Id: <1005591216.470.20.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm running into this problem when using the oss.sgi.com toolchain: mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/ppopov/workdir/master/sforge/linux-dev/include -G 0 -mno-abicalls -fno-pic -mcpu=r5000 -mips2 -Wa,--trap -pipe -c entry.S -o entry.o entry.S: Assembler messages: entry.S:180: Error: .previous without corresponding .section; ignored make[1]: *** [entry.o] Error 1 make[1]: Leaving directory `/home/ppopov/workdir/master/sforge/linux-dev/arch/mips/kernel' make: *** [_dir_arch/mips/kernel] Error 2 [ppopov@zeus linux-dev]$ What's the recommended oss binutils version? Pete From owner-linux-mips@oss.sgi.com Mon Nov 12 11:02:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJ2jm03468 for linux-mips-outgoing; Mon, 12 Nov 2001 11:02:45 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJ2Z003463 for ; Mon, 12 Nov 2001 11:02:36 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA10178; Mon, 12 Nov 2001 19:55:37 +0100 (MET) Date: Mon, 12 Nov 2001 19:55:37 +0100 (MET) From: "Maciej W. Rozycki" To: Jun Sun cc: Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <3BF012CA.287A76A@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Jun Sun wrote: > The /dev/rtc interface is highly influenced by MC146818 chip, which not all > RTC devices are alike. The only fundamental thing in the driver is really the > read and write time. You need only to keep the interface, which is: static struct file_operations rtc_fops = { owner: THIS_MODULE, llseek: no_llseek, read: rtc_read, #if RTC_IRQ poll: rtc_poll, #endif ioctl: rtc_ioctl, open: rtc_open, release: rtc_release, fasync: rtc_fasync, }; Of these you probably must only implement open() and ioctl() -- you may provide others as hardware permits -- see how these functions are implemented in drivers/char/rtc.c. The interface is pretty generic, IMHO. > If their abstraction is reasonable, perhaps they can all converge to a better, > more generic rtc interface. Just implement the ioctls given hardware permits and return -EINVAL for others. Again, they are pretty generic: get/set the time, alarm, epoch, disable/enable various interrupts, etc. -- see include/linux/rtc.h. You may propose additional ioctls if they would be useful for particular hardware. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 12 11:03:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJ3kt03543 for linux-mips-outgoing; Mon, 12 Nov 2001 11:03:46 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJ2h003467 for ; Mon, 12 Nov 2001 11:02:43 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05691 for ; Mon, 12 Nov 2001 11:02:43 -0800 (PST) mail_from (jsun@mvista.com) 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 fACIw7B13253; Mon, 12 Nov 2001 10:58:07 -0800 Message-ID: <3BF01B6C.496179@mvista.com> Date: Mon, 12 Nov 2001 10:56:44 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Pete Popov , "Maciej W. Rozycki" , Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: <1005581679.459.4.camel@zeus> <3BF0145C.9795C8CC@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > > Pete Popov wrote: > > > > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote: > > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > > > > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > > > driver for anyway. > > > > > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > > > > > OK, then you need an RTC chipset-specific driver and not a CPU > > > architecture-specific one. Otherwise we'll end with a zillion of similar > > > RTC drivers like we already have for LANCE and SCC chips. > > > > I agree. We don't have arch specific network drivers so why have arch > > specific rtc drivers. > > > > Because we can have a free RTC driver working once you get kernel working. > Actually there is a longer answer with a little bit of the background info. Kernel needs to know about the real calendar time when it boots up. And optionally it may write to RTC (based on the assumption that kernel timer is more accurate than RTC clock). So it already has abstraction, one form or another, to do RTC read/write. Based on these abstractons you can provide a hardware-independent RTC driver, with RTC read/write operations. Before CONFIG_NEW_TIME_C is introduced, each MIPS board has its own time service routine, which means, even if RTC driver wants to utilize the abstraction, it will be only for that board only. After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common. Therefore, we can afford a MIPS-common generic RTC driver. If that abstraction ever becomes Linux-common code, then the generic RTC driver will essentially be a Linux-common, device-indpendent driver. For most MIPS machine, we need /dev/rtc to merely set time and read time. The generic driver should suffice. Otherwire, you can wirte a complete one for a specific board or a specific chip. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 11:04:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJ4i103631 for linux-mips-outgoing; Mon, 12 Nov 2001 11:04:44 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJ4d003627 for ; Mon, 12 Nov 2001 11:04:39 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10536; Mon, 12 Nov 2001 20:04:18 +0100 (MET) Date: Mon, 12 Nov 2001 20:04:17 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jun Sun cc: Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <3BF013E3.52F45AE9@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Jun Sun wrote: > > OK, then you need an RTC chipset-specific driver and not a CPU > > architecture-specific one. > > You *can* write a chip specific driver in addition to this generic one if you > want. Presumably the chip-specific one provides more operations than just > read/write date. Then why make this driver MIPS-specific? > > Otherwise we'll end with a zillion of similar > > RTC drivers like we already have for LANCE and SCC chips. > > Don't quite understand this statement. This assumed you've meant an MC146818 RTC that already has a driver for certain (but possibly not all) configurations. Since you haven't -- just forget it. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 12 11:14:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJEMV03911 for linux-mips-outgoing; Mon, 12 Nov 2001 11:14:22 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJEG003907 for ; Mon, 12 Nov 2001 11:14:16 -0800 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 fACJFDB14315; Mon, 12 Nov 2001 11:15:13 -0800 Message-ID: <3BF01F6F.D64CEA50@mvista.com> Date: Mon, 12 Nov 2001 11:13:51 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Mon, 12 Nov 2001, Jun Sun wrote: > > > The /dev/rtc interface is highly influenced by MC146818 chip, which not all > > RTC devices are alike. The only fundamental thing in the driver is really the > > read and write time. > > You need only to keep the interface, which is: > > static struct file_operations rtc_fops = { > owner: THIS_MODULE, > llseek: no_llseek, > read: rtc_read, > #if RTC_IRQ > poll: rtc_poll, > #endif > ioctl: rtc_ioctl, > open: rtc_open, > release: rtc_release, > fasync: rtc_fasync, > }; > > Of these you probably must only implement open() and ioctl() -- you may > provide others as hardware permits -- see how these functions are > implemented in drivers/char/rtc.c. The interface is pretty generic, IMHO. > > > If their abstraction is reasonable, perhaps they can all converge to a better, > > more generic rtc interface. > > Just implement the ioctls given hardware permits and return -EINVAL for > others. Again, they are pretty generic: get/set the time, alarm, epoch, > disable/enable various interrupts, etc. -- see include/linux/rtc.h. You > may propose additional ioctls if they would be useful for particular > hardware. > Basically agree. Maybe the only thing really missing is a formal way to determine and report the capability of the driver, rather through checking the return value being -EINVAL. I guess my original question to Geert is more on the abstraction of the RTC hardware routines, especially anything beyond rtc_read_time() and rt_write_time(). Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 11:21:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJLoq04121 for linux-mips-outgoing; Mon, 12 Nov 2001 11:21:50 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJLl004118 for ; Mon, 12 Nov 2001 11:21:47 -0800 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 fACJMqB14694; Mon, 12 Nov 2001 11:22:52 -0800 Message-ID: <3BF0213A.CE13CAA1@mvista.com> Date: Mon, 12 Nov 2001 11:21:30 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > > On Mon, 12 Nov 2001, Jun Sun wrote: > > > > OK, then you need an RTC chipset-specific driver and not a CPU > > > architecture-specific one. > > > > You *can* write a chip specific driver in addition to this generic one if you > > want. Presumably the chip-specific one provides more operations than just > > read/write date. > > Then why make this driver MIPS-specific? > I suppose one of my previous replies should answer this. Let me know if it does not. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 11:26:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJQZr04488 for linux-mips-outgoing; Mon, 12 Nov 2001 11:26:35 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJQW004485 for ; Mon, 12 Nov 2001 11:26:32 -0800 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 fACJRlB14946; Mon, 12 Nov 2001 11:27:47 -0800 Message-ID: <3BF02261.CD039BDA@mvista.com> Date: Mon, 12 Nov 2001 11:26:25 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Atsushi Nemoto CC: linux-mips@oss.sgi.com Subject: Re: [RFC] generic MIPS RTC driver References: <20011110231746.B4342@mvista.com> <20011112.104519.126571085.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Atsushi Nemoto wrote: > > >>>>> On Sat, 10 Nov 2001 23:17:46 -0800, Jun Sun said: > jsun> For many MIPS boards that start to use CONFIG_NEW_TIME_C, two > jsun> rtc operations are implemented, rtc_get_time() and > jsun> rtc_set_time(). > jsun> It is possible to write a simple generic RTC driver that is > jsun> based on these two ops and can do simple RTC read&write ops. > ... > jsun> This is the idea behind the generic MIPS rtc driver. See the > jsun> patch below. > ... > jsun> Any comments? > > Good idea. I hope cvs kernel import this patch. > > I found two small things to fix. to_tm function sets 1..12 value in > tm_mon field, so > > 1. in rtc_ioctl (case RTC_RD_TIME), subtracting 1 from rtc_tm.tm_mon > is needed. > > 2. in rtc_proc_output, adding 1 to tm.tm_mon is not needed. > Good eye for spotting this. :-) It turned out that tm_mon in rtc_time struct really should start from 0 to 11 (by definition). So there is a bug in to_tm(). I sent a patch to Ralf and I think he applied already. Jun From owner-linux-mips@oss.sgi.com Mon Nov 12 11:28:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJSko04578 for linux-mips-outgoing; Mon, 12 Nov 2001 11:28:46 -0800 Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJSi004575 for ; Mon, 12 Nov 2001 11:28:44 -0800 Received: from fwd06.sul.t-online.de by mailout03.sul.t-online.de with smtp id 163Ml4-0006Uz-06; Mon, 12 Nov 2001 20:28:38 +0100 Received: from void.s.bawue.de (520095841842-0001@[62.227.2.105]) by fmrl06.sul.t-online.com with esmtp id 163Mkq-0useEiC; Mon, 12 Nov 2001 20:28:24 +0100 Received: from florian by void.s.bawue.de with local (Exim 3.32 #1 (Debian)) id 163NCH-0000OF-00; Mon, 12 Nov 2001 20:56:45 +0100 Date: Mon, 12 Nov 2001 20:56:45 +0100 To: Jun Sun Cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian Message-ID: <20011112205644.B1459@void.s.bawue.de> Mail-Followup-To: Florian Laws , Jun Sun , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net References: <3BEC20D5.AD6ABBA6@mvista.com> <20011112231528.D3949@dea.linux-mips.net> <3BF0159A.D5DAF75B@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF0159A.D5DAF75B@mvista.com> User-Agent: Mutt/1.3.20i From: Florian Laws X-Sender: 520095841842-0001@t-dialin.net Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 10:31:54AM -0800, Jun Sun wrote: > Ralf Baechle wrote: > > > > On Fri, Nov 09, 2001 at 10:30:45AM -0800, Jun Sun wrote: > > > > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > > > send him a patch to get rid of it (as if he can't do it himself :-0) ? > > > > Nope. Somebody could fix isa_{read,write}[bwl] to use isa_slot_offset. > > Right now all the ISA functions are broken. So in case you're ISA drivers > > seem to work that's the proof that they're broken *evil grin* :-) > > I doubt if there is any MIPS machine using standard PC ISA bus that is *not* > on a PCI bus ... FWIW, there is. There are some old Siemens RM400 models (1989 vintage) with R3000 CPU and ISA bus. Pretty unlikely that they'll be supportet any time, though... :-( Florian From owner-linux-mips@oss.sgi.com Mon Nov 12 11:42:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACJgAl05179 for linux-mips-outgoing; Mon, 12 Nov 2001 11:42:10 -0800 Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACJg7005176 for ; Mon, 12 Nov 2001 11:42:07 -0800 Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id NAA25000 for ; Mon, 12 Nov 2001 13:42:06 -0600 (CST) (envelope-from balaji.ramalingam@philips.com) From: balaji.ramalingam@philips.com Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma024996; Mon, 12 Nov 01 13:42:06 -0600 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA20113 for ; Mon, 12 Nov 2001 13:42:11 -0600 (CST) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA23596 for ; Mon, 12 Nov 2001 13:42:11 -0600 (CST) Subject: initrd disabled To: linux-mips@oss.sgi.com Date: Mon, 12 Nov 2001 11:42:45 -0800 Message-ID: X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.5 |September 22, 2000) at 12/11/2001 13:46:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, I have been working in the linux kernel 2.4.3 which was ported for mips32 ISA. I cant understand certain things. The variable max_low_pfn is used to compare the initrd_end. I can see the max_low_pfn being zero and as a result the phys_to_virt(PFN_PHYS(max_low_pfn)) is zero. Hence in the setup_arch, the initrd comparision fails and the initrd is disabled. I get the following messages, Initial ramdisk at: 0x8010e000 (1916920 bytes) initrd extends beyond end of memory (0x802e1ff8 > 0x80000000) disabling initrd I dont know how this variable gets a value. Also I get some messages like the below in the bootmem.c. while accessing the reserve_bootmem function. Is this a kernel BUG or is it something with my hardware? kernel BUG at bootmem.c:84! kernel BUG at bootmem.c:87! kernel BUG at bootmem.c:181! Any help would be greatly appreciated. regards, Balaji From owner-linux-mips@oss.sgi.com Mon Nov 12 12:03:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACK3Z205672 for linux-mips-outgoing; Mon, 12 Nov 2001 12:03:35 -0800 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACK3U005669 for ; Mon, 12 Nov 2001 12:03:30 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id VAA04378; Mon, 12 Nov 2001 21:02:27 +0100 (MET) Date: Mon, 12 Nov 2001 21:02:26 +0100 (MET) From: Geert Uytterhoeven To: Jun Sun cc: "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <3BF012CA.287A76A@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Jun Sun wrote: > Geert Uytterhoeven wrote: > > On Mon, 12 Nov 2001, Maciej W. Rozycki wrote: > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > driver for anyway. > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > > > Geert, what is the abstraction they used? At first sight, we only use get_rtc_time() and mach_hwclk(). > The /dev/rtc interface is highly influenced by MC146818 chip, which not all > RTC devices are alike. The only fundamental thing in the driver is really the > read and write time. > > If their abstraction is reasonable, perhaps they can all converge to a better, > more generic rtc interface. Check out the following files from the m68k CVS tree (see http://linux-m68k-cvs.apia.dhs.org/): - drivers/char/genrtc.c - include/asm-m68k/machdep.h - include/asm-m68k/rtc.h On PPC, they have something similar. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Mon Nov 12 12:55:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACKtT707085 for linux-mips-outgoing; Mon, 12 Nov 2001 12:55:29 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACKtR007082 for ; Mon, 12 Nov 2001 12:55:27 -0800 Received: from scrub.xs4all.nl (scrub.xs4all.nl [194.109.195.176]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id fACKsuWK005696; Mon, 12 Nov 2001 21:54:56 +0100 (CET) Received: from spit.local ([192.168.3.2] ident=mail) by scrub.xs4all.nl with esmtp (Exim 3.12 #1 (Debian)) id 163O6Z-0008JY-00; Mon, 12 Nov 2001 21:54:55 +0100 Received: from localhost ([127.0.0.1] helo=linux-m68k.org ident=roman) by spit.local with esmtp (Exim 3.32 #1 (Debian)) id 163O6Z-0000J0-00; Mon, 12 Nov 2001 21:54:55 +0100 Message-ID: <3BF0371F.8040575B@linux-m68k.org> Date: Mon, 12 Nov 2001 21:54:55 +0100 From: Roman Zippel X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , rz@linux-m68k.org Subject: Re: [RFC] generic MIPS RTC driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Geert Uytterhoeven wrote: > > Geert, what is the abstraction they used? > > At first sight, we only use get_rtc_time() and mach_hwclk(). Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which are now defined in , so mach_hwclk() is gone in the generic part. Another feature is the emulation of the timer interrupt, although I have no idea which program is using this. Richard? bye, Roman From owner-linux-mips@oss.sgi.com Mon Nov 12 13:50:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACLo4v12581 for linux-mips-outgoing; Mon, 12 Nov 2001 13:50:04 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACLo1012578; Mon, 12 Nov 2001 13:50:01 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fACLnWjV031721; Mon, 12 Nov 2001 13:49:32 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fACLnU37031713; Mon, 12 Nov 2001 13:49:30 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 12 Nov 2001 13:49:28 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Jun Sun , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian In-Reply-To: <20011112231528.D3949@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > > send him a patch to get rid of it (as if he can't do it himself :-0) ? > > Nope. Somebody could fix isa_{read,write}[bwl] to use isa_slot_offset. > Right now all the ISA functions are broken. So in case you're ISA drivers > seem to work that's the proof that they're broken *evil grin* :-) I see you fixed this. Thank you :-) From owner-linux-mips@oss.sgi.com Mon Nov 12 13:50:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACLors12638 for linux-mips-outgoing; Mon, 12 Nov 2001 13:50:53 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACLoo012632; Mon, 12 Nov 2001 13:50:50 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fACLoTjV031837; Mon, 12 Nov 2001 13:50:29 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fACLoSo3031833; Mon, 12 Nov 2001 13:50:28 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 12 Nov 2001 13:50:28 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Han-Seong Kim , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Power MGMT on mips In-Reply-To: <20011112233031.A6493@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > 2.If no, how can manage CPU and Bidge chips for power mgnt ? > > Right now Linux/MIPS will only use the CPU's power managment features, that > is the wait instruction or similar. What would be nice that I have been thinking about is making a cpu scale api very similiar to what ARM has. From owner-linux-mips@oss.sgi.com Mon Nov 12 13:52:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fACLq1c12747 for linux-mips-outgoing; Mon, 12 Nov 2001 13:52:01 -0800 Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fACLps012744 for ; Mon, 12 Nov 2001 13:51:54 -0800 Received: from tmrini by opus.bloom.county with local (Exim 3.32 #1 (Debian)) id 163Oz4-0004Dv-00; Mon, 12 Nov 2001 14:51:14 -0700 Date: Mon, 12 Nov 2001 14:51:14 -0700 From: Tom Rini To: Jun Sun Cc: Pete Popov , "Maciej W. Rozycki" , Geert Uytterhoeven , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011112145114.A16216@cpe-24-221-152-185.az.sprintbbd.net> References: <1005581679.459.4.camel@zeus> <3BF0145C.9795C8CC@mvista.com> <3BF01B6C.496179@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF01B6C.496179@mvista.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 10:56:44AM -0800, Jun Sun wrote: > Jun Sun wrote: > > > > Pete Popov wrote: > > > > > > On Mon, 2001-11-12 at 05:29, Maciej W. Rozycki wrote: > > > > On Mon, 12 Nov 2001, Geert Uytterhoeven wrote: > > > > > > > > > > Unless you use a non-MC146818 RTC, which you need to write a separate > > > > > > driver for anyway. > > > > > > > > > > Yep, so that's why both m68k and PPC have common routines to read/write the > > > > > RTC, with a /dev/rtc-compatible abstraction on top of it. > > > > > > > > OK, then you need an RTC chipset-specific driver and not a CPU > > > > architecture-specific one. Otherwise we'll end with a zillion of similar > > > > RTC drivers like we already have for LANCE and SCC chips. > > > > > > I agree. We don't have arch specific network drivers so why have arch > > > specific rtc drivers. > > > > > > > Because we can have a free RTC driver working once you get kernel working. > > > > Actually there is a longer answer with a little bit of the background info. > > Kernel needs to know about the real calendar time when it boots up. And > optionally it may write to RTC (based on the assumption that kernel timer is > more accurate than RTC clock). So it already has abstraction, one form or > another, to do RTC read/write. > > Based on these abstractons you can provide a hardware-independent RTC driver, > with RTC read/write operations. Right. > Before CONFIG_NEW_TIME_C is introduced, each MIPS board has its own time > service routine, which means, even if RTC driver wants to utilize the > abstraction, it will be only for that board only. > > After CONFIG_NEW_TIME_C is introduced, that RTC abstract becomes MIPS-common. > Therefore, we can afford a MIPS-common generic RTC driver. No. This sounds _exactly_ like the PPC driver. What we need to do, and what I intend to do in 2.5 is make this a bit more generic so thatr any arch can fill out some infos and say we read like this, we write like that and that's that. > If that abstraction ever becomes Linux-common code, then the generic RTC > driver will essentially be a Linux-common, device-indpendent driver. Yeap. I wanna do this in 2.5. > For most MIPS machine, we need /dev/rtc to merely set time and read time. The > generic driver should suffice. Otherwire, you can wirte a complete one for a > specific board or a specific chip. The 'rtc' driver in drivers/char does read, write, some ioctls and a /proc bit. We can make this a bit more 'generic' -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From owner-linux-mips@oss.sgi.com Mon Nov 12 17:32:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD1Wg920184 for linux-mips-outgoing; Mon, 12 Nov 2001 17:32:42 -0800 Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD1Wb020181 for ; Mon, 12 Nov 2001 17:32:38 -0800 Received: from tmrini by opus.bloom.county with local (Exim 3.32 #1 (Debian)) id 163SQg-0004Jb-00; Mon, 12 Nov 2001 18:31:58 -0700 Date: Mon, 12 Nov 2001 18:31:58 -0700 From: Tom Rini To: Roman Zippel Cc: Geert Uytterhoeven , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , rz@linux-m68k.org Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011112183158.C16490@cpe-24-221-152-185.az.sprintbbd.net> References: <3BF0371F.8040575B@linux-m68k.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF0371F.8040575B@linux-m68k.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote: > > Hi, > > Geert Uytterhoeven wrote: > > > > Geert, what is the abstraction they used? > > > > At first sight, we only use get_rtc_time() and mach_hwclk(). > > Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which > are now defined in , so mach_hwclk() is gone in the generic > part. Could you please post a copy of this? I wanna go and try and get the rest of the PPC world going on it, if you didn't do that already. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From owner-linux-mips@oss.sgi.com Mon Nov 12 21:18:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD5IQN27095 for linux-mips-outgoing; Mon, 12 Nov 2001 21:18:26 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAD5IN027088 for ; Mon, 12 Nov 2001 21:18:23 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fACNubA09148; Tue, 13 Nov 2001 10:56:37 +1100 Date: Tue, 13 Nov 2001 10:56:37 +1100 From: Ralf Baechle To: Jun Sun Cc: James Simmons , Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel]Re: i8259.c in big endian Message-ID: <20011113105637.C5274@dea.linux-mips.net> References: <3BEC20D5.AD6ABBA6@mvista.com> <20011112231528.D3949@dea.linux-mips.net> <3BF0159A.D5DAF75B@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF0159A.D5DAF75B@mvista.com>; from jsun@mvista.com on Mon, Nov 12, 2001 at 10:31:54AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 10:31:54AM -0800, Jun Sun wrote: > > > isa_slot_offset is an obselete garbage. Can someone do Ralf's a favor and > > > send him a patch to get rid of it (as if he can't do it himself :-0) ? > > > > Nope. Somebody could fix isa_{read,write}[bwl] to use isa_slot_offset. > > Right now all the ISA functions are broken. So in case you're ISA drivers > > seem to work that's the proof that they're broken *evil grin* :-) > > I doubt if there is any MIPS machine using standard PC ISA bus that is *not* > on a PCI bus ... Many more than you'd ever want to support :-( And yes, EISA and VLB bus also. I even heared the rumour about SBUS in MIPS machines. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 12 22:22:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAD6ML328242 for linux-mips-outgoing; Mon, 12 Nov 2001 22:22:21 -0800 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAD6MH028239 for ; Mon, 12 Nov 2001 22:22:18 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id HAA01510; Tue, 13 Nov 2001 07:20:51 +0100 (MET) Date: Tue, 13 Nov 2001 07:20:51 +0100 (MET) From: Geert Uytterhoeven To: Tom Rini cc: Roman Zippel , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , rz@linux-m68k.org Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <20011112183158.C16490@cpe-24-221-152-185.az.sprintbbd.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 12 Nov 2001, Tom Rini wrote: > On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote: > > Geert Uytterhoeven wrote: > > > > Geert, what is the abstraction they used? > > > > > > At first sight, we only use get_rtc_time() and mach_hwclk(). > > > > Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which > > are now defined in , so mach_hwclk() is gone in the generic > > part. > > Could you please post a copy of this? I wanna go and try and get the > rest of the PPC world going on it, if you didn't do that already. http://linux-m68k-cvs.apia.dhs.org/ Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Nov 13 02:16:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADAGhK00526 for linux-mips-outgoing; Tue, 13 Nov 2001 02:16:43 -0800 Received: from prozac.medialincs.com ([210.126.9.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADAGf000523 for ; Tue, 13 Nov 2001 02:16:41 -0800 Received: from joey.medialincs.com (joey.medialincs.com [210.126.9.86]) by prozac.medialincs.com (8.11.6/8.11.2) with ESMTP id fAD9Lc806490 for ; Tue, 13 Nov 2001 18:21:38 +0900 Received: by joey.medialincs.com (Postfix, from userid 500) id D97B0E65F; Tue, 13 Nov 2001 18:21:19 +0900 (KST) Date: Tue, 13 Nov 2001 18:21:19 +0900 From: "Joe Y." To: linux-mips@oss.sgi.com Subject: gt-64120 bootloader?? Message-ID: <20011113092119.GA7142@medialincs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline User-Agent: Mutt/1.3.23.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk anyone know bootloader for the galileo 64120 board ? PMON or redboot is not support gt-64120.. I looking for having ability to load linux. if you have any experience, inform to me. thanks. From owner-linux-mips@oss.sgi.com Tue Nov 13 06:10:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEAsY13558 for linux-mips-outgoing; Tue, 13 Nov 2001 06:10:54 -0800 Received: from faui02.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEAo013554 for ; Tue, 13 Nov 2001 06:10:51 -0800 Received: from rz.de (root@faui02b.informatik.uni-erlangen.de [131.188.30.151]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id PAA07216; Tue, 13 Nov 2001 15:10:32 +0100 (MET) Received: (from rz@localhost) by rz.de (8.8.8/8.8.8) id OAA00775; Tue, 13 Nov 2001 14:42:40 +0100 Date: Tue, 13 Nov 2001 14:42:40 +0100 From: Richard Zidlicky To: Roman Zippel Cc: Geert Uytterhoeven , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011113144240.B669@linux-m68k.org> References: <3BF0371F.8040575B@linux-m68k.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF0371F.8040575B@linux-m68k.org>; from zippel@linux-m68k.org on Mon, Nov 12, 2001 at 09:54:55PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote: > Hi, > > Geert Uytterhoeven wrote: > > > > Geert, what is the abstraction they used? > > > > At first sight, we only use get_rtc_time() and mach_hwclk(). > > Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which > are now defined in , so mach_hwclk() is gone in the generic > part. > Another feature is the emulation of the timer interrupt, although I have > no idea which program is using this. hwclock and a bunch of less known porgrams like chrony. Where the interrupt can be generated its a clear win, otherwise it might be more reasonable to return EINVAL instead of trying to emulate it - presumably hwclock can use some fallback method. Btw the interrupt need not to be hardware, for the Q40 I test a rtc register once per jiffie and generate a "soft interrupt". It could be done generic at least for m68k. Bye Richard From owner-linux-mips@oss.sgi.com Tue Nov 13 06:45:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEjQW14964 for linux-mips-outgoing; Tue, 13 Nov 2001 06:45:26 -0800 Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEjN014961 for ; Tue, 13 Nov 2001 06:45:23 -0800 Received: from tmrini by opus.bloom.county with local (Exim 3.32 #1 (Debian)) id 163enY-0004mV-00; Tue, 13 Nov 2001 07:44:24 -0700 Date: Tue, 13 Nov 2001 07:44:24 -0700 From: Tom Rini To: Geert Uytterhoeven Cc: Roman Zippel , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , rz@linux-m68k.org Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011113074424.A16723@cpe-24-221-152-185.az.sprintbbd.net> References: <20011112183158.C16490@cpe-24-221-152-185.az.sprintbbd.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 07:20:51AM +0100, Geert Uytterhoeven wrote: > On Mon, 12 Nov 2001, Tom Rini wrote: > > On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote: > > > Geert Uytterhoeven wrote: > > > > > Geert, what is the abstraction they used? > > > > > > > > At first sight, we only use get_rtc_time() and mach_hwclk(). > > > > > > Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which > > > are now defined in , so mach_hwclk() is gone in the generic > > > part. > > > > Could you please post a copy of this? I wanna go and try and get the > > rest of the PPC world going on it, if you didn't do that already. > > http://linux-m68k-cvs.apia.dhs.org/ That's the non-generic m68k version tho, yes? Or did Roman do it in that tree too? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From owner-linux-mips@oss.sgi.com Tue Nov 13 06:48:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEmfN15068 for linux-mips-outgoing; Tue, 13 Nov 2001 06:48:41 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEmX015065 for ; Tue, 13 Nov 2001 06:48:34 -0800 Received: from [192.168.1.179] (192.168.1.179 [192.168.1.179]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN57D; Tue, 13 Nov 2001 09:48:20 -0500 Subject: Re: BE Toolchain From: Marc Karasek To: Dan Temple Cc: Linux MIPS In-Reply-To: <3BE2A852.AFF0D905@mips.com> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 13 Nov 2001 09:49:20 -0500 Message-Id: <1005662974.10352.2.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have one question: I did not know that RH had a MIPS dist for 7.1. Is this something MIPS has done from the RH sources? Or is RH planning on supporting MIPS now? On Fri, 2001-11-02 at 09:06, Dan Temple wrote: > Marc Karasek wrote: > > > > Has anyone got the toolchain (binutils, gcc, glibc) to compile under > > BE? I followed the instructions at Bradley D. LaRonde has put together > > and got the LE to work w/o a prolem. I then proceeded to try the BE. > > Binutils compiled ok, gcc says that mipseb-linux is not a valid target. > > Looking in config.sub I saw a mips-linux, is this the BE option? > > If you can wait a day, here's what we use - which is compilable both BE and LE: > > We are going to release a complete RH7.1/MIPS installation image for the Atlas/Malta board on our FTP site, identical to what we use in MIPS engineering.All of our compiles for Linux/MIPS (except the kernel, which is probably irrelevant here) are done natively on Malta boards running Linux. We are using the compiler from the RedHat 7.1/MIPS Linux distribution. > > The toolchains on this distribution are (all commands run natively on > the installation on a Malta board): > > > uname -a > Linux copmld07.mips.com 2.4.3-MIPS-01.02 > > > gcc -v > Reading specs from /usr/lib/gcc-lib/mipsel-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1) > > > rpm -qf /usr/bin/ld > binutils-2.11.92.0.10-1 > > > rpm -qa | grep glibc > glibc-2.2.4-19.4 > glibc-common-2.2.4-19.4 > glibc-devel-2.2.4-19.4 > glibc-profile-2.2.4-19.4 > > Dan Temple > MIPS Denmark -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Tue Nov 13 06:49:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADEnnu15149 for linux-mips-outgoing; Tue, 13 Nov 2001 06:49:49 -0800 Received: from mail.sonytel.be (main.sonytel.be [195.0.45.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADEnj015145 for ; Tue, 13 Nov 2001 06:49:45 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA05096; Tue, 13 Nov 2001 15:47:54 +0100 (MET) Date: Tue, 13 Nov 2001 15:47:53 +0100 (MET) From: Geert Uytterhoeven To: Tom Rini cc: Roman Zippel , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , rz@linux-m68k.org Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <20011113074424.A16723@cpe-24-221-152-185.az.sprintbbd.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 13 Nov 2001, Tom Rini wrote: > On Tue, Nov 13, 2001 at 07:20:51AM +0100, Geert Uytterhoeven wrote: > > On Mon, 12 Nov 2001, Tom Rini wrote: > > > On Mon, Nov 12, 2001 at 09:54:55PM +0100, Roman Zippel wrote: > > > > Geert Uytterhoeven wrote: > > > > > > Geert, what is the abstraction they used? > > > > > > > > > > At first sight, we only use get_rtc_time() and mach_hwclk(). > > > > > > > > Over the weekend I changed it into set_rtc_time()/get_rtc_time(), which > > > > are now defined in , so mach_hwclk() is gone in the generic > > > > part. > > > > > > Could you please post a copy of this? I wanna go and try and get the > > > rest of the PPC world going on it, if you didn't do that already. > > > > http://linux-m68k-cvs.apia.dhs.org/ > > That's the non-generic m68k version tho, yes? Or did Roman do it in > that tree too? That's the real one. On Q40/Q60 it provides some additional features, though. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Tue Nov 13 07:30:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFUtT30220 for linux-mips-outgoing; Tue, 13 Nov 2001 07:30:55 -0800 Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFUr030190 for ; Tue, 13 Nov 2001 07:30:53 -0800 Received: from scrub.xs4all.nl (scrub.xs4all.nl [194.109.195.176]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id fADFUP3E052723; Tue, 13 Nov 2001 16:30:26 +0100 (CET) Received: from roman (helo=localhost) by scrub.xs4all.nl with local-esmtp (Exim 3.12 #1 (Debian)) id 163fW4-00010K-00; Tue, 13 Nov 2001 16:30:24 +0100 Date: Tue, 13 Nov 2001 16:30:24 +0100 (CET) From: Roman Zippel X-X-Sender: To: Tom Rini cc: Geert Uytterhoeven , Roman Zippel , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development , Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <20011113074424.A16723@cpe-24-221-152-185.az.sprintbbd.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, On Tue, 13 Nov 2001, Tom Rini wrote: > > http://linux-m68k-cvs.apia.dhs.org/ > > That's the non-generic m68k version tho, yes? Or did Roman do it in > that tree too? That version is even more recent than the one currently in the APUS repository. :) But I tested it also under APUS, so you only need to provide [gs]et_rtc_time and it should work. bye, Roman From owner-linux-mips@oss.sgi.com Tue Nov 13 07:33:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFX0A30403 for linux-mips-outgoing; Tue, 13 Nov 2001 07:33:00 -0800 Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFWw030400 for ; Tue, 13 Nov 2001 07:32:58 -0800 Received: from scrub.xs4all.nl (scrub.xs4all.nl [194.109.195.176]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id fADFWrIr003024; Tue, 13 Nov 2001 16:32:55 +0100 (CET) Received: from roman (helo=localhost) by scrub.xs4all.nl with local-esmtp (Exim 3.12 #1 (Debian)) id 163fYI-00010M-00; Tue, 13 Nov 2001 16:32:42 +0100 Date: Tue, 13 Nov 2001 16:32:42 +0100 (CET) From: Roman Zippel X-X-Sender: To: Richard Zidlicky cc: Roman Zippel , Geert Uytterhoeven , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver In-Reply-To: <20011113144240.B669@linux-m68k.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, On Tue, 13 Nov 2001, Richard Zidlicky wrote: > hwclock and a bunch of less known porgrams like chrony. I was playing with chrony, but it was unable to adjust the time, last weekend I switched back to ntp and that works better. bye, Roman From owner-linux-mips@oss.sgi.com Tue Nov 13 07:55:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADFtoV05016 for linux-mips-outgoing; Tue, 13 Nov 2001 07:55:50 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADFtk005013 for ; Tue, 13 Nov 2001 07:55:46 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id EEA72125C0; Tue, 13 Nov 2001 07:55:43 -0800 (PST) Date: Tue, 13 Nov 2001 07:55:43 -0800 From: "H . J . Lu" To: Marc Karasek Cc: Dan Temple , Linux MIPS Subject: Re: BE Toolchain Message-ID: <20011113075543.A30676@lucon.org> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1005662974.10352.2.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Tue, Nov 13, 2001 at 09:49:20AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 09:49:20AM -0500, Marc Karasek wrote: > I have one question: I did not know that RH had a MIPS dist for 7.1. > Is this something MIPS has done from the RH sources? Or is RH planning > on supporting MIPS now? > Red Hat doesn't have a mips port. It is me who ported RedHat 7.1 to mips. H.J. --- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You may need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Tue Nov 13 08:16:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADGGUJ08479 for linux-mips-outgoing; Tue, 13 Nov 2001 08:16:30 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADGGO008470 for ; Tue, 13 Nov 2001 08:16:24 -0800 Received: from [192.168.1.179] (192.168.1.179 [192.168.1.179]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN591; Tue, 13 Nov 2001 11:16:17 -0500 Subject: Re: BE Toolchain From: Marc Karasek To: "H . J . Lu" Cc: Dan Temple , Linux MIPS In-Reply-To: <20011113075543.A30676@lucon.org> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> <20011113075543.A30676@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.16.99+cvs.2001.10.18.15.19 (Preview Release) Date: 13 Nov 2001 11:17:09 -0500 Message-Id: <1005668252.19178.52.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I was refering to a formal (supported) release from RH. Something I can pay RH to get support for. On Tue, 2001-11-13 at 10:55, H . J . Lu wrote: > On Tue, Nov 13, 2001 at 09:49:20AM -0500, Marc Karasek wrote: > > I have one question: I did not know that RH had a MIPS dist for 7.1. > > Is this something MIPS has done from the RH sources? Or is RH planning > > on supporting MIPS now? > > > > Red Hat doesn't have a mips port. It is me who ported RedHat 7.1 to > mips. > > > H.J. > --- > My mini-port of RedHat 7.1 is at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > you should be able to put a small RedHat 7.1 on the mips/mipsel box and > compile the rest of RedHat 7.1 yourselves. > > Here are something you should know: > > 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a > toolchain rpm. The binary rpms for the mips and mipsel cross compilers > are included. You may need glibc 2.2.3-11 or above to use those > rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. > 2. You have to find a way to put those rpms on your machine. I use > network boot and NFS root to do it. > 3. install.tar.bz2 has some scripts to prepare NFS root and install > RedHat 7.1 on a hard drive. > 4. baseline.tar.bz2 contains the cross build tree. > 5. Since everything is cross compiled from x86, which is little endian, > many data files for mips, which is big endian, are either missing or > wrong. To get those data files for mips, you have to rebuild/install > the folowing rpms: > > cracklib > glibc > > natively on Linux/mips. > > Thanks. > > > H.J. -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Tue Nov 13 08:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADGU4F09122 for linux-mips-outgoing; Tue, 13 Nov 2001 08:30:04 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADGU2009119 for ; Tue, 13 Nov 2001 08:30:02 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 49154125C0; Tue, 13 Nov 2001 08:30:01 -0800 (PST) Date: Tue, 13 Nov 2001 08:30:01 -0800 From: "H . J . Lu" To: Marc Karasek Cc: Dan Temple , Linux MIPS Subject: Re: BE Toolchain Message-ID: <20011113083001.A31208@lucon.org> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> <20011113075543.A30676@lucon.org> <1005668252.19178.52.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1005668252.19178.52.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Tue, Nov 13, 2001 at 11:17:09AM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 11:17:09AM -0500, Marc Karasek wrote: > I was refering to a formal (supported) release from RH. Something I can > pay RH to get support for. > You can ask Red Hat about it. I offered my mips port to Red Hat before. But it didn't get very far. Paying customers may change that :-(. On the other hand, I can understand why Red Hat is not interested. I am having trouble to maintain my port. I don't have a fast, stable mips machine to work on. H.J. From owner-linux-mips@oss.sgi.com Tue Nov 13 08:38:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADGcBq09239 for linux-mips-outgoing; Tue, 13 Nov 2001 08:38:11 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADGc8009236 for ; Tue, 13 Nov 2001 08:38:09 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 163ggf-0001d8-00; Tue, 13 Nov 2001 16:45:25 +0000 Subject: Re: BE Toolchain To: marc_karasek@ivivity.com (Marc Karasek) Date: Tue, 13 Nov 2001 16:45:25 +0000 (GMT) Cc: hjl@lucon.org (H . J . Lu), dant@mips.com (Dan Temple), linux-mips@oss.sgi.com (Linux MIPS) In-Reply-To: <1005668252.19178.52.camel@localhost.localdomain> from "Marc Karasek" at Nov 13, 2001 11:17:09 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I was refering to a formal (supported) release from RH. Something I can > pay RH to get support for. Maintaining an entire distribution support for a processor is not a cheap business. It would depend if enough people actually wanted to buy it. I suspect for smaller volumes you want to pay Ralf, HJ or someone rather than try and fund an entire general distro port. We do plenty of MIPS stuff in the embedded and contract side so it would depend what you wanted Alan From owner-linux-mips@oss.sgi.com Tue Nov 13 09:49:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADHnJk14119 for linux-mips-outgoing; Tue, 13 Nov 2001 09:49:19 -0800 Received: from smtp.psdc.com (smtp.psdc.com [209.125.203.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADHnH014116 for ; Tue, 13 Nov 2001 09:49:17 -0800 Received: (from ex2k [172.19.1.1]) by smtp.psdc.com (NAVGW 2.5.1.13) with SMTP id M2001111309494417238 for ; Tue, 13 Nov 2001 09:49:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Which package rc.sysinit is in? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Date: Tue, 13 Nov 2001 09:44:05 -0800 Message-ID: <84CE342693F11946B9F54B18C1AB837B14AEBD@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Which package rc.sysinit is in? Thread-Index: AcFsaslJjm1dFUFqRI2pqdJUOlSDfA== From: "Steven Liu" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fADHnH014117 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All: With your help, I have cross-built and tested the util-linux-2.9s package for my mips r3000 CPU under linux-2.2.12. The system crushed in the program rc.sysinit with pid=8 when it was booting up. What and where is rc.sysinit? Thanks, Steven Liu From owner-linux-mips@oss.sgi.com Tue Nov 13 10:00:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADI0Kk14525 for linux-mips-outgoing; Tue, 13 Nov 2001 10:00:20 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADI0H014521 for ; Tue, 13 Nov 2001 10:00:17 -0800 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 fADI05B08683; Tue, 13 Nov 2001 10:00:05 -0800 Message-ID: <3BF15F55.AABB383C@mvista.com> Date: Tue, 13 Nov 2001 09:58:45 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Richard Zidlicky CC: Roman Zippel , Geert Uytterhoeven , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: <3BF0371F.8040575B@linux-m68k.org> <20011113144240.B669@linux-m68k.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Richard Zidlicky wrote: > Btw the interrupt need not to be hardware, for the Q40 I test > a rtc register once per jiffie and generate a "soft interrupt". > It could be done generic at least for m68k. > I have written an experiemntal ptimer driver to do just this and potential more. Such a device is useful for real-time programming (e.g., when you try to implement a periodic user task). See http://linux.junsun.net/realtime-linux/preemption-test The driver is architecture independent (i.e., linux-common code) Due to the different programming needs behind periodic timers (or user-level timer) and RTC operations, my vote for future work is to leave them as two separate drivers. To me, RTC is really just to read/write RTC clock. Jun From owner-linux-mips@oss.sgi.com Tue Nov 13 11:20:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADJKma22906 for linux-mips-outgoing; Tue, 13 Nov 2001 11:20:48 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADJKk022903 for ; Tue, 13 Nov 2001 11:20:46 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fADJLjB13741; Tue, 13 Nov 2001 11:21:45 -0800 Subject: Re: gt-64120 bootloader?? From: Pete Popov To: "Joe Y." Cc: linux-mips In-Reply-To: <20011113092119.GA7142@medialincs.com> References: <20011113092119.GA7142@medialincs.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 13 Nov 2001 11:22:58 -0800 Message-Id: <1005679378.29107.18.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2001-11-13 at 01:21, Joe Y. wrote: > anyone know bootloader for the galileo 64120 board ? > > PMON or redboot is not support gt-64120.. > > I looking for having ability to load linux. > > if you have any experience, inform to me. If it's one of Galileo's eval boards, it should have pmon running on it already. Unfortunately their pmon only supports serial port downloads of srec files, so it takes about 6 minutes to download the kernel. Pete From owner-linux-mips@oss.sgi.com Tue Nov 13 11:38:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADJcXj23159 for linux-mips-outgoing; Tue, 13 Nov 2001 11:38:33 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADJcQ023152 for ; Tue, 13 Nov 2001 11:38:26 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA09684 for ; Tue, 13 Nov 2001 11:38:18 -0800 (PST) mail_from (ppopov@mvista.com) Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fADJT7B14108; Tue, 13 Nov 2001 11:29:08 -0800 Subject: Re: BE Toolchain From: Pete Popov To: Marc Karasek Cc: "H . J . Lu" , Dan Temple , Linux MIPS In-Reply-To: <1005668252.19178.52.camel@localhost.localdomain> References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> <20011113075543.A30676@lucon.org> <1005668252.19178.52.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 13 Nov 2001 11:30:21 -0800 Message-Id: <1005679821.29107.23.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2001-11-13 at 08:17, Marc Karasek wrote: > I was refering to a formal (supported) release from RH. Something I can > pay RH to get support for. It's hard to make money off of a $60 distribution if you don't have enough volume, and there isn't enough volume for a mips desktop distribution. If you're talking about embedded linux support, Hard Hat Linux from MontaVista runs on mips, sh, x86, ppc, xscale, and SA. But we're talking about thousands of dollars for a product subscription. If you don't want to pay that type of money for support, I think H.J. Lu has done a tremendous job in porting rh71, and you always have the mailing lists. Pete > On Tue, 2001-11-13 at 10:55, H . J . Lu wrote: > > On Tue, Nov 13, 2001 at 09:49:20AM -0500, Marc Karasek wrote: > > > I have one question: I did not know that RH had a MIPS dist for 7.1. > > > Is this something MIPS has done from the RH sources? Or is RH planning > > > on supporting MIPS now? > > > > > > > Red Hat doesn't have a mips port. It is me who ported RedHat 7.1 to > > mips. > > > > > > H.J. > > --- > > My mini-port of RedHat 7.1 is at > > > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > > > you should be able to put a small RedHat 7.1 on the mips/mipsel box and > > compile the rest of RedHat 7.1 yourselves. > > > > Here are something you should know: > > > > 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a > > toolchain rpm. The binary rpms for the mips and mipsel cross compilers > > are included. You may need glibc 2.2.3-11 or above to use those > > rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. > > 2. You have to find a way to put those rpms on your machine. I use > > network boot and NFS root to do it. > > 3. install.tar.bz2 has some scripts to prepare NFS root and install > > RedHat 7.1 on a hard drive. > > 4. baseline.tar.bz2 contains the cross build tree. > > 5. Since everything is cross compiled from x86, which is little endian, > > many data files for mips, which is big endian, are either missing or > > wrong. To get those data files for mips, you have to rebuild/install > > the folowing rpms: > > > > cracklib > > glibc > > > > natively on Linux/mips. > > > > Thanks. > > > > > > H.J. > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > (770) 986-8925 > (770) 986-8926 Fax > *************************/ > From owner-linux-mips@oss.sgi.com Tue Nov 13 11:53:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADJrp723467 for linux-mips-outgoing; Tue, 13 Nov 2001 11:53:51 -0800 Received: from host099.momenco.com (IDENT:root@host099.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADJrl023460 for ; Tue, 13 Nov 2001 11:53:47 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.0) with SMTP id fADJrNi26154; Tue, 13 Nov 2001 11:53:23 -0800 From: "Matthew Dharm" To: "Joe Y." , Subject: RE: gt-64120 bootloader?? Date: Tue, 13 Nov 2001 11:53:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011113092119.GA7142@medialincs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Do you mean the Gallileo EV-64120 board? AFAIK, that comes with PMON. We make a GT-64120 based board with Linux support, and we use a customized version of PMON and RedBoot for that board. Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Joe Y. > Sent: Tuesday, November 13, 2001 1:21 AM > To: linux-mips@oss.sgi.com > Subject: gt-64120 bootloader?? > > > anyone know bootloader for the galileo 64120 board ? > > PMON or redboot is not support gt-64120.. > > I looking for having ability to load linux. > > if you have any experience, inform to me. > > thanks. > From owner-linux-mips@oss.sgi.com Tue Nov 13 12:09:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADK9q224118 for linux-mips-outgoing; Tue, 13 Nov 2001 12:09:52 -0800 Received: from web11908.mail.yahoo.com (web11908.mail.yahoo.com [216.136.172.192]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADK9m024115 for ; Tue, 13 Nov 2001 12:09:49 -0800 Message-ID: <20011113200948.75977.qmail@web11908.mail.yahoo.com> Received: from [209.243.184.191] by web11908.mail.yahoo.com via HTTP; Tue, 13 Nov 2001 12:09:48 PST Date: Tue, 13 Nov 2001 12:09:48 -0800 (PST) From: Wayne Gowcher Subject: ld error " linking PIC files with non-PIC files " To: linux-mips@oss.sgi.com In-Reply-To: <20011026161259.54925.qmail@web11908.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to cross compile X using the redhat7.0 distribution from the sgi mips site as my base. Most files compile OK, but they fail at the link stage with the following error : linking PIC files with non-PIC files. I created my cross-compile library files in /usr/mipsel-linux from the packages : glibc-2.2.2-1.mipsel.rpm & glibc-devel-2.2.2-1.mipsel.rpm are there other libraries I need ? I found a reference on the web to a module called libc6-pic.o, I don't see this anywhere in my libraries is this what I need ? Has anyone else seen this problem before and do they know how to fix it ? TIA Wayne __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-linux-mips@oss.sgi.com Tue Nov 13 15:36:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADNau228664 for linux-mips-outgoing; Tue, 13 Nov 2001 15:36:56 -0800 Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADNai028657 for ; Tue, 13 Nov 2001 15:36:44 -0800 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fADNacu21287; Tue, 13 Nov 2001 15:36:38 -0800 Received: from newton.sanera.net (newton.sanera.net [172.16.2.11]) by icarus.sanera.net (8.11.6/8.11.2) with ESMTP id fADNaXu07839; Tue, 13 Nov 2001 15:36:33 -0800 Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by newton.sanera.net (8.11.4/8.11.4) with ESMTP id fADNaUM23719; Tue, 13 Nov 2001 15:36:30 -0800 (PST) Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by exceed1.sanera.net (8.9.3+Sun/8.9.3) with SMTP id PAA06294; Tue, 13 Nov 2001 15:36:32 -0800 (PST) Message-Id: <200111132336.PAA06294@exceed1.sanera.net> Date: Tue, 13 Nov 2001 15:36:32 -0800 (PST) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel To: ralf@gnu.org, linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LSH7x1WXZ/9lJOHbdoVjeQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Here is the bug we found in the Linux 2.4.2 MIPS SMP kernel and the fix for the bug. 1. Summary: Memory leak in Linux 2.4.2 MIPS SMP kernel 2. Description: Memory leak happens whenever a process is created and destroyed. Whatever memory allocated during process creation is not getting freed when the process exits. This problem can be easily reproduced by writing any program/script which does a lot of process creation and termination. my test script is while true do cat /proc/meminfo ls /bin cat /proc/slabinfo end when /proc/slabinfo is printed, we can see that size of 32-byte memory chunks growing indefinitely and eventually causing the following panic: kernel BUG at page_alloc.c:75! Unable to handle kernel paging request at virtual address 00000000, epc == 8013bcdc, ra == 8013bcdc Oops in fault.c:do_page_fault, line 172: $0 : 00000000 10009f00 0000001f 0000000a $4 : 802afc10 00000001 00000001 00000000 $8 : 802d7636 b0060170 0000001f 0000000d $12: 00000000 0000001f 10009f00 0000000a $16: 80329f50 80329f50 00000000 00657a03 $20: 8053000c 806451a0 80b785a0 ffc00000 $24: 802d7617 8036dca1 $28: 8036c000 8036de08 806451a0 8013bcdc epc : 000000008013bcdc Status : 10009f03 Cause : 1080000c BadAddr: 00000000ffc00000Process kswapd (pid: 5, stackpage=8036c000) Stack: 80253434 8025344c 0000004b 00000001 806451a0 00403000 80329f50 00403000 00000001 00657a03 8053000c 806451a0 80b785a0 ffc00000 806451a0 8013cba8 00403000 00000000 80329f50 00403000 801395fc 8013967c 00000000 00000000 00000000 00000000 00000000 00000000 00657a03 00000000 00000000 00000000 00000000 00000000 00403000 8053000c 00000007 00424000 80b785a0 806451a0 ffc00000 ... Call Trace: [<80253434>] [<8025344c>] [<8013cba8>] [<801395fc>] [<8013967c>] [<801398b8>] [<801399d8>] [<80139ab0>] [<80136a30>] [<8013b42c>] [<80139c1c>] [<80139c24>] [<80162fa8>] [<8013b3e8>] [<8013b4a0>] [<8013b524>] [<8013b55c>] [<80107d38>] [<80108d9c>] [<80108d8c>] 3. Keywords mips, SMP, memory leak 4. Kernel version Linux version 2.4.2 5. Output (included as part of description) 6. testcase (included as part of description) 7. Environment 7.1 software None 7.2 Processor info (NOTE *** cat /proc/cpuinfo does not print information about both the CPUs ***) cpu : MIPS processor : 0 cpu model : SiByte SB1 V0.1 BogoMIPS : 332.59 processor : 1 cpu model : SiByte SB1 V0.1 BogoMIPS : 332.59 system type : SiByte unknown byteorder : big endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : yes hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available 7.3 Module information No modules. 7.4 Loaded driver and hardware information (/proc/ioports, /proc/iomem) bash-2.04# cat /proc/ioports bash-2.04# cat /proc/iomem 00000000-0fe94fff : System RAM 00100000-00267d77 : Kernel code 00299a40-002ad38f : Kernel data 7.5 PCI information No PCI devices attached 7.6 SCSI information No SCSI devices attached 7.7 Other information 8. Fix I found that the bug is in destroy_context() in include/asm-mips/mmu_context.h. destroy_context() is supposed to kfree() the memory that is allocated by init_new_context() but it is not doing that. I modified destroy_context as follows: /* * Destroy context related info for an mm_struct that is about * to be put to rest. */ extern inline void destroy_context(struct mm_struct *mm) { #ifdef CONFIG_SMP kfree((void *)mm->context); #else /* Nothing to do. */ #endif } And when I tested this I do not see the memory leak any more. Krishna Kondaka Sanera Systems Inc. krishna@sanera.net From owner-linux-mips@oss.sgi.com Tue Nov 13 15:42:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADNgeX28816 for linux-mips-outgoing; Tue, 13 Nov 2001 15:42:40 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fADNgb028812 for ; Tue, 13 Nov 2001 15:42:37 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fADNgSjR027307; Tue, 13 Nov 2001 15:42:28 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fADNgRcq027303; Tue, 13 Nov 2001 15:42:27 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 13 Nov 2001 15:42:26 -0800 (PST) From: James Simmons To: Krishna Kondaka cc: ralf@gnu.org, linux-mips@oss.sgi.com Subject: Re: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel In-Reply-To: <200111132336.PAA06294@exceed1.sanera.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > 1. Summary: > Memory leak in Linux 2.4.2 MIPS SMP kernel Fixed in the latest tree. > /* > * Destroy context related info for an mm_struct that is about > * to be put to rest. > */ > extern inline void destroy_context(struct mm_struct *mm) > { > #ifdef CONFIG_SMP > kfree((void *)mm->context); > #else > /* Nothing to do. */ > #endif > } > > And when I tested this I do not see the memory leak any more. BTW you should check to see if mm->context really exist. It can bomb out otherwise. Current function is: static inline void destroy_context(struct mm_struct *mm) { #ifdef CONFIG_SMP if (mm->context) kfree((void *)mm->context); #endif } From owner-linux-mips@oss.sgi.com Tue Nov 13 15:47:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fADNlxT28970 for linux-mips-outgoing; Tue, 13 Nov 2001 15:47:59 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fADNlu028966 for ; Tue, 13 Nov 2001 15:47:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fADNlrs10527; Wed, 14 Nov 2001 10:47:53 +1100 Date: Wed, 14 Nov 2001 10:47:53 +1100 From: Ralf Baechle To: Krishna Kondaka Cc: linux-mips@oss.sgi.com Subject: Re: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel Message-ID: <20011114104753.A10410@dea.linux-mips.net> References: <200111132336.PAA06294@exceed1.sanera.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111132336.PAA06294@exceed1.sanera.net>; from krishna@sanera.net on Tue, Nov 13, 2001 at 03:36:32PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 03:36:32PM -0800, Krishna Kondaka wrote: > extern inline void destroy_context(struct mm_struct *mm) > { > #ifdef CONFIG_SMP > kfree((void *)mm->context); > #else > /* Nothing to do. */ > #endif > } > > And when I tested this I do not see the memory leak any more. Almost correct, as James already explained you have to check for a non-null pointer first. We got a more elegant implementation of context switching which I'll add to CVS asap; it gets away without any memory allocation. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 13 16:16:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0GdX29581 for linux-mips-outgoing; Tue, 13 Nov 2001 16:16:39 -0800 Received: from i01sv4132.ids1.intelonline.com (i01sv4132-p.ids1.intelonline.com [147.208.166.15]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE0Gb029578 for ; Tue, 13 Nov 2001 16:16:37 -0800 Received: from i01sv0648 (unverified [10.81.26.32]) by i01sv4132.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Wed, 14 Nov 2001 00:16:32 +0000 Message-ID: From: Guo-Rong Koh To: "linux-mips@oss.sgi.com" X-Originating-IP: [203.14.96.10] Date: Wed, 14 Nov 2001 10:16:30 +1030 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Subject: 2.4.13-pre5 problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi all, I decided to give up on framebuffer support for now. Anyway, what's the current suggested kernel for a DECStation 5000/25? My cross-compiled 2.4.13-pre5 kernel stops after calibrating the delay loop. Is this kernel revision buggy or is there something else I need to know? (It seems to die somewhere in mem_init). Thanks, Guo-Rong __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From owner-linux-mips@oss.sgi.com Tue Nov 13 16:17:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0H9R29672 for linux-mips-outgoing; Tue, 13 Nov 2001 16:17:09 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE0H5029664; Tue, 13 Nov 2001 16:17:05 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0GwjR028875; Tue, 13 Nov 2001 16:16:58 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0Gv3K028871; Tue, 13 Nov 2001 16:16:57 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 13 Nov 2001 16:16:57 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Krishna Kondaka , linux-mips@oss.sgi.com Subject: Re: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel In-Reply-To: <20011114104753.A10410@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > { > > #ifdef CONFIG_SMP > > kfree((void *)mm->context); > > #else > > /* Nothing to do. */ > > #endif > > } > > > > And when I tested this I do not see the memory leak any more. > > Almost correct, as James already explained you have to check for a > non-null pointer first. Hm. It was pointed out that kfree actually does the checking for us. Do we really need the check? > We got a more elegant implementation of > context switching which I'll add to CVS asap; it gets away without > any memory allocation. :-) From owner-linux-mips@oss.sgi.com Tue Nov 13 16:18:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0I3g29891 for linux-mips-outgoing; Tue, 13 Nov 2001 16:18:03 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE0I2029888 for ; Tue, 13 Nov 2001 16:18:02 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0HtjR028982; Tue, 13 Nov 2001 16:17:55 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0HsaG028978; Tue, 13 Nov 2001 16:17:54 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 13 Nov 2001 16:17:54 -0800 (PST) From: James Simmons To: Guo-Rong Koh cc: "linux-mips@oss.sgi.com" Subject: Re: 2.4.13-pre5 problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I decided to give up on framebuffer support for now. > Anyway, what's the current suggested kernel for a DECStation 5000/25? > My cross-compiled 2.4.13-pre5 kernel stops after calibrating the delay > loop. Is this kernel revision buggy or is there something else I need > to know? (It seems to die somewhere in mem_init). Use the current snapshot from the OSS tree. From owner-linux-mips@oss.sgi.com Tue Nov 13 16:18:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0IfN29965 for linux-mips-outgoing; Tue, 13 Nov 2001 16:18:41 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAE0Ib029960 for ; Tue, 13 Nov 2001 16:18:37 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAE0IYN10837; Wed, 14 Nov 2001 11:18:34 +1100 Date: Wed, 14 Nov 2001 11:18:34 +1100 From: Ralf Baechle To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Subject: Re: ld error " linking PIC files with non-PIC files " Message-ID: <20011114111834.B10410@dea.linux-mips.net> References: <20011026161259.54925.qmail@web11908.mail.yahoo.com> <20011113200948.75977.qmail@web11908.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011113200948.75977.qmail@web11908.mail.yahoo.com>; from wgowcher@yahoo.com on Tue, Nov 13, 2001 at 12:09:48PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 12:09:48PM -0800, Wayne Gowcher wrote: > I am trying to cross compile X using the redhat7.0 > distribution from the sgi mips site as my base. Most > files compile OK, but they fail at the link stage with > the following error : > > linking PIC files with non-PIC files. > > I created my cross-compile library files in > /usr/mipsel-linux from the packages : > glibc-2.2.2-1.mipsel.rpm & > glibc-devel-2.2.2-1.mipsel.rpm > are there other libraries I need ? > > I found a reference on the web to a module called > libc6-pic.o, I don't see this anywhere in my libraries > is this what I need ? > > Has anyone else seen this problem before and do they > know how to fix it ? Don't use non-pic code ever in userspace. Actually it's very strange that you hit this problem as gcc defaults to pic code so you should try to find which of your object files or libraries are non-pic. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 13 16:19:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0JgG30087 for linux-mips-outgoing; Tue, 13 Nov 2001 16:19:42 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAE0Je030084 for ; Tue, 13 Nov 2001 16:19:41 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAE0Ja310847; Wed, 14 Nov 2001 11:19:36 +1100 Date: Wed, 14 Nov 2001 11:19:36 +1100 From: Ralf Baechle To: James Simmons Cc: Krishna Kondaka , linux-mips@oss.sgi.com Subject: Re: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel Message-ID: <20011114111936.C10410@dea.linux-mips.net> References: <20011114104753.A10410@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Tue, Nov 13, 2001 at 04:16:57PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 04:16:57PM -0800, James Simmons wrote: > Hm. It was pointed out that kfree actually does the checking for us. > Do we really need the check? Seems that check sneaked in without telling me :-) Ralf From owner-linux-mips@oss.sgi.com Tue Nov 13 16:28:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE0SXk30362 for linux-mips-outgoing; Tue, 13 Nov 2001 16:28:33 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE0SU030359; Tue, 13 Nov 2001 16:28:30 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0SNjR029471; Tue, 13 Nov 2001 16:28:23 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fAE0SMmd029467; Tue, 13 Nov 2001 16:28:22 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 13 Nov 2001 16:28:22 -0800 (PST) From: James Simmons To: Ralf Baechle cc: Krishna Kondaka , linux-mips@oss.sgi.com Subject: Re: BUG : Memory leak in Linux 2.4.2 MIPS SMP kernel In-Reply-To: <20011114111936.C10410@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Hm. It was pointed out that kfree actually does the checking for us. > > Do we really need the check? > > Seems that check sneaked in without telling me :-) I didn't know here. I have been bite by kfree when passing a null pointer to it before. I'm glad their is a nice check. From owner-linux-mips@oss.sgi.com Tue Nov 13 18:44:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE2iep00651 for linux-mips-outgoing; Tue, 13 Nov 2001 18:44:40 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAE2ic000647 for ; Tue, 13 Nov 2001 18:44:38 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAE2iZE21034; Wed, 14 Nov 2001 13:44:35 +1100 Date: Wed, 14 Nov 2001 13:44:35 +1100 From: Ralf Baechle To: Steven Liu Cc: linux-mips@oss.sgi.com Subject: Re: Which package rc.sysinit is in? Message-ID: <20011114134435.D16741@dea.linux-mips.net> References: <84CE342693F11946B9F54B18C1AB837B14AEBD@ex2k.pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84CE342693F11946B9F54B18C1AB837B14AEBD@ex2k.pcs.psdc.com>; from stevenliu@psdc.com on Tue, Nov 13, 2001 at 09:44:05AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 09:44:05AM -0800, Steven Liu wrote: > With your help, I have cross-built and tested the util-linux-2.9s > package for my mips r3000 CPU under linux-2.2.12. The system crushed in > the program rc.sysinit with pid=8 when it was booting up. > > What and where is rc.sysinit? It's a shell script, so what actually crashed was the shell it's using, probably /bin/sh or /bin/bash. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 13 18:47:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE2lMx00761 for linux-mips-outgoing; Tue, 13 Nov 2001 18:47:22 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAE2lK000756 for ; Tue, 13 Nov 2001 18:47:21 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAE2lIE21866; Wed, 14 Nov 2001 13:47:18 +1100 Date: Wed, 14 Nov 2001 13:47:18 +1100 From: Ralf Baechle To: Pete Popov Cc: linux-mips , sforge Subject: Re: compiler problem Message-ID: <20011114134718.E16741@dea.linux-mips.net> References: <1005591216.470.20.camel@zeus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1005591216.470.20.camel@zeus>; from ppopov@mvista.com on Mon, Nov 12, 2001 at 10:53:36AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 12, 2001 at 10:53:36AM -0800, Pete Popov wrote: > What's the recommended oss binutils version? I'm using 2.9.5-3. But your problem more smells like a bug in the source. Ralf From owner-linux-mips@oss.sgi.com Wed Nov 14 01:57:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAE9vBR12117 for linux-mips-outgoing; Wed, 14 Nov 2001 01:57:11 -0800 Received: from faui02.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAE9v8012114 for ; Wed, 14 Nov 2001 01:57:08 -0800 Received: from rz.de (root@faui02b.informatik.uni-erlangen.de [131.188.30.151]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id KAA02730; Wed, 14 Nov 2001 10:56:51 +0100 (MET) Received: (from rz@localhost) by rz.de (8.8.8/8.8.8) id KAA00191; Wed, 14 Nov 2001 10:46:56 +0100 Date: Wed, 14 Nov 2001 10:46:55 +0100 From: Richard Zidlicky To: Roman Zippel Cc: Geert Uytterhoeven , Jun Sun , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011114104655.A187@linux-m68k.org> References: <20011113144240.B669@linux-m68k.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zippel@linux-m68k.org on Tue, Nov 13, 2001 at 04:32:42PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 04:32:42PM +0100, Roman Zippel wrote: > Hi, > > On Tue, 13 Nov 2001, Richard Zidlicky wrote: > > > hwclock and a bunch of less known porgrams like chrony. > > I was playing with chrony, but it was unable to adjust the time, last > weekend I switched back to ntp and that works better. some years ago chrony was the reason I wrote the Q40 rtc driver. It didn't work very well for me either, but the rtc driver was very useful in the meantime :) Bye Richard From owner-linux-mips@oss.sgi.com Wed Nov 14 02:22:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEAM1r20128 for linux-mips-outgoing; Wed, 14 Nov 2001 02:22:01 -0800 Received: from faui02.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEALw020122 for ; Wed, 14 Nov 2001 02:21:58 -0800 Received: from rz.de (root@faui02b.informatik.uni-erlangen.de [131.188.30.151]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id LAA04217; Wed, 14 Nov 2001 11:21:41 +0100 (MET) Received: (from rz@localhost) by rz.de (8.8.8/8.8.8) id LAA00485; Wed, 14 Nov 2001 11:08:43 +0100 Date: Wed, 14 Nov 2001 11:08:42 +0100 From: Richard Zidlicky To: Jun Sun Cc: Roman Zippel , Geert Uytterhoeven , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver Message-ID: <20011114110842.A473@linux-m68k.org> References: <3BF0371F.8040575B@linux-m68k.org> <20011113144240.B669@linux-m68k.org> <3BF15F55.AABB383C@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BF15F55.AABB383C@mvista.com>; from jsun@mvista.com on Tue, Nov 13, 2001 at 09:58:45AM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 13, 2001 at 09:58:45AM -0800, Jun Sun wrote: > Richard Zidlicky wrote: > > > Btw the interrupt need not to be hardware, for the Q40 I test > > a rtc register once per jiffie and generate a "soft interrupt". > > It could be done generic at least for m68k. > > > > I have written an experiemntal ptimer driver to do just this and potential > more. Such a device is useful for real-time programming (e.g., when you try > to implement a periodic user task). > > See http://linux.junsun.net/realtime-linux/preemption-test > > The driver is architecture independent (i.e., linux-common code) > > Due to the different programming needs behind periodic timers (or user-level > timer) and RTC operations, my vote for future work is to leave them as two > separate drivers. To me, RTC is really just to read/write RTC clock. RTC_UIE is needed (or at least very useful) to set the clock, so it belongs into a rtc driver if it can be implemented. General purpose timers are different story, btw what is wrong with setitimer that you have chosen to implement an additional driver for it? Richard From owner-linux-mips@oss.sgi.com Wed Nov 14 13:26:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAELQw905007 for linux-mips-outgoing; Wed, 14 Nov 2001 13:26:58 -0800 Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAELQs005002 for ; Wed, 14 Nov 2001 13:26:54 -0800 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id NAA97996; Wed, 14 Nov 2001 13:26:52 -0800 (PST) Date: Wed, 14 Nov 2001 13:26:51 -0800 From: Geoffrey Espin To: linux-mips-kernel@lists.sourceforge.net Cc: linux-mips Subject: Re: compiler problem Message-ID: <20011114132651.A85263@idiom.com> References: <1005591216.470.20.camel@zeus> <20011114134718.E16741@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20011114134718.E16741@dea.linux-mips.net>; from Ralf Baechle on Wed, Nov 14, 2001 at 01:47:18PM +1100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I discovered that HJ Lu's toolchain seems to generate binaries sometimes nearly twice what I used to get with the old VR toolchain. Here are some of my apps (-static -stripped): OLD 'VR' tools -rwxr-xr-x 1 root root 302384 Oct 4 2001 chat -rwxr-xr-x 1 root root 443848 Oct 4 2001 iptables -r-sr-x--- 1 root root 619620 Oct 4 2001 pppd -rwxr-xr-x 1 root root 445788 Oct 4 2001 thttpd -rwxr-xr-x 1 root root 335560 Oct 4 2001 udhcpd NEW gcc version 2.96 20000731 -rwxr-xr-x 1 root espin 543876 Nov 13 16:13 chat -rwxr-xr-x 1 espin espin 740092 Nov 13 16:13 iptables -r-sr-x--- 1 root pppusers 907256 Nov 13 16:13 pppd -rwxr-xr-x 1 espin espin 703880 Nov 13 16:13 thttpd -rwxr-xr-x 1 espin espin 599200 Nov 13 16:13 udhcpd I guess this is most likely a glibc issue? Geoff -- Geoffrey Espin espin@idiom.com From owner-linux-mips@oss.sgi.com Wed Nov 14 14:07:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAEM7KT05793 for linux-mips-outgoing; Wed, 14 Nov 2001 14:07:20 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAEM7G005790 for ; Wed, 14 Nov 2001 14:07:16 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id C9112125C0; Wed, 14 Nov 2001 14:07:14 -0800 (PST) Date: Wed, 14 Nov 2001 14:07:14 -0800 From: "H . J . Lu" To: Geoffrey Espin Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips Subject: Re: compiler problem Message-ID: <20011114140714.A26099@lucon.org> References: <1005591216.470.20.camel@zeus> <20011114134718.E16741@dea.linux-mips.net> <20011114132651.A85263@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011114132651.A85263@idiom.com>; from espin@idiom.com on Wed, Nov 14, 2001 at 01:26:51PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 14, 2001 at 01:26:51PM -0800, Geoffrey Espin wrote: > > I discovered that HJ Lu's toolchain seems to generate binaries > sometimes nearly twice what I used to get with the old VR toolchain. > Here are some of my apps (-static -stripped): ^^^^^^^ > > OLD 'VR' tools > > -rwxr-xr-x 1 root root 302384 Oct 4 2001 chat > -rwxr-xr-x 1 root root 443848 Oct 4 2001 iptables > -r-sr-x--- 1 root root 619620 Oct 4 2001 pppd > -rwxr-xr-x 1 root root 445788 Oct 4 2001 thttpd > -rwxr-xr-x 1 root root 335560 Oct 4 2001 udhcpd > > NEW gcc version 2.96 20000731 > > -rwxr-xr-x 1 root espin 543876 Nov 13 16:13 chat > -rwxr-xr-x 1 espin espin 740092 Nov 13 16:13 iptables > -r-sr-x--- 1 root pppusers 907256 Nov 13 16:13 pppd > -rwxr-xr-x 1 espin espin 703880 Nov 13 16:13 thttpd > -rwxr-xr-x 1 espin espin 599200 Nov 13 16:13 udhcpd > > > I guess this is most likely a glibc issue? Yes. If you use -static, the binary will be bigger. If you want smaller binaries, you should check out my sglibc. H.J. From owner-linux-mips@oss.sgi.com Thu Nov 15 05:39:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFDd6J00785 for linux-mips-outgoing; Thu, 15 Nov 2001 05:39:06 -0800 Received: from mail.chimerical.com.au (CPE-144-132-219-161.nsw.bigpond.net.au [144.132.219.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFDcu000782 for ; Thu, 15 Nov 2001 05:38:57 -0800 content-class: urn:content-classes:message Subject: Inclusion of rrm.o in export-objs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 16 Nov 2001 00:38:46 +1100 Message-ID: <4DF7FE7DA7E47442B859983ABCFBBF627971@chimsvr1.chimerical.com.au> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Inclusion of rrm.o in export-objs Thread-Index: AcFt2tMZ4AsjtqC4SJuT59472mrXSg== From: "Ivan Hamilton" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id fAFDcw000783 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm a little new, so let me know if this is out of place. After grabbing the latest source via CVS, I ran into compilation problems. A little (read "a lot of") searching, and I found I was not alone with this problem. This fix, worked for me. But I'm not sure why no one else had run into it. My Makefile knowledge is extremely limited to say the least. But are there possible side-effects of this particular fix? And how does a fix like this, find it's way back into the source tree? Any pointers, or other information welcome. ==ORIGINAL MESSAGE START== * Newsgroups: linux.debian.ports.mips * From: Petter Reinholdtsen > * Subject: Compile problem with latest mips kernel CVS * Date: Wed, 07 Nov 2001 09:40:07 +0100 * Organization: linux.*_mail_to_news_unidirectional_gateway * Approved: robomod@news.nic.it (1.20) Hello I do not have post access to linux-mips@oss.sgi.com, so I try to send it here instead. I tested to compile the kernel from the mips kernel CVS last night, and it stopped with the following error. The error line is "EXPORT_SYMBOL(');". The object rrm.o must be added to export-objs. Patch below. make[4]: Entering directory `/usr/src/linux-cvs/drivers/sgi/char' gcc -I /usr/src/linux-cvs/include/asm/gcc -D__KERNEL__ -I/usr/src/linux-cvs/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -Wa,--trap -pipe -DMODULE -mlong-calls -c -o rrm.o rrm.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. Warning: The -march option is incompatible to -mipsN and therefore ignored. rrm.c:74: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' rrm.c:74: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' rrm.c:74: warning: data definition has no type or storage class rrm.c:75: parse error before `this_object_must_be_defined_as_export_objs_in_the_Makefile' rrm.c:75: warning: type defaults to `int' in declaration of `this_object_must_be_defined_as_export_objs_in_the_Makefile' rrm.c:75: warning: data definition has no type or storage class make[4]: *** [rrm.o] Error 1 make[4]: Leaving directory `/usr/src/linux-cvs/drivers/sgi/char' - Add rrm.o to export-objs, and sort the list of objects. Index: Makefile =================================================================== RCS file: /cvs/linux/drivers/sgi/char/Makefile,v retrieving revision 1.13 diff -u -r1.13 Makefile --- Makefile 2001/03/11 03:35:59 1.13 +++ Makefile 2001/11/07 08:27:35 @@ -9,7 +9,7 @@ O_TARGET := sgichar.o -export-objs := newport.o shmiq.o sgicons.o usema.o +export-objs := newport.o rrm.o sgicons.o shmiq.o usema.o obj-y := newport.o shmiq.o sgicons.o usema.o streamable.o obj-$(CONFIG_SGI_SERIAL) += sgiserial.o -- To UNSUBSCRIBE, email to debian-mips-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org ==ORIGINAL MESSAGE END== From owner-linux-mips@oss.sgi.com Thu Nov 15 07:54:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFFsU716371 for linux-mips-outgoing; Thu, 15 Nov 2001 07:54:30 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAFFsT016368 for ; Thu, 15 Nov 2001 07:54:29 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAFFsKt06620; Fri, 16 Nov 2001 02:54:20 +1100 Date: Fri, 16 Nov 2001 02:54:20 +1100 From: Ralf Baechle To: Ivan Hamilton Cc: linux-mips@oss.sgi.com Subject: Re: Inclusion of rrm.o in export-objs Message-ID: <20011116025420.C6317@dea.linux-mips.net> References: <4DF7FE7DA7E47442B859983ABCFBBF627971@chimsvr1.chimerical.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4DF7FE7DA7E47442B859983ABCFBBF627971@chimsvr1.chimerical.com.au>; from ivan@chimerical.com.au on Fri, Nov 16, 2001 at 12:38:46AM +1100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 16, 2001 at 12:38:46AM +1100, Ivan Hamilton wrote: > My Makefile knowledge is extremely limited to say the least. But are > there possible side-effects of this particular fix? And how does a fix > like this, find it's way back into the source tree? Fixed in CVS. And yes, your fix was correct. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 15 09:42:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFHgc620928 for linux-mips-outgoing; Thu, 15 Nov 2001 09:42:38 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFHgV020925 for ; Thu, 15 Nov 2001 09:42:31 -0800 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 fAFHgSB06799; Thu, 15 Nov 2001 09:42:28 -0800 Message-ID: <3BF3FE39.34C541EB@mvista.com> Date: Thu, 15 Nov 2001 09:41:13 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Richard Zidlicky CC: Roman Zippel , Geert Uytterhoeven , "Maciej W. Rozycki" , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC] generic MIPS RTC driver References: <3BF0371F.8040575B@linux-m68k.org> <20011113144240.B669@linux-m68k.org> <3BF15F55.AABB383C@mvista.com> <20011114110842.A473@linux-m68k.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Richard Zidlicky wrote: > > On Tue, Nov 13, 2001 at 09:58:45AM -0800, Jun Sun wrote: > > Richard Zidlicky wrote: > > > > > Btw the interrupt need not to be hardware, for the Q40 I test > > > a rtc register once per jiffie and generate a "soft interrupt". > > > It could be done generic at least for m68k. > > > > > > > I have written an experiemntal ptimer driver to do just this and potential > > more. Such a device is useful for real-time programming (e.g., when you try > > to implement a periodic user task). > > > > See http://linux.junsun.net/realtime-linux/preemption-test > > > > The driver is architecture independent (i.e., linux-common code) > > > > Due to the different programming needs behind periodic timers (or user-level > > timer) and RTC operations, my vote for future work is to leave them as two > > separate drivers. To me, RTC is really just to read/write RTC clock. > > RTC_UIE is needed (or at least very useful) to set the clock, so it belongs > into a rtc driver if it can be implemented. General purpose timers are > different story, btw what is wrong with setitimer that you have chosen > to implement an additional driver for it? Easy of implmentation and more features. Here is the pseudo code to do a real-time periodic task with /dev/ptimer: void periodic_task(void) { fd=open("/dev/ptimer", O_RDONLY); ioctl(fd, PTIMER_SET_PERIOD, PERIOD); ioctl(fd, PTIMER_SET_PHASE, PHASE); /* become realtime process */ start_realtime(); for(;;) { /* read won't return until next instance release point */ read(fd, &count, sizeof(count)); /* do the job */ ... } } Anybody who has used setitimer() would konw this is even simpler than the setup of itimer, let alone with itimer you still need to deal with SIGALRM signals plus some multi-thread signal handling considerations. On the feature side, ptimer offers the exact control of phase. For example, you can have two tasks with period of 100ms, with one starting *exactly* at time t and the other starting *exactly* at t+50 ms later. Some unimplemented features allow you to control the behavior when missing deadlines. Jun From owner-linux-mips@oss.sgi.com Thu Nov 15 13:43:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAFLhFO27886 for linux-mips-outgoing; Thu, 15 Nov 2001 13:43:15 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAFLhB027883 for ; Thu, 15 Nov 2001 13:43:11 -0800 Received: from c1793011-a.marin1.sfba.home.com (HELO garrickevansw2k) (24.7.89.210) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Nov 2001 21:43:11 -0000 X-Apparently-From: Message-ID: <003b01c16e1e$781aefb0$6401a8c0@autodesk.com> From: "Garrick Evans" To: "Linux MIPS" References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> <20011113075543.A30676@lucon.org> Subject: SGI harddisk only - Debian install Date: Thu, 15 Nov 2001 13:42:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Just looking for a little help here getting woody running on an indy. My problem is once I boot the install kernel (linux), after the scsi snoop and network setup, it all dies on the following line: sending SDTR 011030130f0csync_xfer=2c<0>Kernel panic: VFS: Unable to mount root fs on 08:01 I have IRIX (5.3) on dksc(0,1) and two free drives dksc(0,3) and dksc(0,4) available for debian. I have the following files located at / and /boot directories on IRIX partition: linux, root.bin, root.tar.gz, kernel_config, drivers.tgz I have booted from the "maintainence console" (PROM) with almost every combination I can think of - always with the same failure. So... where is it looking to mount from? Do I need to make a new filesystem in the root parition of the scsi 3 disk and push the kernel and root.bin over there? If so, do I also then need to dvhtool the header on that disk as well? Any help would be HUGELY appreciated. Thanks. g _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Thu Nov 15 17:05:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAG15n912658 for linux-mips-outgoing; Thu, 15 Nov 2001 17:05:49 -0800 Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAG15i012655 for ; Thu, 15 Nov 2001 17:05:44 -0800 Received: from c1793011-a.marin1.sfba.home.com (HELO garrickevansw2k) (24.7.89.210) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Nov 2001 01:05:42 -0000 X-Apparently-From: Message-ID: <00a301c16e3a$c2a18b90$6401a8c0@autodesk.com> From: "Garrick Evans" To: "Linux MIPS" References: <1004708261.31067.6.camel@localhost.localdomain> <3BE2A852.AFF0D905@mips.com> <1005662974.10352.2.camel@localhost.localdomain> <20011113075543.A30676@lucon.org> <003b01c16e1e$781aefb0$6401a8c0@autodesk.com> Subject: Re: SGI harddisk only - Debian install Date: Thu, 15 Nov 2001 17:05:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk sorry for the distrib... boot tftpboot.img root=/dev/ram works fine, i thought i tried it before once again, sorry for the distrib ----- Original Message ----- From: "Garrick Evans" To: "Linux MIPS" Sent: Thursday, November 15, 2001 1:42 PM Subject: SGI harddisk only - Debian install > Just looking for a little help here getting woody running on an indy. > My problem is once I boot the install kernel (linux), after the scsi snoop > and network setup, it all dies on the following line: > > sending SDTR 011030130f0csync_xfer=2c<0>Kernel panic: VFS: Unable to mount > root fs on 08:01 > > I have IRIX (5.3) on dksc(0,1) and two free drives dksc(0,3) and dksc(0,4) > available for debian. > I have the following files located at / and /boot directories on IRIX > partition: > linux, root.bin, root.tar.gz, kernel_config, drivers.tgz > > I have booted from the "maintainence console" (PROM) with almost every > combination I can think of - always with the same failure. > > So... where is it looking to mount from? Do I need to make a new filesystem > in the root parition of the scsi 3 disk and push the kernel and root.bin > over there? If so, do I also then need to dvhtool the header on that disk as > well? > > Any help would be HUGELY appreciated. Thanks. > > > g > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-linux-mips@oss.sgi.com Fri Nov 16 05:01:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAGD14T27138 for linux-mips-outgoing; Fri, 16 Nov 2001 05:01:04 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAGCxog27070 for ; Fri, 16 Nov 2001 04:59:50 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA03937 for ; Fri, 16 Nov 2001 04:59:40 -0800 (PST) mail_from (ladislav.michl@hlubocky.del.cz) Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 164iQt-0006wW-00 for ; Fri, 16 Nov 2001 13:49:23 +0100 Date: Fri, 16 Nov 2001 13:49:22 +0100 (CET) From: Ladislav Michl To: linux-mips@oss.sgi.com Subject: [PATCH] indy_int clenaup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, this will bring you following: * Indy interrupt handling works now better. the only visible change is look of /proc/interrupts CPU0 2: 0 CPU_irq local0 cascade 3: 0 CPU_irq local1 cascade 6: 0 CPU_irq Bus Error 9: 2758 IP22 local 0 SGI WD93 11: 2197 IP22 local 0 SGI Seeq8003 15: 0 IP22 local 0 mappable0 cascade 17: 4 IP22 local 1 Front Panel 28: 6754 IP22 local 2 keyboard 29: 0 IP22 local 2 Zilog8530 ERR: 0 one question: should be cascade interrupts counted too? note, that timer irqs are not present. i'll do so once i'll implement CONFIG_NEW_TIME_C for Indy. * I removed irq 'space' for HPC and GIO interrupts. They weren't implemented and doing so will make interrupt routine _very_ slow. Driver should register HPC/MC/GIO interrupt as shareable and look to the proper register to see what happened (currently there is no such driver, except of HAL2 sitting on my hardisk) * Various definitions of IP22 interrups were added to sgint23.h * other minor fixes. note for those, who are waiting for VINO driver: at the beginning I was unable to start DMA transfer. now i'm unable to stop it... so to bring my ego from dust, i decided to write HAL2 driver, which needs HPC interupts. this patch is HAL2 driver by-product... any comments and/or suggestions are welcome, ladis Index: linux/include/asm-mips/sgi/sgint23.h =================================================================== RCS file: /cvs/linux/include/asm-mips/sgi/sgint23.h,v retrieving revision 1.4 diff -u -r1.4 sgint23.h --- linux/include/asm-mips/sgi/sgint23.h 2001/10/06 22:33:12 1.4 +++ linux/include/asm-mips/sgi/sgint23.h 2001/11/16 12:10:02 @@ -8,100 +8,123 @@ * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com) * Copyright (C) 1997, 98, 1999, 2000 Ralf Baechle * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) - INT2 corrections + * Copyright (C) 2001 Ladislav Michl (ladis@psi.cz) */ #ifndef _ASM_SGI_SGINT23_H #define _ASM_SGI_SGINT23_H /* These are the virtual IRQ numbers, we divide all IRQ's into * 'spaces', the 'space' determines where and how to enable/disable - * that particular IRQ on an SGI machine. Add new 'spaces' as new - * IRQ hardware is supported. + * that particular IRQ on an SGI machine. HPC DMA and MC DMA interrups + * are not supported this way. Driver is supposed to allocate HPC/MC + * interrupt as shareable and then look to proper status bit (see + * HAL2 driver). This will prevent many complications, trust me ;-) + * --ladis */ -#define SGINT_LOCAL0 0 /* INDY has 8 local0 irq levels */ -#define SGINT_LOCAL1 8 /* INDY has 8 local1 irq levels */ -#define SGINT_LOCAL2 16 /* INDY has 8 local2 vectored irq levels */ -#define SGINT_LOCAL3 24 /* INDY has 8 local3 vectored irq levels */ -#define SGINT_GIO 32 /* INDY has 9 GIO irq levels */ -#define SGINT_HPCDMA 41 /* INDY has 11 HPCDMA irq _sources_ */ -#define SGINT_END 52 /* End of 'spaces' */ +#define SGINT_CPU 0 /* MIPS CPU define 8 interrupt sources */ +#define SGINT_LOCAL0 8 /* INDY has 8 local0 irq levels */ +#define SGINT_LOCAL1 16 /* INDY has 8 local1 irq levels */ +#define SGINT_LOCAL2 24 /* INDY has 8 local2 vectored irq levels */ +#define SGINT_LOCAL3 32 /* INDY has 8 local3 vectored irq levels */ +#define SGINT_END 40 /* End of 'spaces' */ /* * Individual interrupt definitions for the INDY and Indigo2 */ -#define SGI_WD93_0_IRQ SGINT_LOCAL0 + 1 /* 1st onboard WD93 */ -#define SGI_WD93_1_IRQ SGINT_LOCAL0 + 2 /* 2nd onboard WD93 */ -#define SGI_ENET_IRQ SGINT_LOCAL0 + 3 /* onboard ethernet */ - -#define SGI_PANEL_IRQ SGINT_LOCAL1 + 1 /* front panel */ -#define SGI_VINO_IRQ SGINT_LOCAL1 + 6 /* Indy VINO */ - -#define SGI_EISA_IRQ SGINT_LOCAL2 + 3 /* EISA interrupts */ +#define SGI_LOCAL_0_IRQ SGINT_CPU + 2 +#define SGI_LOCAL_1_IRQ SGINT_CPU + 3 +#define SGI_BUSERR_IRQ SGINT_CPU + 6 +#define SGI_TIMER_IRQ SGINT_CPU + 7 + +#define SGI_FIFO_IRQ SGINT_LOCAL0 + 0 /* FIFO full */ +#define SGI_GIO_0_IRQ SGI_FIFO_IRQ /* GIO-0 */ +#define SGI_WD93_0_IRQ SGINT_LOCAL0 + 1 /* 1st onboard WD93 */ +#define SGI_WD93_1_IRQ SGINT_LOCAL0 + 2 /* 2nd onboard WD93 */ +#define SGI_ENET_IRQ SGINT_LOCAL0 + 3 /* onboard ethernet */ +#define SGI_MCDMA_IRQ SGINT_LOCAL0 + 4 /* MC DMA done */ +#define SGI_PARPORT_IRQ SGINT_LOCAL0 + 5 /* Parallel port */ +#define SGI_GIO_1_IRQ SGINT_LOCAL0 + 6 /* GE / GIO-1 / 2nd-HPC */ +#define SGI_MAP_0_IRQ SGINT_LOCAL0 + 7 /* Mappable interrupt 0 */ + +#define SGI_GPL0_IRQ SGINT_LOCAL1 + 0 /* General Purpose LOCAL1_N<0> */ +#define SGI_PANEL_IRQ SGINT_LOCAL1 + 1 /* front panel */ +#define SGI_GPL2_IRQ SGINT_LOCAL1 + 2 /* General Purpose LOCAL1_N<2> */ +#define SGI_MAP_1_IRQ SGINT_LOCAL1 + 3 /* Mappable interrupt 1 */ +#define SGI_HPCDMA_IRQ SGINT_LOCAL1 + 4 /* HPC DMA done */ +#define SGI_ACFAIL_IRQ SGINT_LOCAL1 + 5 /* AC fail */ +#define SGI_VINO_IRQ SGINT_LOCAL1 + 6 /* Indy VINO */ +#define SGI_GIO_2_IRQ SGINT_LOCAL1 + 7 /* Vert retrace / GIO-2 */ + +/* Mapped interrupts. These interrupts may be mapped to either 0, or 1 + * We map them to 0 */ +#define SGI_VERT_IRQ SGINT_LOCAL2 + 0 /* INT3: newport vertical status */ +#define SGI_EISA_IRQ SGINT_LOCAL2 + 3 /* EISA interrupts */ #define SGI_KEYBOARD_IRQ SGINT_LOCAL2 + 4 /* keyboard */ -#define SGI_SERIAL_IRQ SGINT_LOCAL2 + 5 /* onboard serial */ +#define SGI_SERIAL_IRQ SGINT_LOCAL2 + 5 /* onboard serial */ /* INT2 occupies HPC PBUS slot 4, INT3 uses slot 6. */ -#define SGI_INT2_BASE 0x1fbd9000 /* physical */ -#define SGI_INT3_BASE 0x1fbd9880 /* physical */ +#define SGI_INT2_BASE 0x1fbd9000 /* physical */ +#define SGI_INT3_BASE 0x1fbd9880 /* physical */ struct sgi_ioc_ints { #ifdef __MIPSEB__ unsigned char _unused0[3]; - volatile unsigned char istat0; /* Interrupt status zero */ + volatile unsigned char istat0; /* Interrupt status zero */ #else - volatile unsigned char istat0; /* Interrupt status zero */ + volatile unsigned char istat0; /* Interrupt status zero */ unsigned char _unused0[3]; #endif -#define ISTAT0_FFULL 0x01 -#define ISTAT0_SCSI0 0x02 -#define ISTAT0_SCSI1 0x04 -#define ISTAT0_ENET 0x08 -#define ISTAT0_GFXDMA 0x10 -#define ISTAT0_LPR 0x20 -#define ISTAT0_HPC2 0x40 -#define ISTAT0_LIO2 0x80 - +#define ISTAT0_FFULL 0x01 +#define ISTAT0_SCSI0 0x02 +#define ISTAT0_SCSI1 0x04 +#define ISTAT0_ENET 0x08 +#define ISTAT0_GFXDMA 0x10 +#define ISTAT0_LPR 0x20 +#define ISTAT0_HPC2 0x40 +#define ISTAT0_LIO2 0x80 + #ifdef __MIPSEB__ unsigned char _unused1[3]; - volatile unsigned char imask0; /* Interrupt mask zero */ + volatile unsigned char imask0; /* Interrupt mask zero */ unsigned char _unused2[3]; - volatile unsigned char istat1; /* Interrupt status one */ + volatile unsigned char istat1; /* Interrupt status one */ #else - volatile unsigned char imask0; /* Interrupt mask zero */ + volatile unsigned char imask0; /* Interrupt mask zero */ unsigned char _unused1[3]; - volatile unsigned char istat1; /* Interrupt status one */ + volatile unsigned char istat1; /* Interrupt status one */ unsigned char _unused2[3]; #endif -#define ISTAT1_ISDNI 0x01 -#define ISTAT1_PWR 0x02 -#define ISTAT1_ISDNH 0x04 -#define ISTAT1_LIO3 0x08 -#define ISTAT1_HPC3 0x10 -#define ISTAT1_AFAIL 0x20 -#define ISTAT1_VIDEO 0x40 -#define ISTAT1_GIO2 0x80 - +#define ISTAT1_ISDNI 0x01 +#define ISTAT1_PWR 0x02 +#define ISTAT1_ISDNH 0x04 +#define ISTAT1_LIO3 0x08 +#define ISTAT1_HPC3 0x10 +#define ISTAT1_AFAIL 0x20 +#define ISTAT1_VIDEO 0x40 +#define ISTAT1_GIO2 0x80 + #ifdef __MIPSEB__ unsigned char _unused3[3]; - volatile unsigned char imask1; /* Interrupt mask one */ + volatile unsigned char imask1; /* Interrupt mask one */ unsigned char _unused4[3]; - volatile unsigned char vmeistat; /* VME interrupt status */ + volatile unsigned char vmeistat; /* VME interrupt status */ unsigned char _unused5[3]; - volatile unsigned char cmeimask0; /* VME interrupt mask zero */ + volatile unsigned char cmeimask0; /* VME interrupt mask zero */ unsigned char _unused6[3]; - volatile unsigned char cmeimask1; /* VME interrupt mask one */ + volatile unsigned char cmeimask1; /* VME interrupt mask one */ unsigned char _unused7[3]; - volatile unsigned char cmepol; /* VME polarity */ + volatile unsigned char cmepol; /* VME polarity */ #else - volatile unsigned char imask1; /* Interrupt mask one */ + volatile unsigned char imask1; /* Interrupt mask one */ unsigned char _unused3[3]; - volatile unsigned char vmeistat; /* VME interrupt status */ + volatile unsigned char vmeistat; /* VME interrupt status */ unsigned char _unused4[3]; - volatile unsigned char cmeimask0; /* VME interrupt mask zero */ + volatile unsigned char cmeimask0; /* VME interrupt mask zero */ unsigned char _unused5[3]; - volatile unsigned char cmeimask1; /* VME interrupt mask one */ + volatile unsigned char cmeimask1; /* VME interrupt mask one */ unsigned char _unused6[3]; - volatile unsigned char cmepol; /* VME polarity */ + volatile unsigned char cmepol; /* VME polarity */ unsigned char _unused7[3]; #endif }; @@ -109,21 +132,21 @@ struct sgi_ioc_timers { #ifdef __MIPSEB__ unsigned char _unused0[3]; - volatile unsigned char tcnt0; /* counter 0 */ + volatile unsigned char tcnt0; /* counter 0 */ unsigned char _unused1[3]; - volatile unsigned char tcnt1; /* counter 1 */ + volatile unsigned char tcnt1; /* counter 1 */ unsigned char _unused2[3]; - volatile unsigned char tcnt2; /* counter 2 */ + volatile unsigned char tcnt2; /* counter 2 */ unsigned char _unused3[3]; - volatile unsigned char tcword; /* control word */ + volatile unsigned char tcword; /* control word */ #else - volatile unsigned char tcnt0; /* counter 0 */ + volatile unsigned char tcnt0; /* counter 0 */ unsigned char _unused0[3]; - volatile unsigned char tcnt1; /* counter 1 */ + volatile unsigned char tcnt1; /* counter 1 */ unsigned char _unused1[3]; - volatile unsigned char tcnt2; /* counter 2 */ + volatile unsigned char tcnt2; /* counter 2 */ unsigned char _unused2[3]; - volatile unsigned char tcword; /* control word */ + volatile unsigned char tcword; /* control word */ unsigned char _unused3[3]; #endif }; @@ -156,22 +179,22 @@ struct sgi_int2_regs { struct sgi_ioc_ints ints; - volatile u32 ledbits; /* LED control bits */ -#define INT2_LED_TXCLK 0x01 /* GPI to TXCLK enable */ -#define INT2_LED_SERSLCT0 0x02 /* serial port0: 0=apple 1=pc */ -#define INT2_LED_SERSLCT1 0x04 /* serial port1: 0=apple 1=pc */ -#define INT2_LED_CHEAPER 0x08 /* 0=cheapernet 1=ethernet */ -#define INT2_LED_POWEROFF 0x10 /* Power-off request, active high */ + volatile u32 ledbits; /* LED control bits */ +#define INT2_LED_TXCLK 0x01 /* GPI to TXCLK enable */ +#define INT2_LED_SERSLCT0 0x02 /* serial port0: 0=apple 1=pc */ +#define INT2_LED_SERSLCT1 0x04 /* serial port1: 0=apple 1=pc */ +#define INT2_LED_CHEAPER 0x08 /* 0=cheapernet 1=ethernet */ +#define INT2_LED_POWEROFF 0x10 /* Power-off request, active high */ #ifdef __MIPSEB__ unsigned char _unused0[3]; - volatile unsigned char tclear; /* Timer clear strobe address */ + volatile unsigned char tclear; /* Timer clear strobe address */ #else - volatile unsigned char tclear; /* Timer clear strobe address */ + volatile unsigned char tclear; /* Timer clear strobe address */ unsigned char _unused0[3]; #endif -#define INT2_TCLEAR_T0CLR 0x1 /* Clear timer0 IRQ */ -#define INT2_TCLEAR_T1CLR 0x2 /* Clear timer1 IRQ */ +#define INT2_TCLEAR_T0CLR 0x1 /* Clear timer0 IRQ */ +#define INT2_TCLEAR_T1CLR 0x2 /* Clear timer1 IRQ */ /* I am guesing there are only two unused registers here * but I could be wrong... - andrewb */ @@ -185,12 +208,12 @@ #ifdef __MIPSEB__ unsigned char _unused0[3]; - volatile unsigned char tclear; /* Timer clear strobe address */ + volatile unsigned char tclear; /* Timer clear strobe address */ #else - volatile unsigned char tclear; /* Timer clear strobe address */ + volatile unsigned char tclear; /* Timer clear strobe address */ unsigned char _unused0[3]; #endif - volatile u32 estatus; /* Error status reg */ + volatile u32 estatus; /* Error status reg */ u32 _unused1[2]; struct sgi_ioc_timers timers; }; Index: linux/arch/mips/sgi/kernel/indy_int.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi/kernel/indy_int.c,v retrieving revision 1.30 diff -u -r1.30 indy_int.c --- linux/arch/mips/sgi/kernel/indy_int.c 2001/11/14 02:40:09 1.30 +++ linux/arch/mips/sgi/kernel/indy_int.c 2001/11/16 12:10:03 @@ -7,54 +7,26 @@ * Copyright (C) 1999 Andrew R. Baker (andrewb@uab.edu) * - Indigo2 changes * - Interrupt handling fixes + * Copyright (C) 2001 Ladislav Michl (ladis@psi.cz) */ -#include -#include +#include +#include #include #include #include -#include #include -#include -#include -#include -#include -#include -#include - -#include -#include -#include + #include #include -#include - -#include -#include -#include -#include -#include -#include +#include #include -/* - * Linux has a controller-independent x86 interrupt architecture. - * every controller has a 'controller-template', that is used - * by the main code to do the right thing. Each driver-visible - * interrupt source is transparently wired to the apropriate - * controller. Thus drivers need not be aware of the - * interrupt-controller. - * - * Various interrupt controllers we handle: 8259 PIC, SMP IO-APIC, - * PIIX4's internal 8259 PIC and SGI's Visual Workstation Cobalt (IO-)APIC. - * (IO-APICs assumed to be messaging to Pentium local-APICs) - * - * the code is designed to be easily extended with new/different - * interrupt controllers, without having to do assembly magic. - */ +#include +#include /* #define DEBUG_SGINT */ +#undef I_REALLY_NEED_THIS_IRQ struct sgi_int2_regs *sgi_i2regs; struct sgi_int3_regs *sgi_i3regs; @@ -68,30 +40,23 @@ static char lc3msk_to_irqnr[256]; extern asmlinkage void indyIRQ(void); +extern void do_IRQ(int irq, struct pt_regs *regs); -/* Local IRQ's are layed out logically like this: - * - * 0 --> 7 == local 0 interrupts - * 8 --> 15 == local 1 interrupts - * 16 --> 23 == vectored level 2 interrupts - * 24 --> 31 == vectored level 3 interrupts (not used) - * 32 --> 40 == vectored GIO interrupts - * 41 --> 52 == vectored HPCDMA interrupts - */ - static void enable_local0_irq(unsigned int irq) { unsigned long flags; save_and_cli(flags); - ioc_icontrol->imask0 |= (1 << (irq - SGINT_LOCAL0)); + /* don't allow mappable interrupt to be enabled from setup_irq, + * we have our own way to do so */ + if (irq != SGI_MAP_0_IRQ) + ioc_icontrol->imask0 |= (1 << (irq - SGINT_LOCAL0)); restore_flags(flags); } static unsigned int startup_local0_irq(unsigned int irq) { enable_local0_irq(irq); - return 0; /* Never anything pending */ } @@ -129,14 +94,16 @@ unsigned long flags; save_and_cli(flags); - ioc_icontrol->imask1 |= (1 << (irq - SGINT_LOCAL1)); + /* don't allow mappable interrupt to be enabled from setup_irq, + * we have our own way to do so */ + if (irq != SGI_MAP_1_IRQ) + ioc_icontrol->imask1 |= (1 << (irq - SGINT_LOCAL1)); restore_flags(flags); } static unsigned int startup_local1_irq(unsigned int irq) { enable_local1_irq(irq); - return 0; /* Never anything pending */ } @@ -145,7 +112,7 @@ unsigned long flags; save_and_cli(flags); - ioc_icontrol->imask1 &= ~(1 << (irq- SGINT_LOCAL1)); + ioc_icontrol->imask1 &= ~(1 << (irq - SGINT_LOCAL1)); restore_flags(flags); } @@ -174,7 +141,7 @@ unsigned long flags; save_and_cli(flags); - enable_local0_irq(7); + ioc_icontrol->imask0 |= (1 << (SGI_MAP_0_IRQ - SGINT_LOCAL0)); ioc_icontrol->cmeimask0 |= (1 << (irq - SGINT_LOCAL2)); restore_flags(flags); } @@ -182,7 +149,6 @@ static unsigned int startup_local2_irq(unsigned int irq) { enable_local2_irq(irq); - return 0; /* Never anything pending */ } @@ -192,6 +158,8 @@ save_and_cli(flags); ioc_icontrol->cmeimask0 &= ~(1 << (irq - SGINT_LOCAL2)); + if (!ioc_icontrol->cmeimask0) + ioc_icontrol->imask0 &= ~(1 << (SGI_MAP_0_IRQ - SGINT_LOCAL0)); restore_flags(flags); } @@ -217,18 +185,21 @@ static void enable_local3_irq(unsigned int irq) { +#ifdef I_REALLY_NEED_THIS_IRQ unsigned long flags; - + save_and_cli(flags); - printk("Yeeee, got passed irq_nr %d at enable_local3_irq\n", irq); - panic("Invalid IRQ level!"); + ioc_icontrol->imask1 |= (1 << (SGI_MAP_1_IRQ - SGINT_LOCAL1)); + ioc_icontrol->cmeimask1 |= (1 << (irq - SGINT_LOCAL3)); restore_flags(flags); +#else + panic("Who need local 3 irq? see indy_int.c\n"); +#endif } static unsigned int startup_local3_irq(unsigned int irq) { enable_local3_irq(irq); - return 0; /* Never anything pending */ } @@ -237,12 +208,9 @@ unsigned long flags; save_and_cli(flags); - /* - * This way we'll see if anyone would ever want vectored level 3 - * interrupts. Highly unlikely. - */ - printk("Yeeee, got passed irq_nr %d at disable_local3_irq\n", irq); - panic("Invalid IRQ level!"); + ioc_icontrol->cmeimask1 &= ~(1 << (irq - SGINT_LOCAL3)); + if (!ioc_icontrol->cmeimask1) + ioc_icontrol->imask1 &= ~(1 << (SGI_MAP_1_IRQ - SGINT_LOCAL1)); restore_flags(flags); } @@ -266,80 +234,6 @@ NULL }; -void enable_gio_irq(unsigned int irq) -{ - /* XXX TODO XXX */ -} - -static unsigned int startup_gio_irq(unsigned int irq) -{ - enable_gio_irq(irq); - - return 0; /* Never anything pending */ -} - -void disable_gio_irq(unsigned int irq) -{ - /* XXX TODO XXX */ -} - -#define shutdown_gio_irq disable_gio_irq -#define mask_and_ack_gio_irq disable_gio_irq - -static void end_gio_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_gio_irq(irq); -} - -static struct hw_interrupt_type ip22_gio_irq_type = { - "IP22 GIO", - startup_gio_irq, - shutdown_gio_irq, - enable_gio_irq, - disable_gio_irq, - mask_and_ack_gio_irq, - end_gio_irq, - NULL -}; - -void enable_hpcdma_irq(unsigned int irq) -{ - /* XXX TODO XXX */ -} - -static unsigned int startup_hpcdma_irq(unsigned int irq) -{ - enable_hpcdma_irq(irq); - - return 0; /* Never anything pending */ -} - -void disable_hpcdma_irq(unsigned int irq) -{ - /* XXX TODO XXX */ -} - -#define shutdown_hpcdma_irq disable_hpcdma_irq -#define mask_and_ack_hpcdma_irq disable_hpcdma_irq - -static void end_hpcdma_irq (unsigned int irq) -{ - if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) - enable_hpcdma_irq(irq); -} - -static struct hw_interrupt_type ip22_hpcdma_irq_type = { - "IP22 HPC DMA", - startup_hpcdma_irq, - shutdown_hpcdma_irq, - enable_hpcdma_irq, - disable_hpcdma_irq, - mask_and_ack_hpcdma_irq, - end_hpcdma_irq, - NULL -}; - void indy_local0_irqdispatch(struct pt_regs *regs) { unsigned char mask = ioc_icontrol->istat0; @@ -369,16 +263,17 @@ mask &= ioc_icontrol->imask1; if (mask & ISTAT1_LIO3) { - printk("WHee: Got an LIO3 irq, winging it...\n"); +#ifndef I_REALLY_NEED_THIS_IRQ + printk("Whee: Got an LIO3 irq, winging it...\n"); +#endif mask2 = ioc_icontrol->vmeistat; mask2 &= ioc_icontrol->cmeimask1; - irq = lc3msk_to_irqnr[ioc_icontrol->vmeistat]; + irq = lc3msk_to_irqnr[mask2]; } else { irq = lc1msk_to_irqnr[mask]; } /* if irq == 0, then the interrupt has already been cleared */ - /* not sure if it is needed here, but it is needed for local0 */ if (irq) do_IRQ(irq, regs); return; @@ -387,16 +282,35 @@ void indy_buserror_irq(struct pt_regs *regs) { int cpu = smp_processor_id(); - int irq = 6; + int irq = SGI_BUSERR_IRQ; irq_enter(cpu, irq); - kstat.irqs[0][irq]++; + kstat.irqs[cpu][irq]++; die("Got a bus error IRQ, shouldn't happen yet\n", regs); printk("Spinning...\n"); while(1); irq_exit(cpu, irq); } +static struct irqaction local0_cascade = + { no_action, SA_INTERRUPT, 0, "local0 cascade", NULL, NULL }; +static struct irqaction local1_cascade = + { no_action, SA_INTERRUPT, 0, "local1 cascade", NULL, NULL }; +static struct irqaction buserr = + { no_action, SA_INTERRUPT, 0, "Bus Error", NULL, NULL }; +static struct irqaction timer = + { no_action, SA_INTERRUPT, 0, "R4k Timer", NULL, NULL }; +static struct irqaction map0_cascade = + { no_action, SA_INTERRUPT, 0, "mappable0 cascade", NULL, NULL }; +#ifdef I_REALLY_NEED_THIS_IRQ +static struct irqaction map1_cascade = + { no_action, SA_INTERRUPT, 0, "mappable1 cascade", NULL, NULL }; +#endif + +extern int setup_irq(unsigned int irq, struct irqaction *irqaction); +extern void mips_cpu_irq_init(u32 irq_base); +extern void init_generic_irq(void); + void __init init_IRQ(void) { int i; @@ -407,45 +321,45 @@ /* Init local mask --> irq tables. */ for (i = 0; i < 256; i++) { if (i & 0x80) { - lc0msk_to_irqnr[i] = 7; - lc1msk_to_irqnr[i] = 15; - lc2msk_to_irqnr[i] = 23; - lc3msk_to_irqnr[i] = 31; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 7; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 7; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 7; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 7; } else if (i & 0x40) { - lc0msk_to_irqnr[i] = 6; - lc1msk_to_irqnr[i] = 14; - lc2msk_to_irqnr[i] = 22; - lc3msk_to_irqnr[i] = 30; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 6; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 6; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 6; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 6; } else if (i & 0x20) { - lc0msk_to_irqnr[i] = 5; - lc1msk_to_irqnr[i] = 13; - lc2msk_to_irqnr[i] = 21; - lc3msk_to_irqnr[i] = 29; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 5; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 5; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 5; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 5; } else if (i & 0x10) { - lc0msk_to_irqnr[i] = 4; - lc1msk_to_irqnr[i] = 12; - lc2msk_to_irqnr[i] = 20; - lc3msk_to_irqnr[i] = 28; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 4; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 4; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 4; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 4; } else if (i & 0x08) { - lc0msk_to_irqnr[i] = 3; - lc1msk_to_irqnr[i] = 11; - lc2msk_to_irqnr[i] = 19; - lc3msk_to_irqnr[i] = 27; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 3; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 3; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 3; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 3; } else if (i & 0x04) { - lc0msk_to_irqnr[i] = 2; - lc1msk_to_irqnr[i] = 10; - lc2msk_to_irqnr[i] = 18; - lc3msk_to_irqnr[i] = 26; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 2; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 2; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 2; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 2; } else if (i & 0x02) { - lc0msk_to_irqnr[i] = 1; - lc1msk_to_irqnr[i] = 9; - lc2msk_to_irqnr[i] = 17; - lc3msk_to_irqnr[i] = 25; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 1; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 1; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 1; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 1; } else if (i & 0x01) { - lc0msk_to_irqnr[i] = 0; - lc1msk_to_irqnr[i] = 8; - lc2msk_to_irqnr[i] = 16; - lc3msk_to_irqnr[i] = 24; + lc0msk_to_irqnr[i] = SGINT_LOCAL0 + 0; + lc1msk_to_irqnr[i] = SGINT_LOCAL1 + 0; + lc2msk_to_irqnr[i] = SGINT_LOCAL2 + 0; + lc3msk_to_irqnr[i] = SGINT_LOCAL3 + 0; } else { lc0msk_to_irqnr[i] = 0; lc1msk_to_irqnr[i] = 0; @@ -474,6 +388,8 @@ set_except_vector(0, indyIRQ); init_generic_irq(); + /* init CPU irqs */ + mips_cpu_irq_init(SGINT_CPU); for (i = SGINT_LOCAL0; i < SGINT_END; i++) { hw_irq_controller *handler; @@ -484,16 +400,27 @@ handler = &ip22_local1_irq_type; else if (i < SGINT_LOCAL3) handler = &ip22_local2_irq_type; - else if (i < SGINT_GIO) + else handler = &ip22_local3_irq_type; - else if (i < SGINT_HPCDMA) - handler = &ip22_gio_irq_type; - else if (i < SGINT_END) - handler = &ip22_hpcdma_irq_type; irq_desc[i].status = IRQ_DISABLED; irq_desc[i].action = 0; irq_desc[i].depth = 1; irq_desc[i].handler = handler; } + + /* vector handler. this register the IRQ as non-sharable */ + setup_irq(SGI_LOCAL_0_IRQ, &local0_cascade); + setup_irq(SGI_LOCAL_1_IRQ, &local1_cascade); + setup_irq(SGI_BUSERR_IRQ, &buserr); +/* This can't be enabled yet. we need to use CONFIG_NEW_TIME_C + * hopefully i'll rewrite it in couple of days. --ladis + setup_irq(SGI_TIMER_IRQ, &timer); +*/ + + /* cascade in cascade. i love Indy ;-) */ + setup_irq(SGI_MAP_0_IRQ, &map0_cascade); +#ifdef I_REALLY_NEED_THIS_IRQ + setup_irq(SGI_MAP_1_IRQ, &map1_cascade); +#endif } Index: linux/arch/mips/sgi/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi/kernel/setup.c,v retrieving revision 1.46 diff -u -r1.46 setup.c --- linux/arch/mips/sgi/kernel/setup.c 2001/08/23 22:24:24 1.46 +++ linux/arch/mips/sgi/kernel/setup.c 2001/11/16 12:10:08 @@ -302,7 +302,4 @@ #ifdef CONFIG_PSMOUSE aux_device_present = 0xaa; #endif -#ifdef CONFIG_VIDEO_VINO - init_vino(); -#endif } Index: linux/arch/mips/sgi/kernel/time.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi/kernel/time.c,v retrieving revision 1.6 diff -u -r1.6 time.c --- linux/arch/mips/sgi/kernel/time.c 2001/03/18 04:20:23 1.6 +++ linux/arch/mips/sgi/kernel/time.c 2001/11/16 12:10:08 @@ -13,7 +13,7 @@ int irq = 4; irq_enter(cpu, irq); - kstat.irqs[0][irq]++; + kstat.irqs[cpu][irq]++; printk("indy_8254timer_irq: Whoops, should not have gotten this IRQ\n"); prom_getchar(); ArcEnterInteractiveMode(); Index: linux/arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.144 diff -u -r1.144 config.in --- linux/arch/mips/config.in 2001/11/13 05:40:00 1.144 +++ linux/arch/mips/config.in 2001/11/16 12:43:33 @@ -177,6 +177,7 @@ define_bool CONFIG_BOARD_SCACHE y define_bool CONFIG_PC_KEYB y define_bool CONFIG_SGI y + define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_OLD_TIME_C y fi From owner-linux-mips@oss.sgi.com Fri Nov 16 05:23:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAGDN3b27711 for linux-mips-outgoing; Fri, 16 Nov 2001 05:23:03 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAGDN1g27707 for ; Fri, 16 Nov 2001 05:23:01 -0800 Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 164ixQ-0004mP-00; Fri, 16 Nov 2001 14:23:00 +0100 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 164iwC-0006BG-00; Fri, 16 Nov 2001 14:21:44 +0100 Date: Fri, 16 Nov 2001 14:21:43 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: [PATCH] indy_int clenaup Message-ID: <20011116142143.A23733@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ladislav.michl@hlubocky.del.cz on Fri, Nov 16, 2001 at 01:49:22PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 16, 2001 at 01:49:22PM +0100, Ladislav Michl wrote: > note for those, who are waiting for VINO driver: at the beginning I was > unable to start DMA transfer. now i'm unable to stop it... so to bring my > ego from dust, i decided to write HAL2 driver, which needs HPC interupts. > this patch is HAL2 driver by-product... I've done some work on porting Ulf's old ALSA HAL2 codebase to a more recent (0.9) version of alsa, could that be of any use to you? -- Guido From owner-linux-mips@oss.sgi.com Fri Nov 16 05:52:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAGDqi028468 for linux-mips-outgoing; Fri, 16 Nov 2001 05:52:44 -0800 Received: from hlubocky.del.cz (hlubocky.del.cz [212.27.221.67]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAGDqeg28465 for ; Fri, 16 Nov 2001 05:52:40 -0800 Received: from ladis (helo=localhost) by hlubocky.del.cz with local-esmtp (Exim 3.12 #1 (Debian)) id 164jPW-000786-00; Fri, 16 Nov 2001 14:52:02 +0100 Date: Fri, 16 Nov 2001 14:52:01 +0100 (CET) From: Ladislav Michl To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] indy_int clenaup In-Reply-To: <20011116142143.A23733@galadriel.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 16 Nov 2001, Guido Guenther wrote: > On Fri, Nov 16, 2001 at 01:49:22PM +0100, Ladislav Michl wrote: > > note for those, who are waiting for VINO driver: at the beginning I was > > unable to start DMA transfer. now i'm unable to stop it... so to bring my > > ego from dust, i decided to write HAL2 driver, which needs HPC interupts. > > this patch is HAL2 driver by-product... > I've done some work on porting Ulf's old ALSA HAL2 codebase to a more recent > (0.9) version of alsa, could that be of any use to you? wow, so many people working on HAL2 :-) Klaus? this is not useful for me, moreover i reworked HPC buffers handling (so maybye, it will be usefull for you :-)). OSS kernel driver is working now. it need some testing and cleanup, but it is mostly finished. i want to listen music, so i implemented pcm playback and mixer only. my plan is: 1. convience Ralf to include indy_int patch to cvs :-) 2. write and send CONFIG_NEW_TIME_C patch for Indy 3. once these will be included, send HAL2 driver. btw, if anyone wants to look at vino driver here it is: ftp://ftp.psi.cz/pub/ladis/vino/ regards, ladis From owner-linux-mips@oss.sgi.com Mon Nov 19 02:05:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAJA5lN14178 for linux-mips-outgoing; Mon, 19 Nov 2001 02:05:47 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAJA5hW14171 for ; Mon, 19 Nov 2001 02:05:43 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAJ95Ff27568; Mon, 19 Nov 2001 20:05:15 +1100 Date: Mon, 19 Nov 2001 20:05:15 +1100 From: Ralf Baechle To: renc stone Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ld error " linking PIC files with non-PIC files " Message-ID: <20011119200514.A26473@dea.linux-mips.net> References: <20011026161259.54925.qmail@web11908.mail.yahoo.com> <20011113200948.75977.qmail@web11908.mail.yahoo.com> <20011114111834.B10410@dea.linux-mips.net> <000a01c170d0$e8662000$101d690a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000a01c170d0$e8662000$101d690a@huawei.com>; from renwei@huawei.com on Mon, Nov 19, 2001 at 04:05:09PM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 19, 2001 at 04:05:09PM +0800, renc stone wrote: > That's the same problem as mine. > I try to use 64bit long long div& mod in one module, > and find I miss some _divdi3 and something like that. > > when I try to link my module with libgcc.a, in my mipsel-glibc 2.95.3, > the ld report the same thing. > > Does it mean I can't use 64bit div in module? How to get rid of this error? Again, it's a grave mistake to mix pic and non-pic libraries. To solve this you must either supply your own non-pic versions of the routines in question or - and better - try to avoid them. In your case take a look at which supplies a 64-bit by 32-bit division routine. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 19 05:31:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAJDVMM25683 for linux-mips-outgoing; Mon, 19 Nov 2001 05:31:22 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAJDVEW25675; Mon, 19 Nov 2001 05:31:14 -0800 Received: from wine.digital-digital.com ([210.122.73.240]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id EAA00373; Mon, 19 Nov 2001 04:31:12 -0800 (PST) mail_from (khs@digital-digital.com) Received: from khs ([210.122.73.37]) by wine.digital-digital.com (8.11.0/8.11.0) with SMTP id fAJCB9Q16460; Mon, 19 Nov 2001 21:11:09 +0900 Reply-To: From: "Han-Seong Kim" To: "'Ralf Baechle'" Cc: , Subject: RE: Power MGMT on mips Date: Mon, 19 Nov 2001 21:13:08 +0900 Message-ID: <000001c170f3$8d784d80$cbadfea9@khs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011112233031.A6493@dea.linux-mips.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id fAJDVFW25676 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Ralf, I reviewed the data sheet of Mips CPU - QED RM5231. There is a wait instruction. But when the SysAD bus goes to idle, the wait instruction is valid. How can I SysAD bus make idle state? Han-Seong -----Original Message----- From: Ralf Baechle [mailto:ralf@oss.sgi.com] Sent: Monday, November 12, 2001 9:31 PM To: Han-Seong Kim Cc: linux-mips@fnet.fr; linux-mips@oss.sgi.com Subject: Re: Power MGMT on mips On Mon, Nov 12, 2001 at 05:13:40PM +0900, Han-Seong Kim wrote: > I want to ask about Power-Mnagement on mips. > 1. Is it possible to use power mgnt (ex. apm,acpi) features of linux kernel? Both are PC stuff, so no. > 2.If no, how can manage CPU and Bidge chips for power mgnt ? Right now Linux/MIPS will only use the CPU's power managment features, that is the wait instruction or similar. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 19 09:19:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAJHJp609099 for linux-mips-outgoing; Mon, 19 Nov 2001 09:19:51 -0800 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAJHJiW09085 for ; Mon, 19 Nov 2001 09:19:44 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 10:19:23 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B743F@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: Memory mapping Date: Mon, 19 Nov 2001 10:18:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk OK, now that I've spent a couple weeks looking at Linux memory management, can someone please help me straighten this out. First, I have a requirement to "unobtrusively" hot-patch instruction code ( and probably data also ) segments in memory. I've decided that the best way to do this is to mmap device memory of a pseudo-device module to both the patching process and the target process. To the patching process it can be viewed as just RW data memory, but to the target process it must look like read-only executable. In addition I have found the find_task_by_pid() for getting the process descriptor for the target process. So... 1. Can I copy off the current task pointer and substitute the task pointer returned by find_task_by_pid() (in the pseudo-device mmap() call), and do remap_page_range() to map the memory to the target process? 2. Do I need to set task->has_cpu or any other controls to have the remap work? 3. The book "Understanding the Linux Kernel" has so many references to vm_area_struct that I'm confused as to when this memory area gets allocated, let alone who it belongs to in the mmap() call. I had thought I'd just do get_free_page() and mmap that address, but everything seems very convoluted with so many references in the API's to vm_area_struct: I can't seem to keep straight just what VM is supposed to be passed in the mmap() call, where it comes from, etc. Is this the [task]->active_mm->mmap vm_area_struct or should I look for another? HELP! Code deadline was supposed to be noon today ( I'm screwed ) and this is the main hitch holding me back. BTW, I can't tell why I'm doing this, so please don't ask... Keith Siders Software Engineer Toshiba America Consumer Products, Inc. Advanced Television Technology Center 801 Royal Parkway, Suite 100 Nashville, Tennessee 37214 Phone: (615) 257-4050 Fax: (615) 453-7880 From owner-linux-mips@oss.sgi.com Mon Nov 19 17:19:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAK1J2V17052 for linux-mips-outgoing; Mon, 19 Nov 2001 17:19:02 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAK1IxW17034 for ; Mon, 19 Nov 2001 17:19:00 -0800 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02253 for ; Mon, 19 Nov 2001 16:18:41 -0800 (PST) mail_from (kaos@melbourne.sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with ESMTP id fAK0FD413100982; Mon, 19 Nov 2001 16:15:14 -0800 (PST) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id A3559300095; Tue, 20 Nov 2001 11:15:10 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 438C796; Tue, 20 Nov 2001 11:15:10 +1100 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" Subject: Re: Memory mapping In-reply-to: Your message of "Mon, 19 Nov 2001 10:18:23 MDT." <7DF7BFDC95ECD411B4010090278A44CA1B743F@ATVX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 11:15:04 +1100 Message-ID: <9740.1006215304@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 19 Nov 2001 10:18:23 -0600, "Siders, Keith" wrote: >OK, now that I've spent a couple weeks looking at Linux memory management, >can someone please help me straighten this out. First, I have a requirement >to "unobtrusively" hot-patch instruction code ( and probably data also ) >segments in memory. At the risk of stating the obvious, have you looked at the ptrace code in arch/$(ARCH)/kernel/ptrace.c? That already does all the work for reading and writing code and data. From owner-linux-mips@oss.sgi.com Tue Nov 20 08:33:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAKGXHQ18152 for linux-mips-outgoing; Tue, 20 Nov 2001 08:33:17 -0800 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAKGXEW18148 for ; Tue, 20 Nov 2001 08:33:15 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 09:32:57 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B7446@ATVX> From: "Siders, Keith" To: "'Keith Owens'" Cc: "Linux-Mips (E-mail)" Subject: RE: Memory mapping Date: Tue, 20 Nov 2001 09:32:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk -> >OK, now that I've spent a couple weeks looking at Linux -> >memory management, -> >can someone please help me straighten this out. First, I -> >have a requirement -> >to "unobtrusively" hot-patch instruction code ( and -> >probably data also ) -> >segments in memory. -> -> At the risk of stating the obvious, have you looked at the -> ptrace code -> in arch/$(ARCH)/kernel/ptrace.c? That already does all the work for -> reading and writing code and data. -> Yep, most of what it does I have in the simple patch case: replace existing instructions. It did give me some things to check to make certain it works, though. Thanks. The other case requires adding code, so kernel space memory must be allocated and mmap'd. That's what I've been wrestling most with. From owner-linux-mips@oss.sgi.com Tue Nov 20 15:04:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAKN4Rv07663 for linux-mips-outgoing; Tue, 20 Nov 2001 15:04:27 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAKN4Oo07660 for ; Tue, 20 Nov 2001 15:04:24 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA08339 for ; Tue, 20 Nov 2001 14:04:20 -0800 (PST) mail_from (agx@gandalf.physik.uni-konstanz.de) Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 166IvH-0001sz-00; Tue, 20 Nov 2001 22:59:19 +0100 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 166Iu7-0006o9-00; Tue, 20 Nov 2001 22:58:07 +0100 Date: Tue, 20 Nov 2001 22:58:07 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: TrueColor on an Indy Message-ID: <20011120225807.A26150@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I just managed to get 24bpp to work on my Indy. I'll have to cleanup the code, but for all of you who can't wait...a patch against current xfree86 cvs can be found at: http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/24bpp-2001-11-20.diff There's one bug left. When the server comes up, you have to switch back and forth to the console once, to get the display right...hope to find it soon. -- Guido From owner-linux-mips@oss.sgi.com Tue Nov 20 15:09:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAKN96P07824 for linux-mips-outgoing; Tue, 20 Nov 2001 15:09:06 -0800 Received: from spinics.net (gte1-22.ce.ftel.net [206.24.95.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAKN91o07818 for ; Tue, 20 Nov 2001 15:09:05 -0800 Received: (from ellis@localhost) by spinics.net (8.11.6/8.11.6) id fAKM8rU23663 for linux-mips@oss.sgi.com; Tue, 20 Nov 2001 14:08:53 -0800 From: ellis@spinics.net Message-Id: <200111202208.fAKM8rU23663@spinics.net> Subject: ns83820 To: linux-mips@oss.sgi.com Date: Tue, 20 Nov 2001 14:08:53 -0800 (PST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Anybody used the ns83820 driver on a MIPS processor? I stopped working after a few packets when I try to use it. From owner-linux-mips@oss.sgi.com Tue Nov 20 15:15:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAKNF1i08183 for linux-mips-outgoing; Tue, 20 Nov 2001 15:15:01 -0800 Received: from fargo.cgs.pl (mail@fargo.cgs.poznan.pl [212.126.5.98]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAKNEvo08177 for ; Tue, 20 Nov 2001 15:14:58 -0800 Received: by fargo.cgs.pl (Postfix, from userid 1000) id E04B8141CC; Tue, 20 Nov 2001 23:14:44 +0100 (CET) Date: Tue, 20 Nov 2001 23:14:44 +0100 From: Krzysztof Krzyzaniak To: linux-mips@oss.sgi.com Subject: Re: TrueColor on an Indy Message-ID: <20011120231444.A3896@transilvania.eu.org> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011120225807.A26150@galadriel.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20011120225807.A26150@galadriel.physik.uni-konstanz.de> User-Agent: Mutt/1.3.23i X-Operating-System: Linux fargo 2.2.20pre8 X-Uptime: 23:13:16 up 71 days, 14:47, 12 users, load average: 0.15, 0.05, 0.01 X-Fingerprint: AC3A 464A DF87 6468 F63D CCB2 F8D3 1F49 DEB0 EC31 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 20, 2001 at 10:58:07PM +0100, Guido Guenther wrote: > Hi, > I just managed to get 24bpp to work on my Indy. I'll have to cleanup the > code, but for all of you who can't wait...a patch against current > xfree86 cvs can be found at: > http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/24bpp-2001-11-20.diff > There's one bug left. When the server comes up, you have to switch back > and forth to the console once, to get the display right...hope to find > it soon. You are my hero-of-the-day! Really! eloy -- . . . , . , | _ __. _.|_| |_| Krzysztof "eloy" Krzy¿aniak |(_) /_(_] | | Oficjalna strona kabaretu Lo¿a 44 http://loza44.topnet.pl/ Rolnicy! M³óckarnie i wialnie w pogotowiu. Wpierw m³ócimy, potem wiejemy. From owner-linux-mips@oss.sgi.com Tue Nov 20 19:38:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL3c8c24873 for linux-mips-outgoing; Tue, 20 Nov 2001 19:38:08 -0800 Received: from mcp.csh.rit.edu (mcp.csh.rit.edu [129.21.60.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAL3bxo24853 for ; Tue, 20 Nov 2001 19:37:59 -0800 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id 81649209; Tue, 20 Nov 2001 17:28:33 -0500 (EST) Date: Tue, 20 Nov 2001 17:28:29 -0500 (EST) From: George Gensure To: Guido Guenther Cc: Subject: Re: TrueColor on an Indy In-Reply-To: <20011120225807.A26150@galadriel.physik.uni-konstanz.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hoo rah, my man... hoo rah. George On Tue, 20 Nov 2001, Guido Guenther wrote: > Hi, > I just managed to get 24bpp to work on my Indy. I'll have to cleanup the > code, but for all of you who can't wait...a patch against current > xfree86 cvs can be found at: > http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/24bpp-2001-11-20.diff > There's one bug left. When the server comes up, you have to switch back > and forth to the console once, to get the display right...hope to find > it soon. > -- Guido > -- George R. Gensure Computer Science House Member werkt@csh.rit.edu Sophomore, Rochester Institute of Technology Computer Science From owner-linux-mips@oss.sgi.com Tue Nov 20 21:32:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL5WgR31269 for linux-mips-outgoing; Tue, 20 Nov 2001 21:32:42 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAL5WQo31253 for ; Tue, 20 Nov 2001 21:32:27 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAL4WLV09253; Wed, 21 Nov 2001 15:32:21 +1100 Date: Wed, 21 Nov 2001 15:32:21 +1100 From: Ralf Baechle To: ellis@spinics.net Cc: linux-mips@oss.sgi.com Subject: Re: ns83820 Message-ID: <20011121153221.A30470@dea.linux-mips.net> References: <200111202208.fAKM8rU23663@spinics.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111202208.fAKM8rU23663@spinics.net>; from ellis@spinics.net on Tue, Nov 20, 2001 at 02:08:53PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 20, 2001 at 02:08:53PM -0800, ellis@spinics.net wrote: > Anybody used the ns83820 driver on a MIPS processor? I stopped > working after a few packets when I try to use it. I've got no reports regarding the ns83820. From your description the problem might be some cache coherence problem which might be both an error in the driver or the MIPS code itself. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 20 23:14:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL7EJ404616 for linux-mips-outgoing; Tue, 20 Nov 2001 23:14:19 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAL7E6o04613; Tue, 20 Nov 2001 23:14:08 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Nov 2001 06:14:05 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id D5E47B46B; Wed, 21 Nov 2001 15:14:03 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA04964; Wed, 21 Nov 2001 15:14:03 +0900 (JST) Date: Wed, 21 Nov 2001 15:18:48 +0900 (JST) Message-Id: <20011121.151848.18315322.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: latest checksum.h From: Atsushi Nemoto 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Is it something wrong in latest checksum.h? a __asm__ statement in csum_fold() has two "r" operands but there are no "%1" in the assembler template. Is this OK? # No patch because I'm not a __asm__ hacker :-) --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Nov 21 00:14:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL8E7i07410 for linux-mips-outgoing; Wed, 21 Nov 2001 00:14:07 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAL8E4o07407 for ; Wed, 21 Nov 2001 00:14:04 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAL7Dxt12954; Wed, 21 Nov 2001 18:13:59 +1100 Date: Wed, 21 Nov 2001 18:13:59 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: latest checksum.h Message-ID: <20011121181359.A12936@dea.linux-mips.net> References: <20011121.151848.18315322.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011121.151848.18315322.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Nov 21, 2001 at 03:18:48PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 21, 2001 at 03:18:48PM +0900, Atsushi Nemoto wrote: > Is it something wrong in latest checksum.h? > > a __asm__ statement in csum_fold() has two "r" operands but there are > no "%1" in the assembler template. Is this OK? > > # No patch because I'm not a __asm__ hacker :-) One of the famous quick fixes that just happens to work because it was my lucky day ... Fix in cvs. Ralf From owner-linux-mips@oss.sgi.com Wed Nov 21 00:21:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL8LxL07842 for linux-mips-outgoing; Wed, 21 Nov 2001 00:21:59 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAL8Lno07836; Wed, 21 Nov 2001 00:21:49 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Nov 2001 07:21:48 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id C40C6B46B; Wed, 21 Nov 2001 15:59:02 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA05072; Wed, 21 Nov 2001 15:59:02 +0900 (JST) Date: Wed, 21 Nov 2001 16:03:47 +0900 (JST) Message-Id: <20011121.160347.48536367.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: FP exception statistics From: Atsushi Nemoto 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Sometimes I want to know what kind of (and how many times) FP exceptions occurred in run time. Here is a patch to provide us these informations via /proc/cpuinfo. Any comments are welcome. (This patch is not tested on SMP) diff -ur linux-sgi-cvs/arch/mips/config.in linux.new/arch/mips/config.in --- linux-sgi-cvs/arch/mips/config.in Wed Nov 21 10:31:56 2001 +++ linux.new/arch/mips/config.in Wed Nov 21 15:45:44 2001 @@ -359,6 +359,7 @@ else bool 'Generate little endian code' CONFIG_CPU_LITTLE_ENDIAN fi +bool 'Support for FPU Exception statistics' CONFIG_MIPS_FPE_STATS if [ "$CONFIG_PROC_FS" = "y" ]; then define_bool CONFIG_KCORE_ELF y diff -ur linux-sgi-cvs/arch/mips/kernel/proc.c linux.new/arch/mips/kernel/proc.c --- linux-sgi-cvs/arch/mips/kernel/proc.c Mon Oct 22 10:29:56 2001 +++ linux.new/arch/mips/kernel/proc.c Wed Nov 21 15:43:24 2001 @@ -19,6 +19,10 @@ #ifndef CONFIG_CPU_HAS_LLSC unsigned long ll_ops, sc_ops; #endif +#ifdef CONFIG_MIPS_FPE_STATS +unsigned int fpu_exceptions[6]; +static char fpe_types[6] = {'I', 'U', 'O', 'Z', 'V', 'E'}; +#endif /* * BUFFER is PAGE_SIZE bytes long. @@ -61,6 +65,9 @@ mach_nec_vr41xx_names}; unsigned int version = read_32bit_cp0_register(CP0_PRID); int len; +#ifdef CONFIG_MIPS_FPE_STATS + int i; +#endif len = sprintf(buffer, "cpu\t\t\t: MIPS\n"); len += sprintf(buffer + len, "cpu model\t\t: %s V%d.%d\n", @@ -101,6 +108,14 @@ ll_ops); len += sprintf(buffer + len, "sc emulations\t\t: %lu\n", sc_ops); +#endif +#ifdef CONFIG_MIPS_FPE_STATS + len += sprintf(buffer + len, "fpu exceptions\t\t:"); + for (i = 0; i < sizeof(fpu_exceptions) / sizeof(fpu_exceptions[0]); i++) { + len += sprintf(buffer + len, " %u(%c)", + fpu_exceptions[i], fpe_types[i]); + } + len += sprintf(buffer + len, "\n"); #endif return len; } diff -ur linux-sgi-cvs/arch/mips/kernel/traps.c linux.new/arch/mips/kernel/traps.c --- linux-sgi-cvs/arch/mips/kernel/traps.c Wed Nov 21 10:31:57 2001 +++ linux.new/arch/mips/kernel/traps.c Wed Nov 21 15:46:15 2001 @@ -461,6 +461,18 @@ */ asmlinkage void do_fpe(struct pt_regs *regs, unsigned long fcr31) { +#ifdef CONFIG_MIPS_FPE_STATS + extern unsigned int fpu_exceptions[]; + unsigned char fpe; + int i; + fpe = ((fcr31 & FPU_CSR_ALL_X) / FPU_CSR_INE_X) & + ((fcr31 | ~FPU_CSR_ALL_E) / FPU_CSR_INE_E); + for (i = 0; i < 6; i++) { + if (fpe & (1 << i)) + fpu_exceptions[i]++; + } +#endif + if (fcr31 & FPU_CSR_UNI_X) { extern void save_fp(struct task_struct *); extern void restore_fp(struct task_struct *); --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Nov 21 01:25:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAL9Phg12983 for linux-mips-outgoing; Wed, 21 Nov 2001 01:25:43 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAL9PZo12963 for ; Wed, 21 Nov 2001 01:25:41 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAL8PUC13477; Wed, 21 Nov 2001 19:25:30 +1100 Date: Wed, 21 Nov 2001 19:25:30 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: FP exception statistics Message-ID: <20011121192530.A13414@dea.linux-mips.net> References: <20011121.160347.48536367.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011121.160347.48536367.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Nov 21, 2001 at 04:03:47PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 21, 2001 at 04:03:47PM +0900, Atsushi Nemoto wrote: > Sometimes I want to know what kind of (and how many times) FP > exceptions occurred in run time. Here is a patch to provide us these > informations via /proc/cpuinfo. > > Any comments are welcome. (This patch is not tested on SMP) It get's atomicity wrong. I suggest to make such statistics a per thread thing. That'll not only solve the SMP issues but also make sure processes running in parallel won't influence the result. Ralf From owner-linux-mips@oss.sgi.com Wed Nov 21 04:48:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fALCmav01371 for linux-mips-outgoing; Wed, 21 Nov 2001 04:48:36 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fALCmQo01362; Wed, 21 Nov 2001 04:48:27 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 21 Nov 2001 11:48:26 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 30EB8B471; Wed, 21 Nov 2001 20:24:22 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id UAA05603; Wed, 21 Nov 2001 20:24:21 +0900 (JST) Date: Wed, 21 Nov 2001 20:29:06 +0900 (JST) Message-Id: <20011121.202906.28780735.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: Re: FP exception statistics From: Atsushi Nemoto In-Reply-To: <20011121192530.A13414@dea.linux-mips.net> References: <20011121.160347.48536367.nemoto@toshiba-tops.co.jp> <20011121192530.A13414@dea.linux-mips.net> 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Wed, 21 Nov 2001 19:25:30 +1100, Ralf Baechle said: ralf> It get's atomicity wrong. I suggest to make such statistics a ralf> per thread thing. That'll not only solve the SMP issues but ralf> also make sure processes running in parallel won't influence the ralf> result. Thank you for the comment. Yes, my patch provides "CPU" statistics (not "thread" statistics). Counting per thread might be useful in some case, but counting globally (like "unaligned_instructions" or "ll_ops" counter) is enough for me. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Wed Nov 21 06:00:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fALE0m906805 for linux-mips-outgoing; Wed, 21 Nov 2001 06:00:48 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fALE0jo06795 for ; Wed, 21 Nov 2001 06:00:45 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fALD0e121274; Thu, 22 Nov 2001 00:00:40 +1100 Date: Thu, 22 Nov 2001 00:00:40 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: FP exception statistics Message-ID: <20011122000040.A19180@dea.linux-mips.net> References: <20011121.160347.48536367.nemoto@toshiba-tops.co.jp> <20011121192530.A13414@dea.linux-mips.net> <20011121.202906.28780735.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011121.202906.28780735.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Nov 21, 2001 at 08:29:06PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 21, 2001 at 08:29:06PM +0900, Atsushi Nemoto wrote: > Yes, my patch provides "CPU" statistics (not "thread" statistics). > Counting per thread might be useful in some case, but counting > globally (like "unaligned_instructions" or "ll_ops" counter) is enough > for me. Those are certainly unlucky examples for performance counter interfaces. We have further problems to solve in that area. Many current cpus implement performance counters and right now Linux/MIPS doesn't use or support those at all. Unfortunately performance counter implementations differ wildly. We have to deciede about an interface that's supportable by all the hardware out there. Ralf From owner-linux-mips@oss.sgi.com Wed Nov 21 10:42:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fALIgwC31543 for linux-mips-outgoing; Wed, 21 Nov 2001 10:42:58 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fALIgro31540 for ; Wed, 21 Nov 2001 10:42:53 -0800 Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id HAA00430 for ; Sun, 18 Nov 2001 07:42:22 -0800 (PST) mail_from (thiruvengada.govindan@wipro.com) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id fAIFcd521692 for ; Sun, 18 Nov 2001 21:08:40 +0530 (IST) Received: from ecvwall1.wipro.com ([164.164.23.6]) by mailstore.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GN063N00.Q6M for ; Sun, 18 Nov 2001 21:08:11 +0530 Received: from wipro.com ([192.168.225.14]) by m3mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GN064400.7XU; Sun, 18 Nov 2001 21:08:28 +0530 Message-ID: <3BF7D74F.7E381427@wipro.com> Date: Sun, 18 Nov 2001 21:14:15 +0530 From: Thiruvengada Govindan Organization: Wipro Ltd. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, thiruvengada.govindan@wipro.com Subject: Linux on SC2000 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, i'm looking to getting Linux up on the LSI SC2000 platform, does anybody know of a Linux on SC2000. Also going through the manuals i found that the SC2000 TinyRISC CPU does not provide support for a user space mapped segment (even though address mapping is supported). Now is this true ??, is it that we can never have user space for Linux on the SC2000 ??. Thanks for any information on this, Govindan --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ --------------InterScan_NT_MIME_Boundary-- From owner-linux-mips@oss.sgi.com Wed Nov 21 13:19:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fALLJV310503 for linux-mips-outgoing; Wed, 21 Nov 2001 13:19:31 -0800 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fALLJNo10497 for ; Wed, 21 Nov 2001 13:19:23 -0800 Received: from excalibur.cologne.de (pD9511275.dip.t-dialin.net [217.81.18.117]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA16549; Wed, 21 Nov 2001 21:19:15 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 166dwG-0000yD-00; Wed, 21 Nov 2001 21:25:44 +0100 Date: Wed, 21 Nov 2001 21:25:44 +0100 From: Karsten Merker To: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: New gpm Debian package with DECstation support available Message-ID: <20011121212544.C957@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , debian-mips@lists.debian.org, linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hallo everybody, I have built a new unofficial gpm .deb with support for DECstation serial mice (DEC VS-XXX-AA) based on gpm_1.19.6-1. The package and its sources can be found at: ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/packages/experimental/ 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 owner-linux-mips@oss.sgi.com Wed Nov 21 16:25:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAM0PgY21798 for linux-mips-outgoing; Wed, 21 Nov 2001 16:25:42 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAM0Pdo21794 for ; Wed, 21 Nov 2001 16:25:40 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fALNPBm24300; Thu, 22 Nov 2001 10:25:11 +1100 Date: Thu, 22 Nov 2001 10:25:11 +1100 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20011122102511.B24183@dea.linux-mips.net> References: <200111180324.fAI3Ob928062@oss.sgi.com> <20011118092625.B23198@lug-owl.de> <001801c17019$56f562a0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001801c17019$56f562a0$0deca8c0@Ulysses>; from kevink@mips.com on Sun, Nov 18, 2001 at 11:10:52AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote: > > Did I miss something? > > Like the possibility that there are more MIPS-based > Laserjets than MIPS-based workstations in the world? > > Interesting platform, though. Consider the possibilities > of a hardcopy-only X display... ;-) Don't forget the possibilities of recycling your laserjet with network card and serial interface as a dialup router and firewall with a manipulation- proof logging device ;-) Ralf From owner-linux-mips@oss.sgi.com Wed Nov 21 16:36:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAM0acN22208 for linux-mips-outgoing; Wed, 21 Nov 2001 16:36:38 -0800 Received: from host099.momenco.com (IDENT:root@www.momenco.com [64.169.228.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAM0aWo22205; Wed, 21 Nov 2001 16:36:32 -0800 Received: from beagle (beagle.internal.momenco.com [192.168.0.115]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id fALNaNf12083; Wed, 21 Nov 2001 15:36:23 -0800 From: "Matthew Dharm" To: "Ralf Baechle" , "Kevin D. Kissell" Cc: "Jan-Benedict Glaw" , Subject: RE: CVS Update@oss.sgi.com: linux Date: Wed, 21 Nov 2001 15:36:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20011122102511.B24183@dea.linux-mips.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hrm... I wonder if you could make the fuser overheat to the point where the paper "log" burst into flames, thereby destroying it.... :) Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: owner-linux-mips@oss.sgi.com > [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle > Sent: Wednesday, November 21, 2001 3:25 PM > To: Kevin D. Kissell > Cc: Jan-Benedict Glaw; linux-mips@oss.sgi.com > Subject: Re: CVS Update@oss.sgi.com: linux > > > On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote: > > > > Did I miss something? > > > > Like the possibility that there are more MIPS-based > > Laserjets than MIPS-based workstations in the world? > > > > Interesting platform, though. Consider the possibilities > > of a hardcopy-only X display... ;-) > > Don't forget the possibilities of recycling your laserjet > with network card > and serial interface as a dialup router and firewall with a > manipulation- > proof logging device ;-) > > Ralf > From owner-linux-mips@oss.sgi.com Thu Nov 22 01:56:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAM9uI527578 for linux-mips-outgoing; Thu, 22 Nov 2001 01:56:18 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAM9uDo27560 for ; Thu, 22 Nov 2001 01:56:14 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 3CAF99F48; Thu, 22 Nov 2001 09:56:11 +0100 (CET) Date: Thu, 22 Nov 2001 09:56:11 +0100 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20011122095610.D23305@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <200111180324.fAI3Ob928062@oss.sgi.com> <20011118092625.B23198@lug-owl.de> <001801c17019$56f562a0$0deca8c0@Ulysses> <20011122102511.B24183@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011122102511.B24183@dea.linux-mips.net> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2001-11-22 10:25:11 +1100, Ralf Baechle wrote in message <20011122102511.B24183@dea.linux-mips.net>: > On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote: > > > > Did I miss something? > > > > Like the possibility that there are more MIPS-based > > Laserjets than MIPS-based workstations in the world? > > > > Interesting platform, though. Consider the possibilities > > of a hardcopy-only X display... ;-) > > Don't forget the possibilities of recycling your laserjet with network card > and serial interface as a dialup router and firewall with a manipulation- > proof logging device ;-) Well, here is a LP LJ 4+ (7 jears old...) flyin' around, and it doesn't seem to contain a MIPS CPU. Only a i960 and a custom HP processor is inside... Well, which models actually *are* fine to run Linux on them, and last question - do they keep printing while running linux? I don't think so... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 http://lug-owl.de/~jbglaw/software/snapshot2cvs/ From owner-linux-mips@oss.sgi.com Thu Nov 22 02:09:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMA9Zo29813 for linux-mips-outgoing; Thu, 22 Nov 2001 02:09:35 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMA9Vo29803 for ; Thu, 22 Nov 2001 02:09:31 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAM99TD11011 for ; Thu, 22 Nov 2001 10:09:29 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XK4A27W7; Thu, 22 Nov 2001 10:09:28 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 22 Nov 2001 10:09:28 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 10:08:45 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E3CA@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Cross Compiler again Date: Thu, 22 Nov 2001 10:08:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. For my environment I need a compiler that supports dwarf debug information. Sadly my precompiled version does not have this support so I tried it on my own, using Bradley D. LaRonde's HowTo. All went well but I had to learn that GCC 3.0.1 is not able to compile a current kernel. So I tried version 2.95.3, but I ran into the same problem that I had last time I tried such a thing. When compiling glibc the process failed because of a missing -D__PIC__ option. I was told that this has to do with a non-MIPS compiler that is used, but the compiler used is my previous build static version of gcc. I don't know what else may be wrong or where to look. Can anybody enlighten me? Or has anybody a precompiled gcc with dwarf support for download (That is able to compile a current kernel, of course. ;-) )? Best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Thu Nov 22 03:03:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMB3qK08273 for linux-mips-outgoing; Thu, 22 Nov 2001 03:03:52 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMB3no08261 for ; Thu, 22 Nov 2001 03:03:49 -0800 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 9EE17125C3; Thu, 22 Nov 2001 02:03:35 -0800 (PST) Received: by lucon.org (Postfix, from userid 1000) id E7A8BEBC9; Thu, 22 Nov 2001 02:03:34 -0800 (PST) Date: Thu, 22 Nov 2001 02:03:34 -0800 From: "H . J . Lu" To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011122020334.A3320@lucon.org> References: <86048F07C015D311864100902760F1DD01B5E3CA@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E3CA@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Thu, Nov 22, 2001 at 10:08:44AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 22, 2001 at 10:08:44AM +0100, Andre.Messerschmidt@infineon.com wrote: > Hi. > > For my environment I need a compiler that supports dwarf debug information. > Sadly my precompiled version does not have this support so I tried it on my > own, using Bradley D. LaRonde's HowTo. > All went well but I had to learn that GCC 3.0.1 is not able to compile a > current kernel. So I tried version 2.95.3, but I ran into the same problem > that I had last time I tried such a thing. When compiling glibc the process > failed because of a missing -D__PIC__ option. I was told that this has to do > with a non-MIPS compiler that is used, but the compiler used is my previous > build static version of gcc. > I don't know what else may be wrong or where to look. Can anybody enlighten > me? > > Or has anybody a precompiled gcc with dwarf support for download (That is > able to compile a current kernel, of course. ;-) )? > May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port supports dwarf, but not as default. I don't know how well it works with dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and native compiler are provided in my mips port. H.J. From owner-linux-mips@oss.sgi.com Thu Nov 22 03:19:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMBJE511017 for linux-mips-outgoing; Thu, 22 Nov 2001 03:19:14 -0800 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMBJ9o11005 for ; Thu, 22 Nov 2001 03:19:10 -0800 Received: from mullein.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA12664; Thu, 22 Nov 2001 11:18:58 +0100 (MET) Date: Thu, 22 Nov 2001 11:18:58 +0100 (MET) From: Geert Uytterhoeven To: Jan-Benedict Glaw cc: Linux/MIPS Development Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20011122095610.D23305@lug-owl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 22 Nov 2001, Jan-Benedict Glaw wrote: > On Thu, 2001-11-22 10:25:11 +1100, Ralf Baechle > wrote in message <20011122102511.B24183@dea.linux-mips.net>: > > On Sun, Nov 18, 2001 at 11:10:52AM +0100, Kevin D. Kissell wrote: > > > > > > Did I miss something? > > > > > > Like the possibility that there are more MIPS-based > > > Laserjets than MIPS-based workstations in the world? > > > > > > Interesting platform, though. Consider the possibilities > > > of a hardcopy-only X display... ;-) > > > > Don't forget the possibilities of recycling your laserjet with network card > > and serial interface as a dialup router and firewall with a manipulation- > > proof logging device ;-) > > Well, here is a LP LJ 4+ (7 jears old...) flyin' around, and it > doesn't seem to contain a MIPS CPU. Only a i960 and a custom HP > processor is inside... uClinux runs on various i960 incarnations. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Nov 22 05:43:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMDhR511849 for linux-mips-outgoing; Thu, 22 Nov 2001 05:43:27 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMDhNo11835 for ; Thu, 22 Nov 2001 05:43:23 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAMChID07721; Thu, 22 Nov 2001 13:43:19 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XK4AJNPF; Thu, 22 Nov 2001 13:43:17 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 22 Nov 2001 13:43:17 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 13:42:33 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E3CE@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: hjl@lucon.org Cc: linux-mips@oss.sgi.com Subject: RE: Cross Compiler again Date: Thu, 22 Nov 2001 13:42:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port > supports dwarf, but not as default. I don't know how well it works with > dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and > native compiler are provided in my mips port. > I need dwarf support because my debugger only supports dwarf. (It is an integrated simulation environment, where I cannot change the debugger to gdb). Do you have a download link for your mips port? regards Andre From owner-linux-mips@oss.sgi.com Thu Nov 22 08:37:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMGbQL20816 for linux-mips-outgoing; Thu, 22 Nov 2001 08:37:26 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGbKo20800 for ; Thu, 22 Nov 2001 08:37:20 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA11880; Thu, 22 Nov 2001 07:37:11 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA07072; Thu, 22 Nov 2001 07:37:12 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fAMFbBA01614; Thu, 22 Nov 2001 16:37:11 +0100 (MET) Message-ID: <3BFD1BA7.C4490465@mips.com> Date: Thu, 22 Nov 2001 16:37:11 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" , linux-mips@oss.sgi.com Subject: FPU test on RedHat7.1 Content-Type: multipart/mixed; boundary="------------9DC6D74387B6EA7415A6F4BB" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------9DC6D74387B6EA7415A6F4BB Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The attached tests fails on my RedHat7.1 system, but works fine on my old HardHat5.1. Anyone got any idea. compile: g++ -o fpu_test fpu_test.cc /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com --------------9DC6D74387B6EA7415A6F4BB Content-Type: text/plain; charset=iso-8859-15; name="fpu_test.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fpu_test.cc" #include #include int main( int argc,char * argv[ ] ) { double res; union { unsigned long long l; double d; } op1, op2; op1.l = 0x7fefffffffffffff; op2.l = 0x0000000000000001; printf("%llx %llx\n", op1.l, op2.l); res = remainder(op1.d, op2.d); printf("%llx\n", res); } --------------9DC6D74387B6EA7415A6F4BB-- From owner-linux-mips@oss.sgi.com Thu Nov 22 08:53:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMGr0a23510 for linux-mips-outgoing; Thu, 22 Nov 2001 08:53:00 -0800 Received: from ns1.ltc.com (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMGqjo23474 for ; Thu, 22 Nov 2001 08:52:50 -0800 Received: from prefect (unknown [10.1.1.86]) by ns1.ltc.com (Postfix) with SMTP id 715F2590A9; Thu, 22 Nov 2001 10:51:57 -0500 (EST) Message-ID: <002801c1736d$caac8d20$5601010a@prefect> From: "Bradley D. LaRonde" To: , References: <86048F07C015D311864100902760F1DD01B5E3CA@dlfw003a.dus.infineon.com> Subject: Re: Cross Compiler again Date: Thu, 22 Nov 2001 10:53:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----- Original Message ----- From: To: Sent: Thursday, November 22, 2001 4:08 AM Subject: Cross Compiler again > All went well but I had to learn that GCC 3.0.1 is not able to compile a > current kernel. I regularly use gcc 3.0.1 to build the latest oss cvs kernels without obvious incident. Regards, Brad From owner-linux-mips@oss.sgi.com Thu Nov 22 09:32:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMHWmL01733 for linux-mips-outgoing; Thu, 22 Nov 2001 09:32:48 -0800 Received: from rexonline-plc ([212.159.17.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMHWfo01684 for ; Thu, 22 Nov 2001 09:32:42 -0800 x-esmtp: 0 0 1 Message-ID: <1512534-220011142216331140@rex.co.uk> X-EM-Version: 6, 0, 0, 6 X-EM-Registration: #00F06206106618006920 X-Priority: 3 Reply-To: alex.bryant@rex.co.uk Organization: Rexonline Plc From: "Alex Bryant" To: "linux-mips@oss.sgi.com" Subject: Careers Link Date: Thu, 22 Nov 2001 16:33:01 -00 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 X-SMTPExp-Version: 1, 0, 2, 13 X-SMTPExp-Registration: 00B0320C107602006905 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dear Sir/Madam I am writing to you as your website currently links to the online recruitment site www.stepstone.co.uk. Earlier this month the site was closed. We would like to bring the following to your attention as an alternative career site recommendation to your visitors: www.jobmagic.net JobMagic.net is an online recruitment site offering vacancies from UK Employers and Recruitment Agencies, CV Distribution, Jobs by Email and other key features to help find your next job. www.career-ahead.co.uk Career Ahead is full of advice on CV writing, real-life scenarios, interview tips along with software to help you improve on your present career. Additionally we have two partner schemes: Add a job search engine to your site - www.jobmagic.net/addlink.asp Add your own online recruitment site - www.rexonline.co.uk/opportunity.htm If we can assist by offering you a reciprocal link or other opportunities that maybe of interest please contact me on the numbers below. Kind regards Alex Bryant RexOnline Plc T: 0845 130 4422 E: alex.bryant@rex.co.uk From owner-linux-mips@oss.sgi.com Thu Nov 22 10:14:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMIEjC09289 for linux-mips-outgoing; Thu, 22 Nov 2001 10:14:45 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMIEdo09285 for ; Thu, 22 Nov 2001 10:14:39 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAMHEbD11939 for ; Thu, 22 Nov 2001 18:14:37 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XK4AKARC; Thu, 22 Nov 2001 18:14:35 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 22 Nov 2001 18:14:30 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 18:13:47 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E3DA@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: AW: Cross Compiler again Date: Thu, 22 Nov 2001 18:13:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I regularly use gcc 3.0.1 to build the latest oss cvs kernels without > obvious incident. > I am using a 2.4.2 Kernel from Montavista, which is not working with gcc 3.0.1. Maybe it would be wise to upgrade. Does anybody know if there are any problems using a MIPS 5Kc with the current kernel? regards Andre From owner-linux-mips@oss.sgi.com Thu Nov 22 11:17:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMJHwv22920 for linux-mips-outgoing; Thu, 22 Nov 2001 11:17:58 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMJHro22897 for ; Thu, 22 Nov 2001 11:17:53 -0800 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 4DA75125C3; Thu, 22 Nov 2001 10:17:52 -0800 (PST) Received: by lucon.org (Postfix, from userid 1000) id 78DB7EBC9; Thu, 22 Nov 2001 10:17:51 -0800 (PST) Date: Thu, 22 Nov 2001 10:17:51 -0800 From: "H . J . Lu" To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011122101751.A1682@lucon.org> References: <86048F07C015D311864100902760F1DD01B5E3CE@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E3CE@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Thu, Nov 22, 2001 at 01:42:32PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 22, 2001 at 01:42:32PM +0100, Andre.Messerschmidt@infineon.com wrote: > > > May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port > > supports dwarf, but not as default. I don't know how well it works with > > dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and > > native compiler are provided in my mips port. > > > I need dwarf support because my debugger only supports dwarf. (It is an > integrated simulation environment, where I cannot change the debugger to > gdb). > > Do you have a download link for your mips port? > > regards > Andre My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You may need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. 5. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. Thanks. H.J. From owner-linux-mips@oss.sgi.com Thu Nov 22 11:39:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMJda327814 for linux-mips-outgoing; Thu, 22 Nov 2001 11:39:36 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMJdXo27805 for ; Thu, 22 Nov 2001 11:39:33 -0800 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id BD149125C3; Thu, 22 Nov 2001 10:39:31 -0800 (PST) Received: by lucon.org (Postfix, from userid 1000) id 29F54EBC9; Thu, 22 Nov 2001 10:39:31 -0800 (PST) Date: Thu, 22 Nov 2001 10:39:30 -0800 From: "H . J . Lu" To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: FPU test on RedHat7.1 Message-ID: <20011122103930.A2007@lucon.org> References: <3BFD1BA7.C4490465@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BFD1BA7.C4490465@mips.com>; from carstenl@mips.com on Thu, Nov 22, 2001 at 04:37:11PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 22, 2001 at 04:37:11PM +0100, Carsten Langgaard wrote: > The attached tests fails on my RedHat7.1 system, but works fine on my > old HardHat5.1. > Anyone got any idea. > > compile: > g++ -o fpu_test fpu_test.cc > Many FPU related tests in the current glibc from CVS failed on MIPS. I am planning to look into them. But I need to find time and docs on MIPS FPU. H.J. From owner-linux-mips@oss.sgi.com Thu Nov 22 15:30:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAMNUii04386 for linux-mips-outgoing; Thu, 22 Nov 2001 15:30:44 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAMNUTo04323 for ; Thu, 22 Nov 2001 15:30:29 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 1672MO-0001ns-00; Thu, 22 Nov 2001 16:30:21 -0600 Message-ID: <3BFD8860.2FC63231@cotw.com> Date: Thu, 22 Nov 2001 17:21:05 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, gdb@sources.redhat.com Subject: Failure to remote debug MIPS kernel modules... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Greetings. I first want to thank Dan J. for fixing binutils to address the error preventing proper parsing of the symbols so that GDB worked properly with remote MIPS kernel debugging. Now onto more of this issue. I am now working on remote debugging of MIPS kernel modules. I am utilizing the script from (http://kgdb.sourceforge.net/) to upload the module to my target and get the GDB script back. The problem that I am running into can be seen below in my run of GDB. I insert the module, there is a breakpoint in 'module.c' of course. I bring in the symbol table for the module and attempt to set a breakpoint. If I continue, the breakpoint in the module triggers, but GDB loses its marbles at this point as you can see below. It appears that it does not believe there to be a stack frame in existance. Does anyone have some insight on this? The tools and kernel source used were: binutils-20011121 gcc-3.0.2 gdb-20011121 linux-2.4.5 (last 2.4.5 code from SGI MIPS kernel tree) Any insight that people have on this would be very much appreciated. Usage of 'set heuristic-fence-post' did not help me at all. Thanks. -Steve ******************************************************************** ------------------------- COMPLETE GDB DEBUGGER RUN ------------------------- GNU gdb 2001-11-21-cvs Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-linux-elf"... (gdb) target remote /dev/ttyS1 Remote debugging using /dev/ttyS1 0x80012cc8 in breakinst () at gdb-stub.c:907 907 __asm__ __volatile__(" (gdb) c [MODULE GETS INSERTED] Program received signal SIGTRAP, Trace/breakpoint trap. 0x80012cc8 in breakinst () at gdb-stub.c:907 907 __asm__ __volatile__(" (gdb) source /opt/mips/gdbscripts/loadmtdchar.o add symbol table from file "/opt/mips/settop/drivers/mtd/mtdchar.o" at .text_addr = 0xc0000060 .reginfo_addr = 0xc0000fe0 .rodata_addr = 0xc0001000 .data_addr = 0xc0001120 .bss_addr = 0xc0001170 (gdb) maintenance print msymbols syms.txt (gdb) break mtdchar.c:548 Breakpoint 1 at 0xc0000f5c: file mtdchar.c, line 548. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. warning: Warning: GDB can't find the start of the function at 0xc0000f5c. GDB is unable to find the start of the function at 0xc0000f5c and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it. This problem is most likely caused by an invalid program counter or stack pointer. However, if you think GDB should simply search farther back from 0xc0000f5c for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command. 0xc0000f5c in ?? () (gdb) c Continuing. [NEVER RECOVERS] ----------------------------------------- FILE '/opt/mips/gdbscripts/loadmtdchar.o' ----------------------------------------- add-symbol-file /opt/mips/settop/drivers/mtd/mtdchar.o 0xc0000060 -s .reginfo 0x c0000fe0 -s .rodata 0xc0001000 -s .data 0xc0001120 -s .bss 0xc0001170 -------------------------- SNIPPET OF 'syms.txt' FILE -------------------------- Object file /opt/mips/settop/drivers/mtd/mtdchar.o: [ 0] d 0x0 __module_kernel_version section .modinfo [ 1] t 0xc0000060 mtd_lseek section .text [ 2] t 0xc0000144 mtd_open section .text [ 3] t 0xc00002d0 mtd_close section .text [ 4] t 0xc0000364 mtd_read section .text [ 5] t 0xc0000554 mtd_write section .text [ 6] t 0xc000077c mtd_erase_callback section .text [ 7] t 0xc00007a8 mtd_ioctl section .text [ 8] T 0xc0000f58 init_module section .text [ 9] t 0xc0000f58 init_mtdchar section .text [10] T 0xc0000fb4 cleanup_module section .text [11] t 0xc0000fb4 cleanup_mtdchar section .text [12] d 0xc0001120 mtd_fops section .data --------------------------- SNIPPET OF 'mtdchar.c' FILE --------------------------- 540: #if LINUX_VERSION_CODE < 0x20212 && defined(MODULE) 541: #define init_mtdchar init_module 542: #define cleanup_mtdchar cleanup_module 543: #endif 544: 545: mod_init_t init_mtdchar(void) 546: { 547: #ifdef CONFIG_DEVFS_FS 548: if (devfs_register_chrdev(MTD_CHAR_MAJOR, "mtd", &mtd_fops)) 549: { -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Thu Nov 22 17:14:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAN1Edn20867 for linux-mips-outgoing; Thu, 22 Nov 2001 17:14:39 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAN1Eco20856 for ; Thu, 22 Nov 2001 17:14:38 -0800 Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 1673zH-0001oq-00; Fri, 23 Nov 2001 01:14:35 +0100 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 1673y3-000599-00; Fri, 23 Nov 2001 01:13:19 +0100 Date: Fri, 23 Nov 2001 01:13:19 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: TrueColor on an Indy Message-ID: <20011123011319.A19776@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011120225807.A26150@galadriel.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011120225807.A26150@galadriel.physik.uni-konstanz.de>; from agx@sigxcpu.org on Tue, Nov 20, 2001 at 10:58:07PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 20, 2001 at 10:58:07PM +0100, Guido Guenther wrote: > http://honk.physik.uni-konstanz.de/~agx/mipslinux/x/24bpp-2001-11-20.diff I've also dumped a tar.gz of my X-server to the above location, compiled against current debian unstable. -- Guido From owner-linux-mips@oss.sgi.com Fri Nov 23 05:55:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fANDtOU13809 for linux-mips-outgoing; Fri, 23 Nov 2001 05:55:24 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANDtJo13806 for ; Fri, 23 Nov 2001 05:55:20 -0800 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 167FrS-0003BZ-00; Fri, 23 Nov 2001 13:55:18 +0100 Date: Fri, 23 Nov 2001 13:55:18 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: ralf@gnu.org Subject: emebedded ramdisk vs initrd Message-ID: <20011123135518.A12210@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com, ralf@gnu.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Trying to link in arch/mips/ramdisk/ramdisk.o whenever CONFIG_BLK_DEV_INITRD is defined is a bad idea, since there are other ways to use a ramdisk (bootloader, addinitrd). I suggest to use CONFIG_EMBEDDED_RAMDISK instead , since it's already used by sibyte/swarm. -- Guido --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ramdisk.diff" --- arch/mips/Makefile.orig Fri Nov 23 13:43:52 2001 +++ arch/mips/Makefile Fri Nov 23 13:46:37 2001 @@ -111,7 +111,7 @@ # You need a compressed ramdisk image, named ramdisk.gz in # arch/mips/ramdisk # -ifdef CONFIG_BLK_DEV_INITRD +ifdef CONFIG_EMBEDDED_RAMDISK CORE_FILES += arch/mips/ramdisk/ramdisk.o SUBDIRS += arch/mips/ramdisk endif --EVF5PPMfhYS0aIcm-- From owner-linux-mips@oss.sgi.com Fri Nov 23 06:23:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fANEN9o17575 for linux-mips-outgoing; Fri, 23 Nov 2001 06:23:09 -0800 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANEN8o17568 for ; Fri, 23 Nov 2001 06:23:08 -0800 Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 167GIN-0003Gi-00; Fri, 23 Nov 2001 14:23:07 +0100 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 167GHS-0000Hx-00; Fri, 23 Nov 2001 14:22:10 +0100 Date: Fri, 23 Nov 2001 14:22:10 +0100 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Re: emebedded ramdisk vs initrd Message-ID: <20011123142210.A32765@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011123135518.A12210@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011123135518.A12210@gandalf.physik.uni-konstanz.de>; from agx@sigxcpu.org on Fri, Nov 23, 2001 at 01:55:18PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 23, 2001 at 01:55:18PM +0100, Guido Guenther wrote: > Trying to link in arch/mips/ramdisk/ramdisk.o whenever > CONFIG_BLK_DEV_INITRD is defined is a bad idea, since there are other ...and therefore makes the compilation fail, I should add. -- Guido From owner-linux-mips@oss.sgi.com Fri Nov 23 07:54:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fANFssg31766 for linux-mips-outgoing; Fri, 23 Nov 2001 07:54:54 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANFsgo31720 for ; Fri, 23 Nov 2001 07:54:42 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA19112; Fri, 23 Nov 2001 06:54:34 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA20534; Fri, 23 Nov 2001 06:54:33 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fANEsVA26971; Fri, 23 Nov 2001 15:54:33 +0100 (MET) Message-ID: <3BFE6327.986D490C@mips.com> Date: Fri, 23 Nov 2001 15:54:31 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: FPU test on RedHat7.1 References: <3BFD1BA7.C4490465@mips.com> <20011122103930.A2007@lucon.org> Content-Type: multipart/mixed; boundary="------------B9EB53B4C32624550BB77E38" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------B9EB53B4C32624550BB77E38 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The file sysdeps/ieee754/dbl-64/e_remainder.c seems to have changed since glibc-2.2.2. I have attached the glibc-2.2.2 remainder file, which seems to work better. /Carsten "H . J . Lu" wrote: > On Thu, Nov 22, 2001 at 04:37:11PM +0100, Carsten Langgaard wrote: > > The attached tests fails on my RedHat7.1 system, but works fine on my > > old HardHat5.1. > > Anyone got any idea. > > > > compile: > > g++ -o fpu_test fpu_test.cc > > > > Many FPU related tests in the current glibc from CVS failed on MIPS. I > am planning to look into them. But I need to find time and docs on MIPS > FPU. > > H.J. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com --------------B9EB53B4C32624550BB77E38 Content-Type: text/plain; charset=iso-8859-15; name="e_remainder.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="e_remainder.c" /* @(#)e_remainder.c 5.1 93/09/24 */ /* * ==================================================== * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. * * Developed at SunPro, a Sun Microsystems, Inc. business. * Permission to use, copy, modify, and distribute this * software is freely granted, provided that this notice * is preserved. * ==================================================== */ #if defined(LIBM_SCCS) && !defined(lint) static char rcsid[] = "$NetBSD: e_remainder.c,v 1.8 1995/05/10 20:46:05 jtc Exp $"; #endif /* __ieee754_remainder(x,p) * Return : * returns x REM p = x - [x/p]*p as if in infinite * precise arithmetic, where [x/p] is the (infinite bit) * integer nearest x/p (in half way case choose the even one). * Method : * Based on fmod() return x-[x/p]chopped*p exactlp. */ #include "math.h" #include "math_private.h" #ifdef __STDC__ static const double zero = 0.0; #else static double zero = 0.0; #endif #ifdef __STDC__ double __ieee754_remainder(double x, double p) #else double __ieee754_remainder(x,p) double x,p; #endif { int32_t hx,hp; u_int32_t sx,lx,lp; double p_half; EXTRACT_WORDS(hx,lx,x); EXTRACT_WORDS(hp,lp,p); sx = hx&0x80000000; hp &= 0x7fffffff; hx &= 0x7fffffff; /* purge off exception values */ if((hp|lp)==0) return (x*p)/(x*p); /* p = 0 */ if((hx>=0x7ff00000)|| /* x not finite */ ((hp>=0x7ff00000)&& /* p is NaN */ (((hp-0x7ff00000)|lp)!=0))) return (x*p)/(x*p); if (hp<=0x7fdfffff) x = __ieee754_fmod(x,p+p); /* now x < 2p */ if (((hx-hp)|(lx-lp))==0) return zero*x; x = fabs(x); p = fabs(p); if (hp<0x00200000) { if(x+x>p) { x-=p; if(x+x>=p) x -= p; } } else { p_half = 0.5*p; if(x>p_half) { x-=p; if(x>=p_half) x -= p; } } GET_HIGH_WORD(hx,x); SET_HIGH_WORD(x,hx^sx); return x; } --------------B9EB53B4C32624550BB77E38-- From owner-linux-mips@oss.sgi.com Fri Nov 23 11:58:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fANJwN304884 for linux-mips-outgoing; Fri, 23 Nov 2001 11:58:23 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANJueo04869 for ; Fri, 23 Nov 2001 11:56:42 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA17000; Fri, 23 Nov 2001 19:46:44 +0100 (MET) Date: Fri, 23 Nov 2001 19:46:42 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: R3k DECstation FPU support Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, Here is an implementation of an FPU interrupt handler for R3k DECstations (R4k ones are fine with the dedicated exception). At first I thought only interrupt to do_fpe() glue is missing but to my surprise I discovered no R3k-class CPU is currently assumed to feature an FPU. As making use of an FPU is usually advantageous if one exists, I implemented an FPU detection function following guidelines given by my MIPS manual (I can't test an FPU-less system). I believe the code is stable as is. It does not provide any additional functionality beyond what is currently available to systems using the dedicated FPU exception. To verify an FPU is detected properly (the kernel does not report it in any way now) and FPU exceptions are delivered successfully the following program can be used. fdiv.c: #include #include #include int main(void) { double x, y, z; int r; fpu_control_t fpcw; unsigned int fpir; setvbuf(stdout, NULL, _IONBF, 0); _FPU_GETCW(fpcw); fpcw &= _FPU_RESERVED; fpcw |= _FPU_IEEE; _FPU_SETCW(fpcw); __asm__("cfc1 %0, $0" : "=r" (fpir) : : "memory"); _FPU_GETCW(fpcw); printf("FPCW: %08x\n", fpcw); printf("FPIR: %08x\n", fpir); __asm__(".set push\n\t" ".set reorder\n\t" "mtc1 %z4, %1\n\t" "mtc1 %z5, %2\n\t" "cvt.d.w %1, %1\n\t" "cvt.d.w %2, %2\n\t" ".set noreorder\n\t" "b 0f\n\t" " div.d %3, %1, %2\n\t" ".set reorder\n\t" "nop\n" "0:\n\t" "cvt.w.d %3, %3\n\t" "mfc1 %0, %3\n\t" ".set pop" : "=r" (r), "=f" (x), "=f" (y), "=f" (z) : "Jr" (0), "Jr" (0)); return r; } You should receive an output similar to one of the following ones: FPCW: 00000f80 FPIR: 00000340 Floating point exception for an R3k-class FPU, FPCW: 00000f80 FPIR: 00000500 Floating point exception for an R4k-class FPU, FPCW: 00000f80 FPIR: 00000000 Floating point exception for the FPU emulation (the Implementation and Revision register is zero). If you don't get an exception then there is a problem with FPU interrupt delivery -- please report it to me, especially if it happens for a DECstation. The patch includes a few minor clean-ups of nearby code as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-dec-fpu-9 diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/dec/int-handler.S linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/int-handler.S --- linux-mips-2.4.14-20011123-dist/arch/mips/dec/int-handler.S Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/int-handler.S Fri Nov 23 16:35:53 2001 @@ -2,7 +2,7 @@ * arch/mips/dec/int-handler.S * * Copyright (C) 1995, 1996, 1997 Paul M. Antoine and Harald Koerfgen - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki * * Written by Ralf Baechle and Andreas Busse, modified for DECStation * support by Paul Antoine and Harald Koerfgen. @@ -145,6 +145,9 @@ beqz t0,spurious + andi t2,t0,DEC_IE_FPU + bnez t2,fpu # handle FPU immediately + /* * Find irq with highest priority */ @@ -169,7 +172,7 @@ * Handle "IRQ Controller" Interrupts * Masked Interrupts are still visible and have to be masked "by hand". */ - EXPORT(kn02_io_int) + FEXPORT(kn02_io_int) kn02_io_int: # 3max lui t0,KN02_CSR_ADDR>>16 # get interrupt status and mask lw t0,(t0) @@ -179,7 +182,7 @@ kn02_io_int: # 3max b find_int and t0,t3 # mask out allowed ones - EXPORT(kn03_io_int) + FEXPORT(kn03_io_int) kn03_io_int: # 3max+ lui t2,KN03_IOASIC_BASE>>16 # upper part of IOASIC Address lw t0,SIR(t2) # get status: IOASIC isr @@ -188,7 +191,7 @@ kn03_io_int: # 3max+ b find_int and t0,t3 # mask out allowed ones - EXPORT(kn02xa_io_int) + FEXPORT(kn02xa_io_int) kn02xa_io_int: # 3min/maxine lui t2,KN02XA_IOASIC_BASE>>16 # upper part of IOASIC Address @@ -219,28 +222,27 @@ handle_it: jal do_IRQ j ret_from_irq nop +fpu: + j handle_fpe_int + nop + spurious: j spurious_interrupt nop END(decstation_handle_int) -/* - * Interrupt routines common to all DECStations first. - */ - EXPORT(dec_intr_fpu) -dec_intr_fpu: PANIC("Unimplemented FPU interrupt handler") /* * Generic unimplemented interrupt routines - ivec_tbl is initialised to * point all interrupts here. The table is then filled in by machine-specific * initialisation in dec_setup(). */ - EXPORT(dec_intr_unimplemented) + FEXPORT(dec_intr_unimplemented) dec_intr_unimplemented: mfc0 a1,CP0_CAUSE # cheats way of printing an arg! nop # to be sure... PANIC("Unimplemented cpu interrupt! CP0_CAUSE: 0x%x"); - EXPORT(asic_intr_unimplemented) + FEXPORT(asic_intr_unimplemented) asic_intr_unimplemented: move a1,t0 # cheats way of printing an arg! PANIC("Unimplemented asic interrupt! ASIC ISR: 0x%x"); diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/dec/setup.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/setup.c --- linux-mips-2.4.14-20011123-dist/arch/mips/dec/setup.c Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/setup.c Thu Nov 22 00:20:46 2001 @@ -6,7 +6,7 @@ * for more details. * * Copyright (C) 1998 Harald Koerfgen - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki */ #include #include @@ -55,7 +55,7 @@ extern int setup_dec_irq(int, struct irq void (*board_time_init) (struct irqaction * irq); -static struct irqaction irq10 = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; +static struct irqaction haltirq = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; /* * enable the periodic interrupts @@ -139,10 +139,10 @@ void __init dec_init_kn01(void) cpu_mask_tbl[4] = IE_IRQ4; cpu_irq_nr[4] = MEMORY; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU. + */ + set_cp0_status(DEC_IE_FPU); } /* dec_init_kn01 */ /* @@ -165,10 +165,10 @@ void __init dec_init_kn230(void) cpu_mask_tbl[0] = IE_IRQ2; cpu_irq_nr[0] = CLOCK; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU. + */ + set_cp0_status(DEC_IE_FPU); } /* dec_init_kn230 */ /* @@ -176,6 +176,8 @@ void __init dec_init_kn230(void) */ void __init dec_init_kn02(void) { + int dec_ie_io; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -184,10 +186,11 @@ void __init dec_init_kn02(void) imr = (void *) KN02_CSR_ADDR; /* - * Setup IOASIC interrupt + * Setup I/O interrupt */ + dec_ie_io = IE_IRQ0; cpu_ivec_tbl[1] = kn02_io_int; - cpu_mask_tbl[1] = IE_IRQ0; + cpu_mask_tbl[1] = dec_ie_io; cpu_irq_nr[1] = -1; *imr = *imr & 0xff00ff00; @@ -234,11 +237,10 @@ void __init dec_init_kn02(void) cpu_mask_tbl[2] = IE_IRQ3; cpu_irq_nr[2] = MEMORY; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[3] = IE_IRQ5; - cpu_irq_nr[3] = FPU; - + /* + * Enable board interrupts: FPU, I/O. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_io); } /* dec_init_kn02 */ /* @@ -246,6 +248,8 @@ void __init dec_init_kn02(void) */ void __init dec_init_kn02ba(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. */ @@ -257,9 +261,10 @@ void __init dec_init_kn02ba(void) /* * Setup IOASIC interrupt */ - cpu_mask_tbl[0] = IE_IRQ3; - cpu_irq_nr[0] = -1; + dec_ie_ioasic = IE_IRQ3; cpu_ivec_tbl[0] = kn02xa_io_int; + cpu_mask_tbl[0] = dec_ie_ioasic; + cpu_irq_nr[0] = -1; *imr = 0; /* @@ -315,12 +320,12 @@ void __init dec_init_kn02ba(void) cpu_mask_tbl[4] = IE_IRQ4; cpu_irq_nr[4] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn02ba */ /* @@ -328,6 +333,8 @@ void __init dec_init_kn02ba(void) */ void __init dec_init_kn02ca(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -339,9 +346,10 @@ void __init dec_init_kn02ca(void) /* * Setup IOASIC interrupt */ + dec_ie_ioasic = IE_IRQ3; cpu_ivec_tbl[1] = kn02xa_io_int; + cpu_mask_tbl[1] = dec_ie_ioasic; cpu_irq_nr[1] = -1; - cpu_mask_tbl[1] = IE_IRQ3; *imr = 0; /* @@ -392,12 +400,12 @@ void __init dec_init_kn02ca(void) cpu_mask_tbl[3] = IE_IRQ4; cpu_irq_nr[3] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[4] = IE_IRQ5; - cpu_irq_nr[4] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn02ca */ /* @@ -405,6 +413,8 @@ void __init dec_init_kn02ca(void) */ void __init dec_init_kn03(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -416,8 +426,9 @@ void __init dec_init_kn03(void) /* * Setup IOASIC interrupt */ + dec_ie_ioasic = IE_IRQ0; cpu_ivec_tbl[1] = kn03_io_int; - cpu_mask_tbl[1] = IE_IRQ0; + cpu_mask_tbl[1] = dec_ie_ioasic; cpu_irq_nr[1] = -1; *imr = 0; @@ -474,10 +485,10 @@ void __init dec_init_kn03(void) cpu_mask_tbl[3] = IE_IRQ4; cpu_irq_nr[3] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[4] = IE_IRQ5; - cpu_irq_nr[4] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn03 */ diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/entry.S linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/entry.S --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/entry.S Tue Nov 20 05:26:20 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/entry.S Fri Nov 23 14:50:11 2001 @@ -106,16 +106,16 @@ LEAF(spurious_interrupt) __INIT - /* - * General exception vector. Used for all CPUs except R4000 - * and R4400 SC and MC versions. - */ .set reorder NESTED(except_vec1_generic, 0, sp) PANIC("Exception vector 1 called") END(except_vec1_generic) + /* + * General exception vector. Used for all CPUs except R4000 + * and R4400 SC and MC versions. + */ NESTED(except_vec3_generic, 0, sp) mfc0 k1, CP0_CAUSE la k0, exception_handlers @@ -225,6 +225,7 @@ EXPORT(exception_count_##exception); NESTED(handle_##exception, PT_SIZE, sp); \ .set noat; \ SAVE_ALL; \ + FEXPORT(handle_##exception##_int); \ __BUILD_clear_##clear(exception); \ .set at; \ __BUILD_##verbose(exception); \ diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/setup.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/setup.c --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/setup.c Tue Nov 20 05:26:20 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/setup.c Fri Nov 23 14:50:11 2001 @@ -7,7 +7,7 @@ * Copyright (C) 1995 Waldorf Electronics * Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 Ralf Baechle * Copyright (C) 1996 Stoned Elipot - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki */ #include #include @@ -182,6 +182,28 @@ static inline int cpu_has_confreg(void) #endif } +/* + * Get the FPU Implementation/Revision. + */ +static inline unsigned long cpu_get_fpu_id(void) +{ + unsigned long tmp, fpu_id; + + tmp = read_32bit_cp0_register(CP0_STATUS); + write_32bit_cp0_register(CP0_STATUS, tmp | ST0_CU1); + fpu_id = read_32bit_cp1_register(CP1_REVISION); + write_32bit_cp0_register(CP0_STATUS, tmp); + return fpu_id; +} + +/* + * Check the CPU has an FPU the official way. + */ +static inline int cpu_has_fpu(void) +{ + return ((cpu_get_fpu_id() & 0xff00) != FPIR_IMP_NONE); +} + /* declaration of the global struct */ struct mips_cpu mips_cpu = {PRID_IMP_UNKNOWN, CPU_UNKNOWN, 0, 0, 0, {0,0,0,0}, {0,0,0,0}, {0,0,0,0}, {0,0,0,0}}; @@ -206,6 +228,8 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R2000; mips_cpu.isa_level = MIPS_CPU_ISA_I; mips_cpu.options = MIPS_CPU_TLB; + if (cpu_has_fpu()) + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; break; case PRID_IMP_R3000: @@ -218,6 +242,8 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R3000; mips_cpu.isa_level = MIPS_CPU_ISA_I; mips_cpu.options = MIPS_CPU_TLB; + if (cpu_has_fpu()) + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; break; case PRID_IMP_R4000: diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/traps.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/traps.c --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/traps.c Wed Nov 21 05:26:46 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/traps.c Fri Nov 23 14:50:11 2001 @@ -501,7 +501,6 @@ asmlinkage void do_fpe(struct pt_regs *r return; force_sig(SIGFPE, current); - printk(KERN_DEBUG "Sent send SIGFPE to %s\n", current->comm); } static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode) diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/cpu.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/cpu.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/cpu.h Fri Nov 23 14:46:34 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/cpu.h Fri Nov 23 15:08:18 2001 @@ -90,6 +90,17 @@ #define PRID_REV_TX3927C 0x0042 #define PRID_REV_TX39H3TEG 0x0050 +/* + * FPU implementation/revision register (CP1 control register 0). + * + * +---------------------------------+----------------+----------------+ + * | 0 | Implementation | Revision | + * +---------------------------------+----------------+----------------+ + * 31 16 15 8 7 0 + */ + +#define FPIR_IMP_NONE 0x0000 + #ifndef _LANGUAGE_ASSEMBLY /* * Capability and feature descriptor structure for MIPS CPU diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/dec/interrupts.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/dec/interrupts.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/dec/interrupts.h Tue Jul 3 04:27:22 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/dec/interrupts.h Wed Nov 21 23:57:52 2001 @@ -13,6 +13,8 @@ #ifndef __ASM_DEC_INTERRUPTS_H #define __ASM_DEC_INTERRUPTS_H +#include + /* * DECstation Interrupts */ @@ -22,7 +24,7 @@ * Exception: on kmins we have to handle Memory Error * Interrupts before the TC Interrupts. */ -#define CLOCK 0 +#define CLOCK 0 #define SCSI_DMA_INT 1 #define SCSI_INT 2 #define ETHER 3 @@ -31,10 +33,17 @@ #define TC1 6 #define TC2 7 #define MEMORY 8 -#define FPU 9 -#define HALT 10 +#define HALT 9 + +#define NR_INTS 10 -#define NR_INTS 11 +/* + * The FPU is special. It must always be handled first. + * Since it bypasses the regular IRQ handler we define + * the line it uses here. All DECstations use the same + * one. + */ +#define DEC_IE_FPU IE_IRQ5 #ifndef __ASSEMBLY__ /* @@ -70,8 +79,6 @@ extern long asic_mask_tbl[32]; * Common interrupt routine prototypes for all DECStations */ extern void dec_intr_unimplemented(void); -extern void dec_intr_fpu(void); -extern void dec_intr_rtc(void); extern void kn02_io_int(void); extern void kn02xa_io_int(void); diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/mipsregs.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/mipsregs.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/mipsregs.h Tue Nov 20 05:27:07 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/mipsregs.h Fri Nov 23 14:55:27 2001 @@ -508,6 +508,19 @@ :"=r" (__res)); \ __res;}) +/* + * Macros to access the floating point coprocessor control registers + */ +#define read_32bit_cp1_register(source) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tpush\n\t" \ + ".set\treorder\n\t" \ + "cfc1\t%0,"STR(source)"\n\t" \ + ".set\tpop" \ + : "=r" (__res)); \ + __res;}) + /* TLB operations. */ static inline void tlb_probe(void) { From owner-linux-mips@oss.sgi.com Fri Nov 23 12:42:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fANKgVM11465 for linux-mips-outgoing; Fri, 23 Nov 2001 12:42:31 -0800 Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fANKgTo11454 for ; Fri, 23 Nov 2001 12:42:29 -0800 Received: from adsl.pacbell.net ([63.194.214.47]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GN9000B9QQSG7@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Fri, 23 Nov 2001 11:42:28 -0800 (PST) Date: Fri, 23 Nov 2001 11:41:17 -0800 From: Pete Popov Subject: Re: emebedded ramdisk vs initrd In-reply-to: <20011123142210.A32765@galadriel.physik.uni-konstanz.de> To: Guido Guenther Cc: linux-mips@oss.sgi.com Message-id: <1006544477.1578.5.camel@adsl.pacbell.net> MIME-version: 1.0 X-Mailer: Evolution/0.16.100+cvs.2001.11.01.03.27 (Preview Release) Content-type: text/plain Content-transfer-encoding: 7bit References: <20011123135518.A12210@gandalf.physik.uni-konstanz.de> <20011123142210.A32765@galadriel.physik.uni-konstanz.de> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2001-11-23 at 05:22, Guido Guenther wrote: > On Fri, Nov 23, 2001 at 01:55:18PM +0100, Guido Guenther wrote: > > Trying to link in arch/mips/ramdisk/ramdisk.o whenever > > CONFIG_BLK_DEV_INITRD is defined is a bad idea, since there are other > ...and therefore makes the compilation fail, I should add. You need a ramdisk.gz in arch/mips/ramdisk. It shouldn't fail then. I think you're right about the CONFIG_EMBEDDED_RAMDISK though. Pete From owner-linux-mips@oss.sgi.com Fri Nov 23 17:27:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAO1RSB26972 for linux-mips-outgoing; Fri, 23 Nov 2001 17:27:28 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAO1RPo26968 for ; Fri, 23 Nov 2001 17:27:25 -0800 Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian)) id 167Qf0-0003BM-00 for ; Fri, 23 Nov 2001 16:27:10 -0800 Date: Fri, 23 Nov 2001 16:27:10 -0800 From: William Lee Irwin III To: linux-mips@oss.sgi.com Subject: advice on dz.c Message-ID: <20011123162710.D1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk startup() in the 2.4.14 dz.c appears to either not terminate or to bring down the kernel on a DecStation 5000/200. The 2.4.5 dz.c when put it in its place appears to work properly, modulo some strangeness in terminal emulation at runtime. Unfortunately, attempts to isolate what difference creates the problem failed to reveal the true cause of this. The kernel appears to die immediately after restore_flags(). This appears unusual to me as the changes are largely cosmetic. I also tried extending the extent of the code over which interrupts are disabled, to no avail. After extending it to what apparently was the entire extent of the driver's ->open code the kernel died somewhere between enabling interrupts again and the printk immediately after the return to tty_open(). It did not appear that the driver was re-entered at this point, as printk's for the other entry points failed to trigger. I am interested in suggestions as to what code changes I should make in order to bring this driver into a more robust state so that I myself can repair the code for use on one of my own personal machines. Thanks, Bill From owner-linux-mips@oss.sgi.com Fri Nov 23 20:01:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAO41BB20806 for linux-mips-outgoing; Fri, 23 Nov 2001 20:01:11 -0800 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAO418o20802 for ; Fri, 23 Nov 2001 20:01:08 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 167T3p-0002gZ-00; Fri, 23 Nov 2001 21:00:57 -0600 Message-ID: <3BFF1941.6421DBFB@cotw.com> Date: Fri, 23 Nov 2001 21:51:29 -0600 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.12-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: Philips Nino pre-compiled kernel image available... References: <3A2FB3CB.3566F805@mips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Greetings. I have uploaded a pre-compiled kernel image for the Philips Nino to my FTP site. It is the most recent kernel from the SGI MIPS kernel with a 512KB ramdisk image linked into it containing a stand alone shell. Simply upload to your Nino and use the PocketBSD bootloader to boot with. It is available at: ftp://ftp.cotw.com/Nino/kernel/vmlinux.bz2 -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Sat Nov 24 04:44:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAOCiqh04297 for linux-mips-outgoing; Sat, 24 Nov 2001 04:44:52 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAOCilo04286 for ; Sat, 24 Nov 2001 04:44:47 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 29D2E2B4BE; Sat, 24 Nov 2001 11:44:40 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id D237AC8CA; Sat, 24 Nov 2001 11:44:40 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id C0488E8C4; Sat, 24 Nov 2001 11:44:40 +0000 (GMT) Date: Sat, 24 Nov 2001 11:44:40 +0000 (GMT) From: Dave Airlie X-X-Sender: To: William Lee Irwin III Cc: Subject: Re: advice on dz.c In-Reply-To: <20011123162710.D1048@holomorphy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is unusual I've just taken a run down through a diff of 1.17 and 1.22 from the MIPS CVS tree and I can't see anything that could cause breakage that has been changed... I'd try commentined out the DZ_DEBUG stuff.. this isn't meant to be called... unless someone wants to specifically debug their dz.c on a decstation.... otherwise it should be switched off.. Granted to code doesn't look like it would compile with it off.. Dave. On Fri, 23 Nov 2001, William Lee Irwin III wrote: > startup() in the 2.4.14 dz.c appears to either not terminate or to > bring down the kernel on a DecStation 5000/200. The 2.4.5 dz.c when > put it in its place appears to work properly, modulo some strangeness > in terminal emulation at runtime. > > Unfortunately, attempts to isolate what difference creates the problem > failed to reveal the true cause of this. The kernel appears to die > immediately after restore_flags(). This appears unusual to me as the > changes are largely cosmetic. > > I also tried extending the extent of the code over which interrupts > are disabled, to no avail. After extending it to what apparently was > the entire extent of the driver's ->open code the kernel died somewhere > between enabling interrupts again and the printk immediately after > the return to tty_open(). It did not appear that the driver was > re-entered at this point, as printk's for the other entry points > failed to trigger. > > > I am interested in suggestions as to what code changes I should make > in order to bring this driver into a more robust state so that I myself > can repair the code for use on one of my own personal machines. > > > Thanks, > Bill > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Sat Nov 24 04:54:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAOCsig05045 for linux-mips-outgoing; Sat, 24 Nov 2001 04:54:44 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAOCsgo05036 for ; Sat, 24 Nov 2001 04:54:42 -0800 Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian)) id 167bO4-0004LE-00 for ; Sat, 24 Nov 2001 03:54:24 -0800 Date: Sat, 24 Nov 2001 03:54:24 -0800 From: William Lee Irwin III To: linux-mips@oss.sgi.com Subject: Re: advice on dz.c Message-ID: <20011124035424.F1048@holomorphy.com> References: <20011123162710.D1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from airlied@csn.ul.ie on Sat, Nov 24, 2001 at 11:44:40AM +0000 Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, Nov 24, 2001 at 11:44:40AM +0000, Dave Airlie wrote: > This is unusual I've just taken a run down through a diff of 1.17 and 1.22 > from the MIPS CVS tree and I can't see anything that could cause breakage > that has been changed... I'd try commentined out the DZ_DEBUG stuff.. this > isn't meant to be called... unless someone wants to specifically debug > their dz.c on a decstation.... otherwise it should be switched off.. > > Granted to code doesn't look like it would compile with it off.. > > Dave. I took a day out to look at it, I can spend more time on debugging it, as hacking the kernel into shape on this box is somewhat of a hobby project for me. I think the one thing I didn't take a look at was the copy_to_user() changes, so it could be useful to explore that, and I've got a couple of other tricks up my sleeve. Cheers, Bill From owner-linux-mips@oss.sgi.com Sat Nov 24 12:27:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAOKRlG03180 for linux-mips-outgoing; Sat, 24 Nov 2001 12:27:47 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAOKRfo03167 for ; Sat, 24 Nov 2001 12:27:41 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id BC8F4125C3; Sat, 24 Nov 2001 11:25:47 -0800 (PST) Date: Sat, 24 Nov 2001 11:25:47 -0800 From: "H . J . Lu" To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: FPU test on RedHat7.1 Message-ID: <20011124112547.A22621@lucon.org> References: <3BFD1BA7.C4490465@mips.com> <20011122103930.A2007@lucon.org> <3BFE6327.986D490C@mips.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BFE6327.986D490C@mips.com>; from carstenl@mips.com on Fri, Nov 23, 2001 at 03:54:31PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 23, 2001 at 03:54:31PM +0100, Carsten Langgaard wrote: > The file sysdeps/ieee754/dbl-64/e_remainder.c seems to have changed since > glibc-2.2.2. > I have attached the glibc-2.2.2 remainder file, which seems to work > better. > I believe it is a MIPS FPU related issue. glibc tries to do 1.7976931348623157e+308 - 8.5720688574901386e+301 * 2097152 and expects -1.9958403095e+292. However, on mips, I got -inf. Could you please look into it? Thanks. H.J. --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ieee.c" #include int main( int argc,char * argv[ ] ) { double res, d; union { unsigned long long l; double d; } op1, op2; op1.l = 0x7fefffffffffffffLL; op2.l = 0x7ea0000000000000LL; d = 2097152; res = op1.d - d * op2.d; printf("%llx\n", res); printf("%20.10e\n", res); } --sm4nu43k4a2Rpi4c-- From owner-linux-mips@oss.sgi.com Sat Nov 24 18:43:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAP2hJb20654 for linux-mips-outgoing; Sat, 24 Nov 2001 18:43:19 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAP2hHo20650 for ; Sat, 24 Nov 2001 18:43:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAP1hGV09707 for linux-mips@oss.sgi.com; Sun, 25 Nov 2001 12:43:16 +1100 Date: Sun, 25 Nov 2001 12:43:16 +1100 From: Ralf Baechle To: linux-mips@oss.sgi.com Subject: Re: emebedded ramdisk vs initrd Message-ID: <20011125124316.A9701@dea.linux-mips.net> References: <20011123135518.A12210@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011123135518.A12210@gandalf.physik.uni-konstanz.de>; from agx@sigxcpu.org on Fri, Nov 23, 2001 at 01:55:18PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Nov 23, 2001 at 01:55:18PM +0100, Guido Guenther wrote: > Trying to link in arch/mips/ramdisk/ramdisk.o whenever > CONFIG_BLK_DEV_INITRD is defined is a bad idea, since there are other > ways to use a ramdisk (bootloader, addinitrd). I suggest to use > CONFIG_EMBEDDED_RAMDISK instead , since it's already used by sibyte/swarm. Good idea, Ralf From owner-linux-mips@oss.sgi.com Sun Nov 25 01:24:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAP9OD500988 for linux-mips-outgoing; Sun, 25 Nov 2001 01:24:13 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAP9OBo00979 for ; Sun, 25 Nov 2001 01:24:11 -0800 Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian)) id 167uZt-0001vd-00 for ; Sun, 25 Nov 2001 00:23:53 -0800 Date: Sun, 25 Nov 2001 00:23:52 -0800 From: William Lee Irwin III To: linux-mips@oss.sgi.com Subject: FPU interrupt handler Message-ID: <20011125002352.G1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk EXPORT(dec_intr_fpu) dec_intr_fpu: PANIC("Unimplemented FPU interrupt handler") I've not encountered this quite yet, but I have an R3K-based DecStation up and running, and if I understand this properly, R3K delivers FPU exceptions as interrupts. It looks like this could take the machine down. Maciej, I was asked to notify you specifically, but this is my only known point of contact. If you could look into this, I would be much obliged. Thanks, Bill From owner-linux-mips@oss.sgi.com Sun Nov 25 10:13:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAPIDds29534 for linux-mips-outgoing; Sun, 25 Nov 2001 10:13:39 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAPIDZo29522 for ; Sun, 25 Nov 2001 10:13:35 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 1682qh-00048X-00; Sun, 25 Nov 2001 12:13:47 -0500 Date: Sun, 25 Nov 2001 12:13:47 -0500 From: Daniel Jacobowitz To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011125121347.A15890@nevyn.them.org> References: <86048F07C015D311864100902760F1DD01B5E3DA@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86048F07C015D311864100902760F1DD01B5E3DA@dlfw003a.dus.infineon.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 22, 2001 at 06:13:46PM +0100, Andre.Messerschmidt@infineon.com wrote: > > I regularly use gcc 3.0.1 to build the latest oss cvs kernels without > > obvious incident. > > > I am using a 2.4.2 Kernel from Montavista, which is not working with gcc > 3.0.1. > Maybe it would be wise to upgrade. Does anybody know if there are any > problems using a MIPS 5Kc with the current kernel? If you simply fix the one declaration it complains about (it involves adding 'volatile' to one of the two declarations of xtime) then this kernel actually will work under GCC 3.0.1. We haven't QA'd it, but I use it routinely for testing. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Sun Nov 25 20:31:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQ4VRd01878 for linux-mips-outgoing; Sun, 25 Nov 2001 20:31:27 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQ4V4o01869; Sun, 25 Nov 2001 20:31:04 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 26 Nov 2001 03:31:03 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 3AC96B475; Mon, 26 Nov 2001 12:30:59 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA18754; Mon, 26 Nov 2001 12:30:59 +0900 (JST) Date: Mon, 26 Nov 2001 12:35:45 +0900 (JST) Message-Id: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: new asm-mips/io.h From: Atsushi Nemoto 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk A last cleanups for io.h looks bit wrong. Please apply. --- linux-sgi-cvs/include/asm-mips/io.h Mon Nov 26 10:49:40 2001 +++ linux.new/include/asm-mips/io.h Mon Nov 26 12:06:31 2001 @@ -283,7 +283,7 @@ { while(count--) { outb(*(__u8 *)addr, port); - addr++; port++; + addr++; } } @@ -291,7 +291,7 @@ { while(count--) { *(__u8 *)addr = inb(port); - addr++; port++; + addr++; } } @@ -299,7 +299,7 @@ { while(count--) { outw(*(__u16 *)addr, port); - addr+=2; port+=2; + addr+=2; } } @@ -307,7 +307,7 @@ { while(count--) { *(__u16 *)addr = inw(port); - addr+=2; port+=2; + addr+=2; } } @@ -315,7 +315,7 @@ { while(count--) { outl(*(__u32 *)addr, port); - addr+=4; port+=4; + addr+=4; } } @@ -323,7 +323,7 @@ { while(count--) { *(__u32 *)addr = inw(port); - addr+=4; port+=4; + addr+=4; } } --- By the way, I have some boards which require special I/O routines. Some of these boards need byteswap on PCI I/O region but noswap on ISA region. And some of these boards do not require byteswap but need swap the address ('port' values). I added following codes to support these boards. Is it worth to apply? --- linux-sgi-cvs/include/asm-mips/io.h Mon Nov 26 10:49:40 2001 +++ linux.new/include/asm-mips/io.h Mon Nov 26 12:06:31 2001 @@ -352,5 +352,88 @@ #define dma_cache_wback_inv(start,size) _dma_cache_wback_inv(start,size) #define dma_cache_wback(start,size) _dma_cache_wback(start,size) #define dma_cache_inv(start,size) _dma_cache_inv(start,size) + +#ifdef CONFIG_HAVE_BOARD_IO_FUNCS +/* redefine all I/O access routines */ +struct mips_io_funcs { + void (*writeb)(unsigned char b, volatile unsigned char *addr); + void (*writew)(unsigned short b, volatile unsigned short *addr); + void (*writel)(unsigned int b, volatile unsigned int *addr); + unsigned char (*readb)(volatile unsigned char *addr); + unsigned short (*readw)(volatile unsigned short *addr); + unsigned int (*readl)(volatile unsigned int *addr); + void (*outb)(unsigned int value, unsigned long port); + void (*outw)(unsigned int value, unsigned long port); + void (*outl)(unsigned int value, unsigned long port); + unsigned char (*inb)(unsigned long port); + unsigned short (*inw)(unsigned long port); + unsigned int (*inl)(unsigned long port); + void (*outsb)(unsigned long port, const void *addr, unsigned int count); + void (*outsw)(unsigned long port, const void *addr, unsigned int count); + void (*outsl)(unsigned long port, const void *addr, unsigned int count); + void (*insb)(unsigned long port, void *addr, unsigned int count); + void (*insw)(unsigned long port, void *addr, unsigned int count); + void (*insl)(unsigned long port, void *addr, unsigned int count); + void (*memset_io)(volatile void *addr, int c, int len); + void (*memcpy_fromio)(void *to, volatile void *from, int len); + void (*memcpy_toio)(volatile void *to, const void *from, int len); +}; +/* board dependent part should declare this variable. */ +extern struct mips_io_funcs mips_io_funcs; +#undef writeb +#undef writew +#undef writel +#undef readb +#undef readw +#undef readl +#undef outb +#undef inb +#undef outb_p +#undef inb_p +#undef outw +#undef inw +#undef outw_p +#undef inw_p +#undef outl +#undef inl +#undef outl_p +#undef inl_p +#undef outsb +#undef insb +#undef outsw +#undef insw +#undef outsl +#undef insl +#undef memset_io +#undef memcpy_fromio +#undef memcpy_toio +#define writeb(b,addr) (*mips_io_funcs.writeb)(b, (volatile unsigned char *)(addr)) +#define writew(b,addr) (*mips_io_funcs.writew)(b, (volatile unsigned short *)(addr)) +#define writel(b,addr) (*mips_io_funcs.writel)(b, (volatile unsigned int *)(addr)) +#define readb(addr) (*mips_io_funcs.readb)((volatile unsigned char *)(addr)) +#define readw(addr) (*mips_io_funcs.readw)((volatile unsigned short *)(addr)) +#define readl(addr) (*mips_io_funcs.readl)((volatile unsigned int *)(addr)) +#define outb(val,port) (*mips_io_funcs.outb)((val),(port)) +#define inb(port) (*mips_io_funcs.inb)(port) +#define outb_p(val,port) (*mips_io_funcs.outb)((val),(port)) +#define inb_p(port) (*mips_io_funcs.inb)(port) +#define outw(val,port) (*mips_io_funcs.outw)((val),(port)) +#define inw(port) (*mips_io_funcs.inw)(port) +#define outw_p(val,port) (*mips_io_funcs.outw)((val),(port)) +#define inw_p(port) (*mips_io_funcs.inw)(port) +#define outl(val,port) (*mips_io_funcs.outl)((val),(port)) +#define inl(port) (*mips_io_funcs.inl)(port) +#define outl_p(val,port) (*mips_io_funcs.outl)((val),(port)) +#define inl_p(port) (*mips_io_funcs.inl)(port) +#define outsb(port,addr,count) (*mips_io_funcs.outsb)((port),(addr),(count)) +#define insb(port,addr,count) (*mips_io_funcs.insb)((port),(addr),(count)) +#define outsw(port,addr,count) (*mips_io_funcs.outsw)((port),(addr),(count)) +#define insw(port,addr,count) (*mips_io_funcs.insw)((port),(addr),(count)) +#define outsl(port,addr,count) (*mips_io_funcs.outsl)((port),(addr),(count)) +#define insl(port,addr,count) (*mips_io_funcs.insl)((port),(addr),(count)) +#define memset_io(a,b,c) (*mips_io_funcs.memset_io)((volatile void *)(a),(b),(c)) +#define memcpy_fromio(a,b,c) (*mips_io_funcs.memcpy_fromio)((a),(volatile void *)(b),(c)) +#define memcpy_toio(a,b,c) (*mips_io_funcs.memcpy_toio)((volatile void *)(a),(b),(c)) +#endif /* CONFIG_HAVE_BOARD_IO_FUNCS */ #endif /* _ASM_IO_H */ --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Mon Nov 26 02:00:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQA0n813569 for linux-mips-outgoing; Mon, 26 Nov 2001 02:00:49 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQA0io13563 for ; Mon, 26 Nov 2001 02:00:44 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAQ90eD24921; Mon, 26 Nov 2001 10:00:40 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X3V69JTS; Mon, 26 Nov 2001 10:00:39 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Mon, 26 Nov 2001 10:00:38 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 09:59:53 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E414@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: dan@debian.org Cc: linux-mips@oss.sgi.com Subject: RE: Cross Compiler again Date: Mon, 26 Nov 2001 09:59:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > If you simply fix the one declaration it complains about (it involves > adding 'volatile' to one of the two declarations of xtime) then this > kernel actually will work under GCC 3.0.1. We haven't QA'd it, but I > use it routinely for testing. > Thanks. Compiling now works, but the linker complains about undefined references: init/main.o: In function `init': init/main.c:794: relocation truncated to fit: R_MIPS_GPREL16 execute_command init/main.o: In function `parse_options': init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16 execute_command arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660' arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549' arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d31f): undefined reference to `L_E8867' arch/mips/kernel/kernel.o(.debug+0x8d3b6): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d3d8): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d52d): undefined reference to `L_E8867' arch/mips/kernel/kernel.o(.debug+0x8d5c4): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d5e6): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d6f2): undefined reference to `L_E8867' arch/mips/kernel/kernel.o(.debug+0x8d718): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d762): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x172bec): undefined reference to `L_E8153' arch/mips/kernel/kernel.o(.debug+0x19dea0): undefined reference to `L_E111' arch/mips/kernel/kernel.o(.debug+0x19debe): undefined reference to `L_E1321' arch/mips/kernel/kernel.o(.debug+0x1f64f2): undefined reference to `L_E7978' arch/mips/kernel/kernel.o(.debug+0x1f662a): undefined reference to `L_E7978' It goes on like this for 800 lines. Does anyone know why this happens? regards Andre From owner-linux-mips@oss.sgi.com Mon Nov 26 02:09:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQA9x913948 for linux-mips-outgoing; Mon, 26 Nov 2001 02:09:59 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAQA9uo13944 for ; Mon, 26 Nov 2001 02:09:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAQ99km09913; Mon, 26 Nov 2001 20:09:46 +1100 Date: Mon, 26 Nov 2001 20:09:46 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h Message-ID: <20011126200946.A8408@dea.linux-mips.net> References: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Nov 26, 2001 at 12:35:45PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 12:35:45PM +0900, Atsushi Nemoto wrote: > A last cleanups for io.h looks bit wrong. Please apply. Yes, the byteswapping stuff (CONFIG_SWAP_IO_SPACE) also got lost. > By the way, I have some boards which require special I/O routines. > Some of these boards need byteswap on PCI I/O region but noswap on ISA > region. And some of these boards do not require byteswap but need > swap the address ('port' values). I added following codes to support > these boards. Is it worth to apply? Not as is - the kernel has changed, so your patch wouldn't apply anymore. Aside of that I don't think we'll have any alternative to do something along the lines of your patch. There are for example systems where the high 8 bits of the I/O or memory address on the ISA bus are supplied in a separate register of the chipset, not as part of the memory address itself. It's really remarkable how much bad taste some hardware designers have ... Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 02:22:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQAMtT14543 for linux-mips-outgoing; Mon, 26 Nov 2001 02:22:55 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQAMoo14537 for ; Mon, 26 Nov 2001 02:22:50 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA07867; Mon, 26 Nov 2001 01:22:43 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA01000; Mon, 26 Nov 2001 01:22:39 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fAQ9McA14893; Mon, 26 Nov 2001 10:22:39 +0100 (MET) Message-ID: <3C0209E0.43747D9E@mips.com> Date: Mon, 26 Nov 2001 10:22:40 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: FPU test on RedHat7.1 References: <3BFD1BA7.C4490465@mips.com> <20011122103930.A2007@lucon.org> <3BFE6327.986D490C@mips.com> <20011124112547.A22621@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H . J . Lu" wrote: > On Fri, Nov 23, 2001 at 03:54:31PM +0100, Carsten Langgaard wrote: > > The file sysdeps/ieee754/dbl-64/e_remainder.c seems to have changed since > > glibc-2.2.2. > > I have attached the glibc-2.2.2 remainder file, which seems to work > > better. > > > > I believe it is a MIPS FPU related issue. glibc tries to do > > 1.7976931348623157e+308 - 8.5720688574901386e+301 * 2097152 > > and expects -1.9958403095e+292. However, on mips, I got -inf. Could you > please look into it? I believe this is ok, 8.5720688574901386e+301 * 2097152 is greater than 1.7976931348623157e+308 (which is the highest floating point number you can represent). So 1.7976931348623157e+308 - 8.5720688574901386e+301 * 2097152 do give -Inf on (I guess) all other architectures than i386, which have a double extended (80 bit / 64 bit mantisse) precision. I have tried the same calculation on a Sun (Sparc) and it also gives -Inf. So I guess the problem is in the e_remainder function. > > Thanks. > > H.J. > > ------------------------------------------------------------------------ > > ieee.cName: ieee.c > Type: Plain Text (text/plain) -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Nov 26 04:22:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQCMT620916 for linux-mips-outgoing; Mon, 26 Nov 2001 04:22:29 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAQCMQo20911 for ; Mon, 26 Nov 2001 04:22:27 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAQBMGt05368; Mon, 26 Nov 2001 22:22:16 +1100 Date: Mon, 26 Nov 2001 22:22:16 +1100 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: dan@debian.org, linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011126222216.C30436@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E414@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E414@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Mon, Nov 26, 2001 at 09:59:52AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 09:59:52AM +0100, Andre.Messerschmidt@infineon.com wrote: > init/main.o: In function `init': > init/main.c:794: relocation truncated to fit: R_MIPS_GPREL16 execute_command ^^^^^^^^^^^^^^ Shit in, shit out. You must be invoking the compiler with some option for GP relative optimization. Won't work. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 04:29:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQCT0v21296 for linux-mips-outgoing; Mon, 26 Nov 2001 04:29:00 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAQCSvo21293 for ; Mon, 26 Nov 2001 04:28:57 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAQBSt605409; Mon, 26 Nov 2001 22:28:55 +1100 Date: Mon, 26 Nov 2001 22:28:55 +1100 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011126222855.D30436@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E3DA@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E3DA@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Thu, Nov 22, 2001 at 06:13:46PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 22, 2001 at 06:13:46PM +0100, Andre.Messerschmidt@infineon.com wrote: > > I regularly use gcc 3.0.1 to build the latest oss cvs kernels without > > obvious incident. > > > I am using a 2.4.2 Kernel from Montavista, which is not working with gcc > 3.0.1. General rule for the kernel is don't use gcc 3.x. It's not only buggier than the older compilers, it also produces worse code. In particular it's know to misscompile certain drivers on other architectures. I'm still using egcs 1.1.2 which is known to be a very solid compiler. That may seem to be a bit overly conservative to some; for those I recommend a compiler derived from 2.95.3. > Maybe it would be wise to upgrade. Does anybody know if there are any > problems using a MIPS 5Kc with the current kernel? Nothing that's known. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 04:59:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQCxnf22568 for linux-mips-outgoing; Mon, 26 Nov 2001 04:59:49 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQCxXo22564 for ; Mon, 26 Nov 2001 04:59:36 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA24991; Mon, 26 Nov 2001 12:57:24 +0100 (MET) Date: Mon, 26 Nov 2001 12:57:23 +0100 (MET) From: "Maciej W. Rozycki" To: William Lee Irwin III cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <20011125002352.G1048@holomorphy.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, 25 Nov 2001, William Lee Irwin III wrote: > EXPORT(dec_intr_fpu) > dec_intr_fpu: PANIC("Unimplemented FPU interrupt handler") > > I've not encountered this quite yet, but I have an R3K-based > DecStation up and running, and if I understand this properly, > R3K delivers FPU exceptions as interrupts. It looks like > this could take the machine down. Nope, R3k DECstations used to use the FPU emulator unconditionally. :-( This would have never got triggered. An FPU interrupt-to-exception glue was non-existent. > Maciej, I was asked to notify you specifically, but this is > my only known point of contact. If you could look into this, > I would be much obliged. No need to do anything -- I happened to work on the FPU a bit recently and I sent a patch here on Friday that adds the glue, enables the FPU and rips the broken code off. Ralf has already applied the patch. I would *really* appreciate any feedback on DECstation patches I'm sending here -- for quite some time I have a feeling I'm the last one to run Linux on a DECstation... :-( Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 05:08:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQD8Fq23017 for linux-mips-outgoing; Mon, 26 Nov 2001 05:08:15 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQD7io22997; Mon, 26 Nov 2001 05:07:47 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA25196; Mon, 26 Nov 2001 13:06:28 +0100 (MET) Date: Mon, 26 Nov 2001 13:06:26 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: Cross Compiler again In-Reply-To: <20011126222855.D30436@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 26 Nov 2001, Ralf Baechle wrote: > General rule for the kernel is don't use gcc 3.x. It's not only buggier > than the older compilers, it also produces worse code. In particular it's > know to misscompile certain drivers on other architectures. I'm still > using egcs 1.1.2 which is known to be a very solid compiler. That may seem > to be a bit overly conservative to some; for those I recommend a compiler > derived from 2.95.3. I'll just add that I'm particularly happy with 2.95.3 with a set of patches. I'm using it for one about year and a half now (it was 2.95.2 then, but MIPS changes are the same) and the last fix I made was in April. No problems since then both for the kernel and the userland. The C++ backend is unchecked, though. An RPM package is available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'; you may extract patches and build it manually if you don't use RPM. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 05:20:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQDK6h23638 for linux-mips-outgoing; Mon, 26 Nov 2001 05:20:06 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQDK1o23634 for ; Mon, 26 Nov 2001 05:20:02 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id NAA22712; Mon, 26 Nov 2001 13:19:57 +0100 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id NAA10058; Mon, 26 Nov 2001 13:19:56 +0100 (MET) Message-Id: <200111261219.NAA10058@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Maciej W. Rozycki" cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: FPU interrupt handler In-reply-to: Your message of "Mon, 26 Nov 2001 12:57:23 +0100." Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Nov 2001 13:19:56 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Maciej You wrote: > > I would *really* appreciate any feedback on DECstation patches I'm > sending here -- for quite some time I have a feeling I'm the last one to > run Linux on a DECstation... :-( > I would love to do more work on my DECstation, but I had some disk problems recently, and I don't seem te get any newer kernels then 2.4.0-test9 running after a native compile by the toolchain provided by H.J. Lu. Some kernels don't start-up, others hang just before forking init, and all have problems with my serial console. When I get a recent kernel running again, I would love to update my DECStation Linux Website with newer instructions and a new root FS. Regards, -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Mon Nov 26 06:09:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQE9Kn25912 for linux-mips-outgoing; Mon, 26 Nov 2001 06:09:20 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQE9Fo25904; Mon, 26 Nov 2001 06:09:15 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA01794; Mon, 26 Nov 2001 05:08:47 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA25196; Mon, 26 Nov 2001 13:06:28 +0100 (MET) Date: Mon, 26 Nov 2001 13:06:26 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: Cross Compiler again In-Reply-To: <20011126222855.D30436@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 26 Nov 2001, Ralf Baechle wrote: > General rule for the kernel is don't use gcc 3.x. It's not only buggier > than the older compilers, it also produces worse code. In particular it's > know to misscompile certain drivers on other architectures. I'm still > using egcs 1.1.2 which is known to be a very solid compiler. That may seem > to be a bit overly conservative to some; for those I recommend a compiler > derived from 2.95.3. I'll just add that I'm particularly happy with 2.95.3 with a set of patches. I'm using it for one about year and a half now (it was 2.95.2 then, but MIPS changes are the same) and the last fix I made was in April. No problems since then both for the kernel and the userland. The C++ backend is unchecked, though. An RPM package is available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'; you may extract patches and build it manually if you don't use RPM. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 06:24:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQEOS629555 for linux-mips-outgoing; Mon, 26 Nov 2001 06:24:28 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAQEOPo29550 for ; Mon, 26 Nov 2001 06:24:26 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAQDO5l15174; Tue, 27 Nov 2001 00:24:05 +1100 Date: Tue, 27 Nov 2001 00:24:05 +1100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: William Lee Irwin III , linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler Message-ID: <20011127002405.E5465@dea.linux-mips.net> References: <20011125002352.G1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 12:57:23PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 12:57:23PM +0100, Maciej W. Rozycki wrote: > I would *really* appreciate any feedback on DECstation patches I'm > sending here -- for quite some time I have a feeling I'm the last one to > run Linux on a DECstation... :-( Certainly not, on the recent Linux porter meating it was probably the most used type of non-x86 machine. So rather blame general passivity of man kind ... Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 06:39:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQEdb605730 for linux-mips-outgoing; Mon, 26 Nov 2001 06:39:37 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQEdVo05721; Mon, 26 Nov 2001 06:39:31 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAQDdTD12640; Mon, 26 Nov 2001 14:39:29 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X3V60CFL; Mon, 26 Nov 2001 14:39:27 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Mon, 26 Nov 2001 14:39:26 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 14:38:40 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E418@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: AW: Cross Compiler again Date: Mon, 26 Nov 2001 14:38:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Shit in, shit out. You must be invoking the compiler with some option for > GP relative optimization. Won't work. > A typical gcc call is like this: gcc -Wall -Wstrict-prototypes -O2 -mno-abicalls -fno-pic -mcpu=r4000 -D_32_ -mips2 -Wa,--trap -pipe -c foo.c -o foo.o Is there any option missing that might me defaulting to such an optimization? I have played with the different -O# options without success. regards Andre From owner-linux-mips@oss.sgi.com Mon Nov 26 06:48:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQEmA206081 for linux-mips-outgoing; Mon, 26 Nov 2001 06:48:10 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAQEm7o06078 for ; Mon, 26 Nov 2001 06:48:07 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAQDm4R15454; Tue, 27 Nov 2001 00:48:04 +1100 Date: Tue, 27 Nov 2001 00:48:04 +1100 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011127004804.A15327@dea.linux-mips.net> References: <86048F07C015D311864100902760F1DD01B5E418@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DD01B5E418@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Mon, Nov 26, 2001 at 02:38:39PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 02:38:39PM +0100, Andre.Messerschmidt@infineon.com wrote: > > Shit in, shit out. You must be invoking the compiler with some option for > > GP relative optimization. Won't work. > > > A typical gcc call is like this: > gcc -Wall -Wstrict-prototypes -O2 -mno-abicalls -fno-pic -mcpu=r4000 -D_32_ > -mips2 -Wa,--trap -pipe -c foo.c -o foo.o > > Is there any option missing that might me defaulting to such an > optimization? -G 0. > I have played with the different -O# options without success. What compiler are you using? All compilers I've ever released did default to -G 0. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 06:52:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQEqA806281 for linux-mips-outgoing; Mon, 26 Nov 2001 06:52:10 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQEpqo06266 for ; Mon, 26 Nov 2001 06:51:56 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA28734; Mon, 26 Nov 2001 14:50:13 +0100 (MET) Date: Mon, 26 Nov 2001 14:50:13 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: FPU interrupt handler In-Reply-To: <200111261219.NAA10058@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Karel, > I would love to do more work on my DECstation, but I had some disk > problems recently, and I don't seem te get any newer kernels > then 2.4.0-test9 running after a native compile by the toolchain > provided by H.J. Lu. Hmm, for R3k gcc 2.95.3 + binutils 2.11.2 as available at my site seem to be rock solid. For R4k you need binutils 2.11.92, as there is a problem with dla/la expansion in the Ulf's patch for .mips3+. That actually can be fixed in 2.11.2 easily but I was going to switch to 2.11.92 anyway, as it has more MIPS/Linux support integrated and 2.12 is supposedly soon to be released. Unfortunately 2.11.92 is not as stable as 2.11.2 due to generic ELF code problems, but I'm trying to track changes and spot a more stable snapshot. > Some kernels don't start-up, others hang just before forking init, > and all have problems with my serial console. Well, I'm very happy with a /240 running a 2.4.14 snapshot dated 20011123. For a /260 I need a small, but critical bugfix I'm sending to the list right now. I wonder how was it possible for the bug to remain uncovered for so long as it's absolutely lethal and often triggered (I've only got my /260 recently and it wasn't even running a few minutes continuously before the fix). I can't comment other models. > When I get a recent kernel running again, I would love to update my > DECStation Linux Website with newer instructions and a new root FS. I may upload binaries of my kernels to my site if they are to be useful -- they are fully monolithic (but with kmod support) due to historical reasons. Only IPv6 is modular due to its unstability -- it freezes the system immediately on my /240 and splashes a bunch of suspicious messages on my /260 (weird, but no time to debug). They only support /240 and /260 due to CONFIG_CPU_HAS_WB unset. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 07:08:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQF83c06913 for linux-mips-outgoing; Mon, 26 Nov 2001 07:08:03 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQF7uo06909 for ; Mon, 26 Nov 2001 07:07:56 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id PAA23894; Mon, 26 Nov 2001 15:07:54 +0100 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id PAA11348; Mon, 26 Nov 2001 15:07:54 +0100 (MET) Message-Id: <200111261407.PAA11348@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "Maciej W. Rozycki" cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-reply-to: Your message of "Mon, 26 Nov 2001 14:50:13 +0100." Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Nov 2001 15:07:54 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Maciej, > Hmm, for R3k gcc 2.95.3 + binutils 2.11.2 as available at my site seem to > be rock solid. > > For R4k you need binutils 2.11.92, as there is a problem with dla/la > expansion in the Ulf's patch for .mips3+. That actually can be fixed in > 2.11.2 easily but I was going to switch to 2.11.92 anyway, as it has more > MIPS/Linux support integrated and 2.12 is supposedly soon to be released. > Unfortunately 2.11.92 is not as stable as 2.11.2 due to generic ELF code > problems, but I'm trying to track changes and spot a more stable snapshot. I'm using the RedHat 7.1 packages from oss: binutils-2.11.92.0.10-1.mips.rpm gcc-2.96-99.1.mips.rpm > > Some kernels don't start-up, others hang just before forking init, > > and all have problems with my serial console. > > Well, I'm very happy with a /240 running a 2.4.14 snapshot dated > 20011123. For a /260 I need a small, but critical bugfix I'm sending to > the list right now. I wonder how was it possible for the bug to remain > uncovered for so long as it's absolutely lethal and often triggered (I've > only got my /260 recently and it wasn't even running a few minutes > continuously before the fix). My 'main' mips box at home is a /260. I sometimes test things out on a /240, but I don't have access to other boxes. > I can't comment other models. > > > When I get a recent kernel running again, I would love to update my > > DECStation Linux Website with newer instructions and a new root FS. > > I may upload binaries of my kernels to my site if they are to be useful > -- they are fully monolithic (but with kmod support) due to historical > reasons. Only IPv6 is modular due to its unstability -- it freezes the > system immediately on my /240 and splashes a bunch of suspicious messages > on my /260 (weird, but no time to debug). They only support /240 and /260 > due to CONFIG_CPU_HAS_WB unset. Yes please. I hope to get a new disk this week, so I can build a stable development server... Thanks a lot, -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Mon Nov 26 07:38:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQFcRB08077 for linux-mips-outgoing; Mon, 26 Nov 2001 07:38:27 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQFbpo08052 for ; Mon, 26 Nov 2001 07:37:58 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA00100; Mon, 26 Nov 2001 15:35:18 +0100 (MET) Date: Mon, 26 Nov 2001 15:35:17 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A critical DECstation interrupt handler fix Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, The DECstation's interrupt handler can crash under certain circumstances. Due to a missing masking of the CP0 Cause register, if a spurious interrupt is delivered (its deasserted before reading the register), the handler may jump to an arbitrary memory location as determined by data fetched from an incorrect location. Due to this problem my new /260 system used to crash frequently, because Cause.CE is often set to 3 (CE is unspecified for all but coprocessor unusable exceptions). The following patch masks Cause appropriately. A small reorganization of code was also possible due to changes in the scheduling of delay slots. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-dec-cause-0 diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S --- linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S Sun Nov 25 00:40:11 2001 @@ -140,7 +140,7 @@ */ mfc0 t0,CP0_CAUSE # get pending interrupts mfc0 t2,CP0_STATUS - la t1,cpu_mask_tbl + andi t0,ST0_IM # CAUSE.CE may be non-zero! and t0,t2 # isolate allowed ones beqz t0,spurious @@ -148,7 +148,8 @@ /* * Find irq with highest priority */ -1: lw t2,(t1) + la t1,cpu_mask_tbl +1: lw t2,(t1) move t3,t0 and t3,t2 beq t3,zero,1b From owner-linux-mips@oss.sgi.com Mon Nov 26 07:47:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQFlAx08359 for linux-mips-outgoing; Mon, 26 Nov 2001 07:47:10 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQFl4o08356 for ; Mon, 26 Nov 2001 07:47:04 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA01539 for ; Mon, 26 Nov 2001 06:46:35 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA00100; Mon, 26 Nov 2001 15:35:18 +0100 (MET) Date: Mon, 26 Nov 2001 15:35:17 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A critical DECstation interrupt handler fix Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, The DECstation's interrupt handler can crash under certain circumstances. Due to a missing masking of the CP0 Cause register, if a spurious interrupt is delivered (its deasserted before reading the register), the handler may jump to an arbitrary memory location as determined by data fetched from an incorrect location. Due to this problem my new /260 system used to crash frequently, because Cause.CE is often set to 3 (CE is unspecified for all but coprocessor unusable exceptions). The following patch masks Cause appropriately. A small reorganization of code was also possible due to changes in the scheduling of delay slots. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-dec-cause-0 diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S --- linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S Sun Nov 25 00:40:11 2001 @@ -140,7 +140,7 @@ */ mfc0 t0,CP0_CAUSE # get pending interrupts mfc0 t2,CP0_STATUS - la t1,cpu_mask_tbl + andi t0,ST0_IM # CAUSE.CE may be non-zero! and t0,t2 # isolate allowed ones beqz t0,spurious @@ -148,7 +148,8 @@ /* * Find irq with highest priority */ -1: lw t2,(t1) + la t1,cpu_mask_tbl +1: lw t2,(t1) move t3,t0 and t3,t2 beq t3,zero,1b From owner-linux-mips@oss.sgi.com Mon Nov 26 07:50:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQForr08541 for linux-mips-outgoing; Mon, 26 Nov 2001 07:50:53 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQFono08536 for ; Mon, 26 Nov 2001 07:50:49 -0800 Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian)) id 168N41-0000Nw-00; Mon, 26 Nov 2001 06:48:53 -0800 Date: Mon, 26 Nov 2001 06:48:53 -0800 From: William Lee Irwin III To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler Message-ID: <20011126064853.K1048@holomorphy.com> References: <20011125002352.G1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 12:57:23PM +0100 Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 12:57:23PM +0100, Maciej W. Rozycki wrote: > Nope, R3k DECstations used to use the FPU emulator unconditionally. :-( > This would have never got triggered. An FPU interrupt-to-exception glue > was non-existent. Okay, that is at least some relief. On Mon, Nov 26, 2001 at 12:57:23PM +0100, Maciej W. Rozycki wrote: > No need to do anything -- I happened to work on the FPU a bit recently > and I sent a patch here on Friday that adds the glue, enables the FPU and > rips the broken code off. Ralf has already applied the patch. Excellent! I'll apply it as well. On Mon, Nov 26, 2001 at 12:57:23PM +0100, Maciej W. Rozycki wrote: > I would *really* appreciate any feedback on DECstation patches I'm > sending here -- for quite some time I have a feeling I'm the last one to > run Linux on a DECstation... :-( Well, I'm a more than willing tester, and perhaps I can even bring some code to the table in my spare time at some point for the drivers my system needs help with. Cheers, Bill From owner-linux-mips@oss.sgi.com Mon Nov 26 08:30:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQGUhZ10333 for linux-mips-outgoing; Mon, 26 Nov 2001 08:30:43 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQGURo10305 for ; Mon, 26 Nov 2001 08:30:33 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA01718; Mon, 26 Nov 2001 16:28:36 +0100 (MET) Date: Mon, 26 Nov 2001 16:28:34 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: Report the faulting FPU instruction Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, I believe it's desireable to point to the faulting instruction upon an FPU trap and not the following one. Why? First, the FPU restores the state from before attempting to exectute the instruction. Second, with the current approach state is lost -- consider instructions in branch/jump delay slots. Third, erroneous execution is possible if SIG_FPE's handler is set to "ignore" by mistake. The following patch implements the described approach. It should not affect standard handlers which use setjmp()/longjmp(), but it should enable a smarter interpreting handler or just better diagnostics. Both the hardware and the emulator are handled. Tested successfully with gdb on an R3k, an R4k and the emulator. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-fpu-epc-0 diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c --- linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c Wed Nov 21 05:26:46 2001 +++ linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c Sun Nov 25 13:25:06 2001 @@ -497,9 +497,6 @@ asmlinkage void do_fpe(struct pt_regs *r return; } - if (compute_return_epc(regs)) - return; - force_sig(SIGFPE, current); printk(KERN_DEBUG "Sent send SIGFPE to %s\n", current->comm); } diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c --- linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c Sun Oct 14 04:26:36 2001 +++ linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c Sun Nov 25 13:29:30 2001 @@ -1721,6 +1721,9 @@ int fpu_emulator_cop1Handler(struct pt_r /* but if epc has advanced, then ignore it */ sig = 0; + if (sig) + xcp->cp0_epc = prevepc; + return sig; } From owner-linux-mips@oss.sgi.com Mon Nov 26 09:11:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQHBSU11890 for linux-mips-outgoing; Mon, 26 Nov 2001 09:11:28 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQHBGo11886; Mon, 26 Nov 2001 09:11:18 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA03226; Mon, 26 Nov 2001 17:10:54 +0100 (MET) Date: Mon, 26 Nov 2001 17:10:53 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: William Lee Irwin III , linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <20011127002405.E5465@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Ralf Baechle wrote: > > I would *really* appreciate any feedback on DECstation patches I'm > > sending here -- for quite some time I have a feeling I'm the last one to > > run Linux on a DECstation... :-( > > Certainly not, on the recent Linux porter meating it was probably the > most used type of non-x86 machine. So rather blame general passivity > of man kind ... Well, but what can I think when even fatal core errors remain unnoticed?... The int-handler.S was one and the file wasn't changed for a very long time, i.e. since I fixed another fatal error there... And both looked like they were present from the day one... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 09:22:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQHMMd12319 for linux-mips-outgoing; Mon, 26 Nov 2001 09:22:22 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQHMFo12314 for ; Mon, 26 Nov 2001 09:22:16 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA03502; Mon, 26 Nov 2001 17:20:27 +0100 (MET) Date: Mon, 26 Nov 2001 17:20:26 +0100 (MET) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <200111261407.PAA11348@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Karel, > I'm using the RedHat 7.1 packages from oss: > binutils-2.11.92.0.10-1.mips.rpm > gcc-2.96-99.1.mips.rpm Can't comment on these. I feel a bit uneasy about gcc 2.96, possibly due to the way it was incarnated. I'll probably switch directly to 3.x when it's proved stable enough not to distract me from primary tasks. I don't know how much binutils 2.11.92.0.10 differ from the mainline. > > I may upload binaries of my kernels to my site if they are to be useful [...] > Yes please. I hope to get a new disk this week, so I can build a > stable development server... OK -- I should have them by tomorrow. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 09:28:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQHSYC12595 for linux-mips-outgoing; Mon, 26 Nov 2001 09:28:34 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQHSSo12590; Mon, 26 Nov 2001 09:28:28 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fAQGSQD29436; Mon, 26 Nov 2001 17:28:26 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X3V60QRT; Mon, 26 Nov 2001 17:28:24 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Mon, 26 Nov 2001 17:28:24 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 17:27:39 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E41A@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: AW: Cross Compiler again Date: Mon, 26 Nov 2001 17:27:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > -G 0. Thanks that helped for the relocation error. init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16 execute_command But I still get a lot of undefined references. arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660' arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549' arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015' arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015' ... I believe there is still something wrong with my glibc, but I need to check that. > What compiler are you using? All compilers I've ever released did default > to -G 0. I compiled my own gcc using Bradley D. LaRonde's howto. regards Andre From owner-linux-mips@oss.sgi.com Mon Nov 26 09:31:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQHV2o12756 for linux-mips-outgoing; Mon, 26 Nov 2001 09:31:02 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQHUxo12751 for ; Mon, 26 Nov 2001 09:30:59 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA05349 for ; Mon, 26 Nov 2001 08:30:25 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA03502; Mon, 26 Nov 2001 17:20:27 +0100 (MET) Date: Mon, 26 Nov 2001 17:20:26 +0100 (MET) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <200111261407.PAA11348@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Karel, > I'm using the RedHat 7.1 packages from oss: > binutils-2.11.92.0.10-1.mips.rpm > gcc-2.96-99.1.mips.rpm Can't comment on these. I feel a bit uneasy about gcc 2.96, possibly due to the way it was incarnated. I'll probably switch directly to 3.x when it's proved stable enough not to distract me from primary tasks. I don't know how much binutils 2.11.92.0.10 differ from the mainline. > > I may upload binaries of my kernels to my site if they are to be useful [...] > Yes please. I hope to get a new disk this week, so I can build a > stable development server... OK -- I should have them by tomorrow. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Nov 26 13:08:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQL8aj23665 for linux-mips-outgoing; Mon, 26 Nov 2001 13:08:36 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQL8Vo23659 for ; Mon, 26 Nov 2001 13:08:31 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 45AD5848; Mon, 26 Nov 2001 20:45:27 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D48903F45; Mon, 26 Nov 2001 20:45:09 +0100 (CET) Date: Mon, 26 Nov 2001 20:45:09 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Status RM200 Message-ID: <20011126204509.A10341@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i guess the RM200 parts are untested for at least a year (possibly even more). Does anyone work on this or does know a working checkout date ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ApvFUaz2rXW+gJcRAuzzAJwNkBviji7tChUNWiGOERfcRIDclQCdGA4C oTc3BzQyileGSJfsJ6fHHQM= =L2ep -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-linux-mips@oss.sgi.com Mon Nov 26 13:28:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQLSNc24314 for linux-mips-outgoing; Mon, 26 Nov 2001 13:28:23 -0800 Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQLSKo24308 for ; Mon, 26 Nov 2001 13:28:20 -0800 Received: from excalibur.cologne.de (pD9E408C5.dip.t-dialin.net [217.228.8.197]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA04936 for ; Mon, 26 Nov 2001 21:23:59 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 168SSo-0000FW-00 for ; Mon, 26 Nov 2001 21:34:50 +0100 Date: Mon, 26 Nov 2001 21:34:50 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011126213450.B943@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20011126204509.A10341@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126204509.A10341@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Nov 26, 2001 at 08:45:09PM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 08:45:09PM +0100, Florian Lohoff wrote: > i guess the RM200 parts are untested for at least a year (possibly > even more). Does anyone work on this or does know a working > checkout date ? Ralf has at least made the RM200 support compile again while we were driving home from Oldenburg :-). I do not know if it really works though - wrong endianess... 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 owner-linux-mips@oss.sgi.com Mon Nov 26 13:31:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQLVNA24491 for linux-mips-outgoing; Mon, 26 Nov 2001 13:31:23 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQLVKo24484 for ; Mon, 26 Nov 2001 13:31:20 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 168SPd-0002DU-00; Mon, 26 Nov 2001 15:31:33 -0500 Date: Mon, 26 Nov 2001 15:31:33 -0500 From: Daniel Jacobowitz To: Andre.Messerschmidt@infineon.com Cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: Cross Compiler again Message-ID: <20011126153132.A8406@nevyn.them.org> References: <86048F07C015D311864100902760F1DD01B5E41A@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86048F07C015D311864100902760F1DD01B5E41A@dlfw003a.dus.infineon.com> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 05:27:38PM +0100, Andre.Messerschmidt@infineon.com wrote: > > > -G 0. > Thanks that helped for the relocation error. > init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16 > execute_command > > But I still get a lot of undefined references. > arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660' > arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549' > arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015' > arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015' > arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015' > arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015' > ... > > I believe there is still something wrong with my glibc, but I need to check > that. I don't know what compiler you're using, but it isn't working right :) I suspect you're running afoul of the change in debugging format between binutils 2.10 and 2.11.2. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Nov 26 14:05:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQM5id25708 for linux-mips-outgoing; Mon, 26 Nov 2001 14:05:44 -0800 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQM5eo25705 for ; Mon, 26 Nov 2001 14:05:40 -0800 Received: from [192.168.1.233] (192.168.1.233 [192.168.1.233]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id QMJCN984; Mon, 26 Nov 2001 16:05:33 -0500 Subject: Serial Console on Malta broken? From: Marc Karasek To: Linux MIPS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.2 (Preview Release) Date: 26 Nov 2001 16:05:43 -0500 Message-Id: <1006808755.7860.5.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I just got the latest source from the cvs server (2.4.14). I am working on the MALTA eval board from MIPS. I noticed that the serial console is very slow once it is initialized, once it starts to print the "serial concole detected" it slows down to a crawl. Prints around 10+ char and then pauses. You can do a ls, etc... but do not expect the output in your lifetime. In debugging I noticed that the mipsIRQ.S file is no longer used for interrupt handling. Does anyone know why this was done? I have compared it to source from 2.4.3-01.01 (from the MIPS site). I checked the mailing list and there was some discussion about a similar bug that had to do with the serial port and the interrupt not working right. Any enlightenment would be greatly appreciated. We are looking to put a stake in the ground as far as kernel version to start working with and we need something that is post 2.4.10. -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Mon Nov 26 15:18:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQNILH28277 for linux-mips-outgoing; Mon, 26 Nov 2001 15:18:21 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQNIGo28274 for ; Mon, 26 Nov 2001 15:18:16 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 41584838; Mon, 26 Nov 2001 23:18:11 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id B92963F45; Mon, 26 Nov 2001 23:17:37 +0100 (CET) Date: Mon, 26 Nov 2001 23:17:37 +0100 From: Florian Lohoff To: Karsten Merker Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011126231737.B13081@paradigm.rfc822.org> References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RASg3xLB4tUQ4RcS" Content-Disposition: inline In-Reply-To: <20011126213450.B943@excalibur.cologne.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --RASg3xLB4tUQ4RcS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2001 at 09:34:50PM +0100, Karsten Merker wrote: > Ralf has at least made the RM200 support compile again while we > were driving home from Oldenburg :-). > I do not know if it really works though - wrong endianess... How can the RM200 port be wrong endianess - The RM200 is bi-endian thus any endianess would be ok (As long as the port does not assume a specific endianess except the prom stuff). AFAIK the RM200 was supported little endian as it was ported to the Windows NT delivered machines. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --RASg3xLB4tUQ4RcS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Ar+BUaz2rXW+gJcRAt41AJwJjdZ2O95day+L8GHm2tl43CqbcQCgt/dS nSplbUuq16IaljiIqaFM9tw= =wgAX -----END PGP SIGNATURE----- --RASg3xLB4tUQ4RcS-- From owner-linux-mips@oss.sgi.com Mon Nov 26 15:46:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQNksR28962 for linux-mips-outgoing; Mon, 26 Nov 2001 15:46:54 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQNkjo28954 for ; Mon, 26 Nov 2001 15:46:45 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 9A05A853; Mon, 26 Nov 2001 23:46:39 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 775373F45; Mon, 26 Nov 2001 23:46:17 +0100 (CET) Date: Mon, 26 Nov 2001 23:46:17 +0100 From: Florian Lohoff To: debian-mips@lists.debian.org, debian-boot@lists.debian.org Cc: linux-mips@oss.sgi.com Subject: failed installation debian-mipsel (Decstation 5000/150) Message-ID: <20011126234617.D13081@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oj4kGyHlBMXGt3Le" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --oj4kGyHlBMXGt3Le Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i am just trying to install debian-mipsel on a Decstation 5000/150=20 with the bootfloppies 3.0.15-2001-10-19. I am working on serial console and dont have a framebuffer nor a keyboard. At first the installation misses a short "Howto boot a decstation over the net" which is not that trivial. At least this should be mentioned: echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time and something along that you need to set a console as the kernel is not able to autodetect the console. The kernel hangs for me at the detection of the LK Keyboard (which is not attached) ------------------------------------------------- >>boot 3/tftp/boot/kn04tftpboot.img console=3DttyS2 -tftp boot(3), bootp 195.71.97.238:/boot/kn04tftpboot.img -tftp load 1679360+1970176+198224 This DECstation is a DS5000/1xx Loading R4000 MMU routines. CPU revision is: 00000430 Primary instruction cache 8kb, linesize 16 bytes. Primary data cache 8kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 32 bytes. Linux version 2.4.5-r4k-kn04 (root@repeat.rfc822.org) (gcc version 2.95.4 200101Determined physical RAM map: memory: 04000000 @ 00000000 (usable) Initial ramdisk at: 0x80203000 (1800109 bytes) On node 0 totalpages: 16384 = =20 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=3DttyS2 Console: colour dummy device 80x25 Calibrating delay loop... 49.75 BogoMIPS Memory: 60392k/65536k available (1632k kernel code, 5144k reserved, 1847k d= ata,) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 12.5 MHz (without parity) slot 0: DEC PMAZ-AA V5.3d slot 1: DEC PMAZ-AA V5.3b slot 2: DEC PMAF-FA V1.1 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured DECstation Z8530 serial driver version 0.05 DECstation LK keyboard driver v0.04...=20 --------------------------------------------------------------- Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --oj4kGyHlBMXGt3Le Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AsY5Uaz2rXW+gJcRAi/ZAJ0VlwNL1Sp2fZRdXoetARrPgXfOiQCgrmJ4 uMy7fAltCrZ1rAUcvDkHGWA= =zK3j -----END PGP SIGNATURE----- --oj4kGyHlBMXGt3Le-- From owner-linux-mips@oss.sgi.com Mon Nov 26 15:57:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQNvAk29252 for linux-mips-outgoing; Mon, 26 Nov 2001 15:57:10 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQNv6o29249 for ; Mon, 26 Nov 2001 15:57:06 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id B4B46851; Mon, 26 Nov 2001 23:57:00 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id BFD333F45; Mon, 26 Nov 2001 23:51:29 +0100 (CET) Date: Mon, 26 Nov 2001 23:51:29 +0100 From: Florian Lohoff To: debian-mips@lists.debian.org, debian-boot@lists.debian.org Cc: linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) Message-ID: <20011126235129.E13081@paradigm.rfc822.org> References: <20011126234617.D13081@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3O1VwFp74L81IIeR" Content-Disposition: inline In-Reply-To: <20011126234617.D13081@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --3O1VwFp74L81IIeR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2001 at 11:46:17PM +0100, Florian Lohoff wrote: > Hi, > i am just trying to install debian-mipsel on a Decstation 5000/150=20 > with the bootfloppies 3.0.15-2001-10-19. OOps - Write once memory - 3.0.14-2001-09-30 i meant. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --3O1VwFp74L81IIeR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AsdxUaz2rXW+gJcRAmJfAJ9C1gEGFyArsOp0I6IcPDtMsGeqYgCfVISr aXeXnXlpRFVdGyzfX4KFBZg= =89I3 -----END PGP SIGNATURE----- --3O1VwFp74L81IIeR-- From owner-linux-mips@oss.sgi.com Mon Nov 26 15:57:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAQNvPQ29306 for linux-mips-outgoing; Mon, 26 Nov 2001 15:57:25 -0800 Received: from luonnotar.infodrom.org (postfix@luonnotar.infodrom.org [195.124.48.78]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAQNvMo29296 for ; Mon, 26 Nov 2001 15:57:22 -0800 Received: by luonnotar.infodrom.org (Postfix, from userid 10) id C81B2366A81; Mon, 26 Nov 2001 23:57:19 +0100 (CET) Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2) from infodrom.org by finlandia.Infodrom.North.DE via smail from stdin id for flo@rfc822.org; Mon, 26 Nov 2001 23:35:48 +0100 (CET) Date: Mon, 26 Nov 2001 23:35:48 +0100 From: Martin Schulze To: Florian Lohoff Cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011126233548.D26510@finlandia.infodrom.north.de> References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> <20011126231737.B13081@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20011126231737.B13081@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Florian Lohoff wrote: > On Mon, Nov 26, 2001 at 09:34:50PM +0100, Karsten Merker wrote: > > Ralf has at least made the RM200 support compile again while we > > were driving home from Oldenburg :-). > > I do not know if it really works though - wrong endianess... > > How can the RM200 port be wrong endianess - The RM200 is bi-endian > thus any endianess would be ok (As long as the port does not assume > a specific endianess except the prom stuff). As I remember, you can't switch to "the right" endianess without a support drivers f*ckup disk - which hasn't appeared on the stage yet. Regards, Joey -- Computers are not intelligent. They only think they are. From owner-linux-mips@oss.sgi.com Mon Nov 26 16:04:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR04Iv29638 for linux-mips-outgoing; Mon, 26 Nov 2001 16:04:18 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR04Eo29627 for ; Mon, 26 Nov 2001 16:04:14 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id A7A07848; Tue, 27 Nov 2001 00:04:08 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 788773F45; Tue, 27 Nov 2001 00:00:11 +0100 (CET) Date: Tue, 27 Nov 2001 00:00:11 +0100 From: Florian Lohoff To: Martin Schulze Cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127000011.F13081@paradigm.rfc822.org> References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> <20011126231737.B13081@paradigm.rfc822.org> <20011126233548.D26510@finlandia.infodrom.north.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bGR76rFJjkSxVeRa" Content-Disposition: inline In-Reply-To: <20011126233548.D26510@finlandia.infodrom.north.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --bGR76rFJjkSxVeRa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2001 at 11:35:48PM +0100, Martin Schulze wrote: >=20 > As I remember, you can't switch to "the right" endianess without a support > drivers f*ckup disk - which hasn't appeared on the stage yet. >=20 If you have the PartNo of the machine i might be able to get some system boot-floppies. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --bGR76rFJjkSxVeRa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Asl7Uaz2rXW+gJcRAmCEAJ9KAm11apV3dxaEMjoCpwjIXREgYACgoDs2 N1OBwcTYKDbm+3655THFsGY= =XwKe -----END PGP SIGNATURE----- --bGR76rFJjkSxVeRa-- From owner-linux-mips@oss.sgi.com Mon Nov 26 17:02:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR12lI30990 for linux-mips-outgoing; Mon, 26 Nov 2001 17:02:47 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR12fo30984 for ; Mon, 26 Nov 2001 17:02:41 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2E385853; Tue, 27 Nov 2001 01:02:36 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id B399C3F45; Tue, 27 Nov 2001 01:02:14 +0100 (CET) Date: Tue, 27 Nov 2001 01:02:14 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: [PATCH] const mips_io_port_base !? Message-ID: <20011127010214.B21296@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For the reason of compilability one should build a consensus ... diff -u -r1.29 io.h --- include/asm-mips/io.h 2001/11/26 11:14:37 1.29 +++ include/asm-mips/io.h 2001/11/27 01:00:07 @@ -60,7 +60,7 @@ * instruction, so the lower 16 bits must be zero. Should be true on * on any sane architecture; generic code does not use this assumption. */ -extern const unsigned long mips_io_port_base; +extern unsigned long mips_io_port_base; =20 #define set_io_port_base(base) \ do { * (unsigned long *) &mips_io_port_base =3D (base); } while (0) Or the other way round ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AtgGUaz2rXW+gJcRAhI1AKCNArDW/o66KzcT6+Br1tmzrvL3UQCgsjqf 6cZ7+gE8sH0DyIPEXnqyegA= =/qVC -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-linux-mips@oss.sgi.com Mon Nov 26 17:02:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR12mW30995 for linux-mips-outgoing; Mon, 26 Nov 2001 17:02:48 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR12fo30983 for ; Mon, 26 Nov 2001 17:02:41 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 0937984F; Tue, 27 Nov 2001 01:02:35 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A36233F45; Tue, 27 Nov 2001 00:32:28 +0100 (CET) Date: Tue, 27 Nov 2001 00:32:28 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: [PATCH] arc_setup_console obsolete ? Message-ID: <20011127003228.A21296@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This doesnt exist anywhere else - I would consider this history ? diff -u -r1.9 init.c --- arch/mips/arc/init.c 2001/01/27 04:34:10 1.9 +++ arch/mips/arc/init.c 2001/11/27 00:31:47 @@ -23,8 +23,6 @@ =20 extern void prom_testtree(void); =20 -extern void arc_setup_console(void); - void __init prom_init(int argc, char **argv, char **envp, int *prom_vec) { struct linux_promblock *pb; @@ -35,19 +33,6 @@ prom_argv =3D argv; prom_envp =3D envp; =20 -#if 0 - /* arc_printf should not use prom_printf as soon as we free - * the prom buffers - This horribly breaks on Indys with framebuffer - * as it simply stops after initialising swap - On the Indigo2 serial - * console you will get A LOT illegal instructions - Only enable - * this for early init crashes - This also brings up artefacts of - * printing everything twice on serial console and on GFX Console - * this has the effect of having the prom printing everything - * in the small rectangle and the kernel printing around. - */ - - arc_setup_console(); -#endif if (pb->magic !=3D 0x53435241) { prom_printf("Aieee, bad prom vector magic %08lx\n", pb->magic); while(1) --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AtEMUaz2rXW+gJcRAmoGAJ0UECxwljztnUeNhQEab5my/vM4XQCgm2dx cPCgLcrVITkcYWTTK4M+0Uw= =DPNy -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-linux-mips@oss.sgi.com Mon Nov 26 18:05:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR25i202153 for linux-mips-outgoing; Mon, 26 Nov 2001 18:05:44 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR25Zo02144 for ; Mon, 26 Nov 2001 18:05:35 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8704A853; Tue, 27 Nov 2001 02:05:29 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 9EE0E3F45; Tue, 27 Nov 2001 02:04:00 +0100 (CET) Date: Tue, 27 Nov 2001 02:04:00 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: [PATCH] mips/mm/c-r4k.c NONCOHERENT compile fix Message-ID: <20011127020400.A28037@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, this is needed for the NONCOHERENT stuff ... diff -u -r1.1 c-r4k.c --- arch/mips/mm/c-r4k.c 2001/10/23 01:02:46 1.1 +++ arch/mips/mm/c-r4k.c 2001/11/27 02:02:19 @@ -1141,6 +1141,7 @@ flush_cache_all(); } =20 +#ifdef CONFIG_NONCOHERENT_IO /* * Writeback and invalidate the primary cache dcache before DMA. * @@ -1247,6 +1248,8 @@ panic("r4k_dma_cache called - should not happen.\n"); } =20 +#endif /* CONFIG_NONCOHERENT_IO */ + /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -1436,9 +1439,14 @@ =20 _flush_icache_page =3D r4k_flush_icache_page_p; =20 +#ifdef CONFIG_NONCOHERENT_IO + _dma_cache_wback_inv =3D r4k_dma_cache_wback_inv_pc; _dma_cache_wback =3D r4k_dma_cache_wback; _dma_cache_inv =3D r4k_dma_cache_inv_pc; + +#endif + } =20 static void __init setup_scache_funcs(void) @@ -1519,9 +1527,15 @@ } ___flush_cache_all =3D _flush_cache_all; _flush_icache_page =3D r4k_flush_icache_page_s; + +#ifdef CONFIG_NONCOHERENT_IO + _dma_cache_wback_inv =3D r4k_dma_cache_wback_inv_sc; _dma_cache_wback =3D r4k_dma_cache_wback; _dma_cache_inv =3D r4k_dma_cache_inv_sc; + +#endif /* CONFIG_NONCOHERENT_IO */ + } =20 typedef int (*probe_func_t)(unsigned long); Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AuaAUaz2rXW+gJcRAq+mAKCbibBiXMx8Y+l38R+k+SY2i2uozACgnLT3 lTHXmMFnRhDwqrhoRgcWLKI= =2zPL -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-linux-mips@oss.sgi.com Mon Nov 26 18:56:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR2uqH03186 for linux-mips-outgoing; Mon, 26 Nov 2001 18:56:52 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR2uko03182 for ; Mon, 26 Nov 2001 18:56:46 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8A68C853; Tue, 27 Nov 2001 02:56:40 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 18CE93F45; Tue, 27 Nov 2001 02:56:22 +0100 (CET) Date: Tue, 27 Nov 2001 02:56:22 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: Decstation /150 kernel (cvs) problems Message-ID: <20011127025622.D28037@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7DO5AaGCk89r4vaK" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --7DO5AaGCk89r4vaK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, it seems the current cvs kernel does not work on my /150 - Does anyone have similar expiriences ? It simply reboots for me ... >>boot 3/rz0 2/linux.test delo V0.7 Copyright 2000 Florian Lohoff Loading /etc/delo.conf .. ok Loading /boot/vmlinux-2.4.14 ................ ok KN04 V2.1k (PC: 0x80148b9c, SP: 0x8043fef0) delo V0.7 Copyright 2000 Florian Lohoff Loading /etc/delo.conf .. ok Loading /boot/vmlinux .................... ok This DECstation is a DS5000/1xx Loading R4000 MMU routines. CPU revision is: 00000430 Primary instruction cache 8kb, linesize 16 bytes. = =20 [...] repeat:~# cat /proc/cpuinfo cpu : MIPS cpu model : R4000SC V3.0 system type : Digital DECstation 5000/1xx BogoMIPS : 49.68 byteorder : little endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : no hardware watchpoint : yes VCED exceptions : 6565 VCEI exceptions : 11303 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --7DO5AaGCk89r4vaK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8AvLFUaz2rXW+gJcRAsqAAJwONYFW8NguSki9YXmt30FaLJg0xgCePslD kLZWZuk0/u/xuKYOqpGAnNE= =tJmR -----END PGP SIGNATURE----- --7DO5AaGCk89r4vaK-- From owner-linux-mips@oss.sgi.com Mon Nov 26 20:11:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR4Bjn05304 for linux-mips-outgoing; Mon, 26 Nov 2001 20:11:45 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR4Bho05298 for ; Mon, 26 Nov 2001 20:11:43 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR1HOt26575; Tue, 27 Nov 2001 12:17:24 +1100 Date: Tue, 27 Nov 2001 12:17:24 +1100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: William Lee Irwin III , linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler Message-ID: <20011127121724.F2525@dea.linux-mips.net> References: <20011127002405.E5465@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 05:10:53PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 05:10:53PM +0100, Maciej W. Rozycki wrote: > Well, but what can I think when even fatal core errors remain > unnoticed?... The int-handler.S was one and the file wasn't changed for a > very long time, i.e. since I fixed another fatal error there... And both > looked like they were present from the day one... In that case if nobody complains those nobodies all had their fair chance :-) Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 20:11:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR4Bpn05324 for linux-mips-outgoing; Mon, 26 Nov 2001 20:11:51 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR4Blo05316 for ; Mon, 26 Nov 2001 20:11:48 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR1DbJ26525; Tue, 27 Nov 2001 12:13:37 +1100 Date: Tue, 27 Nov 2001 12:13:37 +1100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: Report the faulting FPU instruction Message-ID: <20011127121337.E2525@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 04:28:34PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 04:28:34PM +0100, Maciej W. Rozycki wrote: > I believe it's desireable to point to the faulting instruction upon an > FPU trap and not the following one. Why? First, the FPU restores the > state from before attempting to exectute the instruction. Second, with > the current approach state is lost -- consider instructions in branch/jump > delay slots. Third, erroneous execution is possible if SIG_FPE's handler > is set to "ignore" by mistake. > > The following patch implements the described approach. It should not > affect standard handlers which use setjmp()/longjmp(), but it should > enable a smarter interpreting handler or just better diagnostics. Both > the hardware and the emulator are handled. Tested successfully with gdb > on an R3k, an R4k and the emulator. The problem you found in the FPU emulator is a fairly generic one. We got other exception handlers which in error case will still skip over the instruction. What also isn't handled properly is the case of sending a signal to the application. In such a case sigreturn() should do the the compute_return_epc() thing ... Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 20:59:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR4xTI06050 for linux-mips-outgoing; Mon, 26 Nov 2001 20:59:29 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR4xNo06047; Mon, 26 Nov 2001 20:59:23 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 27 Nov 2001 03:59:23 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 17327B474; Tue, 27 Nov 2001 12:59:21 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA21874; Tue, 27 Nov 2001 12:59:20 +0900 (JST) Date: Tue, 27 Nov 2001 13:04:06 +0900 (JST) Message-Id: <20011127.130406.104026562.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h From: Atsushi Nemoto In-Reply-To: <20011126200946.A8408@dea.linux-mips.net> References: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp> <20011126200946.A8408@dea.linux-mips.net> 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Mon, 26 Nov 2001 20:09:46 +1100, Ralf Baechle said: >> By the way, I have some boards which require special I/O routines. >> Some of these boards need byteswap on PCI I/O region but noswap on >> ISA region. And some of these boards do not require byteswap but >> need swap the address ('port' values). I added following codes to >> support these boards. Is it worth to apply? ralf> Not as is - the kernel has changed, so your patch wouldn't apply ralf> anymore. Yes, I had not noticed that changes. Thank you. ralf> Aside of that I don't think we'll have any alternative to do ralf> something along the lines of your patch. There are for example ralf> systems where the high 8 bits of the I/O or memory address on ralf> the ISA bus are supplied in a separate register of the chipset, ralf> not as part of the memory address itself. It's really ralf> remarkable how much bad taste some hardware designers have ... So, what should we do for these tasteless hardware? Is there any suggestions? (please don't say "Do not eat" ...) --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Mon Nov 26 22:30:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR6U4N07590 for linux-mips-outgoing; Mon, 26 Nov 2001 22:30:04 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR6T7o07563 for ; Mon, 26 Nov 2001 22:29:07 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 3A12D125C8; Mon, 26 Nov 2001 21:28:59 -0800 (PST) Date: Mon, 26 Nov 2001 21:28:59 -0800 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , Murat_Berk@bmc.com Subject: The Linux binutils 2.11.92.0.12 is released. Message-ID: <20011126212859.A17557@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.11.92.0.12 for Linux, which is based on binutils 2001 1121 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.92.0.12 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.92.0.12: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.10. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.92.0.12.tar.gz. Source code. 2. binutils-2.11.92.0.10-2.11.92.0.12.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.92.0.12-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.92.0.12.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 11/26/2001 --- --- linux/arch/alpha/vmlinux.lds.in.discard Thu Nov 22 00:30:16 2001 +++ linux/arch/alpha/vmlinux.lds.in Thu Nov 22 00:30:47 2001 @@ -92,5 +92,5 @@ SECTIONS .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } - /DISCARD/ : { *(.text.exit) *(.data.exit) } + /DISCARD/ : { *(.text.exit) *(.data.exit) *(.exitcall.exit) } } --- linux/drivers/char/serial.c.discard Thu Nov 22 00:37:14 2001 +++ linux/drivers/char/serial.c Thu Nov 22 10:54:54 2001 @@ -4887,7 +4887,9 @@ static char serial_pci_driver_name[] = " static struct pci_driver serial_pci_driver = { name: serial_pci_driver_name, probe: serial_init_one, +#ifdef MODULE remove: serial_remove_one, +#endif id_table: serial_pci_tbl, }; From owner-linux-mips@oss.sgi.com Mon Nov 26 23:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7Bhj08320 for linux-mips-outgoing; Mon, 26 Nov 2001 23:11:43 -0800 Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR7Bco08317 for ; Mon, 26 Nov 2001 23:11:38 -0800 Received: from excalibur.cologne.de (pD95117A9.dip.t-dialin.net [217.81.23.169]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id HAA28135 for ; Tue, 27 Nov 2001 07:07:28 +0100 (MET) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 168bZN-0000B4-00 for ; Tue, 27 Nov 2001 07:18:13 +0100 Date: Tue, 27 Nov 2001 07:18:10 +0100 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127071800.A292@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> <20011126231737.B13081@paradigm.rfc822.org> <20011126233548.D26510@finlandia.infodrom.north.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126233548.D26510@finlandia.infodrom.north.de>; from joey@infodrom.org on Mon, Nov 26, 2001 at 11:35:48PM +0100 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 11:35:48PM +0100, Martin Schulze wrote: > > How can the RM200 port be wrong endianess - The RM200 is bi-endian > > thus any endianess would be ok (As long as the port does not assume > > a specific endianess except the prom stuff). Unfortunately the firmware functions are different between little- and big-endian firmware and there are quite some parts in the RM200 support which currently do not work (and some even do not compile) on a big-endian machine due to missing (correct) definitions. Another problem regarding the big endian firmware is that nobody seems to have documentation about it, not even a function vector table. > As I remember, you can't switch to "the right" endianess without a support > drivers f*ckup disk - which hasn't appeared on the stage yet. Right - Ralf had asked around for some disks to convert his LE RM200C to BE firmware for further development, but nobody had yet been able to come up with some. Additionally, AFAICS these disks are different for different machine types and possibly even for different CPU types (RM200 EISA vs. RM200C PCI and R4k vs R5k). If anybody knows more about these issues, any help is welcome. 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 owner-linux-mips@oss.sgi.com Mon Nov 26 23:15:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7FoK08463 for linux-mips-outgoing; Mon, 26 Nov 2001 23:15:50 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR7Fmo08460 for ; Mon, 26 Nov 2001 23:15:49 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR6Fi031355; Tue, 27 Nov 2001 17:15:44 +1100 Date: Tue, 27 Nov 2001 17:15:44 +1100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011127171544.A29424@dea.linux-mips.net> References: <20011127010214.B21296@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127010214.B21296@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Nov 27, 2001 at 01:02:14AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 01:02:14AM +0100, Florian Lohoff wrote: Blame whoever designed C that there is no sane way to give a variable an attribute like "will never change again after the first initalization thus keeping the value in a register beyond function calls and any other kind of memory barrier is ok". This inconsistence merily achieves a better optimization of the code; the set_* function is intended to hide this cute little standard violation away ... Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 23:19:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7JtJ08561 for linux-mips-outgoing; Mon, 26 Nov 2001 23:19:55 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR7Jqo08558 for ; Mon, 26 Nov 2001 23:19:52 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR6JoL31409; Tue, 27 Nov 2001 17:19:50 +1100 Date: Tue, 27 Nov 2001 17:19:50 +1100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127171950.B29424@dea.linux-mips.net> References: <20011126204509.A10341@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126204509.A10341@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Nov 26, 2001 at 08:45:09PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 08:45:09PM +0100, Florian Lohoff wrote: > i guess the RM200 parts are untested for at least a year (possibly > even more). Does anyone work on this or does know a working > checkout date ? I'm only maintaining in the sense of making sure the default configuration still compiles. The last kernel I know is working is 2.1.73 which needs some patches that are not in the standard CVS. Even if the RM200C is broken, it's a relativly sane system and so fixing should be fairly easy. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 23:25:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7Pvo08653 for linux-mips-outgoing; Mon, 26 Nov 2001 23:25:57 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR7Pso08650 for ; Mon, 26 Nov 2001 23:25:55 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR6Pof31489; Tue, 27 Nov 2001 17:25:50 +1100 Date: Tue, 27 Nov 2001 17:25:50 +1100 From: Ralf Baechle To: Karsten Merker Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127172550.D29424@dea.linux-mips.net> References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> <20011126231737.B13081@paradigm.rfc822.org> <20011126233548.D26510@finlandia.infodrom.north.de> <20011127071800.A292@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127071800.A292@excalibur.cologne.de>; from karsten@excalibur.cologne.de on Tue, Nov 27, 2001 at 07:18:10AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 07:18:10AM +0100, Karsten Merker wrote: > > > How can the RM200 port be wrong endianess - The RM200 is bi-endian > > > thus any endianess would be ok (As long as the port does not assume > > > a specific endianess except the prom stuff). > > Unfortunately the firmware functions are different between little- and > big-endian firmware and there are quite some parts in the RM200 support > which currently do not work (and some even do not compile) on a big-endian > machine due to missing (correct) definitions. Another problem regarding > the big endian firmware is that nobody seems to have documentation about > it, not even a function vector table. As I understand the big endian firmware is just yet another ARC firmware implementation with some support for old MIPS firmware style vector tables. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 23:34:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7YKI08898 for linux-mips-outgoing; Mon, 26 Nov 2001 23:34:20 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR7YIo08895 for ; Mon, 26 Nov 2001 23:34:18 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR6YGN31597; Tue, 27 Nov 2001 17:34:16 +1100 Date: Tue, 27 Nov 2001 17:34:16 +1100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] arc_setup_console obsolete ? Message-ID: <20011127173416.E29424@dea.linux-mips.net> References: <20011127003228.A21296@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127003228.A21296@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Nov 27, 2001 at 12:32:28AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 12:32:28AM +0100, Florian Lohoff wrote: > This doesnt exist anywhere else - I would consider this history ? Correct, patch applied. Ralf From owner-linux-mips@oss.sgi.com Mon Nov 26 23:38:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR7ckd08998 for linux-mips-outgoing; Mon, 26 Nov 2001 23:38:46 -0800 Received: from holomorphy (mail@holomorphy.com [216.36.33.161]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR7cgo08995 for ; Mon, 26 Nov 2001 23:38:42 -0800 Received: from wli by holomorphy with local (Exim 3.31 #1 (Debian)) id 168bss-00038I-00 for ; Mon, 26 Nov 2001 22:38:22 -0800 Date: Mon, 26 Nov 2001 22:38:22 -0800 From: William Lee Irwin III To: linux-mips@oss.sgi.com Subject: [RFC] tree-based bootmem Message-ID: <20011126223822.N1048@holomorphy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: brief message Content-Disposition: inline User-Agent: Mutt/1.3.17i Organization: The Domain of Holomorphy Sender: owner-linux-mips@oss.sgi.com Precedence: bulk A number of people have expressed a wish to replace the bitmap-based bootmem allocator with one that tracks ranges explicitly. I have written such a replacement in order to deal with some of the situations I have encountered, in particular, to require less programming effort to initialize on machines with sparse and irregular memory layouts. The following patch features space usage proportional only to the number of distinct fragments of memory, tracking available memory at address granularity up until the point of initializing per-page data structures, and the use of segment trees in order to support efficient searches on those rare machines where this is an issue. According to testing, this patch appears to save somewhere between 8KB and 2MB on i386 PC's versus the bitmap-based bootmem allocator. The following patch has been tested on i386 PC's, IA64 Lions, Netwinders, DecStation 5000/200's, and IBM IA64 NUMA hardware with sparse memory, and debugged without the help of logic analyzers or in-target probes. I would like to thank the testers of #kernelnewbies (reltuk and asalib) and my co-workers for their help in making this work, and Tony Luck and Jack Steiner for their assistance in profiling the existing bootmem. I am now especially interested in feedback regarding its design, and also the results of wider testing. The patch is available at ftp://ftp.kernel.org/pub/linux/kernel/people/wli/bootmem/bootmem-2.5.1-pre1 Cheers, Bill From owner-linux-mips@oss.sgi.com Tue Nov 27 00:07:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR870909608 for linux-mips-outgoing; Tue, 27 Nov 2001 00:07:00 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR86uo09605 for ; Tue, 27 Nov 2001 00:06:56 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR76mt02868; Tue, 27 Nov 2001 18:06:48 +1100 Date: Tue, 27 Nov 2001 18:06:48 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h Message-ID: <20011127180648.H29424@dea.linux-mips.net> References: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp> <20011126200946.A8408@dea.linux-mips.net> <20011127.130406.104026562.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127.130406.104026562.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Tue, Nov 27, 2001 at 01:04:06PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 01:04:06PM +0900, Atsushi Nemoto wrote: > ralf> Aside of that I don't think we'll have any alternative to do > ralf> something along the lines of your patch. There are for example > ralf> systems where the high 8 bits of the I/O or memory address on > ralf> the ISA bus are supplied in a separate register of the chipset, > ralf> not as part of the memory address itself. It's really > ralf> remarkable how much bad taste some hardware designers have ... > > So, what should we do for these tasteless hardware? Punish it's developers with fish and chips [1]. > Is there any suggestions? (please don't say "Do not eat" ...) Not a bad idea in context of fish and chips. Well, talk to it's developers before it's too late. Or as it has already happened for some hardware I think we should simply go with your suggestion and make all those functions vectors. Ralf [1] Unavoidable part of the Australian experience From owner-linux-mips@oss.sgi.com Tue Nov 27 00:53:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAR8rmY10458 for linux-mips-outgoing; Tue, 27 Nov 2001 00:53:48 -0800 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAR8rho10455 for ; Tue, 27 Nov 2001 00:53:44 -0800 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id IAA30759; Tue, 27 Nov 2001 08:53:41 +0100 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id IAA24915; Tue, 27 Nov 2001 08:53:41 +0100 (MET) Message-Id: <200111270753.IAA24915@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Florian Lohoff cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: Decstation /150 kernel (cvs) problems In-reply-to: Your message of "Tue, 27 Nov 2001 02:56:22 +0100." <20011127025622.D28037@paradigm.rfc822.org> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2001 08:53:40 +0100 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Florian, > Hi, > it seems the current cvs kernel does not work on my /150 - Does anyone > have similar expiriences ? It simply reboots for me ... > > >>boot 3/rz0 2/linux.test > delo V0.7 Copyright 2000 Florian Lohoff > Loading /etc/delo.conf .. ok > Loading /boot/vmlinux-2.4.14 ................ ok > > KN04 V2.1k (PC: 0x80148b9c, SP: 0x8043fef0) > delo V0.7 Copyright 2000 Florian Lohoff > ... I've noticed that recent kernels can't be booted by delo. As far as I have dug into that, it might be the changed loadaddr, that is hardcoded in delo... TFTP booting the same kernel does indeed start the kernel (for me it usually crashes or hangs some moments later). Regards, -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Tue Nov 27 03:07:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARB75L13475 for linux-mips-outgoing; Tue, 27 Nov 2001 03:07:05 -0800 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARB5eo13385; Tue, 27 Nov 2001 03:05:40 -0800 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 27 Nov 2001 10:05:39 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 43500B474; Tue, 27 Nov 2001 19:05:38 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA22852; Tue, 27 Nov 2001 19:05:38 +0900 (JST) Date: Tue, 27 Nov 2001 19:10:22 +0900 (JST) Message-Id: <20011127.191022.27957874.nemoto@toshiba-tops.co.jp> To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h From: Atsushi Nemoto In-Reply-To: <20011127180648.H29424@dea.linux-mips.net> References: <20011126200946.A8408@dea.linux-mips.net> <20011127.130406.104026562.nemoto@toshiba-tops.co.jp> <20011127180648.H29424@dea.linux-mips.net> 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 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> On Tue, 27 Nov 2001 18:06:48 +1100, Ralf Baechle said: ralf> Well, talk to it's developers before it's too late. Or as it ralf> has already happened for some hardware I think we should simply ralf> go with your suggestion and make all those functions vectors. For me, currently it happens only in big endian and I can live happy in a little endian world. I will create new patch when I REALLY need it. Thank you. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue Nov 27 03:54:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARBs2x14574 for linux-mips-outgoing; Tue, 27 Nov 2001 03:54:02 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARBrlo14568 for ; Tue, 27 Nov 2001 03:53:47 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id AB8D383E; Tue, 27 Nov 2001 11:53:40 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A489F3F47; Tue, 27 Nov 2001 11:48:49 +0100 (CET) Date: Tue, 27 Nov 2001 11:48:49 +0100 From: Florian Lohoff To: "Houten K.H.C. van (Karel)" Cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: Decstation /150 kernel (cvs) problems Message-ID: <20011127114849.D27987@paradigm.rfc822.org> References: <20011127025622.D28037@paradigm.rfc822.org> <200111270753.IAA24915@sparta.research.kpn.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="llIrKcgUOe3dCx0c" Content-Disposition: inline In-Reply-To: <200111270753.IAA24915@sparta.research.kpn.com> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --llIrKcgUOe3dCx0c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 08:53:40AM +0100, Houten K.H.C. van (Karel) wrote: > I've noticed that recent kernels can't be booted by delo. > As far as I have dug into that, it might be the changed loadaddr, > that is hardcoded in delo... Delo should load the kernel to a specific address and then move the single ELF segments to their address in the ELF header (copyelf.c). > TFTP booting the same kernel does indeed start the kernel > (for me it usually crashes or hangs some moments later). *Urgs* I'am just having a look at it... It looks the elf segments have changed moved and its either overwriting itself or the prom. >>boot 3/rz0 2/linux.test delo V0.7 Copyright 2000 Florian Lohoff Loading /etc/delo.conf .. ok =20 Loading /boot/vmlinux-2.4.14 ................ ok =20 fhdr->e_entry =3D fhdr->e_shoff =3D 1549940/17a674 =20 fhdr->e_phoff =3D 52/34 =20 fhdr->e_shentsize =3D 40 fhdr->e_shnum =3D 20 fhdr->e_shstrndx =3D fhdr->e_phentsize =3D fhdr->e_phnum =3D 0 0017a674 00000000 00000000 00000000 00000000 00000000 1 0017a69c 00000001 80040000 00001000 00131ed0 00000000 memcpy( 2 0017a6c4 00000001 80171ed0 00132ed0 00000e6c 00000000 memcpy( 3 0017a6ec 00000001 80172d3c 00133d3c 000035b4 00000000 memcpy( 4 0017a714 00000001 801762f0 001372f0 00001b98 00000000 memcpy( 5 0017a73c 00000001 80177e88 00138e88 00000000 00000000 6 0017a764 00000001 80177e88 00138e88 00001a38 00000000 memcpy( 7 0017a78c 00000001 8017a000 0013b000 0000c30c 00000000 memcpy( 8 0017a7b4 00000001 8018630c 0014730c 0000040c 00000000 memcpy( 9 0017a7dc 00000001 80186720 00147720 000000a0 00000000 memcpy(10 0017a804 00000001 801867c0 001477c0 00000070 00000000 memcpy(11 0017a82c 00000001 80187000 00148000 00000260 00000000 memcpy(12 0017a854 70000006 80187260 00148260 00000018 00000000 13 0017a87c 00000001 80187280 00148280 00011d80 00000000 memcpy(14 0017a8a4 00000008 80199000 0015a000 000256e0 00000000 memset(15 0017a8cc 00000001 801be6e0 0015a000 00003a33 00000000 memcpy(16 0017a8f4 00000001 00000000 0015da34 0001cb80 00000000 memcpy( When having a look at the kernel file it looks broken - Have a look at segment 16 which is type PROGBITS but address "0"=20 (flo@paradigm)/tmp/i/linux# readelf -e vmlinux=20 ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x8004046c Start of program headers: 52 (bytes into file) Start of section headers: 1549940 (bytes into file) Flags: 0x10000001, noreorder, mips2 UNKNOWN Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 20 Section header string table index: 17 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk I= nf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 80040000 001000 131ed0 00 AX 0 = 0 8192 [ 2] .fixup PROGBITS 80171ed0 132ed0 000e6c 00 AX 0 = 0 1 [ 3] .kstrtab PROGBITS 80172d3c 133d3c 0035b4 00 A 0 = 0 4 [ 4] __ex_table PROGBITS 801762f0 1372f0 001b98 00 A 0 = 0 4 [ 5] __dbe_table PROGBITS 80177e88 138e88 000000 00 A 0 = 0 1 [ 6] __ksymtab PROGBITS 80177e88 138e88 001a38 00 A 0 = 0 4 [ 7] .text.init PROGBITS 8017a000 13b000 00c30c 00 AX 0 = 0 4 [ 8] .data.init PROGBITS 8018630c 14730c 00040c 00 WA 0 = 0 4 [ 9] .setup.init PROGBITS 80186720 147720 0000a0 00 WA 0 = 0 4 [10] .initcall.init PROGBITS 801867c0 1477c0 000070 00 WA 0 = 0 4 [11] .data.cacheline_a PROGBITS 80187000 148000 000260 00 WA 0 = 0 32 [12] .reginfo MIPS_REGINFO 80187260 148260 000018 18 A 0 = 0 4 [13] .data PROGBITS 80187280 148280 011d80 00 WA 0 = 0 32 [14] .bss NOBITS 80199000 15a000 0256e0 00 WA 0 = 0 32 [15] .comment PROGBITS 801be6e0 15a000 003a33 00 0 0 1 [16] .pdr PROGBITS 00000000 15da34 01cb80 00 0 0 4 [17] .shstrtab STRTAB 00000000 17a5b4 0000bd 00 0 0 1 [18] .symtab SYMTAB 00000000 17a994 01dfe0 10 19 cf2 4 [19] .strtab STRTAB 00000000 198974 01e130 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align REGINFO 0x148260 0x80187260 0x80187260 0x00018 0x00018 R 0x4 LOAD 0x001000 0x80040000 0x80040000 0x159000 0x17e6e0 RWE 0x1000 Section to Segment mapping: Segment Sections... 00 .reginfo=20 01 .text .fixup .kstrtab __ex_table __ksymtab .text.init =2Edata.init .setup.init .initcall.init .data.cacheline_aligned .reginfo =2Edata .bss=20 (flo@paradigm)/tmp/i/linux# mipsel-linux-gcc --version 3.0.2 (flo@paradigm)/tmp/i/linux# mipsel-linux-as --version GNU assembler 2.11.92.0.10 Debian/GNU Linux Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `mipsel-linux'. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --llIrKcgUOe3dCx0c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A2+RUaz2rXW+gJcRApJUAKCvFj7pO15Bk22zsUc3QoZnyMxNOgCgq4Gp Lg4yL6KcE3ETKuRDVhMtNBA= =T88G -----END PGP SIGNATURE----- --llIrKcgUOe3dCx0c-- From owner-linux-mips@oss.sgi.com Tue Nov 27 03:59:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARBxaA14712 for linux-mips-outgoing; Tue, 27 Nov 2001 03:59:36 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARBxVo14709 for ; Tue, 27 Nov 2001 03:59:31 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 777977FB; Tue, 27 Nov 2001 11:59:25 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A3AB43F47; Tue, 27 Nov 2001 11:59:03 +0100 (CET) Date: Tue, 27 Nov 2001 11:59:03 +0100 From: Florian Lohoff To: "Houten K.H.C. van (Karel)" Cc: linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems Message-ID: <20011127115903.E27987@paradigm.rfc822.org> References: <20011127025622.D28037@paradigm.rfc822.org> <200111270753.IAA24915@sparta.research.kpn.com> <20011127114849.D27987@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uwl7UQhJk99r8jnw" Content-Disposition: inline In-Reply-To: <20011127114849.D27987@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Uwl7UQhJk99r8jnw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 11:48:49AM +0100, Florian Lohoff wrote: > *Urgs* I'am just having a look at it... It looks the elf segments have > changed moved and its either overwriting itself or the prom. >=20 Ok - this fixes the problem by not only ignoring "length 0" sections but also sections with address 0=20 --- delo-0.7/loader/copyelf.c Sat Oct 14 19:29:00 2000 +++ delo-0.7-flo/loader/copyelf.c Tue Nov 27 11:51:29 2001 @@ -42,7 +42,7 @@ shdr->sh_offset, shdr->sh_size); #endif =20 - if (shdr->sh_size <=3D 0)=20 + if (shdr->sh_size <=3D 0 || shdr->sh_addr =3D=3D 0)=20 continue; =20 if (shdr->sh_type =3D=3D SHT_PROGBITS) { Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --Uwl7UQhJk99r8jnw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A3H3Uaz2rXW+gJcRAqkBAJ4hca+lEKqiQM8djRYlLuCVGo+EFwCfSu2N A5tGF9HmfwjnzdxpEW0P6gc= =+RW9 -----END PGP SIGNATURE----- --Uwl7UQhJk99r8jnw-- From owner-linux-mips@oss.sgi.com Tue Nov 27 04:22:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARCMXs15266 for linux-mips-outgoing; Tue, 27 Nov 2001 04:22:33 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARCMLo15262 for ; Tue, 27 Nov 2001 04:22:22 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 24D8F861; Tue, 27 Nov 2001 12:22:15 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8696B3F47; Tue, 27 Nov 2001 12:21:52 +0100 (CET) Date: Tue, 27 Nov 2001 12:21:52 +0100 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: [PATCH] NONCOHERENT_IO Decstation ?! Message-ID: <20011127122152.F27987@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XIiC+We3v3zHqZ6Z" Content-Disposition: inline User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --XIiC+We3v3zHqZ6Z Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My Decstation /150 does not get the point=20 SCSI subsystem driver Revision: 1.00 SCSI ID 7 Clk 25MHz CCF=3D5 TOut 167 NCR53C9x(esp236) SCSI ID 7 Clk 12MHz CCF=3D3 TOut 139 NCR53C9x(esp236) SCSI ID 7 Clk 12MHz CCF=3D3 TOut 139 NCR53C9x(esp236) ESP: Total of 3 ESP hosts found, 3 actually in use. scsi0 : ESP236 (NCR53C9x) scsi1 : ESP236 (NCR53C9x) scsi2 : ESP236 (NCR53C9x) scsi: unknown type 17 Vendor: Model: > < =E8=BD . Rev: =20 Type: Unknown ANSI SCSI revision: 01 resize_dma_pool: unknown device type 17 resize_dma_pool: unknown device type 17 Without: Index: arch/mips/config.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.151 diff -u -r1.151 config.in --- arch/mips/config.in 2001/11/26 12:01:08 1.151 +++ arch/mips/config.in 2001/11/27 12:17:26 @@ -292,6 +292,10 @@ define_bool CONFIG_PC_KEYB y fi =20 =20 +if [ "$CONFIG_DECSTATION" =3D "y" ]; then + define_bool CONFIG_NONCOHERENT_IO y +fi + if [ "$CONFIG_ISA" !=3D "y" ]; then define_bool CONFIG_ISA n define_bool CONFIG_EISA n Now the current cvs boots until userspace but its not very happy. ----------------------------------- /etc/init.d/rcS: line 28: 32 Illegal Instruction grep -qs resync /proc/mdstat Starting portmap daemon: portmap. /etc/init.d/rcS: line 57: 39 Illegal Instruction ( trap - INT QUIT TSTP; set start; . $i ) Setting the System Clock using the Hardware Clock as reference... /etc/init.d/rcS: line 57: 40 Illegal Instruction ( trap - INT QUIT TSTP; set start; . $i ) Cleaning: /tmp /var/lock /var/run. Initializing random number generator... done. ----------------------------------- Ill dig into this later ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --XIiC+We3v3zHqZ6Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A3dPUaz2rXW+gJcRAumHAJ9WThrgnJu1pqBFkfhnN1iZjxecnwCeLTIO n9OTydijVjtSKA9MPwnSm04= =/0qd -----END PGP SIGNATURE----- --XIiC+We3v3zHqZ6Z-- From owner-linux-mips@oss.sgi.com Tue Nov 27 05:31:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARDVM416648 for linux-mips-outgoing; Tue, 27 Nov 2001 05:31:22 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARDUqo16631 for ; Tue, 27 Nov 2001 05:30:55 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA01293; Tue, 27 Nov 2001 13:07:10 +0100 (MET) Date: Tue, 27 Nov 2001 13:07:09 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems In-Reply-To: <20011127115903.E27987@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Florian Lohoff wrote: > Ok - this fixes the problem by not only ignoring "length 0" sections but > also sections with address 0 Huh? You should be dealing with segments and not sections (as you are loading and not linking the image) and then only LOADable ones. I believe there is no segment mapped at zero for the current kernel. If a segment has a null load address then it still have to be loaded -- you may consider placing part of it away for the time being or just relocating the loader. $ mipsel-linux-objdump -p vmlinux-mips-2.4.14-20011123 vmlinux-mips-2.4.14-20011123: file format elf32-tradlittlemips Program Header: 0x70000000 off 0x0028e2e0 vaddr 0x802ce2e0 paddr 0x802ce2e0 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r-- LOAD off 0x00001000 vaddr 0x80040000 paddr 0x80040000 align 2**12 filesz 0x002744a8 memsz 0x002744a8 flags r-x LOAD off 0x00276000 vaddr 0x802b6000 paddr 0x802b6000 align 2**12 filesz 0x0004c000 memsz 0x0006a890 flags rwx private flags = 10000001: [no abi set] [mips2] [not 32bitmode] There are only two LOADable segments, at 0x80040000 and at 0x802b6000. None is at zero. ;-) If in doubt, just see how I'm loading ELF images in mopd. Or ask me a question. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 05:36:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARDajt16763 for linux-mips-outgoing; Tue, 27 Nov 2001 05:36:45 -0800 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARDago16760 for ; Tue, 27 Nov 2001 05:36:42 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id fARCaaD29953; Tue, 27 Nov 2001 13:36:36 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XW7QX9D0; Tue, 27 Nov 2001 13:36:35 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Tue, 27 Nov 2001 13:36:33 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 13:36:01 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E42B@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: dan@debian.org Cc: linux-mips@oss.sgi.com Subject: AW: Cross Compiler again Date: Tue, 27 Nov 2001 13:35:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I don't know what compiler you're using, but it isn't working right :) > I suspect you're running afoul of the change in debugging format > between binutils 2.10 and 2.11.2. > Using the toolchain provided by H.J.Lu it is now working. (gcc version is 2.96) Don't know what was wrong with the other installation. regards Andre From owner-linux-mips@oss.sgi.com Tue Nov 27 05:45:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARDjmF17043 for linux-mips-outgoing; Tue, 27 Nov 2001 05:45:48 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARDjLo17025 for ; Tue, 27 Nov 2001 05:45:36 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA02357; Tue, 27 Nov 2001 13:43:11 +0100 (MET) Date: Tue, 27 Nov 2001 13:43:10 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) In-Reply-To: <20011126234617.D13081@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 26 Nov 2001, Florian Lohoff wrote: > At first the installation misses a short "Howto boot a decstation over > the net" which is not that trivial. It depends on how you are doing it... For me MOP appears to be piece of cake now that you can boot ELF directly. :-) Nothing to configure, just copy the kernel to the mopd home directory. The drawback is MOP cannot pass routers. > At least this should be mentioned: > > echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time Is it needed for TFTP? What for? > and something along that you need to set a console as the kernel is not > able to autodetect the console. You mean the serial console? Well, that's surely not detectable, but the console on the VT seems to be detected fine. > The kernel hangs for me at the detection of the LK Keyboard (which > is not attached) Yep, the timeouts are definitely too large even for the patient... ;-) If you waited for a few minutes, it should boot anyway. I'll prepare a fix. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 05:51:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARDppG17194 for linux-mips-outgoing; Tue, 27 Nov 2001 05:51:51 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARDp9o17180 for ; Tue, 27 Nov 2001 05:51:09 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA25626; Tue, 27 Nov 2001 04:51:00 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA04187; Tue, 27 Nov 2001 04:50:57 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fARCosA24238; Tue, 27 Nov 2001 13:50:54 +0100 (MET) Message-ID: <3C038C30.951E9D8A@mips.com> Date: Tue, 27 Nov 2001 13:50:56 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Marc Karasek CC: Linux MIPS Subject: Re: Serial Console on Malta broken? References: <1006808755.7860.5.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="------------F975DC772608C03AAC78EB04" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------F975DC772608C03AAC78EB04 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Try replace arch/mips/mips-boards/malta/malta_int.c with the attached file and apply the following patch: Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.145 diff -u -r1.145 config.in --- arch/mips/config.in 2001/11/18 03:24:36 1.145 +++ arch/mips/config.in 2001/11/22 13:14:40 @@ -160,10 +160,10 @@ define_bool CONFIG_SWAP_IO_SPACE y fi if [ "$CONFIG_MIPS_MALTA" = "y" ]; then - define_bool CONFIG_I8259 y +# define_bool CONFIG_I8259 y define_bool CONFIG_PCI y define_bool CONFIG_HAVE_STD_PC_SERIAL_PORT y - define_bool CONFIG_NEW_IRQ y +# define_bool CONFIG_NEW_IRQ y define_bool CONFIG_SWAP_IO_SPACE y fi if [ "$CONFIG_MOMENCO_OCELOT" = "y" ]; then /Carsten Marc Karasek wrote: > I just got the latest source from the cvs server (2.4.14). I am working > on the MALTA eval board from MIPS. I noticed that the serial console is > very slow once it is initialized, once it starts to print the "serial > concole detected" it slows down to a crawl. Prints around 10+ char and > then pauses. You can do a ls, etc... but do not expect the output in > your lifetime. > > In debugging I noticed that the mipsIRQ.S file is no longer used for > interrupt handling. Does anyone know why this was done? I have > compared it to source from 2.4.3-01.01 (from the MIPS site). I checked > the mailing list and there was some discussion about a similar bug that > had to do with the serial port and the interrupt not working right. > > Any enlightenment would be greatly appreciated. We are looking to put a > stake in the ground as far as kernel version to start working with and > we need something that is post 2.4.10. > > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > (770) 986-8925 > (770) 986-8926 Fax > *************************/ -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com --------------F975DC772608C03AAC78EB04 Content-Type: text/plain; charset=iso-8859-15; name="malta_int.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="malta_int.c" /* * Carsten Langgaard, carstenl@mips.com * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. * * Routines for generic manipulation of the interrupts found on the MIPS * Malta board. * The interrupt controller is located in the South Bridge a PIIX4 device * with two internal 82C95 interrupt controllers. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include extern asmlinkage void mipsIRQ(void); unsigned int local_bh_count[NR_CPUS]; unsigned int local_irq_count[NR_CPUS]; unsigned long spurious_count = 0; static struct irqaction *hw0_irq_action[MALTAINT_END] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL }; static struct irqaction r4ktimer_action = { NULL, 0, 0, "R4000 timer/counter", NULL, NULL, }; static struct irqaction *irq_action[8] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, &r4ktimer_action }; #if 0 #define DEBUG_INT(x...) printk(x) #else #define DEBUG_INT(x...) #endif /* * This contains the interrupt mask for both 82C59 interrupt controllers. */ static unsigned int cached_int_mask = 0xffff; void disable_irq(unsigned int irq_nr) { unsigned long flags; if(irq_nr >= MALTAINT_END) { printk("whee, invalid irq_nr %d\n", irq_nr); panic("IRQ, you lose..."); } save_and_cli(flags); cached_int_mask |= (1 << irq_nr); if (irq_nr & 8) { outb((cached_int_mask >> 8) & 0xff, PIIX4_ICTLR2_OCW1); } else { outb(cached_int_mask & 0xff, PIIX4_ICTLR1_OCW1); } restore_flags(flags); } void enable_irq(unsigned int irq_nr) { unsigned long flags; if(irq_nr >= MALTAINT_END) { printk("whee, invalid irq_nr %d\n", irq_nr); panic("IRQ, you lose..."); } save_and_cli(flags); cached_int_mask &= ~(1 << irq_nr); if (irq_nr & 8) { outb((cached_int_mask >> 8) & 0xff, PIIX4_ICTLR2_OCW1); /* Enable irq 2 (cascade interrupt). */ cached_int_mask &= ~(1 << 2); outb(cached_int_mask & 0xff, PIIX4_ICTLR1_OCW1); } else { outb(cached_int_mask & 0xff, PIIX4_ICTLR1_OCW1); } restore_flags(flags); } int get_irq_list(char *buf) { int i, len = 0; int num = 0; struct irqaction *action; for (i = 0; i < 8; i++, num++) { action = irq_action[i]; if (!action) continue; len += sprintf(buf+len, "%2d: %8d %c %s", num, kstat.irqs[0][num], (action->flags & SA_INTERRUPT) ? '+' : ' ', action->name); for (action=action->next; action; action = action->next) { len += sprintf(buf+len, ",%s %s", (action->flags & SA_INTERRUPT) ? " +" : "", action->name); } len += sprintf(buf+len, " [on-chip]\n"); } for (i = 0; i < MALTAINT_END; i++, num++) { action = hw0_irq_action[i]; if (!action) continue; len += sprintf(buf+len, "%2d: %8d %c %s", num, kstat.irqs[0][num], (action->flags & SA_INTERRUPT) ? '+' : ' ', action->name); for (action=action->next; action; action = action->next) { len += sprintf(buf+len, ",%s %s", (action->flags & SA_INTERRUPT) ? " +" : "", action->name); } len += sprintf(buf+len, " [hw0]\n"); } return len; } static int setup_irq(unsigned int irq, struct irqaction * new) { int shared = 0; struct irqaction *old, **p; p = &hw0_irq_action[irq]; if ((old = *p) != NULL) { /* Can't share interrupts unless both agree to */ if (!(old->flags & new->flags & SA_SHIRQ)) return -EBUSY; /* Can't share interrupts unless both are same type */ if ((old->flags ^ new->flags) & SA_INTERRUPT) return -EBUSY; /* add new interrupt at end of irq queue */ do { p = &old->next; old = *p; } while (old); shared = 1; } if (new->flags & SA_SAMPLE_RANDOM) rand_initialize_irq(irq); *p = new; if (!shared) enable_irq(irq); return 0; } int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *), unsigned long irqflags, const char * devname, void *dev_id) { struct irqaction *action; int retval; DEBUG_INT("request_irq: irq=%d, devname = %s\n", irq, devname); if (irq >= MALTAINT_END) return -EINVAL; if (!handler) return -EINVAL; action = (struct irqaction *)kmalloc(sizeof(struct irqaction), GFP_KERNEL); if(!action) return -ENOMEM; action->handler = handler; action->flags = irqflags; action->mask = 0; action->name = devname; action->dev_id = dev_id; action->next = 0; retval = setup_irq(irq, action); if (retval) kfree(action); return retval; } void free_irq(unsigned int irq, void *dev_id) { struct irqaction *action, **p; if (irq >= MALTAINT_END) { printk("Trying to free IRQ%d\n",irq); return; } for (p = &hw0_irq_action[irq]; (action = *p) != NULL; p = &action->next) { if (action->dev_id != dev_id) continue; /* Found it - now free it */ *p = action->next; kfree(action); if (!hw0_irq_action[irq]) disable_irq(irq); return; } printk("Trying to free IRQ%d\n",irq); } void __init init_IRQ(void) { maltaint_init(); } static inline int get_int(int *irq) { /* * Determine highest priority pending interrupt by performing * a PCI Interrupt Acknowledge cycle. */ GT_READ(GT_PCI0_IACK_OFS, *irq); *irq &= 0xFF; /* * IRQ7 is used to detect spurious interrupts. * The interrupt acknowledge cycle returns IRQ7, if no * interrupts is requested. * We can differentiate between this situation and a * "Normal" IRQ7 by reading the ISR. */ if (*irq == 7) { outb(PIIX4_OCW3_SEL | PIIX4_OCW3_ISR, PIIX4_ICTLR1_OCW3); if (!(inb(PIIX4_ICTLR1_OCW3) & (1 << 7))) { printk("We got a spurious interrupt from PIIX4.\n"); return -1; /* Spurious interrupt. */ } } return 0; } static inline void ack_int(int irq) { if (irq & 8) { /* Specific EOI to cascade */ outb(PIIX4_OCW2_SEL | PIIX4_OCW2_NSEOI | PIIX4_OCW2_ILS_2, PIIX4_ICTLR1_OCW2); /* Non specific EOI to cascade */ outb(PIIX4_OCW2_SEL | PIIX4_OCW2_NSEOI, PIIX4_ICTLR2_OCW2); } else { /* Non specific EOI to cascade */ outb(PIIX4_OCW2_SEL | PIIX4_OCW2_NSEOI, PIIX4_ICTLR1_OCW2); } } void malta_hw0_irqdispatch(struct pt_regs *regs) { struct irqaction *action; int irq=0, cpu = smp_processor_id(); DEBUG_INT("malta_hw0_irqdispatch\n"); if (get_int(&irq)) return; /* interrupt has already been cleared */ disable_irq(irq); ack_int(irq); DEBUG_INT("malta_hw0_irqdispatch: irq=%d\n", irq); action = hw0_irq_action[irq]; /* * if action == NULL, then we don't have a handler * for the irq */ if ( action == NULL ) return; irq_enter(cpu, irq); kstat.irqs[0][irq + 8]++; do { action->handler(irq, action->dev_id, regs); action = action->next; } while (action); enable_irq(irq); irq_exit(cpu, irq); } unsigned long probe_irq_on (void) { unsigned int i, irqs = 0; unsigned long delay; /* first, enable any unassigned irqs */ for (i = MALTAINT_END-1; i > 0; i--) { if (!hw0_irq_action[i]) { enable_irq(i); irqs |= (1 << i); } } /* wait for spurious interrupts to mask themselves out again */ for (delay = jiffies + HZ/10; time_before(jiffies, delay); ) /* about 100ms delay */; /* now filter out any obviously spurious interrupts */ return irqs & ~cached_int_mask; } int probe_irq_off (unsigned long irqs) { unsigned int i; irqs &= cached_int_mask; if (!irqs) return 0; i = ffz(~irqs); if (irqs != (irqs & (1 << i))) i = -i; return i; } void __init maltaint_init(void) { /* * Mask out all interrupt by writing "1" to all bit position in * the IMR register. */ outb(cached_int_mask & 0xff, PIIX4_ICTLR1_OCW1); outb((cached_int_mask >> 8) & 0xff, PIIX4_ICTLR2_OCW1); /* Now safe to set the exception vector. */ set_except_vector(0, mipsIRQ); #ifdef CONFIG_REMOTE_DEBUG if (remote_debug) { set_debug_traps(); breakpoint(); } #endif } --------------F975DC772608C03AAC78EB04-- From owner-linux-mips@oss.sgi.com Tue Nov 27 06:23:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARENfs17763 for linux-mips-outgoing; Tue, 27 Nov 2001 06:23:41 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAREKYo17740; Tue, 27 Nov 2001 06:20:37 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA03242; Tue, 27 Nov 2001 14:20:06 +0100 (MET) Date: Tue, 27 Nov 2001 14:20:05 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: Report the faulting FPU instruction In-Reply-To: <20011127121337.E2525@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Ralf Baechle wrote: > The problem you found in the FPU emulator is a fairly generic one. We > got other exception handlers which in error case will still skip over > the instruction. What also isn't handled properly is the case of sending > a signal to the application. In such a case sigreturn() should do the > the compute_return_epc() thing ... Well, with break/trap 6/7 I have already noticed exception handlers tend to call compute_return_epc() unnecessarily. I shall be cleaning the code gradually as time passes by... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 06:47:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARElE418206 for linux-mips-outgoing; Tue, 27 Nov 2001 06:47:14 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAREl6o18199 for ; Tue, 27 Nov 2001 06:47:06 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 3C429848; Tue, 27 Nov 2001 14:47:00 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 483BB3F47; Tue, 27 Nov 2001 13:49:30 +0100 (CET) Date: Tue, 27 Nov 2001 13:49:30 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) Message-ID: <20011127134930.A7022@paradigm.rfc822.org> References: <20011126234617.D13081@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 01:43:10PM +0100, Maciej W. Rozycki wrote: > > At least this should be mentioned: > >=20 > > echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time >=20 > Is it needed for TFTP? What for? The decstation fails to answer ARP requests while downloading. From kernel 2.2 on the arp entries expire faster which lets the tftp download fail somewhere in the middle. > > and something along that you need to set a console as the kernel is not > > able to autodetect the console. >=20 > You mean the serial console? Well, that's surely not detectable, but the > console on the VT seems to be detected fine. It might be detected from the prom env var "osconsole". > > The kernel hangs for me at the detection of the LK Keyboard (which > > is not attached) >=20 > Yep, the timeouts are definitely too large even for the patient... ;-)= =20 > If you waited for a few minutes, it should boot anyway. I'll prepare a > fix.=20 It didnt - I at least let the machine wait for 15-20 Minutes while digging the code... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A4vaUaz2rXW+gJcRAm+DAKCfwqV7gF52Q+WjGjopIVre07SRtwCfUCvz M/oeS/+CVgtcLGDbr0Q1Tew= =UIMV -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-linux-mips@oss.sgi.com Tue Nov 27 06:47:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARElHN18219 for linux-mips-outgoing; Tue, 27 Nov 2001 06:47:17 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAREl6o18200 for ; Tue, 27 Nov 2001 06:47:06 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 63A058BE; Tue, 27 Nov 2001 14:47:00 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3484D3F47; Tue, 27 Nov 2001 13:54:49 +0100 (CET) Date: Tue, 27 Nov 2001 13:54:49 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems Message-ID: <20011127135449.B7022@paradigm.rfc822.org> References: <20011127115903.E27987@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --oC1+HKm2/end4ao3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 01:07:09PM +0100, Maciej W. Rozycki wrote: > On Tue, 27 Nov 2001, Florian Lohoff wrote: >=20 > > Ok - this fixes the problem by not only ignoring "length 0" sections but > > also sections with address 0=20 >=20 > Huh? You should be dealing with segments and not sections (as you are > loading and not linking the image) and then only LOADable ones. I believe I waded through the sections list copieng all sections which are of type PROGBITS which is basically the same. Also i cleared all NOBITS sections. The problem was a progbits section with length > 0 and addr =3D 0 which is IMHO bogus. > If in doubt, just see how I'm loading ELF images in mopd. Or ask me a > question.=20 I'll look into that one... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --oC1+HKm2/end4ao3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A40ZUaz2rXW+gJcRAuCtAKCBvyzuLTjSnS3OmRRR3z+davOCOQCgkNUq zca1UHbSM5LUjXAhUkocfSQ= =3jmy -----END PGP SIGNATURE----- --oC1+HKm2/end4ao3-- From owner-linux-mips@oss.sgi.com Tue Nov 27 06:49:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAREn4K18360 for linux-mips-outgoing; Tue, 27 Nov 2001 06:49:04 -0800 Received: from oval.algor.co.uk (oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAREmno18354 for ; Tue, 27 Nov 2001 06:48:52 -0800 Received: from algor.co.uk (angel.algor.co.uk [62.254.210.234]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id fARDmSZ23744; Tue, 27 Nov 2001 13:48:28 GMT Message-ID: <3C0399AC.9C5D412C@algor.co.uk> Date: Tue, 27 Nov 2001 13:48:28 +0000 From: Chris Dearman Organization: Algorithmics Ltd X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-6 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: MIPS performance counters Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, A few days ago someone (sorry, I deleted the mail...) was asking about support for MIPS performance counters. Some time ago I ported Mikael Pettersson's perfctr (http://www.csd.uu.se/~mikpe/linux/perfctr) driver to 2.2.12 and used that to profile programs running on an RM7000. This driver has a reasonably generic interface and supports per process profiling. Unless anyone can suggest a better starting point I'll have a look at putting this into 2.4.14. Regards Chris -- Algorithmics,The Fruit Farm,Ely Road,Chittering,CAMBS CB5 9PH,ENGLAND P: +44 1223 706200 F: +44 1223 706250 W: http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Tue Nov 27 06:56:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAREulh18523 for linux-mips-outgoing; Tue, 27 Nov 2001 06:56:47 -0800 Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAREuio18520 for ; Tue, 27 Nov 2001 06:56:44 -0800 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 580DCA059; Tue, 27 Nov 2001 14:56:42 +0100 (CET) Date: Tue, 27 Nov 2001 14:56:42 +0100 From: Jan-Benedict Glaw To: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) Message-ID: <20011127145641.K4739@lug-owl.de> Mail-Followup-To: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com References: <20011126234617.D13081@paradigm.rfc822.org> <20011127134930.A7022@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011127134930.A7022@paradigm.rfc822.org> User-Agent: Mutt/1.3.23i X-Operating-System: Linux mail 2.4.15-pre2 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 2001-11-27 13:49:30 +0100, Florian Lohoff wrote in message <20011127134930.A7022@paradigm.rfc822.org>: > On Tue, Nov 27, 2001 at 01:43:10PM +0100, Maciej W. Rozycki wrote: > > > At least this should be mentioned: > > > > > > echo 4096 >/proc/sys/net/ipv4/neigh/eth0/retrans_time > > > > Is it needed for TFTP? What for? > > The decstation fails to answer ARP requests while downloading. From > kernel 2.2 on the arp entries expire faster which lets the tftp download > fail somewhere in the middle. Provide a static ARP entry. Won't expire ever:-) MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 http://lug-owl.de/~jbglaw/software/snapshot2cvs/ From owner-linux-mips@oss.sgi.com Tue Nov 27 07:19:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARFJFG19179 for linux-mips-outgoing; Tue, 27 Nov 2001 07:19:15 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fARFJBo19176 for ; Tue, 27 Nov 2001 07:19:12 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAREJ7J06530; Wed, 28 Nov 2001 01:19:07 +1100 Date: Wed, 28 Nov 2001 01:19:07 +1100 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h Message-ID: <20011128011907.A5508@dea.linux-mips.net> References: <20011126200946.A8408@dea.linux-mips.net> <20011127.130406.104026562.nemoto@toshiba-tops.co.jp> <20011127180648.H29424@dea.linux-mips.net> <20011127.191022.27957874.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127.191022.27957874.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Tue, Nov 27, 2001 at 07:10:22PM +0900 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 07:10:22PM +0900, Atsushi Nemoto wrote: > ralf> Well, talk to it's developers before it's too late. Or as it > ralf> has already happened for some hardware I think we should simply > ralf> go with your suggestion and make all those functions vectors. > > For me, currently it happens only in big endian and I can live happy > in a little endian world. I will create new patch when I REALLY need > it. Thank you. Right now the Linux philosophy is that we don't provide any swapping facility for I/O port accesses. Some hardware supports byteswapping for I/O port and memory access, others must do that in software't, so big endian systems can set CONFIG_SWAP_IO_SPACE to enable swapping for I/O ports and memory. In the past there has been quite some confusion about this and how to use this properly in drivers ... Ralf From owner-linux-mips@oss.sgi.com Tue Nov 27 07:39:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARFdTM19969 for linux-mips-outgoing; Tue, 27 Nov 2001 07:39:29 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARFclo19964 for ; Tue, 27 Nov 2001 07:39:21 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA05429; Tue, 27 Nov 2001 15:33:43 +0100 (MET) Date: Tue, 27 Nov 2001 15:33:42 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) In-Reply-To: <20011127134930.A7022@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Florian Lohoff wrote: > The decstation fails to answer ARP requests while downloading. From > kernel 2.2 on the arp entries expire faster which lets the tftp download > fail somewhere in the middle. I see. I haven't used TFTP on the DECstation ever. I think the default timeout is too low anyway. RFC826 does not specify any timeouts but keeping them below 2 minutes is pointless IMO. If an interface assigned to an IP address changes its MAC address, it will start to use the new one for ARP requests immetiately and all caches in the LAN will have a chance to get updated. > It didnt - I at least let the machine wait for 15-20 Minutes while > digging the code... Weird -- the read should time out after 10000 loops... It definitely needs to be checked. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 08:11:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARGBtt20900 for linux-mips-outgoing; Tue, 27 Nov 2001 08:11:55 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARGBdo20891 for ; Tue, 27 Nov 2001 08:11:46 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA06511; Tue, 27 Nov 2001 16:08:48 +0100 (MET) Date: Tue, 27 Nov 2001 16:08:47 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems In-Reply-To: <20011127135449.B7022@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Florian Lohoff wrote: > > Huh? You should be dealing with segments and not sections (as you are > > loading and not linking the image) and then only LOADable ones. I believe > > I waded through the sections list copieng all sections which are of > type PROGBITS which is basically the same. Also i cleared all NOBITS It's not the same, sorry -- for sections you would need to handle ones marked ALLOC in flags. Of these you need to load ones of type PROGBITS and zero-fill ones of type NOBITS. Others may be discarded. For Linux you may actually skip NOBITS as well, as the head code zero-fills common sections itself, but handling them is saner IMO. Still using segments is the proper way and it's simpler as well. Additionally for platforms that use physical (or in any way different) addressing upon boot, you may (and should) use segments' physical addresses that are not available (assigned) to sections. > sections. The problem was a progbits section with length > 0 and addr > = 0 which is IMHO bogus. Not bogus -- the only section which matches your criteria I'm seeing is ".pdr": $ mipsel-linux-readelf -S vmlinux-mips-2.4.14-20011123 There are 21 section headers, starting at offset 0x2f8e54: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 80040000 001000 2699c0 00 AX 0 0 8192 [...] [17] .pdr PROGBITS 00000000 2c4954 034440 00 0 0 4 [...] Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) But it's not marked as allocatable, so it does not belong to the run-time image. See also the "System V Application Binary Interface, Edition 4.1", chapter 4 for sections and 5 for segments. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 08:15:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARGFJP21032 for linux-mips-outgoing; Tue, 27 Nov 2001 08:15:19 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fARGFGo21029 for ; Tue, 27 Nov 2001 08:15:16 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fARFFER03027; Wed, 28 Nov 2001 02:15:14 +1100 Date: Wed, 28 Nov 2001 02:15:14 +1100 From: Ralf Baechle To: Chris Dearman Cc: linux-mips@oss.sgi.com Subject: Re: MIPS performance counters Message-ID: <20011128021514.A2907@dea.linux-mips.net> References: <3C0399AC.9C5D412C@algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C0399AC.9C5D412C@algor.co.uk>; from chris@algor.co.uk on Tue, Nov 27, 2001 at 01:48:28PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 01:48:28PM +0000, Chris Dearman wrote: > A few days ago someone (sorry, I deleted the mail...) was asking about > support for MIPS performance counters. Some time ago I ported Mikael > Pettersson's perfctr (http://www.csd.uu.se/~mikpe/linux/perfctr) > driver to 2.2.12 and used that to profile programs running on an > RM7000. This driver has a reasonably generic interface and supports per > process profiling. > Unless anyone can suggest a better starting point I'll have a look at > putting this into 2.4.14. Aside a few details I liked the proposal posted by Keith Owens. I guess his proposal is however more aimed at 2.5 than at 2.4 so for 2.4 your proposal is probably a good thing. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 27 08:39:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARGdhW23379 for linux-mips-outgoing; Tue, 27 Nov 2001 08:39:43 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARGdTo23364 for ; Tue, 27 Nov 2001 08:39:29 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 285658D9; Tue, 27 Nov 2001 16:39:22 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id A68253F47; Tue, 27 Nov 2001 16:38:54 +0100 (CET) Date: Tue, 27 Nov 2001 16:38:54 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) Message-ID: <20011127163854.D9282@paradigm.rfc822.org> References: <20011127134930.A7022@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 03:33:42PM +0100, Maciej W. Rozycki wrote: > On Tue, 27 Nov 2001, Florian Lohoff wrote: >=20 > > The decstation fails to answer ARP requests while downloading. From > > kernel 2.2 on the arp entries expire faster which lets the tftp download > > fail somewhere in the middle. >=20 > I see. I haven't used TFTP on the DECstation ever. I think the default > timeout is too low anyway. RFC826 does not specify any timeouts but > keeping them below 2 minutes is pointless IMO. If an interface assigned > to an IP address changes its MAC address, it will start to use the new one > for ARP requests immetiately and all caches in the LAN will have a chance > to get updated. IIRC the kernel refreshes the timeout on communication - But only on TCP not UDP ... > > It didnt - I at least let the machine wait for 15-20 Minutes while > > digging the code... >=20 > Weird -- the read should time out after 10000 loops... It definitely > needs to be checked.=20 Did this change lately - The kernel of the boot-floppies is a little old. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A7OOUaz2rXW+gJcRAgX+AKC4tMtRilCY7J2S9GuvEoYBiLxAfwCeOwIL Ur8PZObdj+Bl1TSHxyM7XNM= =cl+M -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- From owner-linux-mips@oss.sgi.com Tue Nov 27 08:39:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARGdb723374 for linux-mips-outgoing; Tue, 27 Nov 2001 08:39:37 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARGdTo23363 for ; Tue, 27 Nov 2001 08:39:29 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id DCB7B849; Tue, 27 Nov 2001 16:39:22 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id CD1F83F47; Tue, 27 Nov 2001 16:36:02 +0100 (CET) Date: Tue, 27 Nov 2001 16:36:02 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems Message-ID: <20011127163602.C9282@paradigm.rfc822.org> References: <20011127135449.B7022@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IDYEmSnFhs3mNXr+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --IDYEmSnFhs3mNXr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 04:08:47PM +0100, Maciej W. Rozycki wrote: > On Tue, 27 Nov 2001, Florian Lohoff wrote: >=20 > > > Huh? You should be dealing with segments and not sections (as you a= re > > > loading and not linking the image) and then only LOADable ones. I be= lieve > >=20 > > I waded through the sections list copieng all sections which are of > > type PROGBITS which is basically the same. Also i cleared all NOBITS >=20 > It's not the same, sorry -- for sections you would need to handle ones > marked ALLOC in flags. Of these you need to load ones of type PROGBITS > and zero-fill ones of type NOBITS. Others may be discarded. For Linux > you may actually skip NOBITS as well, as the head code zero-fills common > sections itself, but handling them is saner IMO.=20 This is mostly what i do - As the ext2 code loads in the whole file as a chunk i am loading it after the booloader - Then copy it to the end of the first 8Megs (Which is the minimum memory on a decstation) and then copy the chunks marked PROGBITS to their final location. Not optimal but it worked for all the cases where the ELF is ok. > Still using segments is the proper way and it's simpler as well.=20 > Additionally for platforms that use physical (or in any way different) > addressing upon boot, you may (and should) use segments' physical > addresses that are not available (assigned) to sections. >=20 > > sections. The problem was a progbits section with length > 0 and addr > > =3D 0 which is IMHO bogus. >=20 > Not bogus -- the only section which matches your criteria I'm seeing is > ".pdr":=20 Yep - And that the one where the current copyelf function crashes the box. > [17] .pdr PROGBITS 00000000 2c4954 034440 00 0= 0 4 > But it's not marked as allocatable, so it does not belong to the run-time > image. See also the "System V Application Binary Interface, Edition 4.1", > chapter 4 for sections and 5 for segments.=20 ;) I am no elf god by far - I was just in the need of a bootloader so i looked in the elf headers and collected the bits i thought were usefull. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --IDYEmSnFhs3mNXr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A7LiUaz2rXW+gJcRAllaAKDbOrTPVfwnBe79fcrQB63j8CKixACgxgOb 8XowquJbPOYdhVNjsl8IoQ0= =/rY9 -----END PGP SIGNATURE----- --IDYEmSnFhs3mNXr+-- From owner-linux-mips@oss.sgi.com Tue Nov 27 08:47:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARGlFt23651 for linux-mips-outgoing; Tue, 27 Nov 2001 08:47:15 -0800 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARGlAo23646 for ; Tue, 27 Nov 2001 08:47:10 -0800 Received: from localhost.localdomain (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA10220 for ; Tue, 27 Nov 2001 07:47:08 -0800 (PST) Received: (from aldyh@localhost) by localhost.localdomain (8.11.6/8.11.6) id fARFn8e05821; Tue, 27 Nov 2001 09:49:08 -0600 X-Authentication-Warning: localhost.localdomain: aldyh set sender to aldyh@redhat.com using -f To: "H . J . Lu" Cc: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , Murat_Berk@bmc.com Subject: Re: The Linux binutils 2.11.92.0.12 is released. References: <20011126212859.A17557@lucon.org> From: Aldy Hernandez Date: 27 Nov 2001 09:49:08 -0600 In-Reply-To: <20011126212859.A17557@lucon.org> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk >>>>> "H" == H J Lu writes: > This is the beta release of binutils 2.11.92.0.12 for Linux, which is > based on binutils 2001 1121 in CVS on sourecware.cygnus.com plus > various changes. It is purely for Linux. Ok, i am completely new to this... But why is it that we need a separate binutils for linux? Can't we stabilize what we have in sources cvs and distribute this? It seems like this is a duplication of work. I'm sure i'm missing something. Please enlighten me. Aldy From owner-linux-mips@oss.sgi.com Tue Nov 27 09:37:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARHbQ425973 for linux-mips-outgoing; Tue, 27 Nov 2001 09:37:26 -0800 Received: from sina.com ([202.106.187.156]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARHbJo25961 for ; Tue, 27 Nov 2001 09:37:19 -0800 Message-Id: <200111271737.fARHbJo25961@oss.sgi.com> Received: (qmail 55096 invoked from network); 27 Nov 2001 15:15:37 -0000 Received: from unknown (HELO localhost) (61.142.176.68) by 202.106.187.156 with SMTP; 27 Nov 2001 15:15:37 -0000 X-Sender: gentlesales@sina.com From: Jason Wong To: linux-mips@oss.sgi.com Date: Tue, 27 Nov 2001 23:31:12 +0800 Subject: We Produce & Export high quality ultrasonic mist makers, Worldwide Agent Wanted Reply-To: gentlesales@sina.com Organization: Gentle MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dear Sir or Mandam, If your company is in the line of electronics, esp. in Mini Mist Maker, we would be very keen to establish a long term business relationship with you. Nanhai Chaoneng Electronic Factory Co., Ltd. was established in 1989, enjoying over 10 years of good reputation, we have been constantly devoting to investigating and manufacturing wonderful products to improve people's living, and market series of ultrasonic mist makers, underwater light and a whole set of waterfall and mist, artistically handcrafted products. We have set up and adopted a whole series of strict quality control system in our factory, ensuring quality steady and reliable. All of our products have been tested and certified by safety standard approval from CE, EMC, GS, UL, CSA etc. This year, our best sell is Mini Mist Maker, it utilizes electrical oscillation frequencies, via ceramic disc's high frequencies resonance to create natural white mist/fog on the surface of water, No heat or chemicals needed, just place it into clean water, the mist add humidity to a room and the negative ions generated by the unit help to freshen air, if add a few drops of fragrant oil or disinfector oil to the water, it will produce an effect similar to an incense burner and give you a clean dreaming space, breathe natural fresh air. Matching transformer supplied together, safety lower voltage, no harm to body and animal absolutely. "Quality, Credit Standing and Service" are our steady promises, confirmed by highly qualified team. You are welcome to visit our homepage http://chaoneng.com.cn! If you are interest in our products, please don't hesitate to contact us now! Best regards, Mr. Jason Wong Sales Department NANHAI GENTLE ELECTRONIC CO.,LTD. International Marketing Office: Room 722, 7/F, Furong Center, No.1, Zumaio Rd, Foshan, Guangdong, 528000, P.R. China Postal Code: 528000 Tel: +86-757-3982666 Fax: +86-757-2283667 E-Mail: gentlesales@163.com gentlesales@sina.com Website: http://www.chaoeng.com.cn Factory: Nan 2 Road, Guicheng, Nanhai, Guangdong, 528200 P.R. of China TEL: +86-757-3982666 FAX: +86-757-2283667 From owner-linux-mips@oss.sgi.com Tue Nov 27 09:56:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARHuoM26408 for linux-mips-outgoing; Tue, 27 Nov 2001 09:56:50 -0800 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARHuho26405 for ; Tue, 27 Nov 2001 09:56:44 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA10679; Tue, 27 Nov 2001 17:55:01 +0100 (MET) Date: Tue, 27 Nov 2001 17:55:00 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: debian-mips@lists.debian.org, debian-boot@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: failed installation debian-mipsel (Decstation 5000/150) In-Reply-To: <20011127163854.D9282@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Florian Lohoff wrote: > > I see. I haven't used TFTP on the DECstation ever. I think the default > > timeout is too low anyway. RFC826 does not specify any timeouts but > > keeping them below 2 minutes is pointless IMO. If an interface assigned > > to an IP address changes its MAC address, it will start to use the new one > > for ARP requests immetiately and all caches in the LAN will have a chance > > to get updated. > > IIRC the kernel refreshes the timeout on communication - But only on > TCP not UDP ... Weird. > > Weird -- the read should time out after 10000 loops... It definitely > > needs to be checked. > > Did this change lately - The kernel of the boot-floppies is a little > old. I don't think so. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 09:58:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARHwdu26499 for linux-mips-outgoing; Tue, 27 Nov 2001 09:58:39 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARHwao26496 for ; Tue, 27 Nov 2001 09:58:36 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fARGwFh7021779; Tue, 27 Nov 2001 08:58:15 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fARGwEHx021775; Tue, 27 Nov 2001 08:58:15 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 27 Nov 2001 08:58:14 -0800 (PST) From: James Simmons To: Florian Lohoff cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] NONCOHERENT_IO Decstation ?! In-Reply-To: <20011127122152.F27987@paradigm.rfc822.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Without: > > > Index: arch/mips/config.in > =================================================================== > RCS file: /cvs/linux/arch/mips/config.in,v > retrieving revision 1.151 > diff -u -r1.151 config.in > --- arch/mips/config.in 2001/11/26 12:01:08 1.151 > +++ arch/mips/config.in 2001/11/27 12:17:26 > @@ -292,6 +292,10 @@ > define_bool CONFIG_PC_KEYB y > fi > > +if [ "$CONFIG_DECSTATION" = "y" ]; then > + define_bool CONFIG_NONCOHERENT_IO y > +fi > + > if [ "$CONFIG_ISA" != "y" ]; then > define_bool CONFIG_ISA n > define_bool CONFIG_EISA n We got nailed by this to. Ralph I like to suggest that we add set CONFIG_NONCOHERENT_IO to arch/mips/Config.in since most devices of this type don't support IO coherency. From owner-linux-mips@oss.sgi.com Tue Nov 27 10:00:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARI0hU26603 for linux-mips-outgoing; Tue, 27 Nov 2001 10:00:43 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARI0ao26600 for ; Tue, 27 Nov 2001 10:00:36 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 168lao-0001oT-00; Tue, 27 Nov 2001 18:00:22 +0100 Date: Tue, 27 Nov 2001 18:00:22 +0100 From: Johannes Stezenbach To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: The Linux binutils 2.11.92.0.12 is released. Message-ID: <20011127180022.A6897@convergence.de> Mail-Followup-To: Johannes Stezenbach , "H . J . Lu" , linux-mips@oss.sgi.com References: <20011126212859.A17557@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011126212859.A17557@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, On Mon, Nov 26, 2001 at 09:28:59PM -0800, H . J . Lu wrote: > Please report any bugs related to binutils 2.11.92.0.12 to hjl@lucon.org. I tried to use binutils-2.11.92.0.12 with gcc-3.0.2 to compile the linux kernel from linux-mips.sourceforge.net for a VR4121 CPU (littel endian, target mipsel-linux). a) The linker chrashes trying to create the object file for the embedded initrd ramdisk: make CFLAGS="-I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe " -C arch/mips/ramdisk make[1]: Entering directory `/home/js/MIPS/kernel/build/linux-2.4.14-mips/arch/mips/ramdisk' echo "O_FORMAT: " elf32-tradlittlemips O_FORMAT: elf32-tradlittlemips mipsel-linux-ld -G 0 -T ld.script -b binary --oformat elf32-tradlittlemips -o ramdisk.o ramdisk.gz make[1]: *** [ramdisk.o] Segmentation fault make[1]: *** Deleting file `ramdisk.o' The same ramdisk.gz worked with binutils-2.11.92.0.10. The ld.script is: OUTPUT_ARCH(mips) SECTIONS { .initrd : { *(.data) } } b) I still get the -march vs. -mipsN warings: mipsel-linux-gcc -I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe -fno-omit-frame-pointer -c -o sched.o sched.c Assembler messages: Warning: The -march option is incompatible to -mipsN and therefore ignored. I tried to change the CPU options from "-mips2 -Wa,-m4100,--trap" to "-Wa,-march=4111,--trap" with binutils-2.11.92.0.10, which silenced the warnings and seemed to work, but someone notified me that this might cause the compiler to generate wrong code. But I need the VR4111 suspend/hibernate/standby mnemonics for power management. Regards, Johannes From owner-linux-mips@oss.sgi.com Tue Nov 27 10:26:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARIQ7Q27144 for linux-mips-outgoing; Tue, 27 Nov 2001 10:26:07 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARIPto27141 for ; Tue, 27 Nov 2001 10:25:55 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA11475; Tue, 27 Nov 2001 18:23:12 +0100 (MET) Date: Tue, 27 Nov 2001 18:23:11 +0100 (MET) From: "Maciej W. Rozycki" To: Florian Lohoff cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems In-Reply-To: <20011127163602.C9282@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, 27 Nov 2001, Florian Lohoff wrote: > > It's not the same, sorry -- for sections you would need to handle ones > > marked ALLOC in flags. Of these you need to load ones of type PROGBITS > > and zero-fill ones of type NOBITS. Others may be discarded. For Linux > > you may actually skip NOBITS as well, as the head code zero-fills common > > sections itself, but handling them is saner IMO. > > This is mostly what i do - As the ext2 code loads in the whole file > as a chunk i am loading it after the booloader - Then copy it to the > end of the first 8Megs (Which is the minimum memory on a decstation) > and then copy the chunks marked PROGBITS to their final location. That's ugly -- isn't there a possibility to read a file on a block-by-block basis? > > But it's not marked as allocatable, so it does not belong to the run-time > > image. See also the "System V Application Binary Interface, Edition 4.1", > > chapter 4 for sections and 5 for segments. > > ;) I am no elf god by far - I was just in the need of a bootloader so > i looked in the elf headers and collected the bits i thought were > usefull. Neither am I, but come on -- the ELF format is next to trivial to handle and the spec is just a few pages -- the relevant part of chapter 5 fits in three pages. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 10:36:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARIa6w27330 for linux-mips-outgoing; Tue, 27 Nov 2001 10:36:06 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARIZwo27326 for ; Tue, 27 Nov 2001 10:35:59 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA11733; Tue, 27 Nov 2001 18:35:03 +0100 (MET) Date: Tue, 27 Nov 2001 18:35:02 +0100 (MET) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <200111261407.PAA11348@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 26 Nov 2001, Houten K.H.C. van (Karel) wrote: > > I may upload binaries of my kernels to my site if they are to be useful > > -- they are fully monolithic (but with kmod support) due to historical > > reasons. Only IPv6 is modular due to its unstability -- it freezes the > > system immediately on my /240 and splashes a bunch of suspicious messages > > on my /260 (weird, but no time to debug). They only support /240 and /260 > > due to CONFIG_CPU_HAS_WB unset. > > Yes please. I hope to get a new disk this week, so I can build a > stable development server... The kernels are now available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/'. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 10:44:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARIi5R27615 for linux-mips-outgoing; Tue, 27 Nov 2001 10:44:05 -0800 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARIi3o27609 for ; Tue, 27 Nov 2001 10:44:03 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA21150 for ; Tue, 27 Nov 2001 09:43:42 -0800 (PST) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA11733; Tue, 27 Nov 2001 18:35:03 +0100 (MET) Date: Tue, 27 Nov 2001 18:35:02 +0100 (MET) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: linux-mips@oss.sgi.com Subject: Re: FPU interrupt handler In-Reply-To: <200111261407.PAA11348@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 26 Nov 2001, Houten K.H.C. van (Karel) wrote: > > I may upload binaries of my kernels to my site if they are to be useful > > -- they are fully monolithic (but with kmod support) due to historical > > reasons. Only IPv6 is modular due to its unstability -- it freezes the > > system immediately on my /240 and splashes a bunch of suspicious messages > > on my /260 (weird, but no time to debug). They only support /240 and /260 > > due to CONFIG_CPU_HAS_WB unset. > > Yes please. I hope to get a new disk this week, so I can build a > stable development server... The kernels are now available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/linux/'. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Nov 27 10:46:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARIkMS27790 for linux-mips-outgoing; Tue, 27 Nov 2001 10:46:22 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARIivo27759; Tue, 27 Nov 2001 10:44:57 -0800 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 fARHjcB21835; Tue, 27 Nov 2001 09:45:38 -0800 Message-ID: <3C03D113.F8980229@mvista.com> Date: Tue, 27 Nov 2001 09:44:51 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , linux-mips@oss.sgi.com Subject: Re: new asm-mips/io.h References: <20011126.123545.41627333.nemoto@toshiba-tops.co.jp> <20011126200946.A8408@dea.linux-mips.net> <20011127.130406.104026562.nemoto@toshiba-tops.co.jp> <20011127180648.H29424@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Tue, Nov 27, 2001 at 01:04:06PM +0900, Atsushi Nemoto wrote: Not a bad idea in context of fish and chips. > > Well, talk to it's developers before it's too late. Or as it has already > happened for some hardware I think we should simply go with your > suggestion and make all those functions vectors. > I don't know about the details of function vectors, but would imagine it would be 1) slow, 2)clumsy with extra layer of abstraction and 3) intrusive to the most common cases which is the current io file. My suggestion is to have a separate io file for the board, and then add the following to the beginning of io.h: /* for tasteless boards */ #if defined(CONFIG_TOSHIBA_TASTELESS) #define _ASM_IO_H /* so that we don't include the rest */ #include #endif This way not only we have minimum impact to the majority, but also easier to remove such ad hoc support when toshiba becomes more tasteful. Jun From owner-linux-mips@oss.sgi.com Tue Nov 27 11:16:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARJGWp28992 for linux-mips-outgoing; Tue, 27 Nov 2001 11:16:32 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARJGOo28958 for ; Tue, 27 Nov 2001 11:16:24 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id CF519125C8; Tue, 27 Nov 2001 10:16:22 -0800 (PST) Date: Tue, 27 Nov 2001 10:16:22 -0800 From: "H . J . Lu" To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: PATCH: Fix ELF (Re: The Linux binutils 2.11.92.0.12 is released.) Message-ID: <20011127101622.A30458@lucon.org> References: <20011126212859.A17557@lucon.org> <20011127180022.A6897@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127180022.A6897@convergence.de>; from js@convergence.de on Tue, Nov 27, 2001 at 06:00:22PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 06:00:22PM +0100, Johannes Stezenbach wrote: > Hi, > > On Mon, Nov 26, 2001 at 09:28:59PM -0800, H . J . Lu wrote: > > Please report any bugs related to binutils 2.11.92.0.12 to hjl@lucon.org. > > I tried to use binutils-2.11.92.0.12 with gcc-3.0.2 to compile > the linux kernel from linux-mips.sourceforge.net for a VR4121 CPU > (littel endian, target mipsel-linux). > > a) The linker chrashes trying to create the object file for the > embedded initrd ramdisk: > > make CFLAGS="-I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe " -C arch/mips/ramdisk > make[1]: Entering directory `/home/js/MIPS/kernel/build/linux-2.4.14-mips/arch/mips/ramdisk' > echo "O_FORMAT: " elf32-tradlittlemips > O_FORMAT: elf32-tradlittlemips > mipsel-linux-ld -G 0 -T ld.script -b binary --oformat elf32-tradlittlemips -o ramdisk.o ramdisk.gz > make[1]: *** [ramdisk.o] Segmentation fault > make[1]: *** Deleting file `ramdisk.o' > > The same ramdisk.gz worked with binutils-2.11.92.0.10. The ld.script is: > OUTPUT_ARCH(mips) > SECTIONS > { > .initrd : > { > *(.data) > } > } > > I am going to check in this patch to fix it. H.J. ---- 2001-11-27 H.J. Lu * elflink.h (elf_bfd_discard_info): Skip if the input bfd isn't ELF. Index: elflink.h =================================================================== RCS file: /work/cvs/gnu/binutils/bfd/elflink.h,v retrieving revision 1.96.2.1 diff -u -p -r1.96.2.1 elflink.h --- elflink.h 2001/11/25 19:55:57 1.96.2.1 +++ elflink.h 2001/11/27 18:14:32 @@ -8079,6 +8079,9 @@ elf_bfd_discard_info (info) return false; for (abfd = info->input_bfds; abfd != NULL; abfd = abfd->link_next) { + if (bfd_get_flavour (abfd) != bfd_target_elf_flavour) + continue; + bed = get_elf_backend_data (abfd); if ((abfd->flags & DYNAMIC) != 0) From owner-linux-mips@oss.sgi.com Tue Nov 27 11:25:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARJPsw29161 for linux-mips-outgoing; Tue, 27 Nov 2001 11:25:54 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARJPqo29158 for ; Tue, 27 Nov 2001 11:25:52 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id A935C125C8; Tue, 27 Nov 2001 10:25:50 -0800 (PST) Date: Tue, 27 Nov 2001 10:25:50 -0800 From: "H . J . Lu" To: Johannes Stezenbach Cc: linux-mips@oss.sgi.com Subject: Re: The Linux binutils 2.11.92.0.12 is released. Message-ID: <20011127102550.A30681@lucon.org> References: <20011126212859.A17557@lucon.org> <20011127180022.A6897@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127180022.A6897@convergence.de>; from js@convergence.de on Tue, Nov 27, 2001 at 06:00:22PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 06:00:22PM +0100, Johannes Stezenbach wrote: > > b) I still get the -march vs. -mipsN warings: > > mipsel-linux-gcc -I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe -fno-omit-frame-pointer -c -o sched.o sched.c > Assembler messages: > Warning: The -march option is incompatible to -mipsN and therefore ignored. > Please make sure binutils 2.11.92.0.12 is used. Please send me the output of # mipsel-linux-gcc -v -I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe -fno-omit-frame-pointer -c -o sched.o sched.c "-v" will tell me which gas you are using. H.J. From owner-linux-mips@oss.sgi.com Tue Nov 27 11:54:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARJsLZ29686 for linux-mips-outgoing; Tue, 27 Nov 2001 11:54:21 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARJsHo29681 for ; Tue, 27 Nov 2001 11:54:18 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 168nN3-00034i-00; Tue, 27 Nov 2001 13:54:17 -0500 Date: Tue, 27 Nov 2001 13:54:17 -0500 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Johannes Stezenbach , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com Subject: Re: PATCH: Fix ELF (Re: The Linux binutils 2.11.92.0.12 is released.) Message-ID: <20011127135417.B11611@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , Johannes Stezenbach , linux-mips@oss.sgi.com, binutils@sourceware.cygnus.com References: <20011126212859.A17557@lucon.org> <20011127180022.A6897@convergence.de> <20011127101622.A30458@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011127101622.A30458@lucon.org> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 10:16:22AM -0800, H . J . Lu wrote: > I am going to check in this patch to fix it. > > > H.J. > ---- > 2001-11-27 H.J. Lu > > * elflink.h (elf_bfd_discard_info): Skip if the input bfd isn't > ELF. Thanks, you're quite correct. This suggests that linking from ELF to something else won't discard stabs, which makes sense to me. We barely support linking direct to things like SREC as it is, because of the way the linker code is layed out. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Nov 27 12:26:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARKQZT30458 for linux-mips-outgoing; Tue, 27 Nov 2001 12:26:35 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARKNXo30360; Tue, 27 Nov 2001 12:23:33 -0800 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 fARJODB28054; Tue, 27 Nov 2001 11:24:13 -0800 Message-ID: <3C03E82F.462A8E7C@mvista.com> Date: Tue, 27 Nov 2001 11:23:27 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: [PATCH] MIPS RTC driver again Content-Type: multipart/mixed; boundary="------------AF391AE875D823750F12E752" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------AF391AE875D823750F12E752 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In last round of RFC, I heard several voices: . some similar ones are already there, drivers/macintosh/rtc.c. But we can't really use it unless we modified it to interface with MIPS kernel rtc routines and fix a couple of other minor stuff. Even then it seems a little politically incorrect to use a Macintosh driver for MIPS boards. :-) . Tom Rini wants to do a universal RTC driver. Cool, we need to wait. Meanwhile I also heard people who want the driver. So it seems to me it makes sense to check in this driver. Right now there are nine boards using NEW_TIME_C, which can benefit from this driver immediately. I expect more boards will use NEW_TIME_C soon. So here is my updated patch. Please consider for applying. Jun --------------AF391AE875D823750F12E752 Content-Type: text/plain; charset=us-ascii; name="mips-rtc.011127.011127.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mips-rtc.011127.011127.patch" diff -Nru linux/Documentation/Configure.help.orig linux/Documentation/Configure.help --- linux/Documentation/Configure.help.orig Tue Nov 6 11:25:32 2001 +++ linux/Documentation/Configure.help Tue Nov 27 11:05:10 2001 @@ -15163,6 +15163,17 @@ #EFI Real Time Clock Services #CONFIG_EFI_RTC +Generic MIPS RTC Support +CONFIG_MIPS_RTC + + If your machine is a MIPS machine, this option provides a simple, + generic RTC driver for /dev/rtc device. It only implements two IOCTL + operations of the standard PC RTC driver: RTC_RD_TIME and RTC_SET_TIME. + It is sufficient to run hwclock program. + + You should say Y here if there is no machine-specific RTC driver for your + MIPS machine but you do want a simple RTC driver for your RTC device. + Tadpole ANA H8 Support CONFIG_H8 The Hitachi H8/337 is a microcontroller used to deal with the power diff -Nru linux/drivers/char/Config.in.orig linux/drivers/char/Config.in --- linux/drivers/char/Config.in.orig Tue Nov 27 11:03:11 2001 +++ linux/drivers/char/Config.in Tue Nov 27 11:05:10 2001 @@ -213,6 +213,9 @@ if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then bool 'Tadpole ANA H8 Support' CONFIG_H8 fi +if [ "$CONFIG_MIPS" = "y" -a "$CONFIG_NEW_TIME_C" = "y" ]; then + tristate 'Generic MIPS RTC Support' CONFIG_MIPS_RTC +fi tristate 'Double Talk PC internal speech card support' CONFIG_DTLK tristate 'Siemens R3964 line discipline' CONFIG_R3964 diff -Nru linux/drivers/char/Makefile.orig linux/drivers/char/Makefile --- linux/drivers/char/Makefile.orig Tue Nov 27 11:03:12 2001 +++ linux/drivers/char/Makefile Tue Nov 27 11:05:10 2001 @@ -196,6 +196,7 @@ obj-$(CONFIG_PC110_PAD) += pc110pad.o obj-$(CONFIG_RTC) += rtc.o obj-$(CONFIG_EFI_RTC) += efirtc.o +obj-$(CONFIG_MIPS_RTC) += mips_rtc.o ifeq ($(CONFIG_PPC),) obj-$(CONFIG_NVRAM) += nvram.o endif diff -Nru linux/drivers/char/mips_rtc.c.orig linux/drivers/char/mips_rtc.c --- linux/drivers/char/mips_rtc.c.orig Tue Nov 27 11:05:10 2001 +++ linux/drivers/char/mips_rtc.c Tue Nov 27 11:05:10 2001 @@ -0,0 +1,221 @@ +/* + * A simple generic Real Time Clock interface for Linux/MIPS + * + * Copyright (C) 1996 Paul Gortmaker + * + * Copyright (C) 2001 Monta Vista Software + * Author Jun Sun, jsun@mvista.com or jsun@junsun.net + * + * This is a simple generic RTC driver for MIPS boards configured + * with CONFIG_NEW_TIME_C. For now, it makes use of the two + * abstract kernel RTC functions introduced in include/asm-mips/time.h: + * + * extern unsigned long (*rtc_get_time)(void); + * extern int (*rtc_set_time)(unsigned long); + * + * It uses the same protocol as the original drivers/char/rtc.c driver, + * but only implements two ioctls: RTC_RD_TIME and RTC_SET_TIME. + * + * TODO : + * + * 1. we can extend the null rtc ops defined in arch/mips/time.c to + * at least record the elapsed time (by recording/checking jiffies) + * This way RTC_RD_TIME and RTC_SET_TIME will make more sense. + * (Maybe not. A machine without a real RTC is broken anymore. + * Just a thought.) + * + * 2. If we make use of timer bh, we can emulate many RTC functions + * such as RTC alarm interrupt, periodic interrupts, etc. + * + * 3. It is possible to extend the kernel RTC abstractions to more + * than two functions, so that perhaps we can implement more + * full-featured RTC driver and also have a better abstraction + * to support more RTC hardware than the original RTC driver. + * It needs to be done very carefully. + * + * Change Log : + * v1.0 - [jsun] initial version + */ + +#define RTC_VERSION "1.0" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * Check machine + */ +#if !defined(CONFIG_MIPS) || !defined(CONFIG_NEW_TIME_C) +#error "This driver is for MIPS machines with CONFIG_NEW_TIME_C defined" +#endif + +#include + +static unsigned long rtc_status = 0; /* bitmapped status byte. */ + +static int rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data); + + +#define RTC_IS_OPEN 0x01 /* means /dev/rtc is in use */ + +static spinlock_t rtc_lock; + +static int +rtc_ioctl(struct inode *inode, struct file *file, unsigned int cmd, + unsigned long arg) +{ + struct rtc_time rtc_tm; + ulong curr_time; + + switch (cmd) { + case RTC_RD_TIME: /* Read the time/date from RTC */ + curr_time = rtc_get_time(); + to_tm(curr_time, &rtc_tm); + rtc_tm.tm_year -= 1900; + return copy_to_user((void *) arg, &rtc_tm, sizeof(rtc_tm)) ? + -EFAULT : 0; + case RTC_SET_TIME: /* Set the RTC */ + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + if (copy_from_user(&rtc_tm, + (struct rtc_time *) arg, + sizeof(struct rtc_time))) + return -EFAULT; + + curr_time = mktime(rtc_tm.tm_year + 1900, + rtc_tm.tm_mon + 1, /* tm_mon starts from 0 */ + rtc_tm.tm_mday, + rtc_tm.tm_hour, + rtc_tm.tm_min, + rtc_tm.tm_sec); + return rtc_set_time(curr_time); + default: + return -EINVAL; + } +} + +/* We use rtc_lock to protect against concurrent opens. So the BKL is not + * needed here. Or anywhere else in this driver. */ +static int rtc_open(struct inode *inode, struct file *file) +{ + spin_lock_irq(&rtc_lock); + + if (rtc_status & RTC_IS_OPEN) { + spin_unlock_irq(&rtc_lock); + return -EBUSY; + } + + rtc_status |= RTC_IS_OPEN; + + spin_unlock_irq(&rtc_lock); + return 0; +} + +static int rtc_release(struct inode *inode, struct file *file) +{ + spin_lock_irq(&rtc_lock); + rtc_status &= ~RTC_IS_OPEN; + spin_unlock_irq(&rtc_lock); + return 0; +} + +/* + * The various file operations we support. + */ + +static struct file_operations rtc_fops = { + owner:THIS_MODULE, + llseek:no_llseek, + ioctl:rtc_ioctl, + open:rtc_open, + release:rtc_release, +}; + +static struct miscdevice rtc_dev = { + RTC_MINOR, + "rtc", + &rtc_fops +}; + +static int __init rtc_init(void) +{ + + misc_register(&rtc_dev); + create_proc_read_entry("driver/rtc", 0, 0, rtc_read_proc, NULL); + + printk(KERN_INFO "Generic MIPS RTC Driver v" RTC_VERSION "\n"); + + return 0; +} + +static void __exit rtc_exit(void) +{ + remove_proc_entry("driver/rtc", NULL); + misc_deregister(&rtc_dev); + +} + +module_init(rtc_init); +module_exit(rtc_exit); +EXPORT_NO_SYMBOLS; + +/* + * Info exported via "/proc/driver/rtc". + */ + +static int rtc_proc_output(char *buf) +{ + char *p; + struct rtc_time tm; + unsigned long curr_time; + + curr_time = rtc_get_time(); + to_tm(curr_time, &tm); + + p = buf; + + /* + * There is no way to tell if the luser has the RTC set for local + * time or for Universal Standard Time (GMT). Probably local though. + */ + p += sprintf(p, + "rtc_time\t: %02d:%02d:%02d\n" + "rtc_date\t: %04d-%02d-%02d\n" + "rtc_epoch\t: %04lu\n", + tm.tm_hour, tm.tm_min, tm.tm_sec, + tm.tm_year, tm.tm_mon + 1, tm.tm_mday, 0L); + + return p - buf; +} + +static int rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + int len = rtc_proc_output(page); + if (len <= off + count) + *eof = 1; + *start = page + off; + len -= off; + if (len > count) + len = count; + if (len < 0) + len = 0; + return len; +} + +MODULE_AUTHOR("Jun Sun"); +MODULE_LICENSE("GPL"); --------------AF391AE875D823750F12E752-- From owner-linux-mips@oss.sgi.com Tue Nov 27 13:52:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARLqNq32235 for linux-mips-outgoing; Tue, 27 Nov 2001 13:52:23 -0800 Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARLqKo32232 for ; Tue, 27 Nov 2001 13:52:20 -0800 Received: from js by hell with local (Exim 3.33 #1 (Debian)) id 168pDA-000204-00; Tue, 27 Nov 2001 21:52:12 +0100 Date: Tue, 27 Nov 2001 21:52:12 +0100 From: Johannes Stezenbach To: "H . J . Lu" Cc: linux-mips@oss.sgi.com Subject: Re: The Linux binutils 2.11.92.0.12 is released. Message-ID: <20011127215212.A7656@convergence.de> Mail-Followup-To: Johannes Stezenbach , "H . J . Lu" , linux-mips@oss.sgi.com References: <20011126212859.A17557@lucon.org> <20011127180022.A6897@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011127180022.A6897@convergence.de> User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I wrote: > b) I still get the -march vs. -mipsN warings: > > mipsel-linux-gcc -I /home/js/MIPS/kernel/build/linux-2.4.14-mips/include/asm/gcc -D__KERNEL__ -I/home/js/MIPS/kernel/build/linux-2.4.14-mips/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mips2 -Wa,-m4100,--trap -pipe -fno-omit-frame-pointer -c -o sched.o sched.c > Assembler messages: > Warning: The -march option is incompatible to -mipsN and therefore ignored. /me being stupid. I forgot to apply the binutils-2.0.92.0.12/mips/binutils-mips-isa.patch. With the patch, binutils works correctly. Regards, Johannes From owner-linux-mips@oss.sgi.com Tue Nov 27 14:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARMNBq00754 for linux-mips-outgoing; Tue, 27 Nov 2001 14:23:11 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARMN3o00747 for ; Tue, 27 Nov 2001 14:23:03 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id A465497A; Tue, 27 Nov 2001 22:22:57 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5F31F3F47; Tue, 27 Nov 2001 17:39:21 +0100 (CET) Date: Tue, 27 Nov 2001 17:39:21 +0100 From: Florian Lohoff To: Karsten Merker Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127173921.A11918@paradigm.rfc822.org> References: <20011126204509.A10341@paradigm.rfc822.org> <20011126213450.B943@excalibur.cologne.de> <20011126231737.B13081@paradigm.rfc822.org> <20011126233548.D26510@finlandia.infodrom.north.de> <20011127071800.A292@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20011127071800.A292@excalibur.cologne.de> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 07:18:10AM +0100, Karsten Merker wrote: > On Mon, Nov 26, 2001 at 11:35:48PM +0100, Martin Schulze wrote: >=20 > > > How can the RM200 port be wrong endianess - The RM200 is bi-endian > > > thus any endianess would be ok (As long as the port does not assume > > > a specific endianess except the prom stuff). >=20 > Unfortunately the firmware functions are different between little- and > big-endian firmware and there are quite some parts in the RM200 support > which currently do not work (and some even do not compile) on a big-endian > machine due to missing (correct) definitions. Another problem regarding= =20 > the big endian firmware is that nobody seems to have documentation about > it, not even a function vector table. I compiled a kernel yesterday - The only thing comlaining is a header file for some definitions. > > As I remember, you can't switch to "the right" endianess without a supp= ort > > drivers f*ckup disk - which hasn't appeared on the stage yet. >=20 > Right - Ralf had asked around for some disks to convert his LE RM200C to > BE firmware for further development, but nobody had yet been able to > come up with some. Additionally, AFAICS these disks are different for > different machine types and possibly even for different CPU types > (RM200 EISA vs. RM200C PCI and R4k vs R5k). If anybody knows more about > these issues, any help is welcome. They are - The disk type can be determined by the PartNo. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A8G5Uaz2rXW+gJcRAo1SAJ4kvH4BMey/5F24d5ac6SIZducc3gCcCR+0 SfXm4wtOyABOOXmiLcHo0d4= =PNyu -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-linux-mips@oss.sgi.com Tue Nov 27 14:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARMNBv00753 for linux-mips-outgoing; Tue, 27 Nov 2001 14:23:11 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fARMN3o00746; Tue, 27 Nov 2001 14:23:03 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id BFBAF97C; Tue, 27 Nov 2001 22:22:57 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 9F8023F47; Tue, 27 Nov 2001 17:39:47 +0100 (CET) Date: Tue, 27 Nov 2001 17:39:47 +0100 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011127173947.B11918@paradigm.rfc822.org> References: <20011126204509.A10341@paradigm.rfc822.org> <20011127171950.B29424@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <20011127171950.B29424@dea.linux-mips.net> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 05:19:50PM +1100, Ralf Baechle wrote: > I'm only maintaining in the sense of making sure the default configuration > still compiles. The last kernel I know is working is 2.1.73 which needs > some patches that are not in the standard CVS. Even if the RM200C is > broken, it's a relativly sane system and so fixing should be fairly easy. BTW: Do you still have those patches ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8A8HTUaz2rXW+gJcRAqMJAKDdPQDDfMF11HaoCf2aiE7VzgDWcgCgsQLz D5Dhd4T7wYD2Vp/Vcleejxo= =ygd5 -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-linux-mips@oss.sgi.com Tue Nov 27 15:12:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fARNCvT01940 for linux-mips-outgoing; Tue, 27 Nov 2001 15:12:57 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fARNCto01937 for ; Tue, 27 Nov 2001 15:12:55 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fARMCmS24215; Wed, 28 Nov 2001 09:12:48 +1100 Date: Wed, 28 Nov 2001 09:12:48 +1100 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: Status RM200 Message-ID: <20011128091248.A24032@dea.linux-mips.net> References: <20011126204509.A10341@paradigm.rfc822.org> <20011127171950.B29424@dea.linux-mips.net> <20011127173947.B11918@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011127173947.B11918@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Nov 27, 2001 at 05:39:47PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 05:39:47PM +0100, Florian Lohoff wrote: > On Tue, Nov 27, 2001 at 05:19:50PM +1100, Ralf Baechle wrote: > > I'm only maintaining in the sense of making sure the default configuration > > still compiles. The last kernel I know is working is 2.1.73 which needs > > some patches that are not in the standard CVS. Even if the RM200C is > > broken, it's a relativly sane system and so fixing should be fairly easy. > > BTW: Do you still have those patches ? Yes, on a machine that is on the other side of the globe ... As I remember those patches were mostly stuff like endianess fixes to the NCR driver which is looking very different today. Nothing that would still apply these days. Ralf From owner-linux-mips@oss.sgi.com Tue Nov 27 17:06:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS16bm04741 for linux-mips-outgoing; Tue, 27 Nov 2001 17:06:37 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS16Vo04738 for ; Tue, 27 Nov 2001 17:06:32 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id A34A8125C8; Tue, 27 Nov 2001 16:06:30 -0800 (PST) Date: Tue, 27 Nov 2001 16:06:30 -0800 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Does the MIPS 2.4.14 kernel work with RedHat 7.1? Message-ID: <20011127160630.A4448@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does the MIPS 2.4.14 kernel work with RedHat 7.1? I couldn't get RedHat 7.1 to work with today's 2.4.14 kernel from oss.sgi.com. All dynamic binaries die inside of dynamic linker: #0 0x2aab1ed8 in _dl_lookup_versioned_symbol ( undef_name=0x2adc05cb "nis_local_directory", undef_map=0x10012410, ref=0x7fff2050, symbol_scope=0x10012674, version=0x1000f440, type_class=1, explicit=0) at do-lookup.h:80 #1 0x2aab4130 in _dl_relocate_object () at ../sysdeps/mips/dl-machine.h:626 #2 0x2acb9694 in dl_open_worker (a=0x10012410) at dl-open.c:289 #3 0x2aab62c0 in _dl_catch_error (objname=0x7fff2230, errstring=0x7fff2234, operate=0x2acb9220 , args=0x7fff2220) at dl-error.c:152 #4 0x2acb9a00 in _dl_open (file=0x7fff23f0 "libnss_nis.so.2", mode=1, caller=0x0) at dl-open.c:402 #5 0x2acbac50 in do_dlopen (ptr=0x7fff23c0) at dl-libc.c:78 #6 0x2aab62c0 in _dl_catch_error (objname=0x7fff23c8, errstring=0x7fff23cc, operate=0x2acbac14 , args=0x7fff23c0) at dl-error.c:152 #7 0x2acbaa84 in __libc_dlopen ( __name=0x433acb9
) at dl-libc.c:42 #8 0x2ac8d114 in __nss_lookup_function (ni=0x10010110, fct_name=0x2acd068c "endpwent") at nsswitch.c:340 #9 0x2ac8e08c in __nss_next (ni=0x2ad1ea70, fct_name=0x2acd068c "endpwent", fctp=0x7fff7a68, status=2147427264, all_values=1) at nsswitch.c:194 #10 0x2ac8e6f4 in __nss_endent (func_name=0x2acd068c "endpwent", lookup_fct=0x2ac8f650 <__nss_passwd_lookup>, nip=0x2ad1ea70, startp=0x1, last_nip=0x2ad1ea74, res=0) at getnssent_r.c:117 #11 0x2ac406e0 in endpwent () at ../nss/getXXent_r.c:135 #12 0x00413cc4 in get_current_user_info () at shell.c:1455 #13 0x00413e8c in shell_initialize () at shell.c:1498 #14 0x00410880 in main (argc=1, argv=0x7fff7f24, env=0x7fff7f2c) at shell.c:474 (gdb) p sym $34 = (Elf32_Sym *) 0xd8554764 (gdb) p symidx $35 = 718791408 (gdb) p map->l_buckets[hash % map->l_nbuckets] $36 = 718791408 (gdb) p hash % map->l_nbuckets $37 = 113 (gdb) p/x hash $38 = 0x433acb9 (gdb) p map->l_nbuckets $39 = 227 It looks like the memory is corrupted. H.J. From owner-linux-mips@oss.sgi.com Tue Nov 27 18:09:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS29RP06988 for linux-mips-outgoing; Tue, 27 Nov 2001 18:09:27 -0800 Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS29Bo06978; Tue, 27 Nov 2001 18:09:11 -0800 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fAS195u17289; Tue, 27 Nov 2001 17:09:05 -0800 Received: from exceed2.sanera.net (exceed2.sanera.net [172.16.2.39]) by icarus.sanera.net (8.11.6/8.11.6) with ESMTP id fAS190D02504; Tue, 27 Nov 2001 17:09:00 -0800 Received: from exceed2.sanera.net (exceed2.sanera.net [172.16.2.39]) by exceed2.sanera.net (8.9.3+Sun/8.9.3) with SMTP id RAA17976; Tue, 27 Nov 2001 17:09:00 -0800 (PST) Message-Id: <200111280109.RAA17976@exceed2.sanera.net> Date: Tue, 27 Nov 2001 17:09:00 -0800 (PST) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Memory leaks in SMP MIPS linux 2.4.9? To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iJGi9Z33rR7kR0SiCO2dGg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I suspect that there are some memory leaks in the SMP MIPS linux 2.4.9. I would like to know if any one found the root cause and fixed them. Here is the description of the memory leak that I am seeing- 1. Summary: Memory leaks in Linux 2.4.9 MIPS SMP kernel 2. Description: I see that MemFree, as reported by /proc/meminfo, goes down when I run the following script. while true do date cat /proc/meminfo cat /proc/slabinfo done MemFree goes down continuously when this script is run. When I ran this script for 3-4 days, the MemFree went down to 10% of MemTotal! I just ran the script for 3 hours are here is the diff between the out put of /proc/meminfo and /proc/slabinfo before and after the test run ( lines with "<" are before the test and lines with ">" are after the test) < Mem: 259584000 15634432 243949568 0 8388608 3756032 --- > Mem: 259584000 28954624 230629376 0 8388608 3756032 6c6 < MemFree: 238232 kB --- > MemFree: 225224 kB 14c14 < Inact_target: 140 kB --- > Inact_target: 4 kB 18c18 < LowFree: 238232 kB --- > LowFree: 225224 kB 41c41 < sigqueue 29 29 132 1 1 1 : 252 126 --- > sigqueue 261 261 132 9 9 1 : 252 126 45,46c45,46 < inode_cache 88 88 480 11 11 1 : 124 62 < dentry_cache 180 180 128 6 6 1 : 252 126 --- > inode_cache 216 216 480 27 27 1 : 124 62 > dentry_cache 420 420 128 14 14 1 : 252 126 50,53c50,53 < mm_struct 48 48 160 2 2 1 : 252 126 < vm_area_struct 177 177 64 3 3 1 : 252 126 < fs_cache 118 118 64 2 2 1 : 252 126 < files_cache 18 18 416 2 2 1 : 124 62 --- > mm_struct 138 264 160 6 11 1 : 252 126 > vm_area_struct 354 354 64 6 6 1 : 252 126 > fs_cache 169 295 64 4 5 1 : 252 126 > files_cache 135 135 416 15 15 1 : 124 62 70c70 < size-1024 88 88 1024 22 22 1 : 124 62 --- > size-1024 208 208 1024 52 52 1 : 124 62 80c80 < size-32 226 226 32 2 2 1 : 252 126 --- > size-32 339 339 32 3 3 1 : 252 126 3. Keywords mips, SMP, memory leak 4. Kernel version Linux version 2.4.9 5. Output (included as part of description) 6. testcase (included as part of description) 7. Environment 7.1 software None 7.2 Processor info (NOTE *** cat /proc/cpuinfo does not print information about both the CPUs ***) cpu : MIPS processor : 0 cpu model : SiByte SB1 V0.1 BogoMIPS : 332.59 processor : 1 cpu model : SiByte SB1 V0.1 BogoMIPS : 332.59 system type : SiByte unknown byteorder : big endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : yes hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available 7.3 Module information No modules. 7.4 Loaded driver and hardware information (/proc/ioports, /proc/iomem) bash-2.04# cat /proc/ioports bash-2.04# cat /proc/iomem 00000000-0fe94fff : System RAM 00100000-00267d77 : Kernel code 00299a40-002ad38f : Kernel data 7.5 PCI information No PCI devices attached 7.6 SCSI information No SCSI devices attached 7.7 Other information Single user system with no networking. Root file system is in the ramdisk. 8. Notes When I did some investigation, it looked like d_lookup() is not finding /proc/meminfo and /proc/slabinfo in the dcache and it is doing d_alloc() to add these to the cache every time cat /proc/meminfo or cat /proc/slabinfo is done. This looked odd and I ran the same script on x86 based linux (running 2.4.2) and I did not see MemFree (or any other caches) changing after the test was run for an hour. I am not sure how this is architecture dependent. Thanks Krishna Kondaka Sanera Systems From owner-linux-mips@oss.sgi.com Tue Nov 27 21:06:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS562R02190 for linux-mips-outgoing; Tue, 27 Nov 2001 21:06:02 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAS55uo02187 for ; Tue, 27 Nov 2001 21:05:57 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAS45qn28101; Wed, 28 Nov 2001 15:05:52 +1100 Date: Wed, 28 Nov 2001 15:05:52 +1100 From: Ralf Baechle To: Krishna Kondaka Cc: linux-mips@oss.sgi.com Subject: Re: Memory leaks in SMP MIPS linux 2.4.9? Message-ID: <20011128150552.A27925@dea.linux-mips.net> References: <200111280109.RAA17976@exceed2.sanera.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111280109.RAA17976@exceed2.sanera.net>; from krishna@Sanera.net on Tue, Nov 27, 2001 at 05:09:00PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, Nov 27, 2001 at 05:09:00PM -0800, Krishna Kondaka wrote: > I suspect that there are some memory leaks in the SMP MIPS linux 2.4.9. > I would like to know if any one found the root cause and fixed them. See patch below for fix. > I just ran the script for 3 hours are here is the diff between > the out put of /proc/meminfo and /proc/slabinfo before and > after the test run ( lines with "<" are before the test and > lines with ">" are after the test) (Try diff -u which generates much more human readable output.) > When I did some investigation, it looked like d_lookup() is > not finding /proc/meminfo and /proc/slabinfo in the dcache and > it is doing d_alloc() to add these to the cache every time > cat /proc/meminfo or cat /proc/slabinfo is done. This looked odd > and I ran the same script on x86 based linux (running 2.4.2) and > I did not see MemFree (or any other caches) changing after the > test was run for an hour. I am not sure how this is architecture > dependent. These caches essentially keep growing until you run out of memory which is when they'll be freed. Ralf --- linux.orig/include/asm-mips/mmu_context.h.orig Wed Nov 28 14:45:19 2001 +++ linux/include/asm-mips/mmu_context.h Wed Nov 28 14:47:37 2001 @@ -109,7 +109,10 @@ */ extern inline void destroy_context(struct mm_struct *mm) { - /* Nothing to do. */ +#ifdef CONFIG_SMP + if (mm->context) + kfree((void *)mm->context); +#endif } /* From owner-linux-mips@oss.sgi.com Tue Nov 27 21:31:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS5Vwf02618 for linux-mips-outgoing; Tue, 27 Nov 2001 21:31:58 -0800 Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS5Vho02614; Tue, 27 Nov 2001 21:31:43 -0800 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id fAS4Vbu18295; Tue, 27 Nov 2001 20:31:37 -0800 Received: from exceed2.sanera.net (exceed2.sanera.net [172.16.2.39]) by icarus.sanera.net (8.11.6/8.11.6) with ESMTP id fAS4VWD07063; Tue, 27 Nov 2001 20:31:32 -0800 Received: from exceed2.sanera.net (exceed2.sanera.net [172.16.2.39]) by exceed2.sanera.net (8.9.3+Sun/8.9.3) with SMTP id UAA22140; Tue, 27 Nov 2001 20:31:32 -0800 (PST) Message-Id: <200111280431.UAA22140@exceed2.sanera.net> Date: Tue, 27 Nov 2001 20:31:32 -0800 (PST) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Re: Memory leaks in SMP MIPS linux 2.4.9? To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pAX61yYTCRKByEvqLoCbZQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks for the quick reply ralf! Sorry for not mentioning that I did already patch my 2.4.9 with the fix that you mentioned. Even then the MemFree is continuously going down. > >On Tue, Nov 27, 2001 at 05:09:00PM -0800, Krishna Kondaka wrote: > >> I suspect that there are some memory leaks in the SMP MIPS linux 2.4.9. >> I would like to know if any one found the root cause and fixed them. > >See patch below for fix. > >> I just ran the script for 3 hours are here is the diff between >> the out put of /proc/meminfo and /proc/slabinfo before and >> after the test run ( lines with "<" are before the test and >> lines with ">" are after the test) > >(Try diff -u which generates much more human readable output.) > >> When I did some investigation, it looked like d_lookup() is >> not finding /proc/meminfo and /proc/slabinfo in the dcache and >> it is doing d_alloc() to add these to the cache every time >> cat /proc/meminfo or cat /proc/slabinfo is done. This looked odd >> and I ran the same script on x86 based linux (running 2.4.2) and >> I did not see MemFree (or any other caches) changing after the >> test was run for an hour. I am not sure how this is architecture >> dependent. > >These caches essentially keep growing until you run out of memory which >is when they'll be freed. Yeah! But there is no need for them to grow because I am accessing the same file names again and again and hence they should be available in the cache after the first time. d_alloc()s are not not being done when referencing /lib/libc.so.6 second time but they are being done when referencing /proc/meminfo or /proc/slabinfo. The behavior is different because "/proc" is a mount point and "/lib" is not. But I still feel that there is no need to do d_alloc() for repeatedly when /proc/meminfo is already in the cache(I have printed the entire dcache entries and it shows that /proc/meminfo is in the dcache). Thanks Krishna > > Ralf > >--- linux.orig/include/asm-mips/mmu_context.h.orig Wed Nov 28 14:45:19 2001 >+++ linux/include/asm-mips/mmu_context.h Wed Nov 28 14:47:37 2001 >@@ -109,7 +109,10 @@ > */ > extern inline void destroy_context(struct mm_struct *mm) > { >- /* Nothing to do. */ >+#ifdef CONFIG_SMP >+ if (mm->context) >+ kfree((void *)mm->context); >+#endif > } > > /* From owner-linux-mips@oss.sgi.com Tue Nov 27 23:26:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS7Q8G05335 for linux-mips-outgoing; Tue, 27 Nov 2001 23:26:08 -0800 Received: from argyre.fr.uu.net (mail.fr.uu.net [194.98.0.9]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS7Q0o05325 for ; Tue, 27 Nov 2001 23:26:06 -0800 Received: from [213.11.39.87] ([213.11.39.87]) by argyre.fr.uu.net (8.9.3/8.8.7) with SMTP id HAA14794 for ; Wed, 28 Nov 2001 07:32:36 +0100 (MET) From: annuaire@annuairefrancais.com Message-Id: <200111280632.HAA14794@argyre.fr.uu.net> Mime-Version: 1.0 Content-Type: text/plain;charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 28 Nov 2001 07:25:58 +0100 To: linux-mips@oss.sgi.com Subject: Info : L'Annuaire Francais par Departement facilite vos recherches Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Bonjour, L'annuaire Francais Par departement http://www.annuairefrancais.com integre desormais un moteur de recherche pour affiner vos recherches sur le web. L'inscription reste gratuite et la validation toujours manuelle. L'adresse d'inscription est desormais http://inscrip.annuairefrancais.com Pour toutes suggestions contactez par mail : direction : laurent@annuairefrancais.com validation : validation@annuairefrancais.com publicite : publicite@annuairefrancais.com partenariat : partenariat@annuairefrancais.com INFORMATIONS : retrait de notre liste d'info : http://supressinfo.annuairefrancais.com (L'annuaire francais envoi 2 infos par an) L'annuaire Francais 119 Rue des Pyrenees 75020 PARIS +33 (0)1 43 67 00 74 From owner-linux-mips@oss.sgi.com Tue Nov 27 23:55:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAS7tYL05849 for linux-mips-outgoing; Tue, 27 Nov 2001 23:55:34 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS7tUo05846 for ; Tue, 27 Nov 2001 23:55:30 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id AE91D125C8; Tue, 27 Nov 2001 22:55:25 -0800 (PST) Date: Tue, 27 Nov 2001 22:55:25 -0800 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , Murat_Berk@bmc.com Subject: Re: The Linux binutils 2.11.92.0.12 is released. Message-ID: <20011127225525.A10977@lucon.org> References: <20011126212859.A17557@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126212859.A17557@lucon.org>; from hjl@lucon.org on Mon, Nov 26, 2001 at 09:28:59PM -0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Nov 26, 2001 at 09:28:59PM -0800, H . J . Lu wrote: > This is the beta release of binutils 2.11.92.0.12 for Linux, which is > based on binutils 2001 1121 in CVS on sourecware.cygnus.com plus > various changes. It is purely for Linux. > I am planning to make a bug fix release before this weekend. I have only one patch so far: http://sources.redhat.com/ml/binutils/2001-11/msg00691.html Please let me know there are any regressions over the previous Linux binutils. Thanks. H.J. From owner-linux-mips@oss.sgi.com Wed Nov 28 02:00:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASA03008335 for linux-mips-outgoing; Wed, 28 Nov 2001 02:00:03 -0800 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAS9xvo08300 for ; Wed, 28 Nov 2001 01:59:57 -0800 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA09733 for ; Wed, 28 Nov 2001 00:59:50 -0800 (PST) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA00676 for ; Wed, 28 Nov 2001 00:59:49 -0800 (PST) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id fAS8xlA00199 for ; Wed, 28 Nov 2001 09:59:47 +0100 (MET) Message-ID: <3C04A786.DBD06A47@mips.com> Date: Wed, 28 Nov 2001 09:59:50 +0100 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: The 2.4.14 kernel is broken for 5Kc CPUs. Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf please apply the following. Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.93 diff -u -r1.93 setup.c --- arch/mips/kernel/setup.c 2001/11/27 01:43:32 1.93 +++ arch/mips/kernel/setup.c 2001/11/28 09:54:10 @@ -466,8 +466,8 @@ mips_cpu.options |= MIPS_CPU_MIPS16; if (config1 & 1) mips_cpu.options |= MIPS_CPU_FPU; - break; mips_cpu.scache.flags = MIPS_CACHE_NOT_PRESENT; + break; default: mips_cpu.cputype = CPU_UNKNOWN; break; /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Nov 28 05:37:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASDbBn20128 for linux-mips-outgoing; Wed, 28 Nov 2001 05:37:11 -0800 Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.176.19]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASDaxo20110 for ; Wed, 28 Nov 2001 05:37:00 -0800 Received: (qmail 13941 invoked from network); 28 Nov 2001 12:36:18 -0000 Received: from mimas.fachschaften.tu-muenchen.de (HELO mimas) (129.187.176.26) by hermes.fachschaften.tu-muenchen.de with SMTP; 28 Nov 2001 12:36:18 -0000 Date: Wed, 28 Nov 2001 13:36:48 +0100 (CET) From: Adrian Bunk X-X-Sender: bunk@mimas.fachschaften.tu-muenchen.de To: linux-mips@oss.sgi.com Subject: [patch] NONCOHERENT compile fix for r3k Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id fASDb0o20111 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I got the following erros while compiling a kernel for my 5000/240: gcc -I /home/bunk/linux/include/asm/gcc -D__KERNEL__ -I/home/bunk/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c -o c-r3k.o c-r3k.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. c-r3k.c: In function `ld_mmu_r23000': c-r3k.c:334: `_dma_cache_wback_inv' undeclared (first use in this function) c-r3k.c:334: (Each undeclared identifier is reported only once c-r3k.c:334: for each function it appears in.) c-r3k.c:317: warning: unused variable `config' make[2]: *** [c-r3k.o] Error 1 make[2]: Leaving directory `/home/bunk/linux/arch/mips/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/bunk/linux/arch/mips/mm' make: *** [_dir_arch/mips/mm] Error 2 gcc -I /home/bunk/linux/include/asm/gcc -D__KERNEL__ -I/home/bunk/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c -o c-tx39.o c-tx39.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. c-tx39.c: In function `ld_mmu_tx39': c-tx39.c:298: `_dma_cache_wback_inv' undeclared (first use in this function) c-tx39.c:298: (Each undeclared identifier is reported only once c-tx39.c:298: for each function it appears in.) c-tx39.c:320: `_dma_cache_wback' undeclared (first use in this function) c-tx39.c:321: `_dma_cache_inv' undeclared (first use in this function) make[2]: *** [c-tx39.o] Error 1 make[2]: Leaving directory `/home/bunk/linux/arch/mips/mm' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/home/bunk/linux/arch/mips/mm' make: *** [_dir_arch/mips/mm] Error 2 The following patches fix these compile errors: --- arch/mips/mm/c-r3k.c.old Wed Nov 28 11:30:01 2001 +++ arch/mips/mm/c-r3k.c Wed Nov 28 11:38:07 2001 @@ -331,7 +331,11 @@ _flush_icache_page = r3k_flush_icache_page; _flush_icache_range = r3k_flush_icache_range; +#ifdef CONFIG_NONCOHERENT_IO + _dma_cache_wback_inv = r3k_dma_cache_wback_inv; + +#endif /* CONFIG_NONCOHERENT_IO */ printk("Primary instruction cache %dkb, linesize %d bytes\n", (int) (icache_size >> 10), (int) icache_lsize); --- arch/mips/mm/c-tx39.c.old Wed Nov 28 12:08:37 2001 +++ arch/mips/mm/c-tx39.c Wed Nov 28 12:56:28 2001 @@ -295,7 +295,12 @@ _flush_icache_page = (void *) tx39h_flush_icache_all; _flush_icache_range = (void *) tx39h_flush_icache_all; +#ifdef CONFIG_NONCOHERENT_IO + _dma_cache_wback_inv = tx39h_dma_cache_wback_inv; + +#endif /* CONFIG_NONCOHERENT_IO */ + break; case CPU_TX3922: @@ -316,9 +321,13 @@ _flush_icache_page = tx39_flush_icache_page; _flush_icache_range = tx39_flush_icache_range; +#ifdef CONFIG_NONCOHERENT_IO + _dma_cache_wback_inv = tx39_dma_cache_wback_inv; _dma_cache_wback = tx39_dma_cache_wback; _dma_cache_inv = tx39_dma_cache_inv; + +#endif /* CONFIG_NONCOHERENT_IO */ break; } While booting the kernel I had the same problem Flo already reported: scsi0 : ESP236 (NCR53C9x) scsi: unknown type 16 Vendor: . ... . Model: à. . *! Rev: ,. . Type: Unknown ANSI SCSI revision: 04 resize_dma_pool: unknown device type 16 resize_dma_pool: unknown device type 16 cu Adrian From owner-linux-mips@oss.sgi.com Wed Nov 28 06:23:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASEN4H21324 for linux-mips-outgoing; Wed, 28 Nov 2001 06:23:04 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASEMwo21311 for ; Wed, 28 Nov 2001 06:22:58 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id 2F5F5AA2; Wed, 28 Nov 2001 14:22:52 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 701C24127; Wed, 28 Nov 2001 14:19:34 +0100 (CET) Date: Wed, 28 Nov 2001 14:19:34 +0100 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: "Houten K.H.C. van (Karel)" , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com, algernon@debian.org Subject: Re: Decstation /150 kernel (cvs) problems Message-ID: <20011128141934.B5530@paradigm.rfc822.org> References: <20011127163602.C9282@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 06:23:11PM +0100, Maciej W. Rozycki wrote: > On Tue, 27 Nov 2001, Florian Lohoff wrote: > > This is mostly what i do - As the ext2 code loads in the whole file > > as a chunk i am loading it after the booloader - Then copy it to the > > end of the first 8Megs (Which is the minimum memory on a decstation) > > and then copy the chunks marked PROGBITS to their final location. >=20 > That's ugly -- isn't there a possibility to read a file on a > block-by-block basis? >=20 I am using the libext2 which basically might do that - i am unshure. I am currently using=20 retval=3Dext2fs_block_iterate(fs, inode, 0, 0, delo_dump_block, 0); Which basically loads in all the blocks by calling "delo_dump_block" for each block with the block on the device to load and the block number this is in the file. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BORmUaz2rXW+gJcRArAwAJ9hiyiDm8qXO8R5UI0ziyeqAD9lrgCfc0pb 7Snkmd648LtwSmhcmFwDor4= =QYi+ -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- From owner-linux-mips@oss.sgi.com Wed Nov 28 06:23:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASEN8q21330 for linux-mips-outgoing; Wed, 28 Nov 2001 06:23:08 -0800 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASEMwo21312; Wed, 28 Nov 2001 06:22:58 -0800 Received: by noose.gt.owl.de (Postfix, from userid 10) id E29D8AA1; Wed, 28 Nov 2001 14:22:51 +0100 (CET) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id B55814125; Wed, 28 Nov 2001 14:13:39 +0100 (CET) Date: Wed, 28 Nov 2001 14:13:39 +0100 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011128141339.A5530@paradigm.rfc822.org> References: <20011127010214.B21296@paradigm.rfc822.org> <20011127171544.A29424@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20011127171544.A29424@dea.linux-mips.net> User-Agent: Mutt/1.3.23i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 27, 2001 at 05:15:44PM +1100, Ralf Baechle wrote: > On Tue, Nov 27, 2001 at 01:02:14AM +0100, Florian Lohoff wrote: >=20 > Blame whoever designed C that there is no sane way to give a variable an > attribute like "will never change again after the first initalization thus > keeping the value in a register beyond function calls and any other kind > of memory barrier is ok". This inconsistence merily achieves a better > optimization of the code; the set_* function is intended to hide this cute > little standard violation away ... The problem is that it doesnt build without the patch: mipsel-linux-gcc -I /home/mnt/mips/dec/linux/include/asm/gcc -D__KERNEL__ -I/home/mnt/mips/dec/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -G 0 -mno-abicalls -fno-pic -mcpu=3Dr4600 -mips2 -Wa,--trap -pipe -DEXPORT_SYMTAB -c setup.c Assembler messages: Warning: The -mcpu option is deprecated. Please use -march and -mtune instead. Warning: The -march option is incompatible to -mipsN and therefore ignored. setup.c:109: conflicting types for `mips_io_port_base' /home/mnt/mips/dec/linux/include/asm/io.h:63: previous declaration of `mips_io_port_base' setup.c: In function `setup_arch': setup.c:678: warning: unused variable `tmp' setup.c:679: warning: unused variable `initrd_header' make[1]: *** [setup.o] Error 1 make[1]: Leaving directory `/home/mnt/mips/dec/linux/arch/mips/kernel' make: *** [_dir_arch/mips/kernel] Error 2 (flo@paradigm)/home/mnt/mips/dec/linux#=20 (flo@paradigm)/home/mnt/mips/dec/linux# mipsel-linux-gcc -v Reading specs from /usr/local/lib/gcc-lib/mipsel-linux/3.0.2/specs Configured with: ./configure --target=3Dmipsel-linux --enable-languages=3Dc --disable-shared Thread model: single gcc version 3.0.2 20010825 (Debian prerelease) (flo@paradigm)/home/mnt/mips/dec/linux# mipsel-linux-as --version GNU assembler 2.11.92.0.10 Debian/GNU Linux Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `mipsel-linux'. --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Nine nineth on september the 9th Welcome to the new billenium --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8BOMDUaz2rXW+gJcRAl1FAKC27jFWAUwz37hgPqJC2WCmrw+KuQCfUfMp JYeUk7EeRXsaaNi3SDwySB8= =r3NA -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-linux-mips@oss.sgi.com Wed Nov 28 10:16:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASIGxR31780 for linux-mips-outgoing; Wed, 28 Nov 2001 10:16:59 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASIGuo31773; Wed, 28 Nov 2001 10:16:56 -0800 Received: by ocean.lucon.org (Postfix, from userid 1000) id 7308E125C8; Wed, 28 Nov 2001 09:16:55 -0800 (PST) Date: Wed, 28 Nov 2001 09:16:55 -0800 From: "H . J . Lu" To: Florian Lohoff Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011128091655.A20264@lucon.org> References: <20011127010214.B21296@paradigm.rfc822.org> <20011127171544.A29424@dea.linux-mips.net> <20011128141339.A5530@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011128141339.A5530@paradigm.rfc822.org>; from flo@rfc822.org on Wed, Nov 28, 2001 at 02:13:39PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 02:13:39PM +0100, Florian Lohoff wrote: > GNU assembler 2.11.92.0.10 Debian/GNU Linux You need binutils 2.11.92.0.12 and also read my README. H.J. From owner-linux-mips@oss.sgi.com Wed Nov 28 10:23:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASINIJ31925 for linux-mips-outgoing; Wed, 28 Nov 2001 10:23:18 -0800 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASINEo31921; Wed, 28 Nov 2001 10:23:14 -0800 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fASHNBh7012957; Wed, 28 Nov 2001 09:23:11 -0800 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id fASHNAU2012953; Wed, 28 Nov 2001 09:23:10 -0800 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 28 Nov 2001 09:23:10 -0800 (PST) From: James Simmons To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? In-Reply-To: <20011128091655.A20264@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralph please apply this patch to arch/mips/kernel/setup.c. Some compilers don't like the conflict of definition in io.h and setup.c. Thanks. --- setup.c.orig Wed Nov 28 10:19:09 2001 +++ setup.c Wed Nov 28 10:19:20 2001 @@ -106,7 +106,7 @@ * mips_io_port_base is the begin of the address space to which x86 style * I/O ports are mapped. */ -unsigned long mips_io_port_base; EXPORT_SYMBOL(mips_io_port_base); +const unsigned long mips_io_port_base; EXPORT_SYMBOL(mips_io_port_base); /* From owner-linux-mips@oss.sgi.com Wed Nov 28 11:06:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASJ6D800869 for linux-mips-outgoing; Wed, 28 Nov 2001 11:06:13 -0800 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASJ6Ao00866 for ; Wed, 28 Nov 2001 11:06:10 -0800 Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel9.hp.com (Postfix) with ESMTP id B65611F66D for ; Wed, 28 Nov 2001 13:06:03 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 189751F51A for ; Wed, 28 Nov 2001 13:06:03 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 13:06:02 -0500 Message-ID: From: "TWEDE,ROGER (HP-Boise,ex1)" To: Linux/MIPS Development Subject: RedHat 7.1 cross toolchain kernel build problem Date: Wed, 28 Nov 2001 13:06:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does anyone have any ideas why the i386->mipsel cross toolchain at oss.sgi.com:/pub/linux/redhat/7.1/RPMS/i386/toolchain* fails to build vgacon.o in the kernel's drivers/video directory? I get the following errors from the assembler: {standard input}:4683: Error: expression too complex {standard input}:4683: Fatal error: internal Error, line 1980, ../../tools-20011020/gas/config/tc-mips.c make[3]: *** [vgacon.o] Error 1 Apparently the compiler has generated assembly which the assembler cannot handle. I compiled to a .s assembly file and line 4683 was simply 'sb $6,$5($3)'. Thanks, Roger From owner-linux-mips@oss.sgi.com Wed Nov 28 11:21:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASJLZn01150 for linux-mips-outgoing; Wed, 28 Nov 2001 11:21:35 -0800 Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASJLWo01146 for ; Wed, 28 Nov 2001 11:21:33 -0800 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 1699Kf-00076I-00; Wed, 28 Nov 2001 13:21:17 -0500 Date: Wed, 28 Nov 2001 13:21:17 -0500 From: Daniel Jacobowitz To: "TWEDE,ROGER (HP-Boise,ex1)" Cc: Linux/MIPS Development Subject: Re: RedHat 7.1 cross toolchain kernel build problem Message-ID: <20011128132117.A27181@nevyn.them.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 01:06:00PM -0500, TWEDE,ROGER (HP-Boise,ex1) wrote: > Does anyone have any ideas why the i386->mipsel cross toolchain at > oss.sgi.com:/pub/linux/redhat/7.1/RPMS/i386/toolchain* fails to build > vgacon.o in the kernel's drivers/video directory? > > > I get the following errors from the assembler: > {standard input}:4683: Error: expression too complex > {standard input}:4683: Fatal error: internal Error, line 1980, > ../../tools-20011020/gas/config/tc-mips.c > make[3]: *** [vgacon.o] Error 1 > > Apparently the compiler has generated assembly which the assembler cannot > handle. > I compiled to a .s assembly file and line 4683 was simply 'sb $6,$5($3)'. If you search the list archives, I've posted patches for this several times. It's a compiler bug but can be worked around in io.h. $5($3) is not a legal addressing mode. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Nov 28 15:26:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fASNQ5M10939 for linux-mips-outgoing; Wed, 28 Nov 2001 15:26:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fASNPro10926 for ; Wed, 28 Nov 2001 15:25:53 -0800 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 fASMQVB02173; Wed, 28 Nov 2001 14:26:31 -0800 Message-ID: <3C05646B.51BF79FB@mvista.com> Date: Wed, 28 Nov 2001 14:25:47 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: calibrating MIPS counter frequency Content-Type: multipart/mixed; boundary="------------FC85174E863B59DDE137B503" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------FC85174E863B59DDE137B503 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I wrote a little routine to calibrate CPU counter if the frequency is not given by the board setup routine. See the patch below. Not too much use of it right now - unless you are writing some generic MIPS performance test program. Then you should be grateful. It removes the board dependency. In the future, I think mips counter frequency really should go to mips_cpu structure. If we always know the counter frequency, either by board setup routine or runtime calibration, we can get rid of the gettimeoffset calibration routines. Feedbacks are welcome. Jun --------------FC85174E863B59DDE137B503 Content-Type: text/plain; charset=us-ascii; name="calibrate_mips_counter.011128.011128.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="calibrate_mips_counter.011128.011128.patch" Calibrate CPU counter frequency if it is not specified by board setup routine. No usage for now. In the future, it should be part of mips_cpu structure and we can get rid of the run-time gettimeoffset calibration routines. Should also speed timer interrupt a little bit. Jun Sun diff -Nru linux-2.4.14/init/main.c.orig linux-2.4.14/init/main.c --- linux-2.4.14/init/main.c.orig Fri Oct 12 10:17:15 2001 +++ linux-2.4.14/init/main.c Wed Nov 28 11:18:58 2001 @@ -539,6 +539,9 @@ * Activate the first processor. */ +#if defined(CONFIG_MIPS) && defined(CONFIG_NEW_TIME_C) +extern void calibrate_mips_counter(void); +#endif asmlinkage void __init start_kernel(void) { char * command_line; @@ -581,6 +584,9 @@ kmem_cache_init(); sti(); calibrate_delay(); +#if defined(CONFIG_MIPS) && defined(CONFIG_NEW_TIME_C) + calibrate_mips_counter(); +#endif #ifdef CONFIG_BLK_DEV_INITRD if (initrd_start && !initrd_below_start_ok && initrd_start < min_low_pfn << PAGE_SHIFT) { diff -Nru linux-2.4.14/arch/mips/kernel/time.c.orig linux-2.4.14/arch/mips/kernel/time.c --- linux-2.4.14/arch/mips/kernel/time.c.orig Mon Nov 26 18:22:58 2001 +++ linux-2.4.14/arch/mips/kernel/time.c Wed Nov 28 13:57:23 2001 @@ -27,6 +27,7 @@ #include #include #include +#include /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) @@ -505,4 +506,47 @@ * Determine the day of week */ tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */ +} + +/* + * calibrate the mips_counter_frequency + */ +#define CALIBRATION_CYCLES 20 +void calibrate_mips_counter(void) +{ + volatile unsigned long ticks; + volatile unsigned long countStart, countEnd; + + if (mips_counter_frequency) { + /* it is already specified by the board */ + return; + } + + if ((mips_cpu.options & MIPS_CPU_COUNTER) == 0) { + /* we don't have cpu counter */ + return; + } + + printk("calibrating MIPS CPU counter frequency ..."); + + /* wait for the change of jiffies */ + ticks = jiffies; + while (ticks == jiffies); + + /* read cpu counter */ + countStart = read_32bit_cp0_register(CP0_COUNT); + + /* loop for another n jiffies */ + ticks += CALIBRATION_CYCLES + 1; + while (ticks != jiffies); + + /* read counter again */ + countEnd = read_32bit_cp0_register(CP0_COUNT); + + /* assuming HZ is 10's multiple */ + db_assert((HZ % CALIBRATION_CYCLES) == 0); + + mips_counter_frequency = + (countEnd - countStart) * (HZ / CALIBRATION_CYCLES); + printk(" %d Hz\n", mips_counter_frequency); } --------------FC85174E863B59DDE137B503-- From owner-linux-mips@oss.sgi.com Wed Nov 28 20:55:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAT4tJ120742 for linux-mips-outgoing; Wed, 28 Nov 2001 20:55:19 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAT4tHo20738 for ; Wed, 28 Nov 2001 20:55:17 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAT3tDD01829; Thu, 29 Nov 2001 14:55:13 +1100 Date: Thu, 29 Nov 2001 14:55:13 +1100 From: Ralf Baechle To: James Simmons Cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011129145513.D638@dea.linux-mips.net> References: <20011128091655.A20264@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsimmons@transvirtual.com on Wed, Nov 28, 2001 at 09:23:10AM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 09:23:10AM -0800, James Simmons wrote: > Ralph please apply this patch to arch/mips/kernel/setup.c. Some compilers > don't like the conflict of definition in io.h and setup.c. Thanks. Will do. For curiosity's sake, which compilers do complain? Ralf From owner-linux-mips@oss.sgi.com Wed Nov 28 21:14:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAT5Ef521184 for linux-mips-outgoing; Wed, 28 Nov 2001 21:14:41 -0800 Received: from MVista.COM (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAT5EZo21177; Wed, 28 Nov 2001 21:14:35 -0800 Received: (from pmundt@localhost) by MVista.COM (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id fAT4EXx30656; Wed, 28 Nov 2001 20:14:33 -0800 Date: Wed, 28 Nov 2001 20:14:33 -0800 From: Paul Mundt To: Ralf Baechle Cc: James Simmons , linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011128201433.A30490@mvista.com> References: <20011128091655.A20264@lucon.org> <20011129145513.D638@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20011129145513.D638@dea.linux-mips.net>; from ralf@oss.sgi.com on Thu, Nov 29, 2001 at 02:55:13PM +1100 Organization: MontaVista Software, Inc. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 29, 2001 at 02:55:13PM +1100, Ralf Baechle wrote: > > Ralph please apply this patch to arch/mips/kernel/setup.c. Some compile= rs > > don't like the conflict of definition in io.h and setup.c. Thanks. >=20 > Will do. For curiosity's sake, which compilers do complain? >=20 GCC 3.0.2 was the one that complained for me.. 2.95.3 had no problems. Regards, --=20 Paul Mundt MontaVista Software, Inc. --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjwFtigACgkQYLvqhoOEA4GoRQCgh3ds8mcxe+wG43T6z9Ui+MEt 7EQAn1fpjX2JffN6a0CA6HIz17fHLu2q =UzNu -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-linux-mips@oss.sgi.com Wed Nov 28 23:14:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAT7EKc24831 for linux-mips-outgoing; Wed, 28 Nov 2001 23:14:20 -0800 Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAT7EHo24827 for ; Wed, 28 Nov 2001 23:14:17 -0800 Received: from burleighw98 (burleigh-w98.oz.agile.tv [192.168.16.130]) by surfers.oz.agile.tv (8.11.2/8.11.2) with SMTP id fAT6EAv24772 for ; Thu, 29 Nov 2001 16:14:10 +1000 Message-ID: <01f201c1789d$0f872c00$8061a8c0@oz.agile.tv> From: "Jim Grohn" To: Subject: crash from unalgined bad address passed to a syscall Date: Thu, 29 Nov 2001 16:14:10 +1000 Organization: AgileTV MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I get a crash when I run the latest LTP. The test passes 0x1 to getpeername for namelen (socklen_t*) I think the problem may be in emulate_load_store_insn. Should the code below be passing "pc" to search_exception_table and fixup_exception? regs->cp0_epc has been adjusted by compute_return_epc (called from do_ade) to be 4 bytes past the instruction that caused the problems. ************************* fault: /* Did we have an exception handler installed? */ fixup = search_exception_table(regs->cp0_epc); if (fixup) { long new_epc; new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); printk(KERN_DEBUG "%s: Forwarding exception at [<%lx>] (%lx)\n", current->comm, regs->cp0_epc, new_epc); regs->cp0_epc = new_epc; return; } From owner-linux-mips@oss.sgi.com Thu Nov 29 01:00:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAT90uw05520 for linux-mips-outgoing; Thu, 29 Nov 2001 01:00:56 -0800 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAT902o05429 for ; Thu, 29 Nov 2001 01:00:02 -0800 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 9C50B125C8; Wed, 28 Nov 2001 23:22:10 -0800 (PST) Received: by lucon.org (Postfix, from userid 1000) id 5BEFEEBC9; Wed, 28 Nov 2001 23:22:00 -0800 (PST) Date: Wed, 28 Nov 2001 23:22:00 -0800 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.11.92.0.12.3 is released. Message-ID: <20011128232159.A2351@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The only change from 2.11.92.0.12 is http://sources.redhat.com/ml/binutils/2001-11/msg00691.html H.J. ---- This is the beta release of binutils 2.11.92.0.12.3 for Linux, which is based on binutils 2001 1121 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.92.0.12.3 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.92.0.12.3: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.12: 1. Update from binutils 2001 1121. 2. Fix a linker symbol version bug for common symbols. 3. Update handling relocations against the discarded sections. You may need to apply the kernel patch enclosed here to your kernel source. 4. Support "-march=xxx -mipsN" for mips gas if they are compatible. Changes from binutils 2.11.92.0.7: 1. Update from binutils 2001 1021. 2. Fix the ELF/PPC linker. 3. Fix the ELF/cris linker. 4. Fix ELF strip. Changes from binutils 2.11.92.0.5: 1. Update from binutils 2001 1016. 2. Fix all breakages introduced in 2.11.92.0.12. Changes from binutils 2.11.90.0.31: 1. Update from binutils 2001 1005. 2. Support gcc 3.1 for ia64. 3. Support prelink for ELF/PPC. 4. Fix an ELF/x86 linker bug for Oracle. 5. Fix a weak symbol bug. 6. Support locale. Changes from binutils 2.11.90.0.29: 1. Update from binutils 2001 0830. 2. Fix a mips linker bug. Changes from binutils 2.11.90.0.27: 1. Update from binutils 2001 0827. 2. Fix an alpha assembler bug. 3. Fix an ia64 linker bug. 4. Fix a mips linker bug. 5. Support `-z combreloc|nocombreloc' in linker. Changes from binutils 2.11.90.0.25: 1. Update from binutils 2001 0810. 2. Fix an x86 linker bug. Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.92.0.12.3.tar.gz. Source code. 2. binutils-2.11.92.0.12-2.11.92.0.12.3.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.92.0.12.3-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.92.0.12.3.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 11/26/2001 --- --- linux/arch/alpha/vmlinux.lds.in.discard Thu Nov 22 00:30:16 2001 +++ linux/arch/alpha/vmlinux.lds.in Thu Nov 22 00:30:47 2001 @@ -92,5 +92,5 @@ SECTIONS .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } - /DISCARD/ : { *(.text.exit) *(.data.exit) } + /DISCARD/ : { *(.text.exit) *(.data.exit) *(.exitcall.exit) } } --- linux/drivers/char/serial.c.discard Thu Nov 22 00:37:14 2001 +++ linux/drivers/char/serial.c Thu Nov 22 10:54:54 2001 @@ -4887,7 +4887,9 @@ static char serial_pci_driver_name[] = " static struct pci_driver serial_pci_driver = { name: serial_pci_driver_name, probe: serial_init_one, +#ifdef MODULE remove: serial_remove_one, +#endif id_table: serial_pci_tbl, }; From owner-linux-mips@oss.sgi.com Thu Nov 29 07:08:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATF8hh16709 for linux-mips-outgoing; Thu, 29 Nov 2001 07:08:43 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fATF8eo16705 for ; Thu, 29 Nov 2001 07:08:41 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fATE8Gg07739; Fri, 30 Nov 2001 01:08:16 +1100 Date: Fri, 30 Nov 2001 01:08:16 +1100 From: Ralf Baechle To: Daniel Jacobowitz Cc: "TWEDE,ROGER (HP-Boise,ex1)" , Linux/MIPS Development Subject: Re: RedHat 7.1 cross toolchain kernel build problem Message-ID: <20011130010816.E638@dea.linux-mips.net> References: <20011128132117.A27181@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011128132117.A27181@nevyn.them.org>; from dan@debian.org on Wed, Nov 28, 2001 at 01:21:17PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 01:21:17PM -0500, Daniel Jacobowitz wrote: > If you search the list archives, I've posted patches for this several > times. It's a compiler bug but can be worked around in io.h. $5($3) > is not a legal addressing mode. The current kernel source has replaced the inline assembler functions in include/asm-mips/io.h thus this is no longer necessary. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 29 07:19:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATFJGD17297 for linux-mips-outgoing; Thu, 29 Nov 2001 07:19:16 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fATFJCo17294 for ; Thu, 29 Nov 2001 07:19:13 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fATEIva07904; Fri, 30 Nov 2001 01:18:57 +1100 Date: Fri, 30 Nov 2001 01:18:57 +1100 From: Ralf Baechle To: Paul Mundt Cc: James Simmons , linux-mips@oss.sgi.com Subject: Re: [PATCH] const mips_io_port_base !? Message-ID: <20011130011856.C7642@dea.linux-mips.net> References: <20011128091655.A20264@lucon.org> <20011129145513.D638@dea.linux-mips.net> <20011128201433.A30490@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011128201433.A30490@mvista.com>; from pmundt@MVista.COM on Wed, Nov 28, 2001 at 08:14:33PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 08:14:33PM -0800, Paul Mundt wrote: > > > Ralph please apply this patch to arch/mips/kernel/setup.c. Some compilers > > > don't like the conflict of definition in io.h and setup.c. Thanks. > > > > Will do. For curiosity's sake, which compilers do complain? > > > GCC 3.0.2 was the one that complained for me.. 2.95.3 had no problems. Thanks, fix is now in cvs. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 29 08:02:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATG2nM18697 for linux-mips-outgoing; Thu, 29 Nov 2001 08:02:49 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fATG2jo18693 for ; Thu, 29 Nov 2001 08:02:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fATF2eL08386; Fri, 30 Nov 2001 02:02:40 +1100 Date: Fri, 30 Nov 2001 02:02:40 +1100 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: calibrating MIPS counter frequency Message-ID: <20011130020240.F638@dea.linux-mips.net> References: <3C05646B.51BF79FB@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C05646B.51BF79FB@mvista.com>; from jsun@mvista.com on Wed, Nov 28, 2001 at 02:25:47PM -0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, Nov 28, 2001 at 02:25:47PM -0800, Jun Sun wrote: > In the future, I think mips counter frequency really should go to mips_cpu > structure. If we always know the counter frequency, either by board setup > routine or runtime calibration, we can get rid of the gettimeoffset > calibration routines. Better stick with the calibration procedure. The crystal oscilators used in most computer systems don't provide the high accuracy of frequency that is required to keep the clock accurately over long time. An RTC chip which you'd probably use as reference clock is better at that so should be used as the ultimate reference time in the kernel. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 29 08:22:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATGMWb19698 for linux-mips-outgoing; Thu, 29 Nov 2001 08:22:32 -0800 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fATGMDo19685; Thu, 29 Nov 2001 08:22:15 -0800 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA20140; Thu, 29 Nov 2001 16:21:46 +0100 (MET) Date: Thu, 29 Nov 2001 16:21:46 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: calibrating MIPS counter frequency In-Reply-To: <20011130020240.F638@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 30 Nov 2001, Ralf Baechle wrote: > Better stick with the calibration procedure. The crystal oscilators used > in most computer systems don't provide the high accuracy of frequency > that is required to keep the clock accurately over long time. An RTC > chip which you'd probably use as reference clock is better at that so > should be used as the ultimate reference time in the kernel. On the contrary, the DECstation's undocumented I/O ASIC FCR (free running counter) driven by the TURBOchannel bus clock is said to be much more accurate than the DS1287 used there. And it's David L. Mills who says so, thus we may safely assume it's true. :-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Nov 29 08:26:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATGQpp19854 for linux-mips-outgoing; Thu, 29 Nov 2001 08:26:51 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fATGQko19845; Thu, 29 Nov 2001 08:26:46 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 169TCZ-0000Lk-00; Thu, 29 Nov 2001 15:34:15 +0000 Subject: Re: calibrating MIPS counter frequency To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Thu, 29 Nov 2001 15:34:15 +0000 (GMT) Cc: ralf@oss.sgi.com (Ralf Baechle), jsun@mvista.com (Jun Sun), linux-mips@oss.sgi.com In-Reply-To: from "Maciej W. Rozycki" at Nov 29, 2001 04:21:46 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > On the contrary, the DECstation's undocumented I/O ASIC FCR (free running > counter) driven by the TURBOchannel bus clock is said to be much more > accurate than the DS1287 used there. And it's David L. Mills who says so, > thus we may safely assume it's true. :-) The old DEC hardware guaranteed good time quality. But thats rather unusual beyond DEC. From owner-linux-mips@oss.sgi.com Thu Nov 29 10:22:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATIMpq22724 for linux-mips-outgoing; Thu, 29 Nov 2001 10:22:51 -0800 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fATIMmo22721 for ; Thu, 29 Nov 2001 10:22:48 -0800 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 11:22:29 -0600 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA1B7476@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: Memory usage profiling Date: Thu, 29 Nov 2001 11:21:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I"ve been given the "honor" of pofiling our current linux-based system for memory usage. I have a single process of primary concern which has a number of pthreads running. I need to profile the memory usage of the pthreads. What's the best (and/or quickest) way to do that? Keith Siders Software Engineer Toshiba America Consumer Products, Inc. Advanced Television Technology Center 801 Royal Parkway, Suite 100 Nashville, Tennessee 37214 Phone: (615) 257-4050 Fax: (615) 453-7880 From owner-linux-mips@oss.sgi.com Thu Nov 29 11:23:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATJN9r24096 for linux-mips-outgoing; Thu, 29 Nov 2001 11:23:09 -0800 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fATJN3o24092; Thu, 29 Nov 2001 11:23:03 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA01414; Thu, 29 Nov 2001 10:23:02 -0800 (PST) mail_from (jsun@mvista.com) 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 fATIIcB00594; Thu, 29 Nov 2001 10:18:38 -0800 Message-ID: <3C067BD4.6B132389@mvista.com> Date: Thu, 29 Nov 2001 10:17:56 -0800 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: calibrating MIPS counter frequency References: <3C05646B.51BF79FB@mvista.com> <20011130020240.F638@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > > On Wed, Nov 28, 2001 at 02:25:47PM -0800, Jun Sun wrote: > > > In the future, I think mips counter frequency really should go to mips_cpu > > structure. If we always know the counter frequency, either by board setup > > routine or runtime calibration, we can get rid of the gettimeoffset > > calibration routines. > > Better stick with the calibration procedure. The crystal oscilators used > in most computer systems don't provide the high accuracy of frequency > that is required to keep the clock accurately over long time. The drifting clock effect won't happen here because the base value (timerlo)is reset at each jiffies change. So it is as accurate as your system timer, plus minor skew within a jiffy period. The existing calibration routines actually use the same oscilator and a similar algorithm, except calibration is done in an "amortized" fashion. It will suffer the same within-jiffy skew caused by irregular osilator. The existing code calibrates over a longer time. So potentially it can be more accurate. On the other hand, the calibration routine takes a longer time, which affects the accuracy the other way. My current patch uses 20 jiffy cycles as the calibration period. On ddb5476 board, the result is off by 1/100,000, which should well preserve the 1us resolution. It would be interesting to see the actual result from existing calibrations. In any case, the skews are probably so small that it won't be an issue here. Jun From owner-linux-mips@oss.sgi.com Thu Nov 29 13:26:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fATLQN528782 for linux-mips-outgoing; Thu, 29 Nov 2001 13:26:23 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fATLQJo28779 for ; Thu, 29 Nov 2001 13:26:19 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fATKQsB08529; Thu, 29 Nov 2001 12:26:54 -0800 Subject: pcmcia From: Pete Popov To: linux-mips , sforge Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.14.08.58 (Preview Release) Date: 29 Nov 2001 12:32:01 -0800 Message-Id: <1007065921.13095.110.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The pcmcia variable ioaddr_t should be a 32 bit type for my socket driver. Is there any harm to other mips pcmcia socket drivers if we apply the patch below? If not, it would make it so much easier if I don't have to debug this problem with each new kernel (having forgotten about the need for this patch)... --- linux-orig/include/pcmcia/cs_types.h Mon Nov 5 16:55:31 2001 +++ linux/include/pcmcia/cs_types.h Thu Nov 29 12:27:42 2001 @@ -36,7 +36,7 @@ #include #endif -#ifdef __arm__ +#if defined(__arm__) || defined(__mips__) typedef u_int ioaddr_t; #else typedef u_short ioaddr_t; From owner-linux-mips@oss.sgi.com Thu Nov 29 17:57:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAU1vUM20567 for linux-mips-outgoing; Thu, 29 Nov 2001 17:57:30 -0800 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAU1vRo20562 for ; Thu, 29 Nov 2001 17:57:27 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fATFx2M09359; Fri, 30 Nov 2001 02:59:02 +1100 Date: Fri, 30 Nov 2001 02:59:02 +1100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: calibrating MIPS counter frequency Message-ID: <20011130025902.A8456@dea.linux-mips.net> References: <20011130020240.F638@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Nov 29, 2001 at 04:21:46PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Nov 29, 2001 at 04:21:46PM +0100, Maciej W. Rozycki wrote: > > Better stick with the calibration procedure. The crystal oscilators used > > in most computer systems don't provide the high accuracy of frequency > > that is required to keep the clock accurately over long time. An RTC > > chip which you'd probably use as reference clock is better at that so > > should be used as the ultimate reference time in the kernel. > > On the contrary, the DECstation's undocumented I/O ASIC FCR (free running > counter) driven by the TURBOchannel bus clock is said to be much more > accurate than the DS1287 used there. And it's David L. Mills who says so, > thus we may safely assume it's true. :-) Whooa, Master Secundus Minutius Hora himself ;-) Actually the accuracy of crystal oscillators may differ wildly depending on the use in a system and environmental conditions. In case of the SGI Indy the DS1387 RTC (which is rated at +/- 25ppm ~= 1 minute / month) is actually more accurate. Ralf From owner-linux-mips@oss.sgi.com Thu Nov 29 18:38:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAU2cWR21660 for linux-mips-outgoing; Thu, 29 Nov 2001 18:38:32 -0800 Received: from deneb.localdomain (ga-cmng-u1-c3b-97.cmngga.adelphia.net [24.53.98.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAU2cQo21657 for ; Thu, 29 Nov 2001 18:38:26 -0800 Received: (from msalter@localhost) by deneb.localdomain (8.11.6/8.11.6) id fAU1cOA31059; Thu, 29 Nov 2001 20:38:24 -0500 Date: Thu, 29 Nov 2001 20:38:24 -0500 Message-Id: <200111300138.fAU1cOA31059@deneb.localdomain> X-Authentication-Warning: deneb.localdomain: msalter set sender to msalter@redhat.com using -f From: Mark Salter To: linux-mips@oss.sgi.com Subject: math emulator patch Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The following patch fixes the emulation of cvt.w.s and cvt.w.d for values of -2147483648. --Mark Index: sp_tint.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/sp_tint.c,v retrieving revision 1.4 diff -u -p -5 -c -r1.4 sp_tint.c cvs server: conflicting specifications of output style *** sp_tint.c 2001/10/09 23:56:19 1.4 --- sp_tint.c 2001/11/29 19:14:58 *************** int ieee754sp_tint(ieee754sp x) *** 48,57 **** --- 48,60 ---- case IEEE754_CLASS_DNORM: case IEEE754_CLASS_NORM: break; } if (xe >= 31) { + /* look for valid corner case */ + if (xe == 31 && xs && xm == SP_HIDDEN_BIT) + return -2147483648; /* Set invalid. We will only use overflow for floating point overflow */ SETCX(IEEE754_INVALID_OPERATION); return ieee754si_xcpt(ieee754si_indef(), "sp_tint", x); } Index: dp_tint.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/dp_tint.c,v retrieving revision 1.4 diff -u -p -5 -c -r1.4 dp_tint.c cvs server: conflicting specifications of output style *** dp_tint.c 2001/10/09 23:56:18 1.4 --- dp_tint.c 2001/11/29 19:18:02 *************** int ieee754dp_tint(ieee754dp x) *** 48,57 **** --- 48,60 ---- case IEEE754_CLASS_DNORM: case IEEE754_CLASS_NORM: break; } if (xe >= 31) { + /* look for valid corner case */ + if (xe == 31 && xs && xm == DP_HIDDEN_BIT) + return -2147483648; /* Set invalid. We will only use overflow for floating point overflow */ SETCX(IEEE754_INVALID_OPERATION); return ieee754si_xcpt(ieee754si_indef(), "dp_tint", x); } From owner-linux-mips@oss.sgi.com Fri Nov 30 01:14:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAU9EOd31817 for linux-mips-outgoing; Fri, 30 Nov 2001 01:14:24 -0800 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAU9ELo31811 for ; Fri, 30 Nov 2001 01:14:22 -0800 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id fAU8EIj14332 for ; Fri, 30 Nov 2001 09:14:19 +0100 (MET) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X580R8F0; Fri, 30 Nov 2001 09:14:18 +0100 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Fri, 30 Nov 2001 09:14:17 +0100 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 09:13:42 +0100 Message-ID: <86048F07C015D311864100902760F1DD01B5E463@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: Bug in Dwarf support? Date: Fri, 30 Nov 2001 09:13:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi. When I compile kernel 2.4.3 with dwarf debug support (using H.J.Lu's gcc 2.96 binaries) I get no path information for source files. I did a hexdump of .debug_sfnames with readelf and the path is there but separated from the filename by a 0x00. For include files the path is ok. (i.e. the 0x00 is missing) Is this a bug or standard? I believe this prevents my debugger from recognizing the source tree structure. best regards Andre Messerschmidt From owner-linux-mips@oss.sgi.com Fri Nov 30 01:39:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAU9dhK32676 for linux-mips-outgoing; Fri, 30 Nov 2001 01:39:43 -0800 Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAU9deo32673 for ; Fri, 30 Nov 2001 01:39:40 -0800 Received: from 63.70.210.4 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Fri, 30 Nov 2001 00:39:24 -0800 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from nt-sjcb-0501.sv.broadcom.com (mail.sv.broadcom.com [10.19.192.19]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id AAA19508; Fri, 30 Nov 2001 00:39:36 -0800 (PST) Received: by mail.sv.broadcom.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Nov 2001 00:39:36 -0800 Message-ID: From: "Guillermo A. Loyola" To: "'Pete Popov'" , linux-mips , sforge Subject: RE: pcmcia Date: Fri, 30 Nov 2001 00:39:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 10199A36172370-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > The pcmcia variable ioaddr_t should be a 32 bit type for my socket > driver. Is there any harm to other mips pcmcia socket drivers if we > apply the patch below? We need the same here, how about doing this instead: #ifdef __i386__ typedef u_short ioaddr_t; #else typedef u_int ioaddr_t; #endif Gmo. From owner-linux-mips@oss.sgi.com Fri Nov 30 02:49:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAUAno403016 for linux-mips-outgoing; Fri, 30 Nov 2001 02:49:50 -0800 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAUAnjo03011 for ; Fri, 30 Nov 2001 02:49:45 -0800 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id CDA802B2F9; Fri, 30 Nov 2001 09:49:37 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 52E88E7C4; Fri, 30 Nov 2001 09:49:44 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 3AB907243; Fri, 30 Nov 2001 09:49:44 +0000 (GMT) Date: Fri, 30 Nov 2001 09:49:44 +0000 (GMT) From: Dave Airlie X-X-Sender: To: Cc: Subject: Re: Bug in Dwarf support? In-Reply-To: <86048F07C015D311864100902760F1DD01B5E463@dlfw003a.dus.infineon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I had this with a debugger I was beta testing... there is a compile path stored separate to the path of the file, it needs to use the compile path, so it is a bug in the debugger not using the full standard.. you can the info out with gdb (I can't remember the exact incantation...) Dave. On Fri, 30 Nov 2001 Andre.Messerschmidt@infineon.com wrote: > Hi. > > When I compile kernel 2.4.3 with dwarf debug support (using H.J.Lu's gcc > 2.96 binaries) I get no path information for source files. > I did a hexdump of .debug_sfnames with readelf and the path is there but > separated from the filename by a 0x00. For include files the path is ok. > (i.e. the 0x00 is missing) > > Is this a bug or standard? I believe this prevents my debugger from > recognizing the source tree structure. > > best regards > Andre Messerschmidt > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Fri Nov 30 09:03:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAUH3LE22124 for linux-mips-outgoing; Fri, 30 Nov 2001 09:03:21 -0800 Received: from paris58.amenworld.com (paris58.amenworld.com [217.174.192.106]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAUH3Jo22116; Fri, 30 Nov 2001 09:03:19 -0800 Received: (from mail@localhost) by paris58.amenworld.com (8.10.2/8.10.2) id fAUDtH519593 for listecrazyweb_site19-list; Fri, 30 Nov 2001 14:55:17 +0100 Received: from envoi.digroup.org ([212.155.76.254]) by paris58.amenworld.com (8.10.2/8.10.2) with ESMTP id fAUDtGr19589 for ; Fri, 30 Nov 2001 14:55:16 +0100 Received: from fr-paris-di01.int.digroup.org ([172.27.130.11]) by envoi.digroup.org (Lotus Domino Release 5.0.7) with ESMTP id 2001113014571409:148726 ; Fri, 30 Nov 2001 14:57:14 +0100 Subject: To: listecrazyweb@www.crazyweb.fr X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: cduffaud@latribune.fr Date: Fri, 30 Nov 2001 14:57:54 +0100 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on FR-PARIS-DI01/SRV/D-I(Release 5.0.4a |July 24, 2000) at 30/11/2001 14:57:57, Itemize by SMTP Server on envoi/ENVOI/FR(Release 5.0.7 |March 21, 2001) at 30/11/2001 14:57:14, Serialize by Router on envoi/ENVOI/FR(Release 5.0.7 |March 21, 2001) at 30/11/2001 14:57:20 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From owner-linux-mips@oss.sgi.com Fri Nov 30 10:35:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAUIZ1P26572 for linux-mips-outgoing; Fri, 30 Nov 2001 10:35:01 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAUIYxo26569 for ; Fri, 30 Nov 2001 10:34:59 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fAUHZWB01545; Fri, 30 Nov 2001 09:35:32 -0800 Subject: RE: pcmcia From: Pete Popov To: "Guillermo A. Loyola" Cc: linux-mips , sforge In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.14.08.58 (Preview Release) Date: 30 Nov 2001 09:35:01 -0800 Message-Id: <1007141701.22949.140.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 495 Lines: 18 On Fri, 2001-11-30 at 00:39, Guillermo A. Loyola wrote: > > The pcmcia variable ioaddr_t should be a 32 bit type for my socket > > driver. Is there any harm to other mips pcmcia socket drivers if we > > apply the patch below? > > We need the same here, how about doing this instead: > > #ifdef __i386__ > typedef u_short ioaddr_t; > #else > typedef u_int ioaddr_t; > #endif That probably makes more sense. I wasn't sure if it's only x86 that needs? ioaddr_t to be a 16 bit type. Pete From owner-linux-mips@oss.sgi.com Fri Nov 30 10:45:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAUIjZL26867 for linux-mips-outgoing; Fri, 30 Nov 2001 10:45:35 -0800 Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAUIjVo26862 for ; Fri, 30 Nov 2001 10:45:32 -0800 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 169rrU-0004GN-00; Fri, 30 Nov 2001 17:54:08 +0000 Subject: Re: pcmcia To: ppopov@mvista.com (Pete Popov) Date: Fri, 30 Nov 2001 17:54:08 +0000 (GMT) Cc: gmo@broadcom.com (Guillermo A. Loyola), linux-mips@oss.sgi.com (linux-mips), linux-mips-kernel@lists.sourceforge.net (sforge) In-Reply-To: <1007141701.22949.140.camel@zeus> from "Pete Popov" at Nov 30, 2001 09:35:01 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 421 Lines: 16 > > We need the same here, how about doing this instead: > > > > #ifdef __i386__ > > typedef u_short ioaddr_t; > > #else > > typedef u_int ioaddr_t; > > #endif > > That probably makes more sense. I wasn't sure if it's only x86 that > needs? ioaddr_t to be a 16 bit type. Is there any platform where making it int actually -breaks-. At least for 2.5 it would seem a lot saner to just make it bigger and see Alan From owner-linux-mips@oss.sgi.com Fri Nov 30 10:51:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fAUIp5u27103 for linux-mips-outgoing; Fri, 30 Nov 2001 10:51:05 -0800 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fAUIoxo27100 for ; Fri, 30 Nov 2001 10:50:59 -0800 Received: from zeus.mvista.com (zeus.mvista.com [10.0.0.112]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id fAUHpMB02497; Fri, 30 Nov 2001 09:51:22 -0800 Subject: Re: pcmcia From: Pete Popov To: Alan Cox Cc: "Guillermo A. Loyola" , linux-mips , sforge In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.14.08.58 (Preview Release) Date: 30 Nov 2001 09:50:51 -0800 Message-Id: <1007142651.6016.148.camel@zeus> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 690 Lines: 23 On Fri, 2001-11-30 at 09:54, Alan Cox wrote: > > > We need the same here, how about doing this instead: > > > > > > #ifdef __i386__ > > > typedef u_short ioaddr_t; > > > #else > > > typedef u_int ioaddr_t; > > > #endif > > > > That probably makes more sense. I wasn't sure if it's only x86 that > > needs? ioaddr_t to be a 16 bit type. > > Is there any platform where making it int actually -breaks-. I can't see how it would break anything ... but I've said that before. It's not a variable which maps a hardware register, a protocol field, etc, so it should be safe to just make it an int. > At least for 2.5 it would seem a lot saner to just make it bigger and see Pete From owner-linux-mips@oss.sgi.com Fri Nov 30 16:37:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fB10b8l14301 for linux-mips-outgoing; Fri, 30 Nov 2001 16:37:08 -0800 Received: from coplin19.mips.com ([62.243.233.130]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fB10b0o14298 for ; Fri, 30 Nov 2001 16:37:00 -0800 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id fAUNai029302; Sat, 1 Dec 2001 00:36:44 +0100 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Sat, 1 Dec 2001 00:36:44 +0100 (CET) From: Kjeld Borch Egevang To: Mark Salter cc: Subject: Re: math emulator patch In-Reply-To: <200111300138.fAU1cOA31059@deneb.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2217 Lines: 70 Great. The same problem exists for sp_tlong.c and dp_tlong.c. /Kjeld On Thu, 29 Nov 2001, Mark Salter wrote: > > The following patch fixes the emulation of cvt.w.s and cvt.w.d for > values of -2147483648. > > --Mark > > > Index: sp_tint.c > =================================================================== > RCS file: /cvs/linux/arch/mips/math-emu/sp_tint.c,v > retrieving revision 1.4 > diff -u -p -5 -c -r1.4 sp_tint.c > cvs server: conflicting specifications of output style > *** sp_tint.c 2001/10/09 23:56:19 1.4 > --- sp_tint.c 2001/11/29 19:14:58 > *************** int ieee754sp_tint(ieee754sp x) > *** 48,57 **** > --- 48,60 ---- > case IEEE754_CLASS_DNORM: > case IEEE754_CLASS_NORM: > break; > } > if (xe >= 31) { > + /* look for valid corner case */ > + if (xe == 31 && xs && xm == SP_HIDDEN_BIT) > + return -2147483648; > /* Set invalid. We will only use overflow for floating > point overflow */ > SETCX(IEEE754_INVALID_OPERATION); > return ieee754si_xcpt(ieee754si_indef(), "sp_tint", x); > } > Index: dp_tint.c > =================================================================== > RCS file: /cvs/linux/arch/mips/math-emu/dp_tint.c,v > retrieving revision 1.4 > diff -u -p -5 -c -r1.4 dp_tint.c > cvs server: conflicting specifications of output style > *** dp_tint.c 2001/10/09 23:56:18 1.4 > --- dp_tint.c 2001/11/29 19:18:02 > *************** int ieee754dp_tint(ieee754dp x) > *** 48,57 **** > --- 48,60 ---- > case IEEE754_CLASS_DNORM: > case IEEE754_CLASS_NORM: > break; > } > if (xe >= 31) { > + /* look for valid corner case */ > + if (xe == 31 && xs && xm == DP_HIDDEN_BIT) > + return -2147483648; > /* Set invalid. We will only use overflow for floating > point overflow */ > SETCX(IEEE754_INVALID_OPERATION); > return ieee754si_xcpt(ieee754si_indef(), "dp_tint", x); > } > -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From owner-linux-mips@oss.sgi.com Fri Nov 30 22:49:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id fB16nGR20747 for linux-mips-outgoing; Fri, 30 Nov 2001 22:49:16 -0800 Received: from ns1.local (vsat-148-63-243-254.c3.sb4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id fB16mbo20743; Fri, 30 Nov 2001 22:48:40 -0800 Received: from dev1 (unknown [10.1.1.85]) by ns1.local (Postfix) with ESMTP id 86815590A9; Sat, 1 Dec 2001 00:46:41 -0500 (EST) Received: from brad by dev1 with local (Exim 3.32 #1 (Debian)) id 16A2xr-0005mu-00; Sat, 01 Dec 2001 00:45:28 -0500 Date: Sat, 1 Dec 2001 00:45:27 -0500 To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: PATCH: spurious_count cleanup Message-ID: <20011201004526.A22248@dev1.ltc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.20i From: "Bradley D. LaRonde" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8807 Lines: 292 2001-11-30 Bradley D. LaRonde arch/mips/kernel/irq.c prints irq_err_count, but spurious_interupt incremented spurious_count, not irq_err_count. irq_err_count is used for counting spurious interrupts on other platforms. * increment irq_err_count instead of spurious_count in spurious_interrupt * eliminate spurious_count variable * use common spurious intterrupt handler in au1000 --- arch/mips/au1000/common/int-handler.S 2001/05/18 22:13:23 1.2 +++ arch/mips/au1000/common/int-handler.S 2001/11/30 18:42:05 @@ -65,7 +65,5 @@ 5: move a0, sp - jal mips_spurious_interrupt -done: - j ret_from_irq + j spurious_interrupt END(au1000_IRQ) --- arch/mips/au1000/common/irq.c 2001/10/31 12:47:14 1.8 +++ arch/mips/au1000/common/irq.c 2001/11/30 18:42:05 @@ -84,7 +84,7 @@ inline void local_enable_irq(unsigned int irq_nr); inline void local_disable_irq(unsigned int irq_nr); -unsigned long spurious_interrupts; +volatile unsigned long irq_err_count; extern unsigned int do_IRQ(int irq, struct pt_regs *regs); extern void __init init_generic_irq(void); @@ -455,12 +455,6 @@ set_debug_traps(); breakpoint(); #endif -} - - -void mips_spurious_interrupt(struct pt_regs *regs) -{ - spurious_interrupts++; } --- arch/mips/baget/irq.c 2001/03/12 02:46:14 1.12 +++ arch/mips/baget/irq.c 2001/11/30 18:42:05 @@ -27,7 +27,7 @@ #include -unsigned long spurious_count = 0; +volatile unsigned long irq_err_count; /* * This table is a correspondence between IRQ numbers and CPU PILs --- arch/mips/dec/irq.c 2001/09/27 23:45:52 1.16 +++ arch/mips/dec/irq.c 2001/11/30 18:42:05 @@ -34,7 +34,7 @@ extern asmlinkage void decstation_handle_int(void); -unsigned long spurious_count = 0; +volatile unsigned long irq_err_count; static inline void mask_irq(unsigned int irq_nr) { --- arch/mips/galileo-boards/ev64120/irq.c 2001/11/05 20:15:26 1.6 +++ arch/mips/galileo-boards/ev64120/irq.c 2001/11/30 18:42:05 @@ -189,7 +189,7 @@ */ irq_desc_t irq_desc[NR_IRQS]; -unsigned long spurious_count = 0; +volatile unsigned long irq_err_count; int get_irq_list(char *buf) { @@ -219,7 +219,7 @@ } len += sprintf(buf + len, "\n"); } - len += sprintf(buf + len, "BAD: %10lu\n", spurious_count); + len += sprintf(buf + len, "BAD: %10lu\n", irq_err_count); return len; } --- arch/mips/galileo-boards/ev96100/irq.c 2001/11/30 13:28:06 1.10 +++ arch/mips/galileo-boards/ev96100/irq.c 2001/11/30 18:42:06 @@ -64,7 +64,7 @@ extern asmlinkage void ev96100IRQ(void); unsigned int local_bh_count[NR_CPUS]; unsigned int local_irq_count[NR_CPUS]; -unsigned long spurious_count = 0; +volatile unsigned long irq_err_count; irq_desc_t irq_desc[NR_IRQS]; irq_desc_t *irq_desc_base=&irq_desc[0]; @@ -153,7 +153,7 @@ } len += sprintf(buf+len, "\n"); } - len += sprintf(buf+len, "BAD: %10lu\n", spurious_count); + len += sprintf(buf+len, "BAD: %10lu\n", irq_err_count); return len; } @@ -210,7 +210,7 @@ } else { - spurious_count++; + irq_err_count++; printk("Unhandled interrupt %x, cause %x, disabled\n", (unsigned)irq, (unsigned)cause); disable_irq(1<