From owner-linux-mips@oss.sgi.com Thu May 2 11:51:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g42IpbwJ013341 for ; Thu, 2 May 2002 11:51:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g42IpaRm013340 for linux-mips-outgoing; Thu, 2 May 2002 11:51:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g42IpTwJ013337 for ; Thu, 2 May 2002 11:51:30 -0700 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 173Lgm-0008Pi-00 for ; Thu, 02 May 2002 13:52:24 -0500 Message-ID: <3CD19872.63FBF81E@cotw.com> Date: Thu, 02 May 2002 14:50:10 -0500 From: Scott A McConnell X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: "MIPS/Linux List (SGI)" Subject: Accounting for all memory. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am trying to understand memory usage on my system. NEC VR5432, mipsel, 2.4.5 kernel Does slab info appear in "used:" column of /proc/meminfo? What the holes "??????" in /proc/iomem are used for? I can not account for all of the "1268k reserved memory. Thanks in advance, Scott ----------------------------------------------------------------------- <4>Memory: 4876k/6144k available (801k kernel code, 1268k reserved, 69k data, 60k init) ... <4>Freeing unused kernel memory: 60k freed ----------------------------------------------------------------------- /proc # cat iomem 00000000-005fffff : System RAM 00000000-00000fff : ??????????? 4096 (added by hand) 00001000-000ca687 : Kernel code 824968 000ca688-000db99f : ??????????? 70424 (added by hand) 000db9a0-000ed033 : Kernel data 71316 ------ 970804 /proc # cat meminfo total: used: free: shared: buffers: cached: Mem: 5046272 1392640 3653632 0 16384 598016 Swap: 0 0 0 MemTotal: 4928 kB MemFree: 3568 kB MemShared: 0 kB Buffers: 16 kB Cached: 584 kB Active: 600 kB Inact_dirty: 0 kB Inact_clean: 0 kB Inact_target: 12 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 4928 kB LowFree: 3568 kB SwapTotal: 0 kB 6291456 (6 MB allocated to kernel in prom.c) - 5046272 (Total memory in use) --------- 1245184 1245184 - 970804(Kernel memory) = 274380 I can not account for this memory. -- Scott A. McConnell From owner-linux-mips@oss.sgi.com Fri May 3 14:46:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43LkOwJ031764 for ; Fri, 3 May 2002 14:46:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43LkOcR031763 for linux-mips-outgoing; Fri, 3 May 2002 14:46:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43LkKwJ031756 for ; Fri, 3 May 2002 14:46:20 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA00949; Fri, 3 May 2002 14:48:00 -0700 Message-ID: <3CD3052B.1050400@mvista.com> Date: Fri, 03 May 2002 14:46:19 -0700 From: Jun Sun 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 Subject: what is the right behavior of copy_to_user(0x0, ..., ...)? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk When running LTP, I notice that recent kernel has a kernel access fault: <1>Unable to handle kernel paging request at virtual address 00000000, epc == 80273860, ra == 80205aa4 Oops in fault.c:do_page_fault, line 204: $0 : 00000000 10001f00 00000002 00000002 00000000 86df5e98 00000001 00000040 $8 : 00000000 00000000 00000001 ffffffff 00000002 802b4864 00000001 00000001 $16: 100003d8 00000000 00000002 86df5e98 00401080 10002df8 00000000 00000097 $24: 0000000a 802e7ab6 86df4000 86df5e60 7fff7c60 80205aa4 Hi : 00000000 Lo : 00000000 epc : 80273860 Not tainted Status: 10001f03 Cause : 9080800c .... Tracing error reveals that user process passed a NULL buffer pointer to sys_getpeername() syscall, probably intentionally. Then it goes all the way down to copy_to_user(0x0, ..., ...) and caused a oops as above. As a result of oops the user process is killed. However I am not sure if this is the right way to respond to an ill argument. copy_to_user() probably should catch this case and return some meaningful error back to the caller. I am not sure what is the best way to achieve this. Any thoughts? Jun From owner-linux-mips@oss.sgi.com Fri May 3 16:22:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43NMXwJ032754 for ; Fri, 3 May 2002 16:22:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43NMXjV032753 for linux-mips-outgoing; Fri, 3 May 2002 16:22:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43NMVwJ032750 for ; Fri, 3 May 2002 16:22:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g43NNbJ27414; Fri, 3 May 2002 16:23:37 -0700 Date: Fri, 3 May 2002 16:23:37 -0700 From: Ralf Baechle To: Jun Sun Cc: linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? Message-ID: <20020503162337.A27366@dea.linux-mips.net> References: <3CD3052B.1050400@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD3052B.1050400@mvista.com>; from jsun@mvista.com on Fri, May 03, 2002 at 02:46:19PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 03, 2002 at 02:46:19PM -0700, Jun Sun wrote: > When running LTP, I notice that recent kernel has a kernel access fault: > > <1>Unable to handle kernel paging request at virtual address 00000000, epc > == 80273860, ra == 80205aa4 Well, decode the oops message. The question is what is at 0x80273860? Ralf From owner-linux-mips@oss.sgi.com Fri May 3 16:42:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g43Ng4wJ000509 for ; Fri, 3 May 2002 16:42:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g43Ng4Zm000508 for linux-mips-outgoing; Fri, 3 May 2002 16:42:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g43NfvwJ000503; Fri, 3 May 2002 16:41:57 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA04226; Fri, 3 May 2002 16:43:37 -0700 Message-ID: <3CD32044.9040109@mvista.com> Date: Fri, 03 May 2002 16:41:56 -0700 From: Jun Sun 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: Ralf Baechle CC: linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Fri, May 03, 2002 at 02:46:19PM -0700, Jun Sun wrote: > > >>When running LTP, I notice that recent kernel has a kernel access fault: >> >><1>Unable to handle kernel paging request at virtual address 00000000, epc >>== 80273860, ra == 80205aa4 >> > > Well, decode the oops message. The question is what is at 0x80273860? > 0x80273860 is copy_bytes in arch/mips/lib/memcpy.S, which is reached through __copy_user. The faulting instruction, not suprisingly, is writing a byte to the destination at 0x0. Anybody can try to call copy_to_user(0x0, ...) inside kernel and see the scene. The question here is whether we should reach do_page_fault() and terminate calling process or try to catch the fault and return some meaningful error. It appears earlier version of kernel does not have this problem. I have not fully figured out why. Jun From owner-linux-mips@oss.sgi.com Fri May 3 18:39:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g441d3wJ001360 for ; Fri, 3 May 2002 18:39:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g441d39u001359 for linux-mips-outgoing; Fri, 3 May 2002 18:39:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g441cswJ001356 for ; Fri, 3 May 2002 18:38:54 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g441e0p01320; Fri, 3 May 2002 18:40:00 -0700 Date: Fri, 3 May 2002 18:40:00 -0700 From: Ralf Baechle To: Jun Sun Cc: linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? Message-ID: <20020503184000.A1238@dea.linux-mips.net> References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD32044.9040109@mvista.com>; from jsun@mvista.com on Fri, May 03, 2002 at 04:41:56PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, May 03, 2002 at 04:41:56PM -0700, Jun Sun wrote: > It appears earlier version of kernel does not have this problem. I have not > fully figured out why. We didn't handle exceptions in branch delay slots. Try this patch and tell me if it helps. Ralf Index: arch/mips/mm/fault.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/mm/fault.c,v retrieving revision 1.25.2.2 diff -u -r1.25.2.2 fault.c --- arch/mips/mm/fault.c 16 Jan 2002 03:49:24 -0000 1.25.2.2 +++ arch/mips/mm/fault.c 4 May 2002 01:28:34 -0000 @@ -19,6 +19,7 @@ #include #include +#include #include #include #include @@ -77,7 +78,7 @@ struct vm_area_struct * vma; struct task_struct *tsk = current; struct mm_struct *mm = tsk->mm; - unsigned long fixup; + unsigned long epc, fixup; siginfo_t info; /* @@ -181,7 +182,8 @@ no_context: /* Are we prepared to handle this kernel fault? */ - fixup = search_exception_table(regs->cp0_epc); + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; + fixup = search_exception_table(epc); if (fixup) { long new_epc; Index: arch/mips64/mm/fault.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips64/mm/fault.c,v retrieving revision 1.26.2.6 diff -u -r1.26.2.6 fault.c --- arch/mips64/mm/fault.c 23 Feb 2002 02:16:42 -0000 1.26.2.6 +++ arch/mips64/mm/fault.c 4 May 2002 01:28:34 -0000 @@ -21,6 +21,7 @@ #include #include +#include #include #include #include @@ -103,7 +104,7 @@ struct vm_area_struct * vma; struct task_struct *tsk = current; struct mm_struct *mm = tsk->mm; - unsigned long fixup; + unsigned long epc, fixup; siginfo_t info; #if 0 @@ -208,7 +209,8 @@ no_context: /* Are we prepared to handle this kernel fault? */ - fixup = search_exception_table(regs->cp0_epc); + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; + fixup = search_exception_table(epc); if (fixup) { long new_epc; From owner-linux-mips@oss.sgi.com Mon May 6 03:26:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46AQswJ014336 for ; Mon, 6 May 2002 03:26:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46AQsBd014335 for linux-mips-outgoing; Mon, 6 May 2002 03:26:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46AQgwJ014331 for ; Mon, 6 May 2002 03:26:48 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id C6CFC844; Mon, 6 May 2002 12:27:57 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 86F4D37115; Mon, 6 May 2002 12:27:32 +0200 (CEST) Date: Mon, 6 May 2002 12:27:32 +0200 From: Florian Lohoff To: linux-mips@oss.sgi.com Subject: RM200 big endian prom ? Message-ID: <20020506102732.GC27584@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lMM8JwqTlfDpEaS6" Content-Disposition: inline User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --lMM8JwqTlfDpEaS6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i yesterday had a try booting my RM200 (Big Endian Sinix firmware) with a big endian compiled kernel - It immediatly crashes in ArcWrite as the Bios is not an Arc (Probably a bit similar). Does anyone have interesting informations about that prom ? BTW: There are really some funny lines in arc/init.c :) arch/mips/arc/init.c 36 if (pb->magic !=3D 0x53435241) { 37 prom_printf("Aieee, bad prom vector magic %08lx\n",= pb->magic); 38 while(1) 39 ; 40 } 41=20 Calling ArcWrite in case of no Arc ;) At least one knows what happens if the Firmware is giving out EPC Faulting address (Which in this case is 0x6c) Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --lMM8JwqTlfDpEaS6 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 iD8DBQE81lqUUaz2rXW+gJcRAl8dAKCx99Z1+Wa+fLwghWbCTZGYEZG3VACeOdu9 dBjAlhppJ7jPvktsQrEsTgo= =5oiX -----END PGP SIGNATURE----- --lMM8JwqTlfDpEaS6-- From owner-linux-mips@oss.sgi.com Mon May 6 04:03:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46B3WwJ015287 for ; Mon, 6 May 2002 04:03:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46B3WxF015286 for linux-mips-outgoing; Mon, 6 May 2002 04:03:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46B3OwJ015283; Mon, 6 May 2002 04:03:25 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA17553; Mon, 6 May 2002 13:04:59 +0200 (MET DST) Date: Mon, 6 May 2002 13:04:58 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Florian Lohoff cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com, agx@sigxcpu.org Subject: Re: XSHM/shared-pixmap fix Was: Linux Shared Memory Issue In-Reply-To: <20020427214505.GA23046@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 Sat, 27 Apr 2002, Florian Lohoff wrote: [NON-Text Body part not included] Check it doesn't break static executables -- there were a few arch_get_unmapped_area() updates in mm/mmap.c that you don't include in the patch it would seem. -- + 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 May 6 05:43:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46ChQwJ016140 for ; Mon, 6 May 2002 05:43:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46ChQ7L016139 for linux-mips-outgoing; Mon, 6 May 2002 05:43:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46ChLwJ016136 for ; Mon, 6 May 2002 05:43:22 -0700 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g46CiXw21717 for ; Mon, 6 May 2002 14:44:33 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Mon, 6 May 2002 14:44:33 +0200 (CEST) From: Kjeld Borch Egevang To: linux-mips mailing list Subject: zsh on console Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk When I run zsh on the console (serial interface) the process hangs. I can login with /bin/bash, but when I start /bin/zsh it waits forever. I can interrupt the process and regain control. It's only related to the console. If I login with telnet it works just fine. Any idea, what could be wrong? /Kjeld -- _ _ ____ ___ 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 Mon May 6 05:51:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46CpawJ016313 for ; Mon, 6 May 2002 05:51:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46Cpaln016312 for linux-mips-outgoing; Mon, 6 May 2002 05:51:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46CpWwJ016306 for ; Mon, 6 May 2002 05:51:32 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id FAA03423 for ; Mon, 6 May 2002 05:52:42 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA20156; Mon, 6 May 2002 05:51:41 -0700 (PDT) Message-ID: <01db01c1f4fd$94f6ccb0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Kjeld Borch Egevang" , "linux-mips mailing list" References: Subject: Re: zsh on console Date: Mon, 6 May 2002 14:57:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > When I run zsh on the console (serial interface) the process hangs. I can > login with /bin/bash, but when I start /bin/zsh it waits forever. I can > interrupt the process and regain control. > > It's only related to the console. If I login with telnet it works just > fine. > > Any idea, what could be wrong? I don't know what it would be specifically, but having dealt with similar problems on other Unix systems, it's proably the case that zsh uses a particular tty mode that isn't correctly supported by the serial console driver, either due to a bug in the driver or due to a conflict with some other feature enabled on the console port. The next step to take would be to run "stty -all" under /bin/bash and under /bin/zsh on a telnet session, and compare the outputs. From owner-linux-mips@oss.sgi.com Mon May 6 11:35:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46IZMwJ027391 for ; Mon, 6 May 2002 11:35:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46IZMrJ027390 for linux-mips-outgoing; Mon, 6 May 2002 11:35:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46IZ4wJ027370; Mon, 6 May 2002 11:35:04 -0700 Received: from av.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 LAA07204; Mon, 6 May 2002 11:36:12 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA14702; Mon, 6 May 2002 11:19:47 -0700 Message-ID: <3CD6C8EA.9060807@mvista.com> Date: Mon, 06 May 2002 11:18:18 -0700 From: Jun Sun 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: Ralf Baechle CC: linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> <20020503184000.A1238@dea.linux-mips.net> Content-Type: multipart/mixed; boundary="------------080607000901020806060009" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------080607000901020806060009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It would help if not for the gross typo. :-) See the attachment. Jun Ralf Baechle wrote: > On Fri, May 03, 2002 at 04:41:56PM -0700, Jun Sun wrote: > > >>It appears earlier version of kernel does not have this problem. I have not >>fully figured out why. >> > > We didn't handle exceptions in branch delay slots. Try this patch and > tell me if it helps. > > Ralf > > Index: arch/mips/mm/fault.c > =================================================================== > RCS file: /home/pub/cvs/linux/arch/mips/mm/fault.c,v > retrieving revision 1.25.2.2 > diff -u -r1.25.2.2 fault.c > --- arch/mips/mm/fault.c 16 Jan 2002 03:49:24 -0000 1.25.2.2 > +++ arch/mips/mm/fault.c 4 May 2002 01:28:34 -0000 > @@ -19,6 +19,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -77,7 +78,7 @@ > struct vm_area_struct * vma; > struct task_struct *tsk = current; > struct mm_struct *mm = tsk->mm; > - unsigned long fixup; > + unsigned long epc, fixup; > siginfo_t info; > > /* > @@ -181,7 +182,8 @@ > > no_context: > /* Are we prepared to handle this kernel fault? */ > - fixup = search_exception_table(regs->cp0_epc); > + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; > + fixup = search_exception_table(epc); > if (fixup) { > long new_epc; > > Index: arch/mips64/mm/fault.c > =================================================================== > RCS file: /home/pub/cvs/linux/arch/mips64/mm/fault.c,v > retrieving revision 1.26.2.6 > diff -u -r1.26.2.6 fault.c > --- arch/mips64/mm/fault.c 23 Feb 2002 02:16:42 -0000 1.26.2.6 > +++ arch/mips64/mm/fault.c 4 May 2002 01:28:34 -0000 > @@ -21,6 +21,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -103,7 +104,7 @@ > struct vm_area_struct * vma; > struct task_struct *tsk = current; > struct mm_struct *mm = tsk->mm; > - unsigned long fixup; > + unsigned long epc, fixup; > siginfo_t info; > > #if 0 > @@ -208,7 +209,8 @@ > > no_context: > /* Are we prepared to handle this kernel fault? */ > - fixup = search_exception_table(regs->cp0_epc); > + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; > + fixup = search_exception_table(epc); > if (fixup) { > long new_epc; > > --------------080607000901020806060009 Content-Type: text/plain; name="junk" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="junk" diff -Nru link/arch/mips/mm/fault.c.orig link/arch/mips/mm/fault.c --- link/arch/mips/mm/fault.c.orig Mon May 6 11:12:41 2002 +++ link/arch/mips/mm/fault.c Mon May 6 11:15:12 2002 @@ -182,7 +182,7 @@ no_context: /* Are we prepared to handle this kernel fault? */ - epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; + epc = regs->cp0_epc + (delay_slot(regs) ? 4 : 0); fixup = search_exception_table(epc); if (fixup) { long new_epc; diff -Nru link/arch/mips64/mm/fault.c.orig link/arch/mips64/mm/fault.c --- link/arch/mips64/mm/fault.c.orig Mon May 6 11:12:44 2002 +++ link/arch/mips64/mm/fault.c Mon May 6 11:15:26 2002 @@ -209,7 +209,7 @@ no_context: /* Are we prepared to handle this kernel fault? */ - epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; + epc = regs->cp0_epc + (delay_slot(regs) ? 4 : 0); fixup = search_exception_table(epc); if (fixup) { long new_epc; --------------080607000901020806060009-- From owner-linux-mips@oss.sgi.com Mon May 6 12:14:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46JExwJ028153 for ; Mon, 6 May 2002 12:14:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46JEwBZ028152 for linux-mips-outgoing; Mon, 6 May 2002 12:14:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46JEswJ028142 for ; Mon, 6 May 2002 12:14:55 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506191608.VMEB9799.rwcrmhc51.attbi.com@ocean.lucon.org>; Mon, 6 May 2002 19:16:08 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0BBBB125C0; Mon, 6 May 2002 12:16:06 -0700 (PDT) Date: Mon, 6 May 2002 12:16:06 -0700 From: "H . J . Lu" To: "Kevin D. Kissell" Cc: Kjeld Borch Egevang , linux-mips mailing list Subject: Re: zsh on console Message-ID: <20020506121606.B28872@lucon.org> References: <01db01c1f4fd$94f6ccb0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01db01c1f4fd$94f6ccb0$10eca8c0@grendel>; from kevink@mips.com on Mon, May 06, 2002 at 02:57:28PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 06, 2002 at 02:57:28PM +0200, Kevin D. Kissell wrote: > > When I run zsh on the console (serial interface) the process hangs. I can > > login with /bin/bash, but when I start /bin/zsh it waits forever. I can > > interrupt the process and regain control. > > > > It's only related to the console. If I login with telnet it works just > > fine. > > > > Any idea, what could be wrong? > > I don't know what it would be specifically, but having > dealt with similar problems on other Unix systems, > it's proably the case that zsh uses a particular tty > mode that isn't correctly supported by the serial > console driver, either due to a bug in the driver or > due to a conflict with some other feature enabled > on the console port. The next step to take would > be to run "stty -all" under /bin/bash and under > /bin/zsh on a telnet session, and compare the > outputs. That sounds like a zsh bug I fixed. Please try zsh 3.0.8-8.1 in my RedHat 7.1 port and let me know if it doesn't work for you. H.J. From owner-linux-mips@oss.sgi.com Mon May 6 15:05:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46M5lwJ029744 for ; Mon, 6 May 2002 15:05:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46M5kV9029743 for linux-mips-outgoing; Mon, 6 May 2002 15:05:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46M5ewJ029739 for ; Mon, 6 May 2002 15:05:41 -0700 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g46M6ge17977; Tue, 7 May 2002 00:06:42 +0200 From: Hartvig Ekner Message-Id: <200205062206.g46M6ge17977@coplin09.mips.com> Subject: Re: zsh on console To: hjl@lucon.org (H . J . Lu) Date: Tue, 7 May 2002 00:06:42 +0200 (CEST) Cc: kevink@mips.com (Kevin D. Kissell), kjelde@mips.com (Kjeld Borch Egevang), linux-mips@oss.sgi.com (linux-mips mailing list) In-Reply-To: <20020506121606.B28872@lucon.org> from "H . J . Lu" at May 06, 2002 12:16:06 PM 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 H . J . Lu writes: > > On Mon, May 06, 2002 at 02:57:28PM +0200, Kevin D. Kissell wrote: > > > When I run zsh on the console (serial interface) the process hangs. I can > > > login with /bin/bash, but when I start /bin/zsh it waits forever. I can > > > interrupt the process and regain control. > > > > > > It's only related to the console. If I login with telnet it works just > > > fine. > > > > > > Any idea, what could be wrong? > > > > I don't know what it would be specifically, but having > > dealt with similar problems on other Unix systems, > > it's proably the case that zsh uses a particular tty > > mode that isn't correctly supported by the serial > > console driver, either due to a bug in the driver or > > due to a conflict with some other feature enabled > > on the console port. The next step to take would > > be to run "stty -all" under /bin/bash and under > > /bin/zsh on a telnet session, and compare the > > outputs. > > That sounds like a zsh bug I fixed. Please try zsh 3.0.8-8.1 in my RedHat 7.1 > port and let me know if it doesn't work for you. You only have the source RPM on OSS? I believe we compiled from another SRC RPM: zsh-4.0.4-5.src.rpm. What was your fix? /Hartvig From owner-linux-mips@oss.sgi.com Mon May 6 16:07:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46N7jwJ030468 for ; Mon, 6 May 2002 16:07:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46N7jUs030467 for linux-mips-outgoing; Mon, 6 May 2002 16:07:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46N7ewJ030460 for ; Mon, 6 May 2002 16:07:40 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020506230654.FDUX4412.rwcrmhc52.attbi.com@ocean.lucon.org>; Mon, 6 May 2002 23:06:54 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0467B125C0; Mon, 6 May 2002 16:06:51 -0700 (PDT) Date: Mon, 6 May 2002 16:06:51 -0700 From: "H . J . Lu" To: Hartvig Ekner Cc: "Kevin D. Kissell" , Kjeld Borch Egevang , linux-mips mailing list Subject: Re: zsh on console Message-ID: <20020506160651.A310@lucon.org> References: <20020506121606.B28872@lucon.org> <200205062206.g46M6ge17977@coplin09.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: <200205062206.g46M6ge17977@coplin09.mips.com>; from hartvige@mips.com on Tue, May 07, 2002 at 12:06:42AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 12:06:42AM +0200, Hartvig Ekner wrote: > H . J . Lu writes: > > > > On Mon, May 06, 2002 at 02:57:28PM +0200, Kevin D. Kissell wrote: > > > > When I run zsh on the console (serial interface) the process hangs. I can > > > > login with /bin/bash, but when I start /bin/zsh it waits forever. I can > > > > interrupt the process and regain control. > > > > > > > > It's only related to the console. If I login with telnet it works just > > > > fine. > > > > > > > > Any idea, what could be wrong? > > > > > > I don't know what it would be specifically, but having > > > dealt with similar problems on other Unix systems, > > > it's proably the case that zsh uses a particular tty > > > mode that isn't correctly supported by the serial > > > console driver, either due to a bug in the driver or > > > due to a conflict with some other feature enabled > > > on the console port. The next step to take would > > > be to run "stty -all" under /bin/bash and under > > > /bin/zsh on a telnet session, and compare the > > > outputs. > > > > That sounds like a zsh bug I fixed. Please try zsh 3.0.8-8.1 in my RedHat 7.1 > > port and let me know if it doesn't work for you. > > You only have the source RPM on OSS? I didn't add cross compile support for zsh. You have to compile it natively. > I believe we compiled from another SRC RPM: zsh-4.0.4-5.src.rpm. zsh-4.0.4-5 will be in my RedHat 7.3 port. > > What was your fix? > zsh-3.0.8-open.patch is in baseline.tar.bz2. H.J. From owner-linux-mips@oss.sgi.com Mon May 6 16:10:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g46NA1wJ030558 for ; Mon, 6 May 2002 16:10:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g46NA1Ou030557 for linux-mips-outgoing; Mon, 6 May 2002 16:10:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from guest ([66.89.142.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g46N9vwJ030520 for ; Mon, 6 May 2002 16:09:58 -0700 Received: (from ralf@localhost) by guest (8.11.6/8.11.6) id g468BB810652; Mon, 6 May 2002 16:11:11 +0800 Date: Mon, 6 May 2002 16:11:10 +0800 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: RM200 big endian prom ? Message-ID: <20020506161110.A10422@guest.intrengr> References: <20020506102732.GC27584@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: <20020506102732.GC27584@paradigm.rfc822.org>; from flo@rfc822.org on Mon, May 06, 2002 at 12:27:32PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 06, 2002 at 12:27:32PM +0200, Florian Lohoff wrote: > i yesterday had a try booting my RM200 (Big Endian Sinix firmware) > with a big endian compiled kernel - It immediatly crashes in ArcWrite > as the Bios is not an Arc (Probably a bit similar). > > Does anyone have interesting informations about that prom ? > > BTW: There are really some funny lines in arc/init.c :) > > arch/mips/arc/init.c > 36 if (pb->magic != 0x53435241) { > 37 prom_printf("Aieee, bad prom vector magic %08lx\n", pb->magic); > 38 while(1) > 39 ; > 40 } > 41 > > Calling ArcWrite in case of no Arc ;) At least one knows what happens > if the Firmware is giving out EPC Faulting address (Which in this case > is 0x6c) So far the assumption is that SNI's firmware is lookling like ARCS which is basically a big endian abortion of ARC. Alternativly it might as well look similar to the firmware of the old MIPS workstations such as the RC3230 or similar. I wonder if the the magic just needs to be endianess swapped? Ralf From owner-linux-mips@oss.sgi.com Mon May 6 19:51:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g472p2wJ032456 for ; Mon, 6 May 2002 19:51:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g472p22C032455 for linux-mips-outgoing; Mon, 6 May 2002 19:51:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from guest (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g472oxwJ032452 for ; Mon, 6 May 2002 19:50:59 -0700 Received: (from ralf@localhost) by guest (8.11.6/8.11.6) id g46Brft29019; Mon, 6 May 2002 19:53:41 +0800 Date: Mon, 6 May 2002 19:53:41 +0800 From: Ralf Baechle To: Kjeld Borch Egevang Cc: linux-mips mailing list Subject: Re: zsh on console Message-ID: <20020506195340.B15551@guest.intrengr> 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 kjelde@mips.com on Mon, May 06, 2002 at 02:44:33PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 06, 2002 at 02:44:33PM +0200, Kjeld Borch Egevang wrote: > When I run zsh on the console (serial interface) the process hangs. I can > login with /bin/bash, but when I start /bin/zsh it waits forever. I can > interrupt the process and regain control. > > It's only related to the console. If I login with telnet it works just > fine. > > Any idea, what could be wrong? I recently fixed a simliar bug in the sb1250_duart.c driver. Basically a hangup of the tty did result in the close routine getting called thus the driver's usage counter for ttyS0 eventually dropping to zero though it was still open ... Ralf From owner-linux-mips@oss.sgi.com Mon May 6 21:09:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4749DwJ000964 for ; Mon, 6 May 2002 21:09:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4749Dvt000963 for linux-mips-outgoing; Mon, 6 May 2002 21:09:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47499wJ000960 for ; Mon, 6 May 2002 21:09:09 -0700 Received: from delllaptop ([208.187.134.77]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g474ASE05822 for ; Mon, 6 May 2002 21:10:28 -0700 From: "Robert Rusek" To: Subject: depmod help ! Date: Mon, 6 May 2002 21:09:11 -0700 Message-ID: <001501c1f57c$f2188e90$6601a8c0@delllaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am running his on an Indy. I have kernel 2.4.17 and modutils 2.4.16. When a depmod is performed I get the following message: depmod: cannot read ELF header from /lib/modules/2.4.17/modules.dep depmod: cannot read ELF header from /lib/modules/2.4.17/modules.generic_string depmod: /lib/modules/2.4.17/modules.ieee1394map is not an ELF file depmod: /lib/modules/2.4.17/modules.isapnpmap is not an ELF file depmod: cannot read ELF header from /lib/modules/2.4.17/modules.parportmap depmod: /lib/modules/2.4.17/modules.pcimap is not an ELF file depmod: cannot read ELF header from /lib/modules/2.4.17/modules.pnpbiosmap depmod: /lib/modules/2.4.17/modules.usbmap is not an ELF file How can I correct this? I am trying to clean up my startup before I start using the machine. Thank you in advance. -- Robert Rusek From owner-linux-mips@oss.sgi.com Mon May 6 23:47:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g476lMwJ002399 for ; Mon, 6 May 2002 23:47:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g476lMvt002398 for linux-mips-outgoing; Mon, 6 May 2002 23:47:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g476l6wJ002395; Mon, 6 May 2002 23:47:07 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [128.167.58.27]) with SMTP; 7 May 2002 06:48:28 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 B1BC3B471; Tue, 7 May 2002 15:48:26 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id PAA21044; Tue, 7 May 2002 15:48:26 +0900 (JST) Date: Tue, 07 May 2002 15:48:20 +0900 (JST) Message-Id: <20020507.154820.92590599.nemoto@toshiba-tops.co.jp> To: macro@ds2.pg.gda.pl Cc: flo@rfc822.org, ralf@oss.sgi.com, linux-mips@oss.sgi.com, agx@sigxcpu.org Subject: Re: XSHM/shared-pixmap fix Was: Linux Shared Memory Issue From: Atsushi Nemoto In-Reply-To: <20010814104941.F5928@bacchus.dhis.org> References: <20020427214505.GA23046@paradigm.rfc822.org> 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.2 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, 6 May 2002 13:04:58 +0200 (MET DST), "Maciej W. Rozycki" said: macro> Check it doesn't break static executables -- there were a few macro> arch_get_unmapped_area() updates in mm/mmap.c that you don't macro> include in the patch it would seem. I have yet another arch_get_unmapped_area which includes it. My arch_get_unmapped_area is a hybrid of one in mm/mmap.c and one in arch/sparc64/sys_sparc64.c. Also, I am using MY_SHMLBA to avoid wasting address space. I got following comments from Ralf when I posted my previous patch. >>>>> On Tue, 14 Aug 2001 10:49:41 +0200, Ralf Baechle said: ralf> It's wasting huge amounts of address space. That can be ralf> prohibitive if you want to run something such as electric fence. ralf> Technically the worst case of any CPU that's required is 32kb on ralf> R4000 / R4400 SC and MC versions, so I don't want to go beyond ralf> that. Here is my arch_get_unmapped_area. #ifdef HAVE_ARCH_UNMAPPED_AREA /* solve cache aliasing problem (see Documentation/cachetlb.txt and arch/sparc64/kernel/sys_sparc.c */ #if SHMLBA > 0x10000 /* avoid overkill... */ #define MY_SHMLBA 0x10000 #else #define MY_SHMLBA SHMLBA #endif #define COLOUR_ALIGN(addr,pgoff) \ ((((addr)+MY_SHMLBA-1)&~(MY_SHMLBA-1)) + \ (((pgoff)< TASK_SIZE) return -ENOMEM; do_color_align = 0; if (filp || (flags & MAP_SHARED)) do_color_align = 1; if (addr) { if (do_color_align) addr = COLOUR_ALIGN(addr, pgoff); else addr = PAGE_ALIGN(addr); vmm = find_vma(current->mm, addr); if (TASK_SIZE - len >= addr && (!vmm || addr + len <= vmm->vm_start)) return addr; } addr = TASK_UNMAPPED_BASE; if (do_color_align) addr = COLOUR_ALIGN(addr, pgoff); else addr = PAGE_ALIGN(addr); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ if (TASK_SIZE - len < addr) return -ENOMEM; if (!vmm || addr + len <= vmm->vm_start) return addr; addr = vmm->vm_end; if (do_color_align) addr = COLOUR_ALIGN(addr, pgoff); } } #endif /* HAVE_ARCH_UNMAPPED_AREA */ --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Tue May 7 00:26:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g477QnwJ003640 for ; Tue, 7 May 2002 00:26:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g477QnUo003639 for linux-mips-outgoing; Tue, 7 May 2002 00:26:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g477QfwJ003636 for ; Tue, 7 May 2002 00:26:44 -0700 Received: from sohotower ([208.187.134.77]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g477S0E06807 for ; Tue, 7 May 2002 00:28:00 -0700 From: "Robert Rusek" To: Subject: kernel: EXT2-fs error ? Date: Tue, 7 May 2002 00:29:27 -0700 Message-ID: <000001c1f598$efc65070$0a01a8c0@sohotower> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am running Kernel 2.4.17 on an SGI Indy. I recently noticed that I have been getting the following error sparatically. What does this mean? The system boots up cleanly and then the fs gets corrupted somehow. Any help would be greatly appreciated. May 6 04:02:17 catbert kernel: EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory #110032: unaligned di rectory entry - offset=0, inode=6226015, rec_len=95, name_len=95 May 6 04:02:17 catbert kernel: EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory #110056: rec_len is s maller than minimal - offset=0, inode=2551, rec_len=0, name_len=8 May 6 04:02:17 catbert kernel: EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory #110071: rec_len is s maller than minimal - offset=0, inode=0, rec_len=0, name_len=0 May 6 04:02:17 catbert kernel: EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory #110081: rec_len is s maller than minimal - offset=0, inode=547544874, rec_len=0, name_len=0 Thank you in advance, Rob. From owner-linux-mips@oss.sgi.com Tue May 7 01:46:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g478kxwJ004510 for ; Tue, 7 May 2002 01:46:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g478kxl1004509 for linux-mips-outgoing; Tue, 7 May 2002 01:46:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g478kiwJ004504; Tue, 7 May 2002 01:46:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id BAA08698; Tue, 7 May 2002 01:48:00 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA26276; Tue, 7 May 2002 01:47:57 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g478lub14619; Tue, 7 May 2002 10:47:57 +0200 (MEST) Message-ID: <3CD794BC.43264E9E@mips.com> Date: Tue, 07 May 2002 10:47:56 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Jun Sun , linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> <20020503184000.A1238@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Fri, May 03, 2002 at 04:41:56PM -0700, Jun Sun wrote: > > > It appears earlier version of kernel does not have this problem. I have not > > fully figured out why. > > We didn't handle exceptions in branch delay slots. Try this patch and > tell me if it helps. It fix a problem I have had for quite a while in the r4k_fpu.S. The code in question is: jr ra .set nomacro EX(sw t0,SC_FPC_EIR(a0)) .set macro I have fixed it locally by removing the SW from the delay-slot, but obviously your fix is the right one. But I guess we need the same fix in arch/mips/kernel/unaligned.c. > > Ralf > > Index: arch/mips/mm/fault.c > =================================================================== > RCS file: /home/pub/cvs/linux/arch/mips/mm/fault.c,v > retrieving revision 1.25.2.2 > diff -u -r1.25.2.2 fault.c > --- arch/mips/mm/fault.c 16 Jan 2002 03:49:24 -0000 1.25.2.2 > +++ arch/mips/mm/fault.c 4 May 2002 01:28:34 -0000 > @@ -19,6 +19,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -77,7 +78,7 @@ > struct vm_area_struct * vma; > struct task_struct *tsk = current; > struct mm_struct *mm = tsk->mm; > - unsigned long fixup; > + unsigned long epc, fixup; > siginfo_t info; > > /* > @@ -181,7 +182,8 @@ > > no_context: > /* Are we prepared to handle this kernel fault? */ > - fixup = search_exception_table(regs->cp0_epc); > + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; > + fixup = search_exception_table(epc); > if (fixup) { > long new_epc; > > Index: arch/mips64/mm/fault.c > =================================================================== > RCS file: /home/pub/cvs/linux/arch/mips64/mm/fault.c,v > retrieving revision 1.26.2.6 > diff -u -r1.26.2.6 fault.c > --- arch/mips64/mm/fault.c 23 Feb 2002 02:16:42 -0000 1.26.2.6 > +++ arch/mips64/mm/fault.c 4 May 2002 01:28:34 -0000 > @@ -21,6 +21,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -103,7 +104,7 @@ > struct vm_area_struct * vma; > struct task_struct *tsk = current; > struct mm_struct *mm = tsk->mm; > - unsigned long fixup; > + unsigned long epc, fixup; > siginfo_t info; > > #if 0 > @@ -208,7 +209,8 @@ > > no_context: > /* Are we prepared to handle this kernel fault? */ > - fixup = search_exception_table(regs->cp0_epc); > + epc = regs->cp0_epc + delay_slot(regs) ? 4 : 0; > + fixup = search_exception_table(epc); > if (fixup) { > long new_epc; > -- _ _ ____ ___ 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 May 7 01:50:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g478oXwJ004629 for ; Tue, 7 May 2002 01:50:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g478oWjE004628 for linux-mips-outgoing; Tue, 7 May 2002 01:50:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from guest (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g478oTwJ004624 for ; Tue, 7 May 2002 01:50:30 -0700 Received: (from ralf@localhost) by guest (8.11.6/8.11.6) id g46HrDG13452; Tue, 7 May 2002 01:53:13 +0800 Date: Tue, 7 May 2002 01:53:13 +0800 From: Ralf Baechle To: Carsten Langgaard Cc: Jun Sun , linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? Message-ID: <20020507015313.A13262@guest.intrengr> References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> <20020503184000.A1238@dea.linux-mips.net> <3CD794BC.43264E9E@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: <3CD794BC.43264E9E@mips.com>; from carstenl@mips.com on Tue, May 07, 2002 at 10:47:56AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 10:47:56AM +0200, Carsten Langgaard wrote: > It fix a problem I have had for quite a while in the r4k_fpu.S. The code in > question is: > jr ra > .set nomacro > EX(sw t0,SC_FPC_EIR(a0)) > .set macro > > I have fixed it locally by removing the SW from the delay-slot, but obviously > your fix is the right one. > But I guess we need the same fix in arch/mips/kernel/unaligned.c. Good spotting. I'll use a slightly different fix using the new inline function exception_epc() in to implement that slightly more elegant. Thanks, Ralf From owner-linux-mips@oss.sgi.com Tue May 7 03:00:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47A0owJ005378 for ; Tue, 7 May 2002 03:00:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47A0otn005377 for linux-mips-outgoing; Tue, 7 May 2002 03:00:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47A0dwJ005373; Tue, 7 May 2002 03:00:39 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 60B95848; Tue, 7 May 2002 12:01:59 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8EEA03711E; Tue, 7 May 2002 12:01:17 +0200 (CEST) Date: Tue, 7 May 2002 12:01:17 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: RM200 big endian prom ? Message-ID: <20020507100117.GA28542@paradigm.rfc822.org> References: <20020506102732.GC27584@paradigm.rfc822.org> <20020506161110.A10422@guest.intrengr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <20020506161110.A10422@guest.intrengr> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 06, 2002 at 04:11:10PM +0800, Ralf Baechle wrote: > So far the assumption is that SNI's firmware is lookling like ARCS which = is > basically a big endian abortion of ARC. Alternativly it might as well > look similar to the firmware of the old MIPS workstations such as the > RC3230 or similar. >=20 > I wonder if the the magic just needs to be endianess swapped? From dumping the area a0001000 it does not look like it - Not even any version or revision fits the description of the prom block. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --IS0zKkzwUGydFO0o 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 iD8DBQE816XtUaz2rXW+gJcRAp+kAJ9vCiBnK1uDVaOkss6drFwl2ix/+wCg0UVN QwSqxYKlPHuQLosqdzaj4pI= =q679 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-linux-mips@oss.sgi.com Tue May 7 03:31:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47AVXwJ006155 for ; Tue, 7 May 2002 03:31:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47AVXPD006153 for linux-mips-outgoing; Tue, 7 May 2002 03:31:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47AVTwJ006150 for ; Tue, 7 May 2002 03:31:30 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 173BF8D37; Tue, 7 May 2002 12:32:49 +0200 (CEST) Date: Tue, 7 May 2002 12:32:49 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: ralf@gnu.org Subject: howto pass ramdisk loaddress to kernel Message-ID: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com, ralf@gnu.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 Hi, in order to get rid of some ip22 specific hacks in setup.c as well as addinitrd/elf2ecoff I've written a small tool that links kernel+initrd as type "binary" into the data segment of the bootloader. This file can then be fetched by the prom via tftp(or from a CD or whatever). The bootloader copies the kernel to its loaddress and puts the initrd just after the kernel. My question is now: how do i properly pass the initrd's memory address to the kernel? Choices are: 1) on the commandline: rd_start=0x... 2) a bootparameter block like on i386 or sparc in head.S 3) rely on the kernel to identify if a radisk has been loaded by a magic number I'd prefer (1) but it seems none of the other arches does this. Is there a reason for that? If not could we just introduce a new kernel commandline parameter rd_start which has a memory address as a parameter. Ralf, would you let this into the kernel? -- Guido From owner-linux-mips@oss.sgi.com Tue May 7 03:42:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47Ag0wJ006396 for ; Tue, 7 May 2002 03:42:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47Ag0Ss006395 for linux-mips-outgoing; Tue, 7 May 2002 03:42:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from guest (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47AftwJ006392 for ; Tue, 7 May 2002 03:41:55 -0700 Received: (from ralf@localhost) by guest (8.11.6/8.11.6) id g46Jid632458; Tue, 7 May 2002 03:44:39 +0800 Date: Tue, 7 May 2002 03:44:38 +0800 From: Ralf Baechle To: Carsten Langgaard Cc: Jun Sun , linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? Message-ID: <20020507034438.B14268@guest.intrengr> References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> <20020503184000.A1238@dea.linux-mips.net> <3CD794BC.43264E9E@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: <3CD794BC.43264E9E@mips.com>; from carstenl@mips.com on Tue, May 07, 2002 at 10:47:56AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 10:47:56AM +0200, Carsten Langgaard wrote: > I have fixed it locally by removing the SW from the delay-slot, but obviously > your fix is the right one. > But I guess we need the same fix in arch/mips/kernel/unaligned.c. Smoke this: Index: arch/mips64/kernel/unaligned.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips64/kernel/unaligned.c,v retrieving revision 1.6.2.3 diff -u -r1.6.2.3 unaligned.c --- arch/mips64/kernel/unaligned.c 24 Apr 2002 07:58:54 -0000 1.6.2.3 +++ arch/mips64/kernel/unaligned.c 7 May 2002 10:29:05 -0000 @@ -351,7 +351,7 @@ fault: /* Did we have an exception handler installed? */ - fixup = search_exception_table(regs->cp0_epc); + fixup = search_exception_table(exception_epc(regs)); if (fixup) { long new_epc; new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); Index: arch/mips/kernel/unaligned.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/kernel/unaligned.c,v retrieving revision 1.15.2.4 diff -u -r1.15.2.4 unaligned.c --- arch/mips/kernel/unaligned.c 24 Apr 2002 07:50:26 -0000 1.15.2.4 +++ arch/mips/kernel/unaligned.c 7 May 2002 10:29:05 -0000 @@ -332,7 +332,7 @@ fault: /* Did we have an exception handler installed? */ - fixup = search_exception_table(regs->cp0_epc); + fixup = search_exception_table(exception_epc(regs)); if (fixup) { long new_epc; new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); Ralf From owner-linux-mips@oss.sgi.com Tue May 7 03:44:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47AinwJ015024 for ; Tue, 7 May 2002 03:44:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47AimZa015023 for linux-mips-outgoing; Tue, 7 May 2002 03:44:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47AigwJ015019 for ; Tue, 7 May 2002 03:44:43 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 6A51D8A1; Tue, 7 May 2002 12:46:03 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id BDB823711E; Tue, 7 May 2002 12:45:38 +0200 (CEST) Date: Tue, 7 May 2002 12:45:38 +0200 From: Florian Lohoff To: Guido Guenther Cc: linux-mips@oss.sgi.com, ralf@gnu.org Subject: Re: howto pass ramdisk loaddress to kernel Message-ID: <20020507104538.GB795@paradigm.rfc822.org> References: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 07, 2002 at 12:32:49PM +0200, Guido Guenther wrote: > My question is now: how do i properly pass the initrd's memory address > to the kernel? Choices are: > 1) on the commandline: rd_start=3D0x... > 2) a bootparameter block like on i386 or sparc in head.S > 3) rely on the kernel to identify if a radisk has > been loaded by a magic number >=20 > I'd prefer (1) but it seems none of the other arches does this. Is there > a reason for that? If not could we just introduce a new kernel > commandline parameter rd_start which has a memory address as a > parameter. Ralf, would you let this into the kernel? I would do 1+3 - Give the address on the command line and let the ramdisk have a magic + length in the first 2 __u32. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --lEGEL1/lMxI0MVQ2 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 iD8DBQE817BSUaz2rXW+gJcRAmCeAKCIIsxjjGn/9EI7VvPv+tmKGnvfUQCgrUXy IAUCLJ+9Xf6UMd05umVk9eQ= =kPC1 -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-linux-mips@oss.sgi.com Tue May 7 05:04:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47C44wJ016897 for ; Tue, 7 May 2002 05:04:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47C44eZ016896 for linux-mips-outgoing; Tue, 7 May 2002 05:04:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hell (buserror-extern.convergence.de [212.84.236.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47C3xwJ016893 for ; Tue, 7 May 2002 05:04:00 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 1753iO-0001Wr-00; Tue, 07 May 2002 14:05:08 +0200 Date: Tue, 7 May 2002 14:05:08 +0200 From: Johannes Stezenbach To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: depmod help ! Message-ID: <20020507120507.GA5859@convergence.de> Mail-Followup-To: Johannes Stezenbach , Robert Rusek , linux-mips@oss.sgi.com References: <001501c1f57c$f2188e90$6601a8c0@delllaptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501c1f57c$f2188e90$6601a8c0@delllaptop> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 06, 2002 at 09:09:11PM -0700, Robert Rusek wrote: > When a depmod is performed I get the following message: > > depmod: cannot read ELF header from /lib/modules/2.4.17/modules.dep > depmod: cannot read ELF header from > /lib/modules/2.4.17/modules.generic_string > depmod: /lib/modules/2.4.17/modules.ieee1394map is not an ELF file > depmod: /lib/modules/2.4.17/modules.isapnpmap is not an ELF file > depmod: cannot read ELF header from > /lib/modules/2.4.17/modules.parportmap > depmod: /lib/modules/2.4.17/modules.pcimap is not an ELF file > depmod: cannot read ELF header from > /lib/modules/2.4.17/modules.pnpbiosmap > depmod: /lib/modules/2.4.17/modules.usbmap is not an ELF file depmod bug, you get this if you've compiled your kernel with module support but actually havent't installed any modules. Create an empty /lib/modules/2.4.17/kernel/ directory to make depmod happy. Regards, Johannes From owner-linux-mips@oss.sgi.com Tue May 7 15:06:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47M6rwJ009825 for ; Tue, 7 May 2002 15:06:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47M6rrr009824 for linux-mips-outgoing; Tue, 7 May 2002 15:06:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47M6owJ009821 for ; Tue, 7 May 2002 15:06:50 -0700 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) 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 PAA01895 for ; Tue, 7 May 2002 15:08:04 -0700 (PDT) mail_from (keith_siders@toshibatv.com) Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id <26NPQG85>; Tue, 7 May 2002 17:06:35 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: Debugging of embedded target applications Date: Tue, 7 May 2002 17:05:36 -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 I am using x86 Linux for host development to a MIPS Linux embedded target. I finally have a hardware debugger for my target board that works, but I have to get large application files downloaded in a timely fashion. The debugger must download to the target via JTAG, therefore downloads have lots of bits of overhead, i.e. downloads are slow. Is there anything like a gdb server that can I run on the target to connect to a remote client via ethernet? I don't really want to have to compile a complete gdb tool to run on my target board to do this. I don't have the luxury of a lot of memory on this board, and no swap space (flash-based system, no hdd). The real catch is I would like to be able to resolve the symbols of the application so the debugger can be used to set hardware breakpoints, and provide source-level debugging of the application. Or am I going about this totally bassackwards? Keith From owner-linux-mips@oss.sgi.com Tue May 7 15:13:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47MDtwJ010277 for ; Tue, 7 May 2002 15:13:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47MDsmc010276 for linux-mips-outgoing; Tue, 7 May 2002 15:13:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47MDnwJ010272 for ; Tue, 7 May 2002 15:13:50 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 175DEm-0005r9-00; Tue, 07 May 2002 18:15:12 -0400 Date: Tue, 7 May 2002 18:15:12 -0400 From: Daniel Jacobowitz To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020507221512.GA22326@nevyn.them.org> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> User-Agent: Mutt/1.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 05:05:36PM -0500, Siders, Keith wrote: > I am using x86 Linux for host development to a MIPS Linux embedded target. I > finally have a hardware debugger for my target board that works, but I have > to get large application files downloaded in a timely fashion. The debugger > must download to the target via JTAG, therefore downloads have lots of bits > of overhead, i.e. downloads are slow. Is there anything like a gdb server > that can I run on the target to connect to a remote client via ethernet? I > don't really want to have to compile a complete gdb tool to run on my target > board to do this. I don't have the luxury of a lot of memory on this board, > and no swap space (flash-based system, no hdd). The real catch is I would > like to be able to resolve the symbols of the application so the debugger > can be used to set hardware breakpoints, and provide source-level debugging > of the application. Or am I going about this totally bassackwards? There is an appropriate program. In fact, you even got the name right: it's called "gdbserver", and is included with the GDB distribution. I recommend you get GDB 5.2, released last week; the gdbserver included in that version is far superior for GNU/Linux targets to any previous release. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue May 7 15:32:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47MWYwJ011295 for ; Tue, 7 May 2002 15:32:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47MWYCd011294 for linux-mips-outgoing; Tue, 7 May 2002 15:32:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47MWTwJ011291 for ; Tue, 7 May 2002 15:32:29 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id PAA33770; Tue, 7 May 2002 15:33:51 -0700 (PDT) Date: Tue, 7 May 2002 15:33:51 -0700 From: Geoffrey Espin To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020507153351.B12509@idiom.com> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX>; from Siders, Keith on Tue, May 07, 2002 at 05:05:36PM -0500 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 05:05:36PM -0500, Siders, Keith wrote: > I am using x86 Linux for host development to a MIPS Linux embedded target. I > finally have a hardware debugger for my target board that works, but I have > to get large application files downloaded in a timely fashion. The debugger > must download to the target via JTAG, therefore downloads have lots of bits > of overhead, i.e. downloads are slow. Is there anything like a gdb server > that can I run on the target to connect to a remote client via ethernet? I If you have a Linux Ethernet driver working, then most people boot and mount with an NFS root disk. Then you just cross-compile additional apps and tools and adding to your NFS disk. Presumably including gdb (not tried it). Then just debug "normally" -- with the CLI. The JTAG hardware debugger is not used (or maybe just to initially bootstrap the kernel and trap certain exceptions). RH7.1 fs at: ftp://ftp.linux.sgi.com/pub/linux/mips/mipsel-linux/root/ And see: http://www.linux.sgi.com/downloads.html Once your basic apps are complete, then you can think about creating a JFFS2 partition (after the MTD flash driver's debuggged) and using that for standalone bootup. Actually, my first approach was to flash the linux kernel with just a cramfs'd busybox and then NFS mount my home directory from a startup script. To save (a lot of) space in applications checkout uclibc.org. Shared libs support with uclibc is real close for MIPS, but for now use static linking. Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Tue May 7 15:43:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g47Mh8wJ011517 for ; Tue, 7 May 2002 15:43:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g47Mh8a6011516 for linux-mips-outgoing; Tue, 7 May 2002 15:43:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g47Mh5wJ011513 for ; Tue, 7 May 2002 15:43:05 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id PAA40728; Tue, 7 May 2002 15:44:27 -0700 (PDT) Date: Tue, 7 May 2002 15:44:27 -0700 From: Geoffrey Espin To: Daniel Jacobowitz Cc: "Siders, Keith" , "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020507154427.D12509@idiom.com> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> <20020507221512.GA22326@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020507221512.GA22326@nevyn.them.org>; from Daniel Jacobowitz on Tue, May 07, 2002 at 06:15:12PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 06:15:12PM -0400, Daniel Jacobowitz wrote: > it's called "gdbserver", and is included with the GDB distribution. > I recommend you get GDB 5.2, released last week; the gdbserver included > in that version is far superior for GNU/Linux targets to any previous > release. Does work it for kernel type debugging over *Ethernet*? I see some docs saying "TCP/IP" connection... but does that mean a special kind of network driver? Or a gdbstub/agent outside the kernel in a special monitor? Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Tue May 7 18:47:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g481lmwJ017703 for ; Tue, 7 May 2002 18:47:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g481lmXU017702 for linux-mips-outgoing; Tue, 7 May 2002 18:47:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g481lewJ017694 for ; Tue, 7 May 2002 18:47:40 -0700 Received: from nevyn.them.org (NEVYN.RES.CMU.EDU [128.2.145.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 SAA01115 for ; Tue, 7 May 2002 18:48:25 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 175GU6-0007s8-00; Tue, 07 May 2002 21:43:14 -0400 Date: Tue, 7 May 2002 21:43:14 -0400 From: Daniel Jacobowitz To: Geoffrey Espin Cc: "Siders, Keith" , "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020508014314.GA30243@nevyn.them.org> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> <20020507221512.GA22326@nevyn.them.org> <20020507154427.D12509@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020507154427.D12509@idiom.com> User-Agent: Mutt/1.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 03:44:27PM -0700, Geoffrey Espin wrote: > On Tue, May 07, 2002 at 06:15:12PM -0400, Daniel Jacobowitz wrote: > > it's called "gdbserver", and is included with the GDB distribution. > > I recommend you get GDB 5.2, released last week; the gdbserver included > > in that version is far superior for GNU/Linux targets to any previous > > release. > > Does work it for kernel type debugging over *Ethernet*? > I see some docs saying "TCP/IP" connection... but does that > mean a special kind of network driver? Or a gdbstub/agent > outside the kernel in a special monitor? What do you mean by kernel type debugging? It's not a kernel stub. It can debug user programs over TCP/IP or a serial line. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue May 7 19:24:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g482O5wJ018714 for ; Tue, 7 May 2002 19:24:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g482O5AP018713 for linux-mips-outgoing; Tue, 7 May 2002 19:24:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from idiom.com (espin@idiom.com [216.240.32.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g482O1wJ018710 for ; Tue, 7 May 2002 19:24:01 -0700 Received: (from espin@localhost) by idiom.com (8.9.3/8.9.3) id TAA85580; Tue, 7 May 2002 19:25:23 -0700 (PDT) Date: Tue, 7 May 2002 19:25:23 -0700 From: Geoffrey Espin To: Daniel Jacobowitz Cc: "Siders, Keith" , "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020507192523.A73748@idiom.com> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> <20020507221512.GA22326@nevyn.them.org> <20020507154427.D12509@idiom.com> <20020508014314.GA30243@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <20020508014314.GA30243@nevyn.them.org>; from Daniel Jacobowitz on Tue, May 07, 2002 at 09:43:14PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 09:43:14PM -0400, Daniel Jacobowitz wrote: > > Does work it for kernel type debugging over *Ethernet*? > > I see some docs saying "TCP/IP" connection... but does that > > mean a special kind of network driver? Or a gdbstub/agent > > outside the kernel in a special monitor? > What do you mean by kernel type debugging? It's not a kernel stub. It > can debug user programs over TCP/IP or a serial line. In traditional embedded RTOS land, "system-level debugging". In the olden days one had to have BDM/JTAG hardware assist to step thru truly arbitary bits of code, like interrupt handlers, scheduler. The original question was about using using a hardware debugger. Clearly using gdb/gdbserver is for apps only, AFAIK. Does one bother with a h/w debugger for apps? Using kgdb with some kind of remote debug-agent would be a "system level debugger", a s/w solution to a traditional hardware only debug aid. At this time kind of pointless, as its painful to setup and JTAG debuggers are so cheap (for mainline CPUs). Geoff -- Geoffrey Espin espin@idiom.com -- From owner-linux-mips@oss.sgi.com Tue May 7 19:31:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g482VHwJ018841 for ; Tue, 7 May 2002 19:31:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g482VHav018840 for linux-mips-outgoing; Tue, 7 May 2002 19:31:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g482VDwJ018837 for ; Tue, 7 May 2002 19:31:13 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 175HFs-0008Ht-00; Tue, 07 May 2002 22:32:36 -0400 Date: Tue, 7 May 2002 22:32:36 -0400 From: Daniel Jacobowitz To: Geoffrey Espin Cc: "Siders, Keith" , "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications Message-ID: <20020508023236.GA31840@nevyn.them.org> References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> <20020507221512.GA22326@nevyn.them.org> <20020507154427.D12509@idiom.com> <20020508014314.GA30243@nevyn.them.org> <20020507192523.A73748@idiom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020507192523.A73748@idiom.com> User-Agent: Mutt/1.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 07, 2002 at 07:25:23PM -0700, Geoffrey Espin wrote: > On Tue, May 07, 2002 at 09:43:14PM -0400, Daniel Jacobowitz wrote: > > > Does work it for kernel type debugging over *Ethernet*? > > > I see some docs saying "TCP/IP" connection... but does that > > > mean a special kind of network driver? Or a gdbstub/agent > > > outside the kernel in a special monitor? > > What do you mean by kernel type debugging? It's not a kernel stub. It > > can debug user programs over TCP/IP or a serial line. > > In traditional embedded RTOS land, "system-level debugging". > In the olden days one had to have BDM/JTAG hardware assist > to step thru truly arbitary bits of code, like interrupt handlers, > scheduler. > > The original question was about using using a hardware debugger. > Clearly using gdb/gdbserver is for apps only, AFAIK. Does one > bother with a h/w debugger for apps? Using kgdb with some kind Actually, yes, you can. I believe at least the Abatron BDI can do this. Could be wrong, though. > of remote debug-agent would be a "system level debugger", a s/w > solution to a traditional hardware only debug aid. At this time > kind of pointless, as its painful to setup and JTAG debuggers > are so cheap (for mainline CPUs). Depends on your platform. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue May 7 20:15:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g483FHwJ019959 for ; Tue, 7 May 2002 20:15:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g483FHex019957 for linux-mips-outgoing; Tue, 7 May 2002 20:15:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g483FEwJ019954 for ; Tue, 7 May 2002 20:15:14 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g483Gbs13784; Tue, 7 May 2002 20:16:37 -0700 Date: Tue, 7 May 2002 20:16:37 -0700 From: Ralf Baechle To: Jun Sun Cc: linux-mips Subject: Re: what is the right behavior of copy_to_user(0x0, ..., ...)? Message-ID: <20020507201637.B13717@dea.linux-mips.net> References: <3CD3052B.1050400@mvista.com> <20020503162337.A27366@dea.linux-mips.net> <3CD32044.9040109@mvista.com> <20020503184000.A1238@dea.linux-mips.net> <3CD6C8EA.9060807@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CD6C8EA.9060807@mvista.com>; from jsun@mvista.com on Mon, May 06, 2002 at 11:18:18AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 06, 2002 at 11:18:18AM -0700, Jun Sun wrote: > It would help if not for the gross typo. :-) See the attachment. Never noticed that because I already had a slightly more elegant solution in my tree. It's already in CVS, check it out. Ralf From owner-linux-mips@oss.sgi.com Wed May 8 00:54:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g487sYwJ024588 for ; Wed, 8 May 2002 00:54:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g487sYQa024587 for linux-mips-outgoing; Wed, 8 May 2002 00:54:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from tarzan.ugyvitelszolgaltato.hu ([213.163.26.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g487sQwJ024581 for ; Wed, 8 May 2002 00:54:28 -0700 Received: from atti.ugyvitelszolgaltato.hu (atti.ugyvitelszolgaltato.hu [193.80.82.9]) by tarzan.ugyvitelszolgaltato.hu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA04987 for ; Wed, 8 May 2002 10:21:25 +0200 Received: from root by atti.ugyvitelszolgaltato.hu with local (Exim 3.12 #1 (Debian)) id 175MI0-0000U6-00 for ; Wed, 08 May 2002 09:55:08 +0200 Date: Wed, 8 May 2002 09:55:08 +0200 From: Szabo Attila To: linux-mips@oss.sgi.com Subject: indy scsi Message-ID: <20020508095508.A1682@ugyvitelszolgaltato.hu> 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 Organization: Ugyvitelszolgaltato Kft. X-OS: Linux 2.4.17, Debian 2.2 X-Sys: MSI K7TM Pro, AMD Tbird 850MHz, 256MB RAM, Gef2 MX, 10GB Hdd X-WM: Blackbox 0.61 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi ! I've put a WD enterprise 4360 Ultra3 scsi disk into my Indy. It is the only disk, and I disabled the wide negotiating on the disk. But it is too slow.I'm running debian woody and I've tested it with hdparm, but the buffered disk reads is just 1.7 MB/sec. It is very slow !! Is there any way to make it faster ?? Thanks -- ------------------------------------------------------ A t t i l a | trial@ugyvitelszolgaltato.hu | S z a b o ------------------------------------------------------ From owner-linux-mips@oss.sgi.com Wed May 8 04:48:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48BmkwJ027944 for ; Wed, 8 May 2002 04:48:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48BmkdU027943 for linux-mips-outgoing; Wed, 8 May 2002 04:48:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48BmcwJ027940 for ; Wed, 8 May 2002 04:48:40 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7242783A; Wed, 8 May 2002 13:50:03 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id EC2DD3711E; Wed, 8 May 2002 13:49:17 +0200 (CEST) Date: Wed, 8 May 2002 13:49:17 +0200 From: Florian Lohoff To: Szabo Attila Cc: linux-mips@oss.sgi.com Subject: Re: indy scsi Message-ID: <20020508114917.GA6625@paradigm.rfc822.org> References: <20020508095508.A1682@ugyvitelszolgaltato.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20020508095508.A1682@ugyvitelszolgaltato.hu> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2002 at 09:55:08AM +0200, Szabo Attila wrote: > Hi ! >=20 > I've put a WD enterprise 4360 Ultra3 scsi disk into my Indy. > It is the only disk, and I disabled the wide negotiating on the disk. > But it is too slow.I'm running debian woody and I've tested it > with hdparm, but the buffered disk reads is just 1.7 MB/sec. > It is very slow !! > Is there any way to make it faster ?? Probably no - 1.7MB/s sound not too bad - Remember - That machine is 10 Years old and was produced at times a i386 was modern which had 1MB/s memory bandwidth. SCSI transfers on the indy/I2 are made with DMA so i guess there is=20 no real speedup to expect. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --Kj7319i9nmIyA2yE 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 iD8DBQE82RC9Uaz2rXW+gJcRAuVKAKDJ7IHMHY7oPdV+HHNWMypUXGAjmgCgmHPW NphrmEPazaaFOtAw6B3wEBY= =OkX9 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-linux-mips@oss.sgi.com Wed May 8 05:42:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48Cg9wJ028396 for ; Wed, 8 May 2002 05:42:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48Cg8bj028395 for linux-mips-outgoing; Wed, 8 May 2002 05:42:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from tarzan.ugyvitelszolgaltato.hu ([213.163.26.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48Cg2wJ028391 for ; Wed, 8 May 2002 05:42:04 -0700 Received: from atti.ugyvitelszolgaltato.hu (atti.ugyvitelszolgaltato.hu [193.80.82.9]) by tarzan.ugyvitelszolgaltato.hu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA09359 for ; Wed, 8 May 2002 15:09:08 +0200 Received: from root by atti.ugyvitelszolgaltato.hu with local (Exim 3.12 #1 (Debian)) id 175QmO-0000aB-00 for ; Wed, 08 May 2002 14:42:48 +0200 Date: Wed, 8 May 2002 14:42:47 +0200 From: Szabo Attila To: linux-mips@oss.sgi.com Subject: indy scsi Message-ID: <20020508144247.A2023@ugyvitelszolgaltato.hu> 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 Organization: Ugyvitelszolgaltato Kft. X-OS: Linux 2.4.17, Debian 2.2 X-Sys: MSI K7TM Pro, AMD Tbird 850MHz, 256MB RAM, Gef2 MX, 10GB Hdd X-WM: Blackbox 0.61 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 2002, May 08 -> Florian Lohoff wrote : > Probably no - 1.7MB/s sound not too bad - Remember - That machine > is 10 Years old and was produced at times a i386 was modern which > had 1MB/s memory bandwidth. Yes, I know all of that, and I've expected only max 3-5 MB/sec but not 1.7. The scsi bandwith on indy is 10MB/s, the disk is above 10 MB/s. Maybe I expect too much Thanks -- ------------------------------------------------------ A t t i l a | trial@ugyvitelszolgaltato.hu | S z a b o ------------------------------------------------------ From owner-linux-mips@oss.sgi.com Wed May 8 06:07:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48D71wJ028779 for ; Wed, 8 May 2002 06:07:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48D71Oo028778 for linux-mips-outgoing; Wed, 8 May 2002 06:07:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48D6rwJ028775 for ; Wed, 8 May 2002 06:06:53 -0700 Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) 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 GAA03124 for ; Wed, 8 May 2002 06:08:09 -0700 (PDT) mail_from (keith_siders@toshibatv.com) Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id <26NPQHHT>; Wed, 8 May 2002 08:06:47 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA379AA4@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Cc: "'Daniel Jacobowitz'" , Geoffrey Espin Subject: RE: Debugging of embedded target applications Date: Wed, 8 May 2002 08:05:43 -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 Thanks for the lively discussion and input. It's now clear to me that I'll be tracking (not tracing) the kernel with the h/w debugger through its kgdb shell. We're still working on some drivers, so control over the kernel is a must. I'll have to set up the server to autoload when a connection on a particular port is attempted from another gdb shell, and shut down on disconnection. Keith -> -----Original Message----- -> From: Daniel Jacobowitz [mailto:dan@debian.org] -> Sent: Tuesday, May 07, 2002 9:33 PM -> To: Geoffrey Espin -> Cc: Siders, Keith; Linux-Mips (E-mail) -> Subject: Re: Debugging of embedded target applications -> -> -> On Tue, May 07, 2002 at 07:25:23PM -0700, Geoffrey Espin wrote: -> > On Tue, May 07, 2002 at 09:43:14PM -0400, Daniel Jacobowitz wrote: -> > > > Does work it for kernel type debugging over *Ethernet*? -> > > > I see some docs saying "TCP/IP" connection... but does that -> > > > mean a special kind of network driver? Or a gdbstub/agent -> > > > outside the kernel in a special monitor? -> > > What do you mean by kernel type debugging? It's not a -> kernel stub. It -> > > can debug user programs over TCP/IP or a serial line. -> > -> > In traditional embedded RTOS land, "system-level debugging". -> > In the olden days one had to have BDM/JTAG hardware assist -> > to step thru truly arbitary bits of code, like interrupt handlers, -> > scheduler. -> > -> > The original question was about using using a hardware debugger. -> > Clearly using gdb/gdbserver is for apps only, AFAIK. Does one -> > bother with a h/w debugger for apps? Using kgdb with some kind -> -> Actually, yes, you can. I believe at least the Abatron BDI can do -> this. Could be wrong, though. -> -> > of remote debug-agent would be a "system level debugger", a s/w -> > solution to a traditional hardware only debug aid. At this time -> > kind of pointless, as its painful to setup and JTAG debuggers -> > are so cheap (for mainline CPUs). -> -> Depends on your platform. -> -> -- -> Daniel Jacobowitz Carnegie Mellon -> University -> MontaVista Software Debian GNU/Linux -> Developer -> From owner-linux-mips@oss.sgi.com Wed May 8 07:24:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EO4wJ029523 for ; Wed, 8 May 2002 07:24:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EO4qA029522 for linux-mips-outgoing; Wed, 8 May 2002 07:24:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48ENwwJ029515 for ; Wed, 8 May 2002 07:24:00 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 175RdX-0001aT-00; Wed, 08 May 2002 14:37:43 +0100 Subject: Re: indy scsi To: trial@ugyvitelszolgaltato.hu (Szabo Attila) Date: Wed, 8 May 2002 14:37:43 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: <20020508144247.A2023@ugyvitelszolgaltato.hu> from "Szabo Attila" at May 08, 2002 02:42:47 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 > Yes, I know all of that, and I've expected only max 3-5 MB/sec but not > 1.7. > The scsi bandwith on indy is 10MB/s, the disk is above 10 MB/s. > Maybe I expect too much An old 2Gb 5400 RPM drive ought to deliver about 2Mbytes/second data rates. The 1.7 sounds suprisingly low unless the driver code doesn't support disconnect and scsi2 tagged stuff. For an old NCR538x/9x device without those it sounds all too believable. Alan From owner-linux-mips@oss.sgi.com Wed May 8 07:32:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EWwwJ029761 for ; Wed, 8 May 2002 07:32:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EWwHF029760 for linux-mips-outgoing; Wed, 8 May 2002 07:32:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48EWrwJ029755 for ; Wed, 8 May 2002 07:32:54 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA05784; Wed, 8 May 2002 16:32:37 +0200 (MET DST) Date: Wed, 8 May 2002 16:32:35 +0200 (MEST) From: Geert Uytterhoeven To: Alan Cox cc: Szabo Attila , Linux/MIPS Development Subject: Re: indy scsi 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, 8 May 2002, Alan Cox wrote: > > Yes, I know all of that, and I've expected only max 3-5 MB/sec but not > > 1.7. > > The scsi bandwith on indy is 10MB/s, the disk is above 10 MB/s. > > Maybe I expect too much > > An old 2Gb 5400 RPM drive ought to deliver about 2Mbytes/second data rates. > The 1.7 sounds suprisingly low unless the driver code doesn't support > disconnect and scsi2 tagged stuff. For an old NCR538x/9x device without > those it sounds all too believable. Doesn't the Indy have a wd33c93, like the Amiga 3000? If yes, 1.7 MiB/s is indeed quite low. 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 Wed May 8 07:51:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48EptwJ030158 for ; Wed, 8 May 2002 07:51:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48EptUq030157 for linux-mips-outgoing; Wed, 8 May 2002 07:51:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48EpjwJ030154 for ; Wed, 8 May 2002 07:51:45 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id C3C1684D; Wed, 8 May 2002 16:53:10 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C4A403711E; Wed, 8 May 2002 16:52:44 +0200 (CEST) Date: Wed, 8 May 2002 16:52:44 +0200 From: Florian Lohoff To: Geert Uytterhoeven Cc: Alan Cox , Szabo Attila , Linux/MIPS Development Subject: Re: indy scsi Message-ID: <20020508145244.GB9959@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2002 at 04:32:35PM +0200, Geert Uytterhoeven wrote: > On Wed, 8 May 2002, Alan Cox wrote: > > > Yes, I know all of that, and I've expected only max 3-5 MB/sec but not > > > 1.7. > > > The scsi bandwith on indy is 10MB/s, the disk is above 10 MB/s. > > > Maybe I expect too much > >=20 > > An old 2Gb 5400 RPM drive ought to deliver about 2Mbytes/second data ra= tes. > > The 1.7 sounds suprisingly low unless the driver code doesn't support= =20 > > disconnect and scsi2 tagged stuff. For an old NCR538x/9x device without > > those it sounds all too believable. >=20 > Doesn't the Indy have a wd33c93, like the Amiga 3000? If yes, 1.7 MiB/s is > indeed quite low. It does have one of those. And it supports disconnect which was the problem with the read corruption going on in former days. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --EuxKj2iCbKjpUGkD 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 iD8DBQE82Tu8Uaz2rXW+gJcRAp8jAJ9oHVkF2Os5iBmWcLFnsmtYfw6ljQCgnRHd qOdhazyqBtVmH24xnY/uFFU= =I1JF -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-linux-mips@oss.sgi.com Wed May 8 10:21:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48HLtwJ003572 for ; Wed, 8 May 2002 10:21:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48HLtoe003571 for linux-mips-outgoing; Wed, 8 May 2002 10:21:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48HLqwJ003567 for ; Wed, 8 May 2002 10:21:52 -0700 Received: from whrrusek (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g48HNJF01827 for ; Wed, 8 May 2002 10:23:19 -0700 From: "Robert Rusek" To: Subject: Indy SCSI Errors Date: Wed, 8 May 2002 10:23:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am currently running kernel 2.4.17 and am getting sparatice errors like the following. I seen that there had been bugs in the scsi driver in the earlier kernel versions. Has anyone encountered this? Is there a newer kernal that maybe addresses this? EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory #110030: unaligned directory entry - offset=0, inode=6226015, rec_len=95, name_len=95 Thank you in advance, -- Robert Rusek From owner-linux-mips@oss.sgi.com Wed May 8 11:17:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48IH4wJ004345 for ; Wed, 8 May 2002 11:17:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48IH4Bl004344 for linux-mips-outgoing; Wed, 8 May 2002 11:17:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48IGwwJ004341 for ; Wed, 8 May 2002 11:16:58 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA13302; Wed, 8 May 2002 11:17:54 -0700 Message-ID: <3CD96B76.5090506@mvista.com> Date: Wed, 08 May 2002 11:16:22 -0700 From: Jun Sun 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: Daniel Jacobowitz CC: Geoffrey Espin , "Siders, Keith" , "Linux-Mips (E-mail)" Subject: Re: Debugging of embedded target applications References: <7DF7BFDC95ECD411B4010090278A44CA379AA1@ATVX> <20020507221512.GA22326@nevyn.them.org> <20020507154427.D12509@idiom.com> <20020508014314.GA30243@nevyn.them.org> <20020507192523.A73748@idiom.com> <20020508023236.GA31840@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Daniel Jacobowitz wrote: > On Tue, May 07, 2002 at 07:25:23PM -0700, Geoffrey Espin wrote: > >>On Tue, May 07, 2002 at 09:43:14PM -0400, Daniel Jacobowitz wrote: >> >>>>Does work it for kernel type debugging over *Ethernet*? >>>>I see some docs saying "TCP/IP" connection... but does that >>>>mean a special kind of network driver? Or a gdbstub/agent >>>>outside the kernel in a special monitor? >>>> >>>What do you mean by kernel type debugging? It's not a kernel stub. It >>>can debug user programs over TCP/IP or a serial line. >>> >>In traditional embedded RTOS land, "system-level debugging". >>In the olden days one had to have BDM/JTAG hardware assist >>to step thru truly arbitary bits of code, like interrupt handlers, >>scheduler. >> >>The original question was about using using a hardware debugger. >>Clearly using gdb/gdbserver is for apps only, AFAIK. Does one >>bother with a h/w debugger for apps? Using kgdb with some kind >> > > Actually, yes, you can. I believe at least the Abatron BDI can do > this. Could be wrong, though. > I have used kgdb over JTAG. Jun From owner-linux-mips@oss.sgi.com Wed May 8 14:24:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48LOiwJ016458 for ; Wed, 8 May 2002 14:24:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48LOiYC016457 for linux-mips-outgoing; Wed, 8 May 2002 14:24:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.5.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48LOfwJ016441 for ; Wed, 8 May 2002 14:24:42 -0700 Received: from dev1 (dev.cvnet.com [24.185.255.18]) by mta4.srv.hcvlny.cv.net (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with SMTP id <0GVT00H11A7JN4@mta4.srv.hcvlny.cv.net> for linux-mips@oss.sgi.com; Wed, 08 May 2002 17:26:08 -0400 (EDT) Date: Wed, 08 May 2002 17:26:09 -0400 From: Rick Spanbauer Subject: copy_mount_options To: linux-mips@oss.sgi.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Howdy - I am having a bit of a problem with a kernel port I've been working on recently. Linux is up and running to the initial sh prompt, networking/ethernet works, and so on. When I try a mount(), I am getting a kernel page fault. Between a few hours worth of debugging and some Googling around, I believe I understand what is happening, ie when copy_mount_option is copying in from user space, it seems to be running off the end of the data segment (code was apparently written with the assumption that this is legal). I can think of several different solutions, but the question is this - is there some common, accepted practice solution to this particular problem? From searching the discussion groups, this class of problem seems to be a known issue, but the arguments pro/con about what to do about it never seem to converge :) So before tracking off into the wilderness on my own, I thought I might ask! Tnx Rick Spanbauer From owner-linux-mips@oss.sgi.com Wed May 8 14:32:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48LWOwJ016635 for ; Wed, 8 May 2002 14:32:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48LWNB2016634 for linux-mips-outgoing; Wed, 8 May 2002 14:32:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48LWJwJ016619 for ; Wed, 8 May 2002 14:32:19 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA19502; Wed, 8 May 2002 14:33:59 -0700 Message-ID: <3CD9996A.1030500@mvista.com> Date: Wed, 08 May 2002 14:32:26 -0700 From: Jun Sun 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: Rick Spanbauer CC: linux-mips@oss.sgi.com Subject: Re: copy_mount_options References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Rick Spanbauer wrote: > Howdy - I am having a bit of a problem with a kernel port I've been working > on recently. Linux is up and running to the initial sh prompt, networking/ethernet > works, and so on. When I try a mount(), I am getting a kernel page fault. Between > a few hours worth of debugging and some Googling around, I believe I understand > what is happening, ie when copy_mount_option is copying in from user space, it > seems to be running off the end of the data segment (code was apparently written with > the assumption that this is legal). I can think of several different solutions, but > the question is this - is there some common, accepted practice solution to > this particular problem? From searching the discussion groups, this class of problem > seems to be a known issue, but the arguments pro/con about what to do about > it never seem to converge :) So before tracking off into the wilderness > on my own, I thought I might ask! Tnx Rick Spanbauer > Congradulations! You must have checked out the kernel from OSS CVS tree sometime in the past a couple of days. There is a small time window when Ralf checked in the "correct epc for delay slot" fix with a typo and later got fixed again. And coyp_mount_option() kernel fault was the symptom of the typo. Get the latest code and give it a try. Jun From owner-linux-mips@oss.sgi.com Wed May 8 14:41:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g48LfkwJ016786 for ; Wed, 8 May 2002 14:41:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g48Lfk5A016785 for linux-mips-outgoing; Wed, 8 May 2002 14:41:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g48LfawJ016779 for ; Wed, 8 May 2002 14:41:36 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g48Lfav19198; Wed, 8 May 2002 14:41:37 -0700 Subject: Re: [Fwd: Current state of MIPS16 support?] From: Eric Christopher To: Dominic Sweetman Cc: Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk In-Reply-To: <15566.28397.770794.272735@gladsmuir.algor.co.uk> References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4.99 Date: 08 May 2002 14:40:52 -0700 Message-Id: <1020894054.2575.2.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dominic, > > I have not looked at the Algorithmics code because I don't have > > copyright on it... > > We do publish our sources on our web server. Not only are they GPL > but we have a copyright assignment to the FSF in place (which I know > was sent to Jim Wilson of Cygnus, albeit in 1993...) > It's great that your changes do get out in one form or another. I'm personally uncertain as to the nature of copyright and how it would affect if I looked at your code and put it into the mainline sources - so I haven't :) > We're operating from a baseline which was a Cygnus/RedHat "2.96" > release made to MIPS Technologies in late 2000. A snapshot from a > contract which had run into some kind of dissension, it had some new > MIPS16 support but it was very buggy (the regular 32-bit MIPS code > generator, too). It has some nice features, though, like the "Haifa" > scheduler and the DFA extensions to machine descriptions for > superscalar CPUs. > I don't remember any new mips16 support, however, I do remember that the work was quite old (more than 2 years now). MIPS32 support is quite a bit better now, and with the acceptance of Vlad's DFA scheduler into mainline the scheduling descriptions will be following shortly. > It's true we have not contributed patches lately. We don't really > have the resouces; our success rate used to be very low, and since > we're not working around the developing 3.x sources the prospects seem > even dimmer. > The backend has changed a bit in the time, however, it hasn't changed so much that the patches would be that difficult for you to bring forward. I encourage you to reconsider contributing them. > We're working (with funding from MIPS Technologies) on building a > toolchain which: > > o Can build Linux kernel, libraries and applications alike; > > o Is substantially more efficient than other GCC versions when > producing MIPS application ("MIPS/ABI", PIC) code; > > o Will produce ugly-but-correct PIC code for MIPS16 functions, so > MIPS16 can be tested in a standard Linux environment; > > o Operates to a known and documented ABI (even the forgotten details, > like gprof...) > > (The modesty of those ambitions should be measured against the reality > of today's Linux/MIPS...) I'm not certain what you are actually fixing here as I've not seen any descriptions of problems here. I'd love to fix any problems that you've had reported in the mainline sources so that everyone can get the benefit of the work you are doing. > It would be even more valuable if we could ensure that MIPS becomes a > "first-class" architecture for the evolving GCC - but the latter > surely is a big commitment for the core GCC group. > I'm putting in a lot of effort to cleaning up the MIPS port and am committed to the architecture. > It's a pity that the different priorities of various funders and > developers mean that there is no baseline toolkit for Linux/MIPS, so > that such resources as are available are frequently used to re-invent > the wheel. > > Anyone got any ideas how to make it better? > The problem as I see it is that no one wants/cares to contribute their changes back that they make, or at least file bug reports against the problems that they have. Almost 90% of the bug reports I see are against IRIX. People have to "re-invent the wheel" because the changes never make it back into the official sources - everyone has their own one offs. If we fix this then the work that all of the disparate groups are doing will at least go toward a common goal. -eric -- A fire drill does not demand a fire. From owner-linux-mips@oss.sgi.com Wed May 8 19:30:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g492UBwJ021427 for ; Wed, 8 May 2002 19:30:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g492UBiR021426 for linux-mips-outgoing; Wed, 8 May 2002 19:30:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g492TvwJ021414 for ; Wed, 8 May 2002 19:29:57 -0700 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g492VKu16288 for ; Wed, 8 May 2002 19:31:20 -0700 Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g492VFH01587 for ; Wed, 8 May 2002 19:31:15 -0700 Message-Id: <200205090231.g492VFH01587@icarus.sanera.net> Date: Wed, 8 May 2002 19:31:15 -0700 (PDT) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Is this a /proc or kernel bug? To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MlNmEPCKMcnxsokctwLjjQ== 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 an example proc read function which is part of my driver static int mydriver_proc_read(char *page, char **start, off_t off, int count, int *eof, void *d) { uint32_t pos, len; /* Here I replaced the original code with some test code. Basically, I want to write a SIZE number of bytes to 'page' */ len = SIZE; for (pos=0;pos count) len = count; if (len < 0) len = 0; return (len) } The above function works fine as long as the SIZE is lessthan 4K. If SIZE is greater than 4K then some times I see the following kernel panic when I try to do "cat /proc/" Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 373: $0 : 00000000 10009f00 8f20802c 48494a4b $4 : 8f320988 00000001 00000000 00000116 $8 : 00000002 5c5d5e5f 00000000 20212223 $12: 24252627 00000025 10009f00 8f2fe116 $16: 4c4d4e4f 00000000 8f208024 00000001 $20: 8f320988 10009f01 80282998 00000001 $24: 00000001 2ac0ec10 $28: 8f226000 8f227ce8 8f227ce8 8019d938 epc : 000000008011268c Status : 10009f02 Cause : 00800010 BadAddr: 0000000048494a4bProcess cat (pid: 72, stackpage=8f226000) Stack: 801af260 0000003c 8f320000 00000000 8f320000 00000000 8f227e68 00001000 00000000 10009f01 00000000 8f2ff150 10000238 8019d938 8011b7a8 00000000 00000000 801cd818 8fdd3300 02000001 00000001 8027b880 00000000 8027b888 8011b1b8 8011b1b8 80283a94 0000ee41 00000001 802a7420 8027b260 8fdd3300 00000013 fffffffb 8010ec40 8010ebf4 00801400 b00a0020 80223744 63646566 00080000 ... Call Trace: [<801af260>] [<8019d938>] [<8011b7a8>] [<801cd818>] [<8011b1b8>] [<8011b1b8>] [<8010ec40>] [<8010ebf4>] [<80223744>] [<80223518>] [<801a1cc8>] [<8019d080>] [<8019f960>] [<801362c8>] [<8019f790>] [<8019a3d4>] [<8013c81c>] [<8013c6a8>] [<80128514>] [<80147ba0>] [<8010d924>] [<8010d924>] Code: 00003021 8e100000 8c620000 <00571024> 1040002f 00000000 40116000 36210001 38210001 Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 373: $0 : 00000000 10009f00 8f208014 30313233 $4 : 8f51bf5c 00000001 00000000 00000000 $8 : 8fa3f960 00000001 00001000 00002000 $12: 10009f00 00000000 00000000 00000000 $16: 34353637 8fa3faec 8f20800c 00000001 $20: 8f51bf5c 10009f01 80282998 00000001 $24: 00000000 00000001 $28: 80106000 80107cb0 80107cb0 801c85a4 epc : 000000008011268c Status : 10009f02 Cause : 00800010 BadAddr: 0000000030313233Process swapper (pid: 0, stackpage=80106000) Stack: 00000060 00000248 81617e91 8fd41a48 8fa3f960 8fa3faec 8fd4f460 8fa3f960 8fd43044 ffffffff 00000000 0000012c 8027b9ac 801c85a4 8fa3fa1c 00000001 8fd4f460 8fa3f960 8fa3fa1c 801ed86c 8fcf6064 801cb304 8fcf6000 8f227d70 8fa3fa1c 00000014 8fd4f460 8fa3f960 8fd43044 00000000 00000000 0000012c 801ef1a0 801ef168 8fd42660 8fd42660 00000068 8fd47044 8fd43030 8fd4f460 8fd4f460 ... Call Trace: [<801c85a4>] [<801ed86c>] [<801cb304>] [<801ef1a0>] [<801ef168>] [<801f89c4>] [<801f9050>] [<801dd32c>] [<801dd350>] [<801dbd5c>] [<801c89e4>] [<801dc188>] [<801dc2a0>] [<801cd658>] [<801af088>] [<801af07c>] [<801af088>] [<801af07c>] [<801cdb14>] [<801b0654>] [<80107eb8>] [<8011b1b8>] [<8010ec40>] [<8010ebf4>] [<80223744>] [<80223518>] [<80223518>] [<80107fe0>] [<80106000>] [<80107f68>] [<8010891c>] [<80108928>] [<80108030>] [<80227628>] [<80107d40>] [<8010078c>] Code: 00003021 8e100000 8c620000 <00571024> 1040002f 00000000 40116000 36210001 38210001 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Some times the user level process "cat" panics with the same panic message. Some times the "cat" process prints the proper messages but at the end does segmentation fault. I did some investigation and found that the value of "page", when the function is entered multiple times, is different causing the statement *start = page + off meaningless because "page" is not always same as the "page" when called with off=0. Here is the print log- page = 8f209000 count = 3072 off = 0 page = 8f209000 count = 1024 off = 3072 page = 8f207000 count = 3072 off = 4096 Is this a bug in my code or in the kernel code? Thanks Krishna Kondaka Sanera Systems Inc. From owner-linux-mips@oss.sgi.com Wed May 8 20:27:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g493RWwJ021883 for ; Wed, 8 May 2002 20:27:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g493RWQC021882 for linux-mips-outgoing; Wed, 8 May 2002 20:27:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g493RDwJ021877 for ; Wed, 8 May 2002 20:27:14 -0700 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g493Sbu16500 for ; Wed, 8 May 2002 20:28:37 -0700 Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g493SWH02942 for ; Wed, 8 May 2002 20:28:32 -0700 Message-Id: <200205090328.g493SWH02942@icarus.sanera.net> Date: Wed, 8 May 2002 20:28:32 -0700 (PDT) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Is this a /proc or kernel bug? (more info...) To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: r3DDBzcDRcGjFoGiETEQWQ== 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 Sorry for not including the following information: OS version: 2.4.9 # cat /proc/version Linux version 2.4.9sb20011031 (gcc version 3.0.1 with SiByte modifications) #1 Tue Mar 5 10:58:57 PST 2002 # cat /proc/cpuinfo cpu : MIPS processor : 0 cpu model : SiByte SB1 V0.1 BogoMIPS : 332.59 system type : SiByte SWARM byteorder : big endian unaligned accesses : 0 wait instruction : no microsecond timers : yes extra interrupt vector : yes hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Date: Wed, 8 May 2002 19:31:15 -0700 (PDT) From: Krishna Kondaka Subject: Is this a /proc or kernel bug? To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-MD5: MlNmEPCKMcnxsokctwLjjQ== Hi, Here is an example proc read function which is part of my driver static int mydriver_proc_read(char *page, char **start, off_t off, int count, int *eof, void *d) { uint32_t pos, len; /* Here I replaced the original code with some test code. Basically, I want to write a SIZE number of bytes to 'page' */ len = SIZE; for (pos=0;pos count) len = count; if (len < 0) len = 0; return (len) } The above function works fine as long as the SIZE is lessthan 4K. If SIZE is greater than 4K then some times I see the following kernel panic when I try to do "cat /proc/" Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 373: $0 : 00000000 10009f00 8f20802c 48494a4b $4 : 8f320988 00000001 00000000 00000116 $8 : 00000002 5c5d5e5f 00000000 20212223 $12: 24252627 00000025 10009f00 8f2fe116 $16: 4c4d4e4f 00000000 8f208024 00000001 $20: 8f320988 10009f01 80282998 00000001 $24: 00000001 2ac0ec10 $28: 8f226000 8f227ce8 8f227ce8 8019d938 epc : 000000008011268c Status : 10009f02 Cause : 00800010 BadAddr: 0000000048494a4bProcess cat (pid: 72, stackpage=8f226000) Stack: 801af260 0000003c 8f320000 00000000 8f320000 00000000 8f227e68 00001000 00000000 10009f01 00000000 8f2ff150 10000238 8019d938 8011b7a8 00000000 00000000 801cd818 8fdd3300 02000001 00000001 8027b880 00000000 8027b888 8011b1b8 8011b1b8 80283a94 0000ee41 00000001 802a7420 8027b260 8fdd3300 00000013 fffffffb 8010ec40 8010ebf4 00801400 b00a0020 80223744 63646566 00080000 ... Call Trace: [<801af260>] [<8019d938>] [<8011b7a8>] [<801cd818>] [<8011b1b8>] [<8011b1b8>] [<8010ec40>] [<8010ebf4>] [<80223744>] [<80223518>] [<801a1cc8>] [<8019d080>] [<8019f960>] [<801362c8>] [<8019f790>] [<8019a3d4>] [<8013c81c>] [<8013c6a8>] [<80128514>] [<80147ba0>] [<8010d924>] [<8010d924>] Code: 00003021 8e100000 8c620000 <00571024> 1040002f 00000000 40116000 36210001 38210001 Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line 373: $0 : 00000000 10009f00 8f208014 30313233 $4 : 8f51bf5c 00000001 00000000 00000000 $8 : 8fa3f960 00000001 00001000 00002000 $12: 10009f00 00000000 00000000 00000000 $16: 34353637 8fa3faec 8f20800c 00000001 $20: 8f51bf5c 10009f01 80282998 00000001 $24: 00000000 00000001 $28: 80106000 80107cb0 80107cb0 801c85a4 epc : 000000008011268c Status : 10009f02 Cause : 00800010 BadAddr: 0000000030313233Process swapper (pid: 0, stackpage=80106000) Stack: 00000060 00000248 81617e91 8fd41a48 8fa3f960 8fa3faec 8fd4f460 8fa3f960 8fd43044 ffffffff 00000000 0000012c 8027b9ac 801c85a4 8fa3fa1c 00000001 8fd4f460 8fa3f960 8fa3fa1c 801ed86c 8fcf6064 801cb304 8fcf6000 8f227d70 8fa3fa1c 00000014 8fd4f460 8fa3f960 8fd43044 00000000 00000000 0000012c 801ef1a0 801ef168 8fd42660 8fd42660 00000068 8fd47044 8fd43030 8fd4f460 8fd4f460 ... Call Trace: [<801c85a4>] [<801ed86c>] [<801cb304>] [<801ef1a0>] [<801ef168>] [<801f89c4>] [<801f9050>] [<801dd32c>] [<801dd350>] [<801dbd5c>] [<801c89e4>] [<801dc188>] [<801dc2a0>] [<801cd658>] [<801af088>] [<801af07c>] [<801af088>] [<801af07c>] [<801cdb14>] [<801b0654>] [<80107eb8>] [<8011b1b8>] [<8010ec40>] [<8010ebf4>] [<80223744>] [<80223518>] [<80223518>] [<80107fe0>] [<80106000>] [<80107f68>] [<8010891c>] [<80108928>] [<80108030>] [<80227628>] [<80107d40>] [<8010078c>] Code: 00003021 8e100000 8c620000 <00571024> 1040002f 00000000 40116000 36210001 38210001 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing Some times the user level process "cat" panics with the same panic message. Some times the "cat" process prints the proper messages but at the end does segmentation fault. I did some investigation and found that the value of "page", when the function is entered multiple times, is different causing the statement *start = page + off meaningless because "page" is not always same as the "page" when called with off=0. Here is the print log- page = 8f209000 count = 3072 off = 0 page = 8f209000 count = 1024 off = 3072 page = 8f207000 count = 3072 off = 4096 Is this a bug in my code or in the kernel code? Thanks Krishna Kondaka Sanera Systems Inc. From owner-linux-mips@oss.sgi.com Thu May 9 08:43:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49Fh3wJ031265 for ; Thu, 9 May 2002 08:43:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49Fh3Vm031264 for linux-mips-outgoing; Thu, 9 May 2002 08:43:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49FguwJ031260 for ; Thu, 9 May 2002 08:42:57 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 70BE3844; Thu, 9 May 2002 17:44:26 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C22A63711E; Thu, 9 May 2002 17:43:27 +0200 (CEST) Date: Thu, 9 May 2002 17:43:27 +0200 From: Florian Lohoff To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Indy SCSI Errors Message-ID: <20020509154327.GB6197@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 08, 2002 at 10:23:18AM -0700, Robert Rusek wrote: > I am currently running kernel 2.4.17 and am getting sparatice errors > like the following. I seen that there had been bugs in the scsi driver > in the earlier kernel versions. Has anyone encountered this? Is there > a newer kernal that maybe addresses this? >=20 > EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in directory > #110030: unaligned > directory entry - offset=3D0, inode=3D6226015, rec_len=3D95, name_len=3D= 95 >=20 The SCSI errors we had on the Indy and Indigo2 happened with multiple disks, disconnects and were pure "read" errors. Filesystem corruption was quite rare. Mostly we had file data corruption on copy. The bug is fixed for at least half a year now. Do you see any other errors than that ? SCSI errors ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --/NkBOFFp2J2Af1nK 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 iD8DBQE82pkfUaz2rXW+gJcRAkBeAKDfEfjJEyPkcL00u3pGQmXEg1rObACgsi0V wdrft6JS5fdm34HTefGHBIE= =Zkw1 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-linux-mips@oss.sgi.com Thu May 9 09:31:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49GV2wJ003827 for ; Thu, 9 May 2002 09:31:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49GV2ie003826 for linux-mips-outgoing; Thu, 9 May 2002 09:31:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49GUtwJ003821 for ; Thu, 9 May 2002 09:30:56 -0700 Received: from whrrusek (whnat1.weiderpub.com [65.115.104.67] (may be forged)) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g49GVMT01926; Thu, 9 May 2002 09:31:22 -0700 From: "Robert Rusek" To: "'Florian Lohoff'" Cc: Subject: RE: Indy SCSI Errors Date: Thu, 9 May 2002 09:31:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20020509154327.GB6197@paradigm.rfc822.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am familiar with the error that you are referring to. I just fixed it by upgrading to kernel 2.4.17. The error that I am describing, should I just ignore it and just do a fsck on my main drive every month? I have three drives sda1, sdb1, and sdc1 and it only seems to happened on the sda1. My sda2 is the swap drive, would that be affecting my sda1 ? Thanks, Rob. -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com] On Behalf Of Florian Lohoff Sent: Thursday, May 09, 2002 8:43 AM To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Indy SCSI Errors On Wed, May 08, 2002 at 10:23:18AM -0700, Robert Rusek wrote: > I am currently running kernel 2.4.17 and am getting sparatice errors > like the following. I seen that there had been bugs in the scsi > driver in the earlier kernel versions. Has anyone encountered this? > Is there a newer kernal that maybe addresses this? > > EXT2-fs error (device sd(8,1)): ext2_check_page: bad entry in > directory > #110030: unaligned > directory entry - offset=0, inode=6226015, rec_len=95, name_len=95 > The SCSI errors we had on the Indy and Indigo2 happened with multiple disks, disconnects and were pure "read" errors. Filesystem corruption was quite rare. Mostly we had file data corruption on copy. The bug is fixed for at least half a year now. Do you see any other errors than that ? SCSI errors ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. From owner-linux-mips@oss.sgi.com Thu May 9 09:38:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49GcjwJ003947 for ; Thu, 9 May 2002 09:38:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49GcjEm003946 for linux-mips-outgoing; Thu, 9 May 2002 09:38:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49GchwJ003943 for ; Thu, 9 May 2002 09:38:43 -0700 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 g49GeCsf011702 for ; Thu, 9 May 2002 09:40:12 -0700 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 g49GeBUo011698 for ; Thu, 9 May 2002 09:40:11 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 9 May 2002 09:40:11 -0700 (PDT) From: James Simmons To: linux-mips@oss.sgi.com Subject: Debian on Indy. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I just recently attempted to install debian on a new indy I just got. I entered the prom boot console and typed bootp()/tftpboot/tfptboot.img. It failed. What steps am I missing? . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ From owner-linux-mips@oss.sgi.com Thu May 9 10:08:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49H8LwJ004283 for ; Thu, 9 May 2002 10:08:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49H8LTx004282 for linux-mips-outgoing; Thu, 9 May 2002 10:08:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49H8HwJ004271 for ; Thu, 9 May 2002 10:08:18 -0700 Received: from excalibur.cologne.de (pD9E40480.dip.t-dialin.net [217.228.4.128]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA00470; Thu, 9 May 2002 19:09:42 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 175rZx-0000kF-00; Thu, 09 May 2002 19:19:45 +0200 Date: Thu, 9 May 2002 19:19:45 +0200 From: Karsten Merker To: James Simmons Cc: linux-mips@oss.sgi.com Subject: Re: Debian on Indy. Message-ID: <20020509191945.K1913@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , James Simmons , 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 jsimmons@transvirtual.com on Thu, May 09, 2002 at 09:40:11AM -0700 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 09, 2002 at 09:40:11AM -0700, James Simmons wrote: > > I just recently attempted to install debian on a new indy I just got. I > entered the prom boot console and typed bootp()/tftpboot/tfptboot.img. It > failed. What steps am I missing? Without more information on how it failed that is difficult to tell. Any logfile entries on the bootp/tftp server? Have you looked at http://www.linux-mips.org/technical_faq.html? There you can find a list of possible problems when netbooting an Indy. HTH, 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 Thu May 9 10:26:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49HQpwJ004621 for ; Thu, 9 May 2002 10:26:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49HQpU8004620 for linux-mips-outgoing; Thu, 9 May 2002 10:26:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.to11.net (adsl-64-173-206-186.dsl.renocs.nvbell.net [64.173.206.186]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49HQmwJ004617 for ; Thu, 9 May 2002 10:26:48 -0700 Received: from hmpiii2.trinity200.org (hmpiii2.trinity200.org [10.0.0.9]) by mail.to11.net (Postfix) with ESMTP id B2D98168C0; Thu, 9 May 2002 10:28:07 -0700 (PDT) Received: from hmpiii2.trinity200.org (tmoss@localhost [127.0.0.1]) by hmpiii2.trinity200.org (8.12.1/8.12.1/Debian -5) with ESMTP id g49HS6tc027163; Thu, 9 May 2002 10:28:06 -0700 Received: (from tmoss@localhost) by hmpiii2.trinity200.org (8.12.1/8.12.1/Debian -5) id g49HS51o027161; Thu, 9 May 2002 10:28:05 -0700 X-Authentication-Warning: hmpiii2.trinity200.org: tmoss set sender to mips@to11.net using -f Date: Thu, 9 May 2002 10:28:05 -0700 From: Tim Moss To: Karsten Merker Cc: James Simmons , linux-mips@oss.sgi.com Subject: Re: Debian on Indy. Message-ID: <20020509172805.GI23999@hmpiii2.trinity200.org> References: <20020509191945.K1913@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020509191945.K1913@excalibur.cologne.de> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Apparently, on Thu, May 09, 2002 at 07:19:45PM +0200, Karsten Merker wrote: > On Thu, May 09, 2002 at 09:40:11AM -0700, James Simmons wrote: > > > > I just recently attempted to install debian on a new indy I just got. I > > entered the prom boot console and typed bootp()/tftpboot/tfptboot.img. It > > failed. What steps am I missing? > > Without more information on how it failed that is difficult to tell. > Any logfile entries on the bootp/tftp server? > Have you looked at http://www.linux-mips.org/technical_faq.html? > There you can find a list of possible problems when netbooting an Indy. > http://ftp.debian.org/debian/dists/woody/main/disks-mips/current/doc/ch-install-methods.en.html#s-install-tftp In particular, make sure to set the two /proc settings on the tftp server: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_range From owner-linux-mips@oss.sgi.com Thu May 9 11:02:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g49I29wJ005105 for ; Thu, 9 May 2002 11:02:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g49I29aD005104 for linux-mips-outgoing; Thu, 9 May 2002 11:02:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g49I25wJ005101 for ; Thu, 9 May 2002 11:02:05 -0700 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 g49I3M7M018668; Thu, 9 May 2002 11:03:22 -0700 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 g49I3L7O018664; Thu, 9 May 2002 11:03:21 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 9 May 2002 11:03:21 -0700 (PDT) From: James Simmons To: Tim Moss cc: Karsten Merker , linux-mips@oss.sgi.com Subject: Re: Debian on Indy. In-Reply-To: <20020509172805.GI23999@hmpiii2.trinity200.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Apparently, on Thu, May 09, 2002 at 07:19:45PM +0200, Karsten Merker wrote: > > On Thu, May 09, 2002 at 09:40:11AM -0700, James Simmons wrote: > > > > > > I just recently attempted to install debian on a new indy I just got. I > > > entered the prom boot console and typed bootp()/tftpboot/tfptboot.img. It > > > failed. What steps am I missing? > > > > Without more information on how it failed that is difficult to tell. > > Any logfile entries on the bootp/tftp server? > > Have you looked at http://www.linux-mips.org/technical_faq.html? > > There you can find a list of possible problems when netbooting an Indy. > > > http://ftp.debian.org/debian/dists/woody/main/disks-mips/current/doc/ch-install-methods.en.html#s-install-tftp > > In particular, make sure to set the two /proc settings on the tftp > server: > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc > echo "2048 32767" > /proc/sys/net/ipv4/ip_local_port_ran Okay. Got it to boot. Now it fails with a bunch of SCSI errors. After it complained it hanged. Any ideas or do you need th exact SCSI errors? From owner-linux-mips@oss.sgi.com Fri May 10 02:31:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4A9VhwJ004946 for ; Fri, 10 May 2002 02:31:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4A9VhWP004945 for linux-mips-outgoing; Fri, 10 May 2002 02:31:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4A9VbwJ004942 for ; Fri, 10 May 2002 02:31:38 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id D0972859; Fri, 10 May 2002 11:33:10 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 1B66D3711E; Fri, 10 May 2002 11:32:32 +0200 (CEST) Date: Fri, 10 May 2002 11:32:32 +0200 From: Florian Lohoff To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Indy SCSI Errors Message-ID: <20020510093232.GD26862@paradigm.rfc822.org> References: <20020509154327.GB6197@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BRE3mIcgqKzpedwo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --BRE3mIcgqKzpedwo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2002 at 09:31:01AM -0700, Robert Rusek wrote: > I am familiar with the error that you are referring to. I just fixed it > by upgrading to kernel 2.4.17. The error that I am describing, should I > just ignore it and just do a fsck on my main drive every month? I have > three drives sda1, sdb1, and sdc1 and it only seems to happened on the > sda1. My sda2 is the swap drive, would that be affecting my sda1 ? If its not the error i fixed a couple of months ago i would suspect bad hardware - Either ram or disk. I wouldnt ignore it. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --BRE3mIcgqKzpedwo 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 iD8DBQE825OvUaz2rXW+gJcRAiUIAKCWJg5nyKpgCrjPUPx4oMhQiZSzJQCg0LWh +rzaob3+WxoLITCs9ckoBPU= =kNpc -----END PGP SIGNATURE----- --BRE3mIcgqKzpedwo-- From owner-linux-mips@oss.sgi.com Fri May 10 11:36:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4AIa6wJ013345 for ; Fri, 10 May 2002 11:36:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4AIa6kV013344 for linux-mips-outgoing; Fri, 10 May 2002 11:36:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4AIa2wJ013341 for ; Fri, 10 May 2002 11:36:02 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 67ABB8D35; Fri, 10 May 2002 20:37:37 +0200 (CEST) Date: Fri, 10 May 2002 20:37:37 +0200 From: Guido Guenther To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: howto pass ramdisk loaddress to kernel Message-ID: <20020510203737.A5410@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Florian Lohoff , linux-mips@oss.sgi.com References: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> <20020507104538.GB795@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: <20020507104538.GB795@paradigm.rfc822.org>; from flo@rfc822.org on Tue, May 07, 2002 at 12:45:38PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, On Tue, May 07, 2002 at 12:45:38PM +0200, Florian Lohoff wrote: > On Tue, May 07, 2002 at 12:32:49PM +0200, Guido Guenther wrote: > > My question is now: how do i properly pass the initrd's memory address > > to the kernel? Choices are: > > 1) on the commandline: rd_start=0x... > > 2) a bootparameter block like on i386 or sparc in head.S > > 3) rely on the kernel to identify if a radisk has > > been loaded by a magic number > > > > I'd prefer (1) but it seems none of the other arches does this. Is there > > a reason for that? If not could we just introduce a new kernel > > commandline parameter rd_start which has a memory address as a > > parameter. Ralf, would you let this into the kernel? > > I would do 1+3 - Give the address on the command line and let the ramdisk > have a magic + length in the first 2 __u32. I implemented (1) only since the kernel checks for a proper fs/gzip magic anyway. I added this to the kernels at: http://honk.physik.uni-konstanz.de/linux-mips/kernels/ Patch is at: http://honk.physik.uni-konstanz.de/linux-mips/kernel-patches/ramdisk-cmdline-2002-05-09.diff Regards, -- Guido From owner-linux-mips@oss.sgi.com Sat May 11 11:51:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4BIp9wJ027249 for ; Sat, 11 May 2002 11:51:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4BIp9P4027248 for linux-mips-outgoing; Sat, 11 May 2002 11:51:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4BIp2wJ027245 for ; Sat, 11 May 2002 11:51:03 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id BF60E857; Sat, 11 May 2002 20:52:41 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 2184E3711E; Sat, 11 May 2002 20:38:08 +0200 (CEST) Date: Sat, 11 May 2002 20:38:08 +0200 From: Florian Lohoff To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: howto pass ramdisk loaddress to kernel Message-ID: <20020511183808.GA7240@paradigm.rfc822.org> References: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> <20020507104538.GB795@paradigm.rfc822.org> <20020510203737.A5410@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <20020510203737.A5410@gandalf.physik.uni-konstanz.de> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 10, 2002 at 08:37:37PM +0200, Guido Guenther wrote: > > I would do 1+3 - Give the address on the command line and let the ramdi= sk > > have a magic + length in the first 2 __u32. > I implemented (1) only since the kernel checks for a proper fs/gzip > magic anyway. I added this to the kernels at: Ok ... > http://honk.physik.uni-konstanz.de/linux-mips/kernels/ > Patch is at: > http://honk.physik.uni-konstanz.de/linux-mips/kernel-patches/ramdisk-cmd= line-2002-05-09.diff I looked at the patch and it seems it does support all sub-archs - Is that correct ? BTW: When we boot with tip we might also compress the kernel as gzip. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --Qxx1br4bt0+wmkIi 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 iD8DBQE83WUPUaz2rXW+gJcRArAsAKCk5Kx40HzI3MA5S6nzrP36AUcW6wCffTY+ HBVCqaJi5RnkmpWkzkxHqbE= =TRin -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-linux-mips@oss.sgi.com Sat May 11 16:38:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4BNc2wJ029699 for ; Sat, 11 May 2002 16:38:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4BNc2kZ029698 for linux-mips-outgoing; Sat, 11 May 2002 16:38:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from postfix1-2.free.fr (postfix1-2.free.fr [213.228.0.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4BNbmwJ029692 for ; Sat, 11 May 2002 16:37:48 -0700 Received: from yak (lyon-2-a7-62-147-23-243.dial.proxad.net [62.147.23.243]) by postfix1-2.free.fr (Postfix) with SMTP id 229D0AB34D; Sun, 12 May 2002 01:04:27 +0200 (CEST) Message-ID: <007001c1f940$ba95b0c0$011e1ec0@home> From: "nsauzede" To: "James Simmons" Cc: References: Subject: Re: Debian on Indy. Date: Sun, 12 May 2002 01:08:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Okay. Got it to boot. Now it fails with a bunch of SCSI errors. After it > complained it hanged. Any ideas or do you need th exact SCSI errors? Just for info : I managed to have the Debian Woody to work fine on my Indy (kernel is 2.4.13 if I remember well...) But when I tried to boot some kernel 2.5.?? (can't remember last number -- I fetched the source from CVS) I cross compiled on an i386 platform, I got the same problem : bootup crashes at SCSI probing time... Must be some kind of SCSI code regression or something.. I think I already posted my problem to the list but didn't get reply.... Nicolas Sauzede. From owner-linux-mips@oss.sgi.com Sun May 12 06:34:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4CDY9wJ008353 for ; Sun, 12 May 2002 06:34:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4CDY9LD008352 for linux-mips-outgoing; Sun, 12 May 2002 06:34:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4CDY2wJ008349 for ; Sun, 12 May 2002 06:34:03 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id E5756853; Sun, 12 May 2002 15:35:44 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 29B363711E; Sun, 12 May 2002 15:35:15 +0200 (CEST) Date: Sun, 12 May 2002 15:35:15 +0200 From: Florian Lohoff To: nsauzede Cc: James Simmons , linux-mips@oss.sgi.com Subject: Re: Debian on Indy. Message-ID: <20020512133515.GA1091@paradigm.rfc822.org> References: <007001c1f940$ba95b0c0$011e1ec0@home> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <007001c1f940$ba95b0c0$011e1ec0@home> User-Agent: Mutt/1.3.28i 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 Sun, May 12, 2002 at 01:08:13AM +0200, nsauzede wrote: > Just for info : I managed to have the Debian Woody to work fine on my Indy > (kernel is 2.4.13 if I remember well...) >=20 > But when I tried to boot some kernel 2.5.?? (can't remember last number -= - I > fetched the source from CVS) I cross compiled on an i386 platform, I got = the > same problem : bootup crashes at SCSI probing time... >=20 > Must be some kind of SCSI code regression or something.. >=20 > I think I already posted my problem to the list but didn't get reply.... The problem is the major block device change in 2.5 - It is still not finished and needs more work in the individual drivers (IIRC the driver itself has to do some error handling). So the crash points to work to be done in the driver. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --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 iD8DBQE83m+SUaz2rXW+gJcRAh3KAJwIsn5zLbJVbEQA3DgvnjsZY+CNcQCfe1CK myEPAGDCWzVOaZSq6ksPWYk= =eBvU -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-linux-mips@oss.sgi.com Sun May 12 06:35:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4CDZmwJ008429 for ; Sun, 12 May 2002 06:35:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4CDZm5x008428 for linux-mips-outgoing; Sun, 12 May 2002 06:35:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4CDZgwJ008425 for ; Sun, 12 May 2002 06:35:42 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8A30F857; Sun, 12 May 2002 15:37:25 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 841B93711E; Sun, 12 May 2002 15:36:56 +0200 (CEST) Date: Sun, 12 May 2002 15:36:56 +0200 From: Florian Lohoff To: Krishna Kondaka Cc: linux-mips@oss.sgi.com Subject: Re: Is this a /proc or kernel bug? (more info...) Message-ID: <20020512133656.GB1091@paradigm.rfc822.org> References: <200205090328.g493SWH02942@icarus.sanera.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: <200205090328.g493SWH02942@icarus.sanera.net> User-Agent: Mutt/1.3.28i 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 Wed, May 08, 2002 at 08:28:32PM -0700, Krishna Kondaka wrote: > The above function works fine as long as the SIZE is lessthan 4K. If SIZE= is > greater than 4K then some times I see the following kernel panic when > I try to do "cat /proc/" >=20 > Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn,= line=20 > 373: > $0 : 00000000 10009f00 8f20802c 48494a4b > $4 : 8f320988 00000001 00000000 00000116 IIRC i386 has the same problem with reading more then a single page from=20 /proc. Retrieving more information should probably be a device driver with a char or block interface. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --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 iD8DBQE83m/4Uaz2rXW+gJcRAg1mAJ4phppOf7xRHdsfFJlWoPgduE0KKACfYywX pbJ3Dp4qfg/Nu6RwkGgN2BA= =0ZLb -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- From owner-linux-mips@oss.sgi.com Sun May 12 14:30:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4CLUIwJ013168 for ; Sun, 12 May 2002 14:30:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4CLUH6U013167 for linux-mips-outgoing; Sun, 12 May 2002 14:30:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4CLUDwJ013163 for ; Sun, 12 May 2002 14:30:13 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 4DFD18D35; Sun, 12 May 2002 23:31:52 +0200 (CEST) Date: Sun, 12 May 2002 23:31:52 +0200 From: Guido Guenther To: Florian Lohoff Cc: linux-mips@oss.sgi.com Subject: Re: howto pass ramdisk loaddress to kernel Message-ID: <20020512233152.A9766@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Florian Lohoff , linux-mips@oss.sgi.com References: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> <20020507104538.GB795@paradigm.rfc822.org> <20020510203737.A5410@gandalf.physik.uni-konstanz.de> <20020511183808.GA7240@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: <20020511183808.GA7240@paradigm.rfc822.org>; from flo@rfc822.org on Sat, May 11, 2002 at 08:38:08PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, May 11, 2002 at 08:38:08PM +0200, Florian Lohoff wrote: > On Fri, May 10, 2002 at 08:37:37PM +0200, Guido Guenther wrote: > > > I would do 1+3 - Give the address on the command line and let the ramdisk > > > have a magic + length in the first 2 __u32. > > I implemented (1) only since the kernel checks for a proper fs/gzip > > magic anyway. I added this to the kernels at: > > Ok ... > > > http://honk.physik.uni-konstanz.de/linux-mips/kernels/ > > Patch is at: > > http://honk.physik.uni-konstanz.de/linux-mips/kernel-patches/ramdisk-cmdline-2002-05-09.diff > > I looked at the patch and it seems it does support all sub-archs - Is that > correct ? It doesn't refer to any subarchitecture specific details so it can be used by any subarch, yes. > > BTW: When we boot with tip we might also compress the kernel as gzip. That's also on my todo list for arcboot/tip22 but I'd like to get bootfloppies fixed first. -- Guido From owner-linux-mips@oss.sgi.com Mon May 13 11:20:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIKenC006534 for ; Mon, 13 May 2002 11:20:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIKeW1006533 for linux-mips-outgoing; Mon, 13 May 2002 11:20:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DIK5nC006521 for ; Mon, 13 May 2002 11:20:05 -0700 Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) 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 HAA03874 for ; Mon, 13 May 2002 07:33:12 -0700 (PDT) mail_from (brad@ltc.com) Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 177Gl1-0000MI-00 for ; Mon, 13 May 2002 10:24:59 -0400 Message-ID: <006c01c1fa8a$68ad1910$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: Subject: Fw: Mips scalibility problems & softirq.c improvments Date: Mon, 13 May 2002 10:28:10 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0069_01C1FA68.E14F06C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C1FA68.E14F06C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "D.J. Barrow" To: "Kernel Mailing List" ; "Netfilter" Sent: Monday, May 13, 2002 6:12 AM Subject: Mips scalibility problems & softirq.c improvments > Hi, > While testing the SMP performance of iptables with a lot of rules on a mips based cpu, > I found that the SMP performance was 40% lower on 2 cpus than 1 cpu. > > There is a number of reasons for this the primary being that the rules were bigger > than the shared L2 cache, little enough can be done about this. > > The second is that interrupts are on every mips port I bothered checking > are only delivered on cpu 0 ( this is really pathetic ). > > > See the code that prints /proc/interrupts in arch/mips/kernel/irq.c > int get_irq_list(char *buf) > { > struct irqaction * action; > char *p = buf; > int i; > > p += sprintf(p, " "); > for (i=0; i < 1 /*smp_num_cpus*/; i++) > > Need I say more..... > > As softirqs are usually bound to the same > cpu that start the softirqs softirqs performs really really badly, > also the fact that the softirq.c code checks in_interrupt on > entry means that it frequently does a quick exit. > > > I also will be providing a patch I developed to the developers of a mips based > system on chip which distributes the irqs over all cpus using 2 polices > even interrupts to cpu 0 odd interrupts to cpu 1 or leaving the interrupts > enter in all cpus & only call do_IRQ on the cpu with the lowest local_irq_count > & local_bh_count this should cause softirqs to perform will on this > system anyway. > > > I've provided a small patch to irq.c which fixes /proc/interrupts in 2.4.18 mips32 > hopefully somebody will be kind enough to fix up the 64 bit & > the latest stuff in mips64 & the latest oss.sgi.com cvs trees. > > --- linux.orig/arch/mips/kernel/irq.c Sun Sep 9 18:43:01 2001 > +++ linux/arch/mips/kernel/irq.c Mon May 13 10:34:15 2002 > @@ -71,13 +71,13 @@ > > int get_irq_list(char *buf) > { > + int i, j; > struct irqaction * action; > char *p = buf; > - int i; > > p += sprintf(p, " "); > - for (i=0; i < 1 /*smp_num_cpus*/; i++) > - p += sprintf(p, "CPU%d ", i); > + for (j=0; j + p += sprintf(p, "CPU%d ",j); > *p++ = '\n'; > > for (i = 0 ; i < NR_IRQS ; i++) { > @@ -85,7 +85,13 @@ > if (!action) > continue; > p += sprintf(p, "%3d: ",i); > +#ifndef CONFIG_SMP > p += sprintf(p, "%10u ", kstat_irqs(i)); > +#else > + for (j = 0; j < smp_num_cpus; j++) > + p += sprintf(p, "%10u ", > + kstat.irqs[cpu_logical_map(j)][i]); > +#endif > p += sprintf(p, " %14s", irq_desc[i].handler->typename); > p += sprintf(p, " %s", action->name); > > @@ -93,7 +99,7 @@ > p += sprintf(p, ", %s", action->name); > *p++ = '\n'; > } > - p += sprintf(p, "ERR: %10lu\n", irq_err_count); > + p += sprintf(p, "ERR: %10u\n", atomic_read(&irq_err_count)); > return p - buf; > } > > > > I also provide a small patch for softirq.c which makes sure the > the softirqs stay running if in cpu_idle & no reschedule is pending. > This improves softirq.c performance a small bit as it usually exits > after calling each softirq once rather than staying in the loop > if it has nothing better to do. > > --- linux.old/kernel/softirq.c Tue Jan 15 04:13:43 2002 > +++ linux.new/kernel/softirq.c Thu May 9 12:36:46 2002 > @@ -95,7 +95,8 @@ > local_irq_disable(); > > pending = softirq_pending(cpu); > - if (pending & mask) { > + if ((pending && current==idle_task(cpu) && !current->need_resched ) > + || (pending & mask) ) { > mask &= ~pending; > goto restart; > } > diff -u -r linux.old/include/linux/sched.h linux.new/include/linux/sched.h > --- linux.old/include/linux/sched.h Thu May 9 18:08:42 2002 > +++ linux.new/include/linux/sched.h Thu May 9 10:30:34 2002 > @@ -936,6 +936,19 @@ > return res; > } > > +#ifdef CONFIG_SMP > + > +#define idle_task(cpu) (init_tasks[cpu_number_map(cpu)]) > +#define can_schedule(p,cpu) \ > + ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu)) > + > +#else > + > +#define idle_task(cpu) (&init_task) > +#define can_schedule(p,cpu) (1) > + > +#endif > + > #endif /* __KERNEL__ */ > > #endif > > diff -u -r linux.old/kernel/sched.c linux.new/kernel/sched.c > --- linux.old/kernel/sched.c Wed May 1 10:40:26 2002 > +++ linux.new/kernel/sched.c Thu May 9 10:30:26 2002 > @@ -112,18 +112,7 @@ > struct kernel_stat kstat; > extern struct task_struct *child_reaper; > > -#ifdef CONFIG_SMP > > -#define idle_task(cpu) (init_tasks[cpu_number_map(cpu)]) > -#define can_schedule(p,cpu) \ > - ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu)) > - > -#else > - > -#define idle_task(cpu) (&init_task) > -#define can_schedule(p,cpu) (1) > - > -#endif > > void scheduling_functions_start_here(void) { } > > > Also find the patches sent as attachments. > > > ===== > D.J. Barrow Linux kernel developer > eMail: dj_barrow@ariasoft.ie > Home: +353-22-47196. > Work: +353-91-758353 > > __________________________________________________ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com ------=_NextPart_000_0069_01C1FA68.E14F06C0 Content-Type: application/octet-stream; name="softirq_fix.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="softirq_fix.diff" --- linux.old/kernel/softirq.c Tue Jan 15 04:13:43 2002=0A= +++ linux.new/kernel/softirq.c Thu May 9 12:36:46 2002=0A= @@ -95,7 +95,8 @@=0A= local_irq_disable();=0A= =0A= pending =3D softirq_pending(cpu);=0A= - if (pending & mask) {=0A= + if ((pending && current=3D=3Didle_task(cpu) && !current->need_resched = )=0A= + || (pending & mask) ) {=0A= mask &=3D ~pending;=0A= goto restart;=0A= }=0A= diff -u -r linux.old/include/linux/sched.h = linux.new/include/linux/sched.h=0A= --- linux.old/include/linux/sched.h Thu May 9 18:08:42 2002=0A= +++ linux.new/include/linux/sched.h Thu May 9 10:30:34 2002=0A= @@ -936,6 +936,19 @@=0A= return res;=0A= }=0A= =0A= +#ifdef CONFIG_SMP=0A= +=0A= +#define idle_task(cpu) (init_tasks[cpu_number_map(cpu)])=0A= +#define can_schedule(p,cpu) \=0A= + ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu))=0A= +=0A= +#else=0A= +=0A= +#define idle_task(cpu) (&init_task)=0A= +#define can_schedule(p,cpu) (1)=0A= +=0A= +#endif=0A= +=0A= #endif /* __KERNEL__ */=0A= =0A= #endif=0A= =0A= diff -u -r linux.old/kernel/sched.c linux.new/kernel/sched.c=0A= --- linux.old/kernel/sched.c Wed May 1 10:40:26 2002=0A= +++ linux.new/kernel/sched.c Thu May 9 10:30:26 2002=0A= @@ -112,18 +112,7 @@=0A= struct kernel_stat kstat;=0A= extern struct task_struct *child_reaper;=0A= =0A= -#ifdef CONFIG_SMP=0A= =0A= -#define idle_task(cpu) (init_tasks[cpu_number_map(cpu)])=0A= -#define can_schedule(p,cpu) \=0A= - ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu))=0A= -=0A= -#else=0A= -=0A= -#define idle_task(cpu) (&init_task)=0A= -#define can_schedule(p,cpu) (1)=0A= -=0A= -#endif=0A= =0A= void scheduling_functions_start_here(void) { }=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ------=_NextPart_000_0069_01C1FA68.E14F06C0 Content-Type: application/octet-stream; name="mips32_irq.c_fix.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mips32_irq.c_fix.diff" --- linux.orig/arch/mips/kernel/irq.c Sun Sep 9 18:43:01 2001=0A= +++ linux/arch/mips/kernel/irq.c Mon May 13 10:34:15 2002=0A= @@ -71,13 +71,13 @@=0A= =0A= int get_irq_list(char *buf)=0A= {=0A= + int i, j;=0A= struct irqaction * action;=0A= char *p =3D buf;=0A= - int i;=0A= =0A= p +=3D sprintf(p, " ");=0A= - for (i=3D0; i < 1 /*smp_num_cpus*/; i++)=0A= - p +=3D sprintf(p, "CPU%d ", i);=0A= + for (j=3D0; jtypename);=0A= p +=3D sprintf(p, " %s", action->name);=0A= =0A= @@ -93,7 +99,7 @@=0A= p +=3D sprintf(p, ", %s", action->name);=0A= *p++ =3D '\n';=0A= }=0A= - p +=3D sprintf(p, "ERR: %10lu\n", irq_err_count);=0A= + p +=3D sprintf(p, "ERR: %10u\n", atomic_read(&irq_err_count));=0A= return p - buf;=0A= }=0A= =0A= ------=_NextPart_000_0069_01C1FA68.E14F06C0-- From owner-linux-mips@oss.sgi.com Mon May 13 11:22:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIMTnC006625 for ; Mon, 13 May 2002 11:22:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIMTTo006624 for linux-mips-outgoing; Mon, 13 May 2002 11:22:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DILZnC006581 for ; Mon, 13 May 2002 11:21:36 -0700 Received: from crisis.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) 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 HAA03690 for ; Mon, 13 May 2002 07:07:04 -0700 (PDT) mail_from (maz@misterjones.org) Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by crisis.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 177GMp-0003SP-00 for ; Mon, 13 May 2002 15:59:59 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.35 #1 (Debian)) id 177GOF-0004XY-00; Mon, 13 May 2002 16:01:27 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH] Basic Indigo-2 EISA support Organization: Metropolis -- Nowhere X-Attribution: maz X-Baby-1: =?iso-8859-1?q?Lo=EBn?= 12 juin 1996 13:10 X-Baby-2: None X-Love-1: Gone X-Love-2: Crazy-Cat Reply-to: maz@misterjones.org From: Marc Zyngier Date: 13 May 2002 16:01:27 +0200 Message-ID: Lines: 62 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-=-= Hi all, The included patch adds some very basic EISA support to the Indigo-2 (patch is against oss.sgi.com CVS from yesterday). It only supports PIO mode at the moment, and enabling CONFIG_ISA crashes the machine. Handle with care ! Anyway, I've been able to use an unmodified 3c509 driver (with a 3c579 card) on my 150MHz Indigo-2 for hours without problems : lazy:/home/maz# dmesg|tail -4 eth1: 3c5x9 at 0x3000, BNC port, address 00 20 af eb 79 a3, IRQ 10. 3c509.c:1.18a 17Nov2001becker@scyld.com http://www.scyld.com/network/3c509.html eth1: Setting Rx mode to 1 addresses. lazy:/home/maz# cat /proc/interrupts CPU0 10: 17556 IP22 EISA eth1 18: 0 MIPS local0 cascade 19: 0 MIPS local1 cascade 22: 0 MIPS Bus Error 23: 2534068 MIPS timer 25: 10615 IP22 local 0 SGI WD93 26: 7 IP22 local 0 SGI WD93 27: 32701 IP22 local 0 SGI Seeq8003 31: 0 IP22 local 0 mappable0 cascade 33: 0 IP22 local 1 Front Panel 43: 17556 IP22 local 2 IP22 EISA 44: 2 IP22 local 2 keyboard 45: 1402 IP22 local 2 Zilog8530 ERR: 0 Summary of changes : - Add 16 to all IRQ numbers, so we can insert EISA irq from 0 to 15 and keep existing drivers happy, - Set io_port_base to 0x80000, which is where the EISA bus lives on the IP22, - Swap 32bits accesses to the IO space (16bits IO are handled just fine... One more IP22 mystery), - Add arch/mips/sgi-ip22/ip22-eisa.c, which implements the eisa hw_interrupt_type, and programs the EIU in a mysterious way... - Add CONFIG_IP22_EISA configuration option. TODO : - Solve CONFIG_ISA crashes - Add DMA I'd be very happy if someone with EIU knowledge could enlight me with details about the magic bits in ip22_eisa_init()... I'd also be glad to receive any comment on this patch. Regards, M. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=eisa-irq.patch Content-Description: Indigo-2 Eisa patch Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.154.2.17 diff -u -r1.154.2.17 config.in --- arch/mips/config.in 2002/05/12 07:13:04 1.154.2.17 +++ arch/mips/config.in 2002/05/13 11:51:23 @@ -178,6 +178,7 @@ define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_SWAP_IO_SPACE y fi if [ "$CONFIG_SNI_RM200_PCI" = "y" ]; then define_bool CONFIG_ARC32 y @@ -447,6 +448,15 @@ tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC if [ "$CONFIG_MIPS_AU1000" = "y" ]; then dep_bool 'Power Management support (experimental)' CONFIG_PM $CONFIG_EXPERIMENTAL +fi + +if [ "$CONFIG_SGI_IP22" = "y" ]; then + bool 'Indigo-2 (IP22) EISA bus support' CONFIG_IP22_EISA +fi + +if [ "$CONFIG_IP22_EISA" = "y" ]; then +# define_bool CONFIG_ISA y + define_bool CONFIG_EISA y fi bool 'Networking support' CONFIG_NET Index: arch/mips/sgi-ip22/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/Makefile,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 Makefile --- arch/mips/sgi-ip22/Makefile 2001/12/07 15:45:29 1.1.2.1 +++ arch/mips/sgi-ip22/Makefile 2002/05/13 11:51:25 @@ -20,6 +20,8 @@ obj-y += ip22-mc.o ip22-sc.o ip22-hpc.o ip22-int.o ip22-time.o ip22-rtc.o \ ip22-irq.o ip22-system.o ip22-reset.o ip22-setup.o +obj-$(CONFIG_IP22_EISA) += ip22-eisa.o + ip22-irq.o: ip22-irq.S include $(TOPDIR)/Rules.make Index: arch/mips/sgi-ip22/ip22-int.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-int.c,v retrieving revision 1.2.2.1 diff -u -r1.2.2.1 ip22-int.c --- arch/mips/sgi-ip22/ip22-int.c 2001/12/19 18:23:48 1.2.2.1 +++ arch/mips/sgi-ip22/ip22-int.c 2002/05/13 11:51:26 @@ -41,6 +41,7 @@ extern asmlinkage void indyIRQ(void); extern void do_IRQ(int irq, struct pt_regs *regs); +extern int ip22_eisa_init (void); static void enable_local0_irq(unsigned int irq) { @@ -415,5 +416,9 @@ setup_irq(SGI_MAP_0_IRQ, &map0_cascade); #ifdef I_REALLY_NEED_THIS_IRQ setup_irq(SGI_MAP_1_IRQ, &map1_cascade); +#endif +#ifdef CONFIG_IP22_EISA + if (!sgi_guiness) /* Only Indigo-2 have EISA stuff */ + ip22_eisa_init (); #endif } Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.1.2.6 diff -u -r1.1.2.6 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 2002/05/12 07:25:39 1.1.2.6 +++ arch/mips/sgi-ip22/ip22-setup.c 2002/05/13 11:51:26 @@ -28,6 +28,7 @@ #include #include #include +#include #ifdef CONFIG_REMOTE_DEBUG extern void rs_kgdb_hook(int); @@ -146,6 +147,9 @@ /* Now enable boardcaches, if any. */ indy_sc_init(); + + /* Set the IO space to some sane value */ + set_io_port_base (KSEG1ADDR (0x00080000)); #ifdef CONFIG_SERIAL_CONSOLE /* ARCS console environment variable is set to "g?" for Index: include/asm-mips/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips/io.h,v retrieving revision 1.29.2.10 diff -u -r1.29.2.10 io.h --- include/asm-mips/io.h 2002/04/15 07:37:50 1.29.2.10 +++ include/asm-mips/io.h 2002/05/13 11:51:56 @@ -30,7 +30,13 @@ #if defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) #define __ioswab8(x) (x) +#ifdef CONFIG_SGI_IP22 +/* IP22 seems braindead enough to swap 16bits values in hardware, but + not 32bits. Go figure... Can't tell without documentation. */ +#define __ioswab16(x) (x) +#else #define __ioswab16(x) swab16(x) +#endif #define __ioswab32(x) swab32(x) #else Index: include/asm-mips/sgi/sgint23.h =================================================================== RCS file: /cvs/linux/include/asm-mips/sgi/sgint23.h,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 sgint23.h --- include/asm-mips/sgi/sgint23.h 2001/12/14 20:49:49 1.5.2.1 +++ include/asm-mips/sgi/sgint23.h 2002/05/13 11:51:59 @@ -21,12 +21,13 @@ * HAL2 driver). This will prevent many complications, trust me ;-) * --ladis */ -#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' */ +#define SGINT_EISA 0 /* INDIGO-2 has 16 EISA irq levels */ +#define SGINT_CPU 16 /* MIPS CPU define 8 interrupt sources */ +#define SGINT_LOCAL0 24 /* INDY has 8 local0 irq levels */ +#define SGINT_LOCAL1 32 /* INDY has 8 local1 irq levels */ +#define SGINT_LOCAL2 40 /* INDY has 8 local2 vectored irq levels */ +#define SGINT_LOCAL3 48 /* INDY has 8 local3 vectored irq levels */ +#define SGINT_END 56 /* End of 'spaces' */ /* * Individual interrupt definitions for the INDY and Indigo2 --- /dev/null Mon Mar 18 16:22:16 2002 +++ arch/mips/sgi-ip22/ip22-eisa.c Mon May 13 13:52:16 2002 @@ -0,0 +1,224 @@ +/* + * Basic EISA bus support for the SGI Indigo-2. + * + * (C) 2002 Pascal Dameme + * and Marc Zyngier + * + * This code is released under both the GPL version 2 and BSD + * licenses. Either license may be used. + * + * This code offers a very basic support for this EISA bus present in + * the SGI Indigo-2. It currently only supports PIO (forget about DMA + * for the time being). This is enough for a low-end ethernet card, + * but forget about your favorite SCSI card... + * + * TODO : + * - Fix bugs... + * - Add ISA support + * - Add DMA (yeah, right...). + * - Fix more bugs. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +extern int EISA_bus; +extern void do_IRQ(int irq, struct pt_regs *regs); + +#define EISA_MAX_IRQ 16 + +#define EISA_TO_PHYS(x) (0x00080000 | (x)) +#define EISA_TO_KSEG1(x) ((void *) KSEG1ADDR(EISA_TO_PHYS(x))) + +#define EIU_MODE_REG 0x0009ffc0 +#define EIU_STAT_REG 0x0009ffc4 +#define EIU_PREMPT_REG 0x0009ffc8 +#define EIU_QUIET_REG 0x0009ffcc +#define EIU_INTRPT_ACK 0x00090004 + +#define EISA_DMA1_STATUS 8 +#define EISA_INT1_CTRL 0x20 +#define EISA_INT1_MASK 0x21 +#define EISA_INT2_CTRL 0xA0 +#define EISA_INT2_MASK 0xA1 +#define EISA_DMA2_STATUS 0xD0 +#define EISA_DMA2_WRITE_SINGLE 0xD4 +#define EISA_EXT_NMI_RESET_CTRL 0x461 +#define EISA_INT1_EDGE_LEVEL 0x4D0 +#define EISA_INT2_EDGE_LEVEL 0x4D1 +#define EISA_VENDOR_ID_OFFSET 0xC80 + +#define EIU_WRITE_32(x,y) { *((u32 *) KSEG1ADDR(x)) = (u32) (y); mb (); } +#define EIU_READ_8(x) *((volatile u8 *) KSEG1ADDR(x)) +#define EISA_WRITE_8(x,y) { *((u8 *) EISA_TO_KSEG1(x)) = (u8) (y); mb(); } +#define EISA_READ_8(x) *((volatile u8 *) EISA_TO_KSEG1(x)) + +static void ip22_eisa_intr (int irq, void *dev_id, struct pt_regs *regs) +{ + u8 eisa_irq, dma1, dma2; + + eisa_irq = EIU_READ_8 (EIU_INTRPT_ACK); + dma1 = EISA_READ_8 (EISA_DMA1_STATUS); + dma2 = EISA_READ_8 (EISA_DMA2_STATUS); + + if (eisa_irq >= EISA_MAX_IRQ) + { + /* Oops, Bad Stuff Happened... */ + printk ("eisa_irq %d out of bound\n", eisa_irq); + + if (eisa_irq >= 8) + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); + + return; + } + + do_IRQ (eisa_irq, regs); +} + +static void enable_eisa_irq(unsigned int irq) +{ + unsigned long flags; + u8 mask1, mask2; + + save_and_cli(flags); + mask1 = EISA_READ_8 (EISA_INT1_MASK); + mask2 = EISA_READ_8 (EISA_INT2_MASK); + + if (irq < 8) + mask1 &= ~((u8) (1 << irq)); + else + { + mask1 &= ~((u8) (1 << 2)); /* Activate cascade */ + mask2 &= ~((u8) (1 << (irq - 8))); + } + + EISA_WRITE_8 (EISA_INT1_MASK, mask1); + EISA_WRITE_8 (EISA_INT2_MASK, mask2); + restore_flags(flags); +} + +static unsigned int startup_eisa_irq(unsigned int irq) +{ + u8 edge1, edge2; + + /* Only use edge interrupts for EISA */ + edge1 = EISA_READ_8 (EISA_INT1_EDGE_LEVEL); + edge2 = EISA_READ_8 (EISA_INT2_EDGE_LEVEL); + + if (irq < 8) + edge1 &= ~((u8) (1 << irq)); + else + edge2 &= ~((u8) (1 << (irq - 8))); + + EISA_WRITE_8 (EISA_INT2_EDGE_LEVEL, edge2); + EISA_WRITE_8 (EISA_INT1_EDGE_LEVEL, edge1); + + enable_eisa_irq(irq); + return 0; +} + +static void disable_eisa_irq(unsigned int irq) +{ + u8 mask1, mask2; + + mask1 = EISA_READ_8 (EISA_INT1_MASK); + mask2 = EISA_READ_8 (EISA_INT2_MASK); + + if (irq < 8) + mask1 |= ((u8) (1 << irq)); + else + { + mask2 |= ((u8) (1 << (irq - 8))); + if (mask2 == 0xff) + mask1 |= ((u8) (1 << 2)); + } + + EISA_WRITE_8 (EISA_INT1_MASK, mask1); + EISA_WRITE_8 (EISA_INT2_MASK, mask2); +} + +#define shutdown_eisa_irq disable_eisa_irq + +static void mask_and_ack_eisa_irq (unsigned int irq) +{ + disable_eisa_irq (irq); + + if (irq >= 8) + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); +} + +static void end_eisa_irq (unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) + enable_eisa_irq(irq); +} + +static struct hw_interrupt_type ip22_eisa_irq_type = +{ + "IP22 EISA", + startup_eisa_irq, + shutdown_eisa_irq, + enable_eisa_irq, + disable_eisa_irq, + mask_and_ack_eisa_irq, + end_eisa_irq, + NULL +}; + +static struct irqaction eisa_action = + { ip22_eisa_intr, 0, 0, "IP22 EISA", NULL, NULL }; + +int ip22_eisa_init (void) +{ + int i; + + /* Warning : BlackMagicAhead(tm). + Please wave your favorite dead chicken over the busses */ + + /* First say hello to the EIU */ + EIU_WRITE_32 (EIU_PREMPT_REG, 0x0000FFFF); + EIU_WRITE_32 (EIU_QUIET_REG, 1); + EIU_WRITE_32 (EIU_MODE_REG, 0x40f3c07F); + + /* Now be nice to the EISA chipset */ + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 1); + for (i = 0; i < 10000; i++); + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 0); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT2_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT1_MASK, 0); + EISA_WRITE_8 (EISA_INT2_MASK, 8); + EISA_WRITE_8 (EISA_INT1_MASK, 4); + EISA_WRITE_8 (EISA_INT2_MASK, 2); + EISA_WRITE_8 (EISA_INT1_MASK, 1); + EISA_WRITE_8 (EISA_INT2_MASK, 1); + EISA_WRITE_8 (EISA_INT1_MASK, 0xfb); + EISA_WRITE_8 (EISA_INT2_MASK, 0xff); + EISA_WRITE_8 (EISA_DMA2_WRITE_SINGLE, 0); + + for (i = SGINT_EISA; i < (SGINT_EISA + EISA_MAX_IRQ); i++) + { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = 0; + irq_desc[i].depth = 1; + irq_desc[i].handler = &ip22_eisa_irq_type; + } + + /* Cannot use request_irq because of kmalloc not being ready at such + * an early stage. Yes, I've been bitten... */ + setup_irq(SGI_EISA_IRQ, &eisa_action); + + EISA_bus = 1; + return 0; +} --=-=-= -- Places change, faces change. Life is so very strange. --=-=-=-- From owner-linux-mips@oss.sgi.com Mon May 13 11:22:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIMTnC006630 for ; Mon, 13 May 2002 11:22:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIMT5h006629 for linux-mips-outgoing; Mon, 13 May 2002 11:22:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DILZnE006581 for ; Mon, 13 May 2002 11:21:36 -0700 Received: from crisis.wild-wind.fr.eu.org (lopsy-lu.misterjones.org [62.4.18.26]) 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 HAA05122 for ; Mon, 13 May 2002 07:39:43 -0700 (PDT) mail_from (maz@misterjones.org) Received: from hina.wild-wind.fr.eu.org ([192.168.70.139]) by crisis.wild-wind.fr.eu.org with esmtp (Exim 3.35 #1 (Debian)) id 177GsY-0003UD-00 for ; Mon, 13 May 2002 16:32:46 +0200 Received: from maz by hina.wild-wind.fr.eu.org with local (Exim 3.35 #1 (Debian)) id 177Gty-0004Y6-00; Mon, 13 May 2002 16:34:14 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH] Basic Indigo-2 EISA support Organization: Metropolis -- Nowhere X-Attribution: maz X-Baby-1: =?iso-8859-1?q?Lo=EBn?= 12 juin 1996 13:10 X-Baby-2: None X-Love-1: Gone X-Love-2: Crazy-Cat Reply-to: mzyngier@freesurf.fr From: Marc Zyngier Date: 13 May 2002 16:34:14 +0200 Message-ID: Lines: 62 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-=-= Hi all, The included patch adds some very basic EISA support to the Indigo-2 (patch is against oss.sgi.com CVS from yesterday). It only supports PIO mode at the moment, and enabling CONFIG_ISA crashes the machine. Handle with care ! Anyway, I've been able to use an unmodified 3c509 driver (with a 3c579 card) on my 150MHz Indigo-2 for hours without problems : lazy:/home/maz# dmesg|tail -4 eth1: 3c5x9 at 0x3000, BNC port, address 00 20 af eb 79 a3, IRQ 10. 3c509.c:1.18a 17Nov2001becker@scyld.com http://www.scyld.com/network/3c509.html eth1: Setting Rx mode to 1 addresses. lazy:/home/maz# cat /proc/interrupts CPU0 10: 17556 IP22 EISA eth1 18: 0 MIPS local0 cascade 19: 0 MIPS local1 cascade 22: 0 MIPS Bus Error 23: 2534068 MIPS timer 25: 10615 IP22 local 0 SGI WD93 26: 7 IP22 local 0 SGI WD93 27: 32701 IP22 local 0 SGI Seeq8003 31: 0 IP22 local 0 mappable0 cascade 33: 0 IP22 local 1 Front Panel 43: 17556 IP22 local 2 IP22 EISA 44: 2 IP22 local 2 keyboard 45: 1402 IP22 local 2 Zilog8530 ERR: 0 Summary of changes : - Add 16 to all IRQ numbers, so we can insert EISA irq from 0 to 15 and keep existing drivers happy, - Set io_port_base to 0x80000, which is where the EISA bus lives on the IP22, - Swap 32bits accesses to the IO space (16bits IO are handled just fine... One more IP22 mystery), - Add arch/mips/sgi-ip22/ip22-eisa.c, which implements the eisa hw_interrupt_type, and programs the EIU in a mysterious way... - Add CONFIG_IP22_EISA configuration option. TODO : - Solve CONFIG_ISA crashes - Add DMA I'd be very happy if someone with EIU knowledge could enlight me with details about the magic bits in ip22_eisa_init()... I'd also be glad to receive any comment on this patch. Regards, M. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=eisa-irq.patch Content-Description: Indigo-2 Eisa patch Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.154.2.17 diff -u -r1.154.2.17 config.in --- arch/mips/config.in 2002/05/12 07:13:04 1.154.2.17 +++ arch/mips/config.in 2002/05/13 11:51:23 @@ -178,6 +178,7 @@ define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_NONCOHERENT_IO y + define_bool CONFIG_SWAP_IO_SPACE y fi if [ "$CONFIG_SNI_RM200_PCI" = "y" ]; then define_bool CONFIG_ARC32 y @@ -447,6 +448,15 @@ tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC if [ "$CONFIG_MIPS_AU1000" = "y" ]; then dep_bool 'Power Management support (experimental)' CONFIG_PM $CONFIG_EXPERIMENTAL +fi + +if [ "$CONFIG_SGI_IP22" = "y" ]; then + bool 'Indigo-2 (IP22) EISA bus support' CONFIG_IP22_EISA +fi + +if [ "$CONFIG_IP22_EISA" = "y" ]; then +# define_bool CONFIG_ISA y + define_bool CONFIG_EISA y fi bool 'Networking support' CONFIG_NET Index: arch/mips/sgi-ip22/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/Makefile,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 Makefile --- arch/mips/sgi-ip22/Makefile 2001/12/07 15:45:29 1.1.2.1 +++ arch/mips/sgi-ip22/Makefile 2002/05/13 11:51:25 @@ -20,6 +20,8 @@ obj-y += ip22-mc.o ip22-sc.o ip22-hpc.o ip22-int.o ip22-time.o ip22-rtc.o \ ip22-irq.o ip22-system.o ip22-reset.o ip22-setup.o +obj-$(CONFIG_IP22_EISA) += ip22-eisa.o + ip22-irq.o: ip22-irq.S include $(TOPDIR)/Rules.make Index: arch/mips/sgi-ip22/ip22-int.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-int.c,v retrieving revision 1.2.2.1 diff -u -r1.2.2.1 ip22-int.c --- arch/mips/sgi-ip22/ip22-int.c 2001/12/19 18:23:48 1.2.2.1 +++ arch/mips/sgi-ip22/ip22-int.c 2002/05/13 11:51:26 @@ -41,6 +41,7 @@ extern asmlinkage void indyIRQ(void); extern void do_IRQ(int irq, struct pt_regs *regs); +extern int ip22_eisa_init (void); static void enable_local0_irq(unsigned int irq) { @@ -415,5 +416,9 @@ setup_irq(SGI_MAP_0_IRQ, &map0_cascade); #ifdef I_REALLY_NEED_THIS_IRQ setup_irq(SGI_MAP_1_IRQ, &map1_cascade); +#endif +#ifdef CONFIG_IP22_EISA + if (!sgi_guiness) /* Only Indigo-2 have EISA stuff */ + ip22_eisa_init (); #endif } Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.1.2.6 diff -u -r1.1.2.6 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 2002/05/12 07:25:39 1.1.2.6 +++ arch/mips/sgi-ip22/ip22-setup.c 2002/05/13 11:51:26 @@ -28,6 +28,7 @@ #include #include #include +#include #ifdef CONFIG_REMOTE_DEBUG extern void rs_kgdb_hook(int); @@ -146,6 +147,9 @@ /* Now enable boardcaches, if any. */ indy_sc_init(); + + /* Set the IO space to some sane value */ + set_io_port_base (KSEG1ADDR (0x00080000)); #ifdef CONFIG_SERIAL_CONSOLE /* ARCS console environment variable is set to "g?" for Index: include/asm-mips/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips/io.h,v retrieving revision 1.29.2.10 diff -u -r1.29.2.10 io.h --- include/asm-mips/io.h 2002/04/15 07:37:50 1.29.2.10 +++ include/asm-mips/io.h 2002/05/13 11:51:56 @@ -30,7 +30,13 @@ #if defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) #define __ioswab8(x) (x) +#ifdef CONFIG_SGI_IP22 +/* IP22 seems braindead enough to swap 16bits values in hardware, but + not 32bits. Go figure... Can't tell without documentation. */ +#define __ioswab16(x) (x) +#else #define __ioswab16(x) swab16(x) +#endif #define __ioswab32(x) swab32(x) #else Index: include/asm-mips/sgi/sgint23.h =================================================================== RCS file: /cvs/linux/include/asm-mips/sgi/sgint23.h,v retrieving revision 1.5.2.1 diff -u -r1.5.2.1 sgint23.h --- include/asm-mips/sgi/sgint23.h 2001/12/14 20:49:49 1.5.2.1 +++ include/asm-mips/sgi/sgint23.h 2002/05/13 11:51:59 @@ -21,12 +21,13 @@ * HAL2 driver). This will prevent many complications, trust me ;-) * --ladis */ -#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' */ +#define SGINT_EISA 0 /* INDIGO-2 has 16 EISA irq levels */ +#define SGINT_CPU 16 /* MIPS CPU define 8 interrupt sources */ +#define SGINT_LOCAL0 24 /* INDY has 8 local0 irq levels */ +#define SGINT_LOCAL1 32 /* INDY has 8 local1 irq levels */ +#define SGINT_LOCAL2 40 /* INDY has 8 local2 vectored irq levels */ +#define SGINT_LOCAL3 48 /* INDY has 8 local3 vectored irq levels */ +#define SGINT_END 56 /* End of 'spaces' */ /* * Individual interrupt definitions for the INDY and Indigo2 --- /dev/null Mon Mar 18 16:22:16 2002 +++ arch/mips/sgi-ip22/ip22-eisa.c Mon May 13 13:52:16 2002 @@ -0,0 +1,224 @@ +/* + * Basic EISA bus support for the SGI Indigo-2. + * + * (C) 2002 Pascal Dameme + * and Marc Zyngier + * + * This code is released under both the GPL version 2 and BSD + * licenses. Either license may be used. + * + * This code offers a very basic support for this EISA bus present in + * the SGI Indigo-2. It currently only supports PIO (forget about DMA + * for the time being). This is enough for a low-end ethernet card, + * but forget about your favorite SCSI card... + * + * TODO : + * - Fix bugs... + * - Add ISA support + * - Add DMA (yeah, right...). + * - Fix more bugs. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +extern int EISA_bus; +extern void do_IRQ(int irq, struct pt_regs *regs); + +#define EISA_MAX_IRQ 16 + +#define EISA_TO_PHYS(x) (0x00080000 | (x)) +#define EISA_TO_KSEG1(x) ((void *) KSEG1ADDR(EISA_TO_PHYS(x))) + +#define EIU_MODE_REG 0x0009ffc0 +#define EIU_STAT_REG 0x0009ffc4 +#define EIU_PREMPT_REG 0x0009ffc8 +#define EIU_QUIET_REG 0x0009ffcc +#define EIU_INTRPT_ACK 0x00090004 + +#define EISA_DMA1_STATUS 8 +#define EISA_INT1_CTRL 0x20 +#define EISA_INT1_MASK 0x21 +#define EISA_INT2_CTRL 0xA0 +#define EISA_INT2_MASK 0xA1 +#define EISA_DMA2_STATUS 0xD0 +#define EISA_DMA2_WRITE_SINGLE 0xD4 +#define EISA_EXT_NMI_RESET_CTRL 0x461 +#define EISA_INT1_EDGE_LEVEL 0x4D0 +#define EISA_INT2_EDGE_LEVEL 0x4D1 +#define EISA_VENDOR_ID_OFFSET 0xC80 + +#define EIU_WRITE_32(x,y) { *((u32 *) KSEG1ADDR(x)) = (u32) (y); mb (); } +#define EIU_READ_8(x) *((volatile u8 *) KSEG1ADDR(x)) +#define EISA_WRITE_8(x,y) { *((u8 *) EISA_TO_KSEG1(x)) = (u8) (y); mb(); } +#define EISA_READ_8(x) *((volatile u8 *) EISA_TO_KSEG1(x)) + +static void ip22_eisa_intr (int irq, void *dev_id, struct pt_regs *regs) +{ + u8 eisa_irq, dma1, dma2; + + eisa_irq = EIU_READ_8 (EIU_INTRPT_ACK); + dma1 = EISA_READ_8 (EISA_DMA1_STATUS); + dma2 = EISA_READ_8 (EISA_DMA2_STATUS); + + if (eisa_irq >= EISA_MAX_IRQ) + { + /* Oops, Bad Stuff Happened... */ + printk ("eisa_irq %d out of bound\n", eisa_irq); + + if (eisa_irq >= 8) + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); + + return; + } + + do_IRQ (eisa_irq, regs); +} + +static void enable_eisa_irq(unsigned int irq) +{ + unsigned long flags; + u8 mask1, mask2; + + save_and_cli(flags); + mask1 = EISA_READ_8 (EISA_INT1_MASK); + mask2 = EISA_READ_8 (EISA_INT2_MASK); + + if (irq < 8) + mask1 &= ~((u8) (1 << irq)); + else + { + mask1 &= ~((u8) (1 << 2)); /* Activate cascade */ + mask2 &= ~((u8) (1 << (irq - 8))); + } + + EISA_WRITE_8 (EISA_INT1_MASK, mask1); + EISA_WRITE_8 (EISA_INT2_MASK, mask2); + restore_flags(flags); +} + +static unsigned int startup_eisa_irq(unsigned int irq) +{ + u8 edge1, edge2; + + /* Only use edge interrupts for EISA */ + edge1 = EISA_READ_8 (EISA_INT1_EDGE_LEVEL); + edge2 = EISA_READ_8 (EISA_INT2_EDGE_LEVEL); + + if (irq < 8) + edge1 &= ~((u8) (1 << irq)); + else + edge2 &= ~((u8) (1 << (irq - 8))); + + EISA_WRITE_8 (EISA_INT2_EDGE_LEVEL, edge2); + EISA_WRITE_8 (EISA_INT1_EDGE_LEVEL, edge1); + + enable_eisa_irq(irq); + return 0; +} + +static void disable_eisa_irq(unsigned int irq) +{ + u8 mask1, mask2; + + mask1 = EISA_READ_8 (EISA_INT1_MASK); + mask2 = EISA_READ_8 (EISA_INT2_MASK); + + if (irq < 8) + mask1 |= ((u8) (1 << irq)); + else + { + mask2 |= ((u8) (1 << (irq - 8))); + if (mask2 == 0xff) + mask1 |= ((u8) (1 << 2)); + } + + EISA_WRITE_8 (EISA_INT1_MASK, mask1); + EISA_WRITE_8 (EISA_INT2_MASK, mask2); +} + +#define shutdown_eisa_irq disable_eisa_irq + +static void mask_and_ack_eisa_irq (unsigned int irq) +{ + disable_eisa_irq (irq); + + if (irq >= 8) + EISA_WRITE_8 (EISA_INT2_CTRL, 0x20); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x20); +} + +static void end_eisa_irq (unsigned int irq) +{ + if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) + enable_eisa_irq(irq); +} + +static struct hw_interrupt_type ip22_eisa_irq_type = +{ + "IP22 EISA", + startup_eisa_irq, + shutdown_eisa_irq, + enable_eisa_irq, + disable_eisa_irq, + mask_and_ack_eisa_irq, + end_eisa_irq, + NULL +}; + +static struct irqaction eisa_action = + { ip22_eisa_intr, 0, 0, "IP22 EISA", NULL, NULL }; + +int ip22_eisa_init (void) +{ + int i; + + /* Warning : BlackMagicAhead(tm). + Please wave your favorite dead chicken over the busses */ + + /* First say hello to the EIU */ + EIU_WRITE_32 (EIU_PREMPT_REG, 0x0000FFFF); + EIU_WRITE_32 (EIU_QUIET_REG, 1); + EIU_WRITE_32 (EIU_MODE_REG, 0x40f3c07F); + + /* Now be nice to the EISA chipset */ + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 1); + for (i = 0; i < 10000; i++); + EISA_WRITE_8 (EISA_EXT_NMI_RESET_CTRL, 0); + EISA_WRITE_8 (EISA_INT1_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT2_CTRL, 0x11); + EISA_WRITE_8 (EISA_INT1_MASK, 0); + EISA_WRITE_8 (EISA_INT2_MASK, 8); + EISA_WRITE_8 (EISA_INT1_MASK, 4); + EISA_WRITE_8 (EISA_INT2_MASK, 2); + EISA_WRITE_8 (EISA_INT1_MASK, 1); + EISA_WRITE_8 (EISA_INT2_MASK, 1); + EISA_WRITE_8 (EISA_INT1_MASK, 0xfb); + EISA_WRITE_8 (EISA_INT2_MASK, 0xff); + EISA_WRITE_8 (EISA_DMA2_WRITE_SINGLE, 0); + + for (i = SGINT_EISA; i < (SGINT_EISA + EISA_MAX_IRQ); i++) + { + irq_desc[i].status = IRQ_DISABLED; + irq_desc[i].action = 0; + irq_desc[i].depth = 1; + irq_desc[i].handler = &ip22_eisa_irq_type; + } + + /* Cannot use request_irq because of kmalloc not being ready at such + * an early stage. Yes, I've been bitten... */ + setup_irq(SGI_EISA_IRQ, &eisa_action); + + EISA_bus = 1; + return 0; +} --=-=-= -- Places change, faces change. Life is so very strange. --=-=-=-- From owner-linux-mips@oss.sgi.com Mon May 13 11:33:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DIXQnC006993 for ; Mon, 13 May 2002 11:33:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DIXQL9006992 for linux-mips-outgoing; Mon, 13 May 2002 11:33:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DIXInC006989 for ; Mon, 13 May 2002 11:33:18 -0700 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g4DIXW006620; Mon, 13 May 2002 11:33:32 -0700 Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g4DIXRT21466; Mon, 13 May 2002 11:33:27 -0700 Message-Id: <200205131833.g4DIXRT21466@icarus.sanera.net> Date: Mon, 13 May 2002 11:33:27 -0700 (PDT) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Re: Is this a /proc or kernel bug? (more info...) To: flo@rfc822.org Cc: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jKWVtFz27WkEbVsnIesOKA== 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 reply florian! I think I was able to fix this problem by writing the code differently. Initially I copied some code from the existing proc_read routines but they are assuming a maximum of page size, in this case 4K. I have modified the my proc read code as below, and it seem to work fine! static int mydriver_proc_read(char *page, char **start, off_t off, int count, int *eof void *d) { uint32_t pos, len, i; len = MIN(count, (SIZE-off)); pos = (off & (PAGE_SIZE-1)); if (len > 0) { for (i = 0; i < len; i++) page[pos+i] = ' ' + i % 64; *start = page + (off & (PAGE_SIZE-1)); } else { len = 0; *eof = 0; } } I am assuming that (off & (PAGE_SIZE-1)) + count <= PAGE_SIZE, which seems to be the case always during my testing. Krishna >X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs >X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f >Date: Sun, 12 May 2002 15:36:56 +0200 >From: Florian Lohoff >To: Krishna Kondaka >Cc: linux-mips@oss.sgi.com >Subject: Re: Is this a /proc or kernel bug? (more info...) >Mime-Version: 1.0 >Content-Disposition: inline >User-Agent: Mutt/1.3.28i > >On Wed, May 08, 2002 at 08:28:32PM -0700, Krishna Kondaka wrote: >> The above function works fine as long as the SIZE is lessthan 4K. If SIZE is >> greater than 4K then some times I see the following kernel panic when >> I try to do "cat /proc/" >> >> Unhandled kernel unaligned access in unaligned.c:emulate_load_store_insn, line >> 373: >> $0 : 00000000 10009f00 8f20802c 48494a4b >> $4 : 8f320988 00000001 00000000 00000116 > >IIRC i386 has the same problem with reading more then a single page from >/proc. > >Retrieving more information should probably be a device driver with >a char or block interface. > >Flo >-- >Florian Lohoff flo@rfc822.org +49-5201-669912 > Heisenberg may have been here. From owner-linux-mips@oss.sgi.com Mon May 13 14:53:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4DLrAnC014952 for ; Mon, 13 May 2002 14:53:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4DLrA5D014951 for linux-mips-outgoing; Mon, 13 May 2002 14:53:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4DLr8nC014948 for ; Mon, 13 May 2002 14:53:08 -0700 Received: from whrrusek (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4DLrSn03080 for ; Mon, 13 May 2002 14:53:28 -0700 From: "Robert Rusek" To: Subject: dump/Restore issues on Indy Date: Mon, 13 May 2002 14:53:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am having problems doing a restore after a dump. The dump finishes without any problems. I get an invalid header when doing a restore. When I use tar it works great so I know that it is not a hardware problem. I have compiled the lates dump/restore and ef2progs. Any help would be greatly appreciated. -- Robert Rusek From owner-linux-mips@oss.sgi.com Mon May 13 18:02:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E12knC003325 for ; Mon, 13 May 2002 18:02:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E12kd0003324 for linux-mips-outgoing; Mon, 13 May 2002 18:02:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E12inC003317 for ; Mon, 13 May 2002 18:02:44 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA04326; Mon, 13 May 2002 18:02:56 -0700 Message-ID: <3CE061E0.8000909@mvista.com> Date: Mon, 13 May 2002 18:01:20 -0700 From: Jun Sun 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@oss.sgi.com Subject: deleted /dev/zero Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I am running some stress tests (such as ltp, netperf, lmbench, etc) on the SMP swarm board. Once in a while I notice /dev/zero will get deleted. This causes all kinds of weired problems (such as internal gcc error. Why?) I don't know how to re-produce this problem yet. It seems a little non-deterministic. I would appreciate any insight into this problem. Jun From owner-linux-mips@oss.sgi.com Mon May 13 18:18:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E1IunC003745 for ; Mon, 13 May 2002 18:18:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E1Iuvp003743 for linux-mips-outgoing; Mon, 13 May 2002 18:18:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E1InnC003740 for ; Mon, 13 May 2002 18:18:51 -0700 Received: from agile.tv (tugun.oz.agile.tv [192.168.16.20]) by surfers.oz.agile.tv (8.11.6/8.11.2) with ESMTP id g4E1J0E13875; Tue, 14 May 2002 11:19:00 +1000 Message-ID: <3CE06604.2050800@agile.tv> Date: Tue, 14 May 2002 11:19:00 +1000 From: Liam Davies Reply-To: ldavies@agile.tv Organization: AgileTV Corporation User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: deleted /dev/zero References: <3CE061E0.8000909@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > > I don't know how to re-produce this problem yet. It seems a little > non-deterministic. I would appreciate any insight into this problem. The ltp mtest05 test had a bug in which it would remove /dev/zero when it cleaned up. Have you got an updated ltp suite? This is the fix that they did in late March to the mtest05 test. /ltp/ltp/testcases/kernel/mem/mtest05/mmstress.c:246 - if (strcmp(filename, "NULL") || strcmp(filename, "/dev/zero")) + if (strcmp(filename, "NULL") && strcmp(filename, "/dev/zero")) I suppose that there may be other LTP tests that could have similar bugs... Cheers Liam From owner-linux-mips@oss.sgi.com Mon May 13 18:29:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E1TsnC003934 for ; Mon, 13 May 2002 18:29:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E1Tss0003933 for linux-mips-outgoing; Mon, 13 May 2002 18:29:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E1TnnC003929 for ; Mon, 13 May 2002 18:29:49 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id SAA04718; Mon, 13 May 2002 18:29:55 -0700 Message-ID: <3CE06833.60104@mvista.com> Date: Mon, 13 May 2002 18:28:19 -0700 From: Jun Sun 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: ldavies@agile.tv CC: linux-mips@oss.sgi.com Subject: Re: deleted /dev/zero References: <3CE061E0.8000909@mvista.com> <3CE06604.2050800@agile.tv> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Thanks. I am using an old version of ltp, and I still see the bug there. Jun Liam Davies wrote: > Jun Sun wrote: > >> >> I don't know how to re-produce this problem yet. It seems a little >> non-deterministic. I would appreciate any insight into this problem. > > > > The ltp mtest05 test had a bug in which it would remove /dev/zero when > it cleaned up. Have you got an updated ltp suite? > > This is the fix that they did in late March to the mtest05 test. > > /ltp/ltp/testcases/kernel/mem/mtest05/mmstress.c:246 > - if (strcmp(filename, "NULL") || strcmp(filename, "/dev/zero")) > + if (strcmp(filename, "NULL") && strcmp(filename, "/dev/zero")) > > I suppose that there may be other LTP tests that could have similar > bugs... > > > Cheers > Liam > > > > From owner-linux-mips@oss.sgi.com Mon May 13 19:35:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E2ZSnC005203 for ; Mon, 13 May 2002 19:35:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E2ZSoh005202 for linux-mips-outgoing; Mon, 13 May 2002 19:35:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E2ZCnC005198; Mon, 13 May 2002 19:35:12 -0700 Received: from av.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 TAA04482; Mon, 13 May 2002 19:35:25 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id TAA05413; Mon, 13 May 2002 19:19:28 -0700 Message-ID: <3CE073D0.8030402@mvista.com> Date: Mon, 13 May 2002 19:17:52 -0700 From: Jun Sun 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: ralf@oss.sgi.com CC: linux-mips@oss.sgi.com Subject: [PATCH] gettimeoffset for swarm Content-Type: multipart/mixed; boundary="------------020401010503040805090101" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------020401010503040805090101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit By default, swarm will use calibrate_div64_gettimeoffset(). That does not work in SMP mode because the two cores have different counter register value. This patch gives swarm its own and accurate gettimeoffset(). The symptom without this patch is that cpu core 1 does not have micro-second resolution of gettimeofday(). It applies to 2.4 branch with 1 or 2 line offset warnings. It does not apply to 2.5 branch. 2.5 branch appears to be outdated. http://linux.junsun.net/patches/oss.sgi.com/submitted/020515.swarm-own-gettimeoffset.patch Jun --------------020401010503040805090101 Content-Type: text/plain; name="020515.swarm-own-gettimeoffset.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="020515.swarm-own-gettimeoffset.patch" By default, swarm will use calibrate_div64_gettimeoffset(). That does not work in SMP mode because the two cores have different counter register value. This patch gives swarm its own and accurate gettimeoffset(). The symptom without this patch is that cpu core 1 does not have micro-second resolution of gettimeofday(). Jun diff -Nru linux/arch/mips/sibyte/sb1250/time.c.orig linux/arch/mips/sibyte/sb1250/time.c --- linux/arch/mips/sibyte/sb1250/time.c.orig Tue Apr 30 17:29:25 2002 +++ linux/arch/mips/sibyte/sb1250/time.c Fri May 10 14:53:39 2002 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include @@ -107,3 +108,19 @@ */ ll_local_timer_interrupt(0, regs); } + +/* + * We use our own do_gettimeoffset() instead of the generic one, + * because the generic one does not work for SMP case. + * In addition, since we use general timer 0 for system time, + * we can get accurate intra-jiffy offset without calibration. + */ +unsigned long sb1250_gettimeoffset(void) +{ + unsigned long count = + in64(KSEG1 + A_SCD_TIMER_REGISTER(0, R_SCD_TIMER_CNT)); + + db_assert(count <= 1000000 / HZ); + return 1000000/HZ - count; +} + diff -Nru linux/arch/mips/sibyte/swarm/setup.c.orig linux/arch/mips/sibyte/swarm/setup.c --- linux/arch/mips/sibyte/swarm/setup.c.orig Tue Apr 30 17:38:09 2002 +++ linux/arch/mips/sibyte/swarm/setup.c Fri May 10 14:54:36 2002 @@ -237,12 +237,15 @@ * interrupts through low-level (direct) meachanism. */ + /* Use our own gettimeoffset() routine */ + do_gettimeoffset = sb1250_gettimeoffset; + /* We only need to setup the generic timer */ sb1250_time_init(); } extern int xicor_set_time(unsigned long); -extern unsigned int xicor_get_time(void); +extern unsigned long xicor_get_time(void); void __init swarm_setup(void) { diff -Nru linux/include/asm-mips/sibyte/sb1250.h.orig linux/include/asm-mips/sibyte/sb1250.h --- linux/include/asm-mips/sibyte/sb1250.h.orig Tue Jan 15 13:25:45 2002 +++ linux/include/asm-mips/sibyte/sb1250.h Fri May 10 14:51:50 2002 @@ -20,6 +20,7 @@ #define _ASM_SIBYTE_SB1250_H extern void sb1250_time_init(void); +extern unsigned long sb1250_gettimeoffset(void); extern void sb1250_mask_irq(int cpu, int irq); extern void sb1250_unmask_irq(int cpu, int irq); extern void sb1250_smp_finish(void); diff -Nru linux/include/asm-mips64/sibyte/sb1250.h.orig linux/include/asm-mips64/sibyte/sb1250.h --- linux/include/asm-mips64/sibyte/sb1250.h.orig Tue Apr 30 17:30:44 2002 +++ linux/include/asm-mips64/sibyte/sb1250.h Fri May 10 14:52:16 2002 @@ -20,6 +20,7 @@ #define _ASM_SIBYTE_SB1250_H extern void sb1250_time_init(void); +extern unsigned long sb1250_gettimeoffset(void); extern void sb1250_mask_irq(int cpu, int irq); extern void sb1250_unmask_irq(int cpu, int irq); extern void sb1250_smp_finish(void); --------------020401010503040805090101-- From owner-linux-mips@oss.sgi.com Tue May 14 02:26:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4E9QVnC016071 for ; Tue, 14 May 2002 02:26:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4E9QUel016070 for linux-mips-outgoing; Tue, 14 May 2002 02:26:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E9QOnC016040 for ; Tue, 14 May 2002 02:26:24 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) 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 CAA03372 for ; Tue, 14 May 2002 02:26:33 -0700 (PDT) mail_from (Geert.Uytterhoeven@sonycom.com) Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA16262; Tue, 14 May 2002 11:15:05 +0200 (MET DST) Date: Tue, 14 May 2002 11:15:04 +0200 (MEST) From: Geert Uytterhoeven To: Robert Rusek cc: Linux/MIPS Development Subject: Re: dump/Restore issues on Indy 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, 13 May 2002, Robert Rusek wrote: > I am having problems doing a restore after a dump. The dump finishes > without any problems. I get an invalid header when doing a restore. > When I use tar it works great so I know that it is not a hardware > problem. I have compiled the lates dump/restore and ef2progs. Probably not related to the problem, but using dump on Linux (>= 2.4.x) is unsafe due to the way the buffer cache works. 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 May 14 06:02:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ED2QnC022351 for ; Tue, 14 May 2002 06:02:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ED2QUT022350 for linux-mips-outgoing; Tue, 14 May 2002 06:02:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ED2KnC022335 for ; Tue, 14 May 2002 06:02:22 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA01844; Tue, 14 May 2002 15:02:39 +0200 (MET DST) Date: Tue, 14 May 2002 15:02:38 +0200 (MET DST) From: "Maciej W. Rozycki" To: ldavies@agile.tv cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: deleted /dev/zero In-Reply-To: <3CE06604.2050800@agile.tv> 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, 14 May 2002, Liam Davies wrote: > The ltp mtest05 test had a bug in which it would remove /dev/zero when > it cleaned up. Have you got an updated ltp suite? > > This is the fix that they did in late March to the mtest05 test. > > /ltp/ltp/testcases/kernel/mem/mtest05/mmstress.c:246 > - if (strcmp(filename, "NULL") || strcmp(filename, "/dev/zero")) > + if (strcmp(filename, "NULL") && strcmp(filename, "/dev/zero")) > > I suppose that there may be other LTP tests that could have similar > bugs... Which only proves again one shouldn't run software as root unless absolutely needed... -- + 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 May 14 06:18:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EDIunC027162 for ; Tue, 14 May 2002 06:18:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EDIuXj027161 for linux-mips-outgoing; Tue, 14 May 2002 06:18:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4EDIonC027151; Tue, 14 May 2002 06:18:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA02245; Tue, 14 May 2002 15:18:50 +0200 (MET DST) Date: Tue, 14 May 2002 15:18:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: [PATCH] gettimeoffset for swarm In-Reply-To: <3CE073D0.8030402@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, 13 May 2002, Jun Sun wrote: > By default, swarm will use calibrate_div64_gettimeoffset(). That does > not work in SMP mode because the two cores have different counter register > value. This patch gives swarm its own and accurate gettimeoffset(). You may consider synchronising the counters as it's done for the i386, instead. See synchronize_tsc_ap(). It may be useful for other purposes 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 Tue May 14 10:55:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EHtAnC007114 for ; Tue, 14 May 2002 10:55:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4EHtA5d007113 for linux-mips-outgoing; Tue, 14 May 2002 10:55:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4EHt8nC007109 for ; Tue, 14 May 2002 10:55:08 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4EHtVM30814 for linux-mips@oss.sgi.com; Tue, 14 May 2002 10:55:31 -0700 Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4E9PnnC015919 for ; Tue, 14 May 2002 02:25:49 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id A36701E458; Tue, 14 May 2002 11:26:05 +0200 (MEST) Date: Tue, 14 May 2002 11:26:05 +0200 (CEST) From: Adrian Schroeter Reply-To: Adrian Schroeter To: linux-mips@oss.sgi.com Cc: ralf@gnu.org, Michael Schroeder Subject: sgiarcs_con generic SGI console driver Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168484352-2043690147-1021368365=:14912" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168484352-2043690147-1021368365=:14912 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Michael Schroeder has written a console driver that only uses functions from the ARCS prom and therefore should work on all SGIs. The disadvantage is that it is not very fast and it needs the RAM area reserved for the PROM. But you'll get a nice console on IMPACT machines and other. enjoy, adrian ********************************************************************** Adrian Schroeter SuSE AG, Deutschherrnstr. 15-19, 90429 Nuernberg, Germany email: adrian@suse.de (296 mails already received today.) --168484352-2043690147-1021368365=:14912 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sgiarcs_patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: sgiarcs.dif Content-Disposition: attachment; filename=sgiarcs_patch LS0tIC4vYXJjaC9taXBzL2FyYy9hcmNfY29uLmMub3JpZwkyMDAyLTA1LTEx IDE3OjE3OjA2LjAwMDAwMDAwMCArMDIwMA0KKysrIC4vYXJjaC9taXBzL2Fy Yy9hcmNfY29uLmMJMjAwMi0wNS0xMSAxNzoxNzowOC4wMDAwMDAwMDAgKzAy MDANCkBAIC0zNSw4ICszNSwxMSBAQA0KIAlyZXR1cm4gcHJvbV9nZXRjaGFy KCk7DQogfQ0KIA0KK2V4dGVybiBpbnQgcHJvbV9tZW1vcnlfZnJlZWQ7DQor DQogc3RhdGljIGludCBfX2luaXQgcHJvbV9jb25zb2xlX3NldHVwKHN0cnVj dCBjb25zb2xlICpjbywgY2hhciAqb3B0aW9ucykNCiB7DQorCXByb21fbWVt b3J5X2ZyZWVkID0gLTE7CQkvKiBuZWVkZWQgZm9yIHByb20gZnVuY3Rpb25z ICovDQogCXJldHVybiAwOw0KIH0NCiANCi0tLSAuL2FyY2gvbWlwcy9jb25m aWcuaW4ub3JpZwkyMDAyLTA1LTExIDE5OjA5OjU5LjAwMDAwMDAwMCArMDIw MA0KKysrIC4vYXJjaC9taXBzL2NvbmZpZy5pbgkyMDAyLTA1LTExIDE5OjM4 OjU3LjAwMDAwMDAwMCArMDIwMA0KQEAgLTU5MCw3ICs1OTAsOCBAQA0KICAg IGNvbW1lbnQgJ1NHSSBDaGFyYWN0ZXIgZGV2aWNlcycNCiAgICBpZiBbICIk Q09ORklHX1ZUIiA9ICJ5IiBdOyB0aGVuDQogICAgICAgdHJpc3RhdGUgJ1NH SSBOZXdwb3J0IENvbnNvbGUgc3VwcG9ydCcgQ09ORklHX1NHSV9ORVdQT1JU X0NPTlNPTEUNCi0gICAgICBpZiBbICIkQ09ORklHX1NHSV9ORVdQT1JUX0NP TlNPTEUiID0gInkiIF07IHRoZW4NCisgICAgICB0cmlzdGF0ZSAnU0dJIEFS Q1MgQ29uc29sZSBzdXBwb3J0JyBDT05GSUdfU0dJX0FSQ1NfQ09OU09MRQ0K KyAgICAgIGlmIFsgIiRDT05GSUdfU0dJX05FV1BPUlRfQ09OU09MRSIgPSAi eSIgLW8gIiRDT05GSUdfU0dJX0FSQ1NfQ09OU09MRSIgPSAieSIgXTsgdGhl bg0KIAkgZGVmaW5lX2Jvb2wgQ09ORklHX0ZPTlRfOHgxNiB5DQogICAgICAg ZmkNCiAgICAgICBkZWZpbmVfYm9vbCBDT05GSUdfRFVNTVlfQ09OU09MRSB5 DQotLS0gLi9hcmNoL21pcHMvbW0vaW5pdC5jLm9yaWcJMjAwMi0wNS0xMSAx NzoxNToyMi4wMDAwMDAwMDAgKzAyMDANCisrKyAuL2FyY2gvbWlwcy9tbS9p bml0LmMJMjAwMi0wNS0xMSAxNzoxNTo0Ny4wMDAwMDAwMDAgKzAyMDANCkBA IC0zNjAsMTEgKzM2MCwxNiBAQA0KIGV4dGVybiBjaGFyIF9faW5pdF9iZWdp biwgX19pbml0X2VuZDsNCiBleHRlcm4gdm9pZCBwcm9tX2ZyZWVfcHJvbV9t ZW1vcnkodm9pZCk7DQogDQoraW50CXByb21fbWVtb3J5X2ZyZWVkOw0KKw0K IHZvaWQgZnJlZV9pbml0bWVtKHZvaWQpDQogew0KIAl1bnNpZ25lZCBsb25n IGFkZHI7DQogDQotCXByb21fZnJlZV9wcm9tX21lbW9yeSAoKTsNCisJaWYg KHByb21fbWVtb3J5X2ZyZWVkID09IDApIHsNCisJCXByb21fZnJlZV9wcm9t X21lbW9yeSAoKTsNCisJCXByb21fbWVtb3J5X2ZyZWVkID0gMTsNCisJfQ0K ICAgICANCiAJYWRkciA9ICh1bnNpZ25lZCBsb25nKSAmX19pbml0X2JlZ2lu Ow0KIAl3aGlsZSAoYWRkciA8ICh1bnNpZ25lZCBsb25nKSAmX19pbml0X2Vu ZCkgew0KLS0tIC4vYXJjaC9taXBzL3NnaS1pcDIyL2lwMjItbWMuYy5vcmln CTIwMDItMDUtMTMgMjE6NTk6MzcuMDAwMDAwMDAwICswMjAwDQorKysgLi9h cmNoL21pcHMvc2dpLWlwMjIvaXAyMi1tYy5jCTIwMDItMDUtMTMgMjI6NTc6 MzAuMDAwMDAwMDAwICswMjAwDQpAQCAtMTYyLDMgKzE2Miw4IEBADQogCX0N CiAJbWNtaXNjX3JlZ3MtPmdpb3Bhcm0gPSB0bXByZWc7IC8qIHBvb2YgKi8N CiB9DQorDQordm9pZA0KK3NnaW1jX2V4cDA2NCgpIHsNCisJbWNtaXNjX3Jl Z3MtPmdpb3Bhcm0gfD0gU0dJTUNfR0lPUEFSTV9FWFAwNjQ7DQorfQ0KLS0t IC4vYXJjaC9taXBzL3NnaS1pcDIyL2lwMjItc2V0dXAuYy5vcmlnCTIwMDIt MDUtMTEgMTY6NTk6NDMuMDAwMDAwMDAwICswMjAwDQorKysgLi9hcmNoL21p cHMvc2dpLWlwMjIvaXAyMi1zZXR1cC5jCTIwMDItMDUtMTMgMjM6MjY6Mzku MDAwMDAwMDAwICswMjAwDQpAQCAtMTI0LDYgKzEyNCwyNiBAQA0KIHsNCiB9 DQogDQorc3RydWN0IHNnaV9wcm9tZ2Z4aW5mbyBzZ2lfcHJvbWdmeGluZm87 DQorc3RydWN0IHNnaV9wcm9tZ2Z4ICpzZ2lfcHJvbWdmeDsNCisNCitzdGF0 aWMgdm9pZCBzZ2lfZ2V0Z2Z4aW5mbyh2b2lkKQ0KK3sNCisJc3RydWN0IHNn aV9wdmVjdG9yICpwdmVjdG9yID0gKFBST01CTE9DSyktPnB2ZWN0b3I7DQor CXNnaV9wcm9tZ2Z4ID0gQVJDX0NBTEwwX1ZFQyhwdmVjdG9yLCBnZXRfcHJv bWdmeCk7DQorCWlmIChzZ2lfcHJvbWdmeCAmJiBzZ2lfcHJvbWdmeC0+Z2Z4 YWRkcikgew0KKwkJLyogd2UgY29weSBzb21lIGZpZWxkcyBpbnRvIHNnaV9w cm9tZ2Z4aW5mbyBzbyB0aGF0DQorCQkgKiB3ZSBoYXZlIHRoZSBpbmZvIGV2 ZW4gaWYgdGhlIHByb20gZGF0YSBpcyBmcmVlZC4NCisJCSAqLw0KKwkJc2dp X3Byb21nZnhpbmZvLmFkZHIgPSBzZ2lfcHJvbWdmeC0+Z2Z4YWRkcjsNCisJ CXNnaV9wcm9tZ2Z4aW5mby53aWR0aCA9IHNnaV9wcm9tZ2Z4LT53aWR0aDsN CisJCXNnaV9wcm9tZ2Z4aW5mby5oZWlnaHQgPSBzZ2lfcHJvbWdmeC0+aGVp Z2h0Ow0KKwl9DQorCS8qIGltcGFjdCBncmFwaGljcyBzZWVtcyB0byBuZWVk IEVYUDA2NCAqLw0KKwlpZiAoc2dpX3Byb21nZnhpbmZvLmFkZHIgPT0gMHhi ZjQwMDAwMCkNCisJCXNnaW1jX2V4cDA2NCgpOw0KK30NCisNCiB2b2lkIF9f aW5pdCBpcDIyX3NldHVwKHZvaWQpDQogew0KICNpZmRlZiBDT05GSUdfU0VS SUFMX0NPTlNPTEUNCkBAIC0xNDIsNiArMTYyLDcgQEANCiAJLyogSW5pdCBJ TkRZIG1lbW9yeSBjb250cm9sbGVyLiAqLw0KIAlzZ2ltY19pbml0KCk7DQog DQorCXNnaV9nZXRnZnhpbmZvKCk7DQogCS8qIE5vdyBlbmFibGUgYm9hcmRj YWNoZXMsIGlmIGFueS4gKi8NCiAJaW5keV9zY19pbml0KCk7DQogDQpAQCAt MTg2LDEwICsyMDcsMTEgQEANCiAgDQogCXNnaV92b2x1bWVfc2V0KHNpbXBs ZV9zdHJ0b3VsKEFyY0dldEVudmlyb25tZW50VmFyaWFibGUoInZvbHVtZSIp LCBOVUxMLCAxMCkpOw0KIA0KKwlzZ2lfZ2V0Z2Z4aW5mbygpOw0KICNpZmRl ZiBDT05GSUdfVlQNCisJY29uc3dpdGNocCA9IDA7DQogI2lmZGVmIENPTkZJ R19TR0lfTkVXUE9SVF9DT05TT0xFDQotCWlmKCBtaXBzX21hY2h0eXBlID09 IE1BQ0hfU0dJX0lORFkgKSB7DQotCQljb25zd2l0Y2hwID0gJm5ld3BvcnRf Y29uOw0KKwlpZiAoc2dpX3Byb21nZnhpbmZvLmFkZHIgPT0gMHhiZjBmMDAw MCB8fCBzZ2lfcHJvbWdmeGluZm8uYWRkciA9PSAweGJmNGYwMDAwKSB7DQog DQogCQlzY3JlZW5faW5mbyA9IChzdHJ1Y3Qgc2NyZWVuX2luZm8pIHsNCiAJ CQkwLCAwLAkJLyogb3JpZy14LCBvcmlnLXkgKi8NCkBAIC0yMDIsMTIgKzIy NCwyOCBAQA0KIAkJCTAsCQkvKiBvcmlnX3ZpZGVvX2lzVkdBICovDQogCQkJ MTYJCS8qIG9yaWdfdmlkZW9fcG9pbnRzICovDQogCQl9Ow0KLQl9IGVsc2Ug ew0KLQkJY29uc3dpdGNocCA9ICZkdW1teV9jb247DQorCQljb25zd2l0Y2hw ID0gJm5ld3BvcnRfY29uOw0KKwl9DQorI2VuZGlmDQorI2lmZGVmIENPTkZJ R19TR0lfQVJDU19DT05TT0xFDQorCWlmICghY29uc3dpdGNocCAmJiBzZ2lf cHJvbWdmeGluZm8uYWRkcikgew0KKwkJZXh0ZXJuIGNvbnN0IHN0cnVjdCBj b25zdyBzZ2lhcmNzX2NvbjsNCisJCXNjcmVlbl9pbmZvID0gKHN0cnVjdCBz Y3JlZW5faW5mbykgew0KKwkJCTAsIDAsCQkvKiBvcmlnLXgsIG9yaWcteSAq Lw0KKwkJCTAsCQkvKiB1bnVzZWQgKi8NCisJCQkwLAkJLyogb3JpZ192aWRl b19wYWdlICovDQorCQkJMCwJCS8qIG9yaWdfdmlkZW9fbW9kZSAqLw0KKwkJ CTE2MCwJCS8qIG9yaWdfdmlkZW9fY29scyAqLw0KKwkJCTAsIDAsIDAsCS8q IHVudXNlZCwgZWdhX2J4LCB1bnVzZWQgKi8NCisJCQk2NCwJCS8qIG9yaWdf dmlkZW9fbGluZXMgKi8NCisJCQkwLAkJLyogb3JpZ192aWRlb19pc1ZHQSAq Lw0KKwkJCTE2CQkvKiBvcmlnX3ZpZGVvX3BvaW50cyAqLw0KKwkJfTsNCisJ CWNvbnN3aXRjaHAgPSAmc2dpYXJjc19jb247DQogCX0NCi0jZWxzZQ0KLQlj b25zd2l0Y2hwID0gJmR1bW15X2NvbjsNCiAjZW5kaWYNCisJaWYgKGNvbnN3 aXRjaHAgPT0gMCkNCisJCWNvbnN3aXRjaHAgPT0gJmR1bW15X2NvbjsNCiAj ZW5kaWYNCiANCiAJcnRjX29wcyA9ICZpbmR5X3J0Y19vcHM7DQotLS0gLi9k cml2ZXJzL3ZpZGVvL01ha2VmaWxlLm9yaWcJMjAwMi0wNS0xMSAxODo1Nzox My4wMDAwMDAwMDAgKzAyMDANCisrKyAuL2RyaXZlcnMvdmlkZW8vTWFrZWZp bGUJMjAwMi0wNS0xMSAxODo1Nzo0NC4wMDAwMDAwMDAgKzAyMDANCkBAIC0y MSw2ICsyMSw3IEBADQogDQogb2JqLSQoQ09ORklHX0RVTU1ZX0NPTlNPTEUp ICAgICAgICs9IGR1bW15Y29uLm8NCiBvYmotJChDT05GSUdfU0dJX05FV1BP UlRfQ09OU09MRSkgKz0gbmV3cG9ydF9jb24ubw0KK29iai0kKENPTkZJR19T R0lfQVJDU19DT05TT0xFKSAgICArPSBzZ2lhcmNzX2Nvbi5vDQogb2JqLSQo Q09ORklHX1BST01fQ09OU09MRSkgICAgICAgICs9IHByb21jb24ubyBwcm9t Y29uX3RibC5vDQogb2JqLSQoQ09ORklHX1NUSV9DT05TT0xFKSAgICAgICAg ICs9IHN0aWNvbi5vIHN0aWNvbi1ibW9kZS5vIHN0aWNvcmUubw0KIG9iai0k KENPTkZJR19WR0FfQ09OU09MRSkgICAgICAgICArPSB2Z2Fjb24ubw0KLS0t IC4vZHJpdmVycy92aWRlby9zZ2lhcmNzX2Nvbi5jLm9yaWcJMjAwMi0wNS0x MSAxNzoxOTo1MS4wMDAwMDAwMDAgKzAyMDANCisrKyAuL2RyaXZlcnMvdmlk ZW8vc2dpYXJjc19jb24uYwkyMDAyLTA1LTEzIDIzOjI4OjUyLjAwMDAwMDAw MCArMDIwMA0KQEAgLTAsMCArMSw2MjcgQEANCisvKg0KKyAqIHNnaWFyY3Nf Y29uLmM6IGdlbmVyaWMgY29uc29sZSBmb3IgU0dJIEFSQ1Mgc3lzdGVtcw0K KyAqIA0KKyAqIChDKSAyMDAyIE1pY2hhZWwgU2Nocm9lZGVyIChtbHNAc3Vz ZS5kZSkNCisgKiANCisgKiBBZHZhbnRhZ2VzOg0KKyAqICAtIHNob3VsZCB3 b3JrIG9uIGV2ZXJ5IFNHSSB3aXRoIEFSQ1MgcHJvbQ0KKyAqIERpc2FkdmFu dGFnZXM6DQorICogIC0gaXMgc2xvdw0KKyAqICAtIG5lZWRzIHByb20gbWVt b3J5IGJsb2NrDQorICoNCisgKiBTb21lIGNvZGUgc3RvbGVuIGZyb20gZmJj b24uYyBhbmQgbmV3cG9ydF9jb24uYw0KKyAqLw0KKw0KKyNpbmNsdWRlIDxs aW51eC9pbml0Lmg+DQorI2luY2x1ZGUgPGxpbnV4L2tlcm5lbC5oPg0KKyNp bmNsdWRlIDxsaW51eC9lcnJuby5oPg0KKyNpbmNsdWRlIDxsaW51eC90dHku aD4NCisjaW5jbHVkZSA8bGludXgva2QuaD4NCisjaW5jbHVkZSA8bGludXgv c2VsZWN0aW9uLmg+DQorI2luY2x1ZGUgPGxpbnV4L2NvbnNvbGUuaD4NCisj aW5jbHVkZSA8bGludXgvY29uc29sZV9zdHJ1Y3QuaD4NCisjaW5jbHVkZSA8 bGludXgvdnRfa2Vybi5oPg0KKyNpbmNsdWRlIDxsaW51eC9tbS5oPg0KKyNp bmNsdWRlIDxsaW51eC9tb2R1bGUuaD4NCisjaW5jbHVkZSA8bGludXgvc2xh Yi5oPg0KKyNpbmNsdWRlIDxhc20vc2dpYXJjcy5oPg0KKyNpbmNsdWRlIDxh c20vYmNhY2hlLmg+DQorDQorI2lmbmRlZiBDT05GSUdfU0dJX05FV1BPUlRf Q09OU09MRQ0KKyMgZGVmaW5lIElOQ0xVREVfTElOVVhfTE9HT19EQVRBDQor I2VuZGlmDQorI2luY2x1ZGUgPGFzbS9saW51eF9sb2dvLmg+DQorDQorI2lu Y2x1ZGUgPHZpZGVvL2ZvbnQuaD4NCisNCisjZGVmaW5lIExPR09fVwkJODAN CisjZGVmaW5lIExPR09fSAkJODANCisNCitleHRlcm4gc3RydWN0IGZiY29u X2ZvbnRfZGVzYyBmb250X3ZnYV84eDE2Ow0KKw0KKyNkZWZpbmUgRk9OVF9E QVRBICgodW5zaWduZWQgY2hhciAqKWZvbnRfdmdhXzh4MTYuZGF0YSkNCisN CisvKiBib3Jyb3dlZCBmcm9tIGZiY29uLmMgKi8NCisjZGVmaW5lIFJFRkNP VU5UKGZkKQkoKChpbnQgKikoZmQpKVstMV0pDQorI2RlZmluZSBGTlRTSVpF KGZkKQkoKChpbnQgKikoZmQpKVstMl0pDQorI2RlZmluZSBGTlRDSEFSQ05U KGZkKQkoKChpbnQgKikoZmQpKVstM10pDQorI2RlZmluZSBGT05UX0VYVFJB X1dPUkRTIDMNCisNCitzdGF0aWMgdW5zaWduZWQgY2hhciAqZm9udF9kYXRh W01BWF9OUl9DT05TT0xFU107DQorDQorc3RhdGljIGludCBsb2dvX2FjdGl2 ZTsNCisNCitleHRlcm4gc3RydWN0IHNnaV9wcm9tZ2Z4ICpzZ2lfcHJvbWdm eDsNCitleHRlcm4gaW50IHByb21fbWVtb3J5X2ZyZWVkOw0KKw0KK2V4dGVy biB2b2lkIHNnaV9ocGM2NF9yZXN0b3JlKHZvaWQpLCBzZ2lfaHBjNjRfb2Zm KHZvaWQpOw0KKw0KKyNkZWZpbmUgU0dJR0ZYVkVDVE9SICgoc3RydWN0IHNn aV9nZnh2ZWN0b3IgKilzZ2lfcHJvbWdmeC0+Z2Z4dmVjdG9yKQ0KKyNkZWZp bmUgU0dJQVJDU19DQUxMMChmdW5jKQkJQVJDX0NBTEwxX1ZFQyhTR0lHRlhW RUNUT1IsIGZ1bmMsIHNnaV9wcm9tZ2Z4LT5nZnhhZGRyKQ0KKyNkZWZpbmUg U0dJQVJDU19DQUxMMShmdW5jLGExKQkJQVJDX0NBTEwyX1ZFQyhTR0lHRlhW RUNUT1IsIGZ1bmMsIHNnaV9wcm9tZ2Z4LT5nZnhhZGRyLCBhMSkNCisjZGVm aW5lIFNHSUFSQ1NfQ0FMTDIoZnVuYyxhMSxhMikJQVJDX0NBTEwzX1ZFQyhT R0lHRlhWRUNUT1IsIGZ1bmMsIHNnaV9wcm9tZ2Z4LT5nZnhhZGRyLCBhMSwg YTIpDQorI2RlZmluZSBTR0lBUkNTX0NBTEwzKGZ1bmMsYTEsYTIsYTMpCUFS Q19DQUxMNF9WRUMoU0dJR0ZYVkVDVE9SLCBmdW5jLCBzZ2lfcHJvbWdmeC0+ Z2Z4YWRkciwgYTEsIGEyLCBhMykNCisjZGVmaW5lIFNHSUFSQ1NfQ0FMTDQo ZnVuYyxhMSxhMixhMyxhNCkJQVJDX0NBTEw1X1ZFQyhTR0lHRlhWRUNUT1Is IGZ1bmMsIHNnaV9wcm9tZ2Z4LT5nZnhhZGRyLCBhMSwgYTIsIGEzLCBhNCkN CisNCisjZGVmaW5lIFNHSUFSQ1NfU1RBUlQoZmxhZ3MpCQlkbyB7c2F2ZV9h bmRfY2xpKGZsYWdzKTtiY19kaXNhYmxlKCk7fSB3aGlsZSAoMCkNCisjZGVm aW5lIFNHSUFSQ1NfRU5EKGZsYWdzKQkJZG8ge2JjX2VuYWJsZSgpO3Jlc3Rv cmVfZmxhZ3MoZmxhZ3MpO30gd2hpbGUgKDApDQorDQorI2RlZmluZSBDVVJT T1JfRFJBV19ERUxBWSAgICAgICAgICAgICAgICgxKQ0KKyNkZWZpbmUgREVG QVVMVF9DVVJTT1JfQkxJTktfUkFURSAgICAgICAoMjApDQorDQorc3RhdGlj IGludCBjdXJzb3JfZHJhd247DQorc3RhdGljIGludCB2YmxfY3Vyc29yX2Nu dDsNCitzdGF0aWMgaW50IGN1cnNvcl9vbjsNCitzdGF0aWMgaW50IGN1cnNv cl9ibGlua19yYXRlOw0KK3N0YXRpYyBpbnQgY3Vyc29yX3g7DQorc3RhdGlj IGludCBjdXJzb3JfeTsNCisNCitzdGF0aWMgaW5saW5lIHZvaWQgY3Vyc29y X3VuZHJhd24odm9pZCkNCit7DQorICAgIHZibF9jdXJzb3JfY250ID0gMDsN CisgICAgY3Vyc29yX2RyYXduID0gMDsNCit9DQorDQorc3RhdGljIHZvaWQg Y3Vyc29yX3RpbWVyX2hhbmRsZXIodW5zaWduZWQgbG9uZyBkZXZfYWRkcik7 DQorc3RhdGljIHZvaWQgZmJjb25fdmJsX2hhbmRsZXIoaW50IGlycSwgdm9p ZCAqZHVtbXksIHN0cnVjdCBwdF9yZWdzICpmcCk7DQorDQorc3RhdGljIHN0 cnVjdCB0aW1lcl9saXN0IGN1cnNvcl90aW1lciA9IHsNCisgICAgZnVuY3Rp b246IGN1cnNvcl90aW1lcl9oYW5kbGVyDQorfTsNCisNCitzdGF0aWMgdm9p ZCBjdXJzb3JfdGltZXJfaGFuZGxlcih1bnNpZ25lZCBsb25nIGRldl9hZGRy KQ0KK3sNCisgICAgICBmYmNvbl92YmxfaGFuZGxlcigwLCBOVUxMLCBOVUxM KTsNCisgICAgICBjdXJzb3JfdGltZXIuZXhwaXJlcyA9IGppZmZpZXMrSFov NTA7DQorICAgICAgYWRkX3RpbWVyKCZjdXJzb3JfdGltZXIpOw0KK30NCisN CitzdGF0aWMgaW5saW5lIHZvaWQgc2dpYXJjc19pbml0X2NtYXAodm9pZCkN Cit7DQorCXVuc2lnbmVkIHNob3J0IGk7DQorCXVuc2lnbmVkIGxvbmcgZmxh Z3M7DQorDQorCVNHSUFSQ1NfU1RBUlQoZmxhZ3MpOw0KKwlmb3IgKGkgPSAw OyBpIDwgMTY7IGkrKykgew0KKwkJU0dJQVJDU19DQUxMNChTZXRDbWFwLCBj b2xvcl90YWJsZVtpXSwgZGVmYXVsdF9yZWRbaV0sIGRlZmF1bHRfZ3JuW2ld LCBkZWZhdWx0X2JsdVtpXSk7DQorCX0NCisJU0dJQVJDU19FTkQoZmxhZ3Mp Ow0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgc2dpYXJjc19zaG93X2xv Z28odm9pZCkNCit7DQorCXVuc2lnbmVkIGxvbmcgaSwgeCwgeTsNCisJdW5z aWduZWQgbG9uZyBmbGFnczsNCisNCisJU0dJQVJDU19TVEFSVChmbGFncyk7 DQorCWZvciAoaSA9IDA7IGkgPCBMSU5VWF9MT0dPX0NPTE9SUzsgaSsrKQ0K KwkJIFNHSUFSQ1NfQ0FMTDQoU2V0Q21hcCwgaSArIDB4MjAsIGxpbnV4X2xv Z29fcmVkW2ldLCBsaW51eF9sb2dvX2dyZWVuW2ldLCBsaW51eF9sb2dvX2Js dWVbaV0pOw0KKwlmb3IgKHkgPSAwOyB5IDwgTE9HT19IOyB5KyspDQorCQlm b3IgKHggPSAwOyB4IDwgTE9HT19XOyB4KyspIHsNCisJCQlTR0lBUkNTX0NB TEwxKFNldENvbG9yLCBsaW51eF9sb2dvW3kgKiBMT0dPX1cgKyB4XSk7DQor CQkJU0dJQVJDU19DQUxMMihEcmF3UGl4ZWwsIHNnaV9wcm9tZ2Z4LT53aWR0 aCAtIExPR09fVyArIHgsIHNnaV9wcm9tZ2Z4LT5oZWlnaHQgLSAxIC0geSk7 DQorCQl9DQorCVNHSUFSQ1NfRU5EKGZsYWdzKTsNCit9DQorDQorc3RhdGlj IGlubGluZSB2b2lkIHNnaWFyY3NfY2xlYXJfc2NyZWVuKGludCB4c3RhcnQs IGludCB5c3RhcnQsIGludCB4ZW5kLA0KKwkJCQkJaW50IHllbmQsIGludCBj aSkNCit7DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQorCWlmIChsb2dvX2Fj dGl2ZSkNCisJCXJldHVybjsNCisJU0dJQVJDU19TVEFSVChmbGFncyk7DQor CVNHSUFSQ1NfQ0FMTDEoU2V0Q29sb3IsIGNpKTsNCisJU0dJQVJDU19DQUxM NChEcmF3QmxvY2ssIHhzdGFydCwgc2dpX3Byb21nZngtPmhlaWdodCAtIDEg LSB5c3RhcnQsIHhlbmQsIHNnaV9wcm9tZ2Z4LT5oZWlnaHQgLSAxIC0geWVu ZCk7DQorCVNHSUFSQ1NfRU5EKGZsYWdzKTsNCit9DQorDQorI2lmZGVmIE1P RFVMRQ0KK3N0YXRpYyBjb25zdCBjaGFyICpzZ2lhcmNzX3N0YXJ0dXAodm9p ZCkNCisjZWxzZQ0KK3N0YXRpYyBjb25zdCBjaGFyICpfX2luaXQgc2dpYXJj c19zdGFydHVwKHZvaWQpDQorI2VuZGlmDQorew0KKwlpbnQgaTsNCisJdW5z aWduZWQgbG9uZyBmbGFnczsNCisNCisJaWYgKHNnaV9wcm9tZ2Z4ID09IDAg fHwgcHJvbV9tZW1vcnlfZnJlZWQgPiAwKQ0KKwkJcmV0dXJuIE5VTEw7DQor CXByb21fbWVtb3J5X2ZyZWVkID0gLTE7DQorCWZvciAoaSA9IDA7IGkgPCBN QVhfTlJfQ09OU09MRVM7IGkrKykNCisJCWZvbnRfZGF0YVtpXSA9IEZPTlRf REFUQTsNCisJc2dpYXJjc19pbml0X2NtYXAoKTsNCisJc2dpYXJjc19jbGVh cl9zY3JlZW4oMCwgMCwgc2dpX3Byb21nZngtPndpZHRoIC0gMSwgc2dpX3By b21nZngtPmhlaWdodCAtIDEsIDApOw0KKwlTR0lBUkNTX1NUQVJUKGZsYWdz KTsNCisJLyogbW92ZSBtb3VzZSBvZmZzY3JlZW4gKi8NCisJU0dJQVJDU19D QUxMMihTZXRDdXJzb3IsIHNnaV9wcm9tZ2Z4LT53aWR0aCArIDEwLCBzZ2lf cHJvbWdmeC0+aGVpZ2h0ICsgMTApOw0KKwlTR0lBUkNTX0VORChmbGFncyk7 DQorCQ0KKwljdXJzb3JfYmxpbmtfcmF0ZSA9IERFRkFVTFRfQ1VSU09SX0JM SU5LX1JBVEU7DQorCWN1cnNvcl90aW1lci5leHBpcmVzID0gamlmZmllcytI Wi81MDsNCisJYWRkX3RpbWVyKCZjdXJzb3JfdGltZXIpOw0KKw0KKwlwcmlu dGsoIlNHSUFSQ1MgY29sb2xlIGRyaXZlciwgJWR4JWQgYXQgMHgleFxuIiwg c2dpX3Byb21nZngtPndpZHRoLCBzZ2lfcHJvbWdmeC0+aGVpZ2h0LCBzZ2lf cHJvbWdmeC0+Z2Z4YWRkcik7DQorCXJldHVybiAiU0dJX0FSQ1MiOw0KK30N CisNCitzdGF0aWMgdm9pZCBzZ2lhcmNzX2luaXQoc3RydWN0IHZjX2RhdGEg KnZjLCBpbnQgaW5pdCkNCit7DQorCXZjLT52Y19jb2xzID0gc2dpX3Byb21n ZngtPndpZHRoIC8gODsNCisJdmMtPnZjX3Jvd3MgPSBzZ2lfcHJvbWdmeC0+ aGVpZ2h0IC8gMTY7DQorCXZjLT52Y19jYW5fZG9fY29sb3IgPSAxOw0KK30N CisNCitzdGF0aWMgdm9pZCBzZ2lhcmNzX2NsZWFyKHN0cnVjdCB2Y19kYXRh ICp2YywgaW50IHN5LCBpbnQgc3gsIGludCBoZWlnaHQsDQorCQkJICBpbnQg d2lkdGgpDQorew0KKwlpbnQgcmVkcmF3X2N1cnNvciA9IDA7DQorCWlmIChs b2dvX2FjdGl2ZSkNCisJCXJldHVybjsNCisJaWYgKChzeSA8PSBjdXJzb3Jf eSkgJiYgKGN1cnNvcl95IDwgc3kraGVpZ2h0KSAmJg0KKwkgICAgKHN4IDw9 IGN1cnNvcl94KSAmJiAoY3Vyc29yX3ggPCBzeCt3aWR0aCkpIHsNCisJCWN1 cnNvcl91bmRyYXduKCk7DQorCQlyZWRyYXdfY3Vyc29yID0gMTsNCisJfQ0K KwlzZ2lhcmNzX2NsZWFyX3NjcmVlbihzeCA8PCAzLCBzeSA8PCA0LCAoKHN4 ICsgd2lkdGgpIDw8IDMpIC0gMSwgKChzeSArIGhlaWdodCkgPDwgNCkgLSAx LCAodmMtPnZjX2NvbG9yICYgMHhmMCkgPj4gNCk7DQorCWlmIChyZWRyYXdf Y3Vyc29yKQ0KKwkJdmJsX2N1cnNvcl9jbnQgPSBDVVJTT1JfRFJBV19ERUxB WTsNCit9DQorDQorc3RhdGljIHZvaWQgc2dpYXJjc19wdXRjX3JhdyhzdHJ1 Y3QgdmNfZGF0YSAqdmMsIGludCBjaGFyYXR0ciwgaW50IHlwb3MsDQorCQkJ IGludCB4cG9zKQ0KK3sNCisJc3RydWN0IHNnaV9nZnhiaXRtYXAgYm07DQor CXVuc2lnbmVkIGNoYXIgKnA7DQorCVVTSE9SVCBtWzE2XTsNCisJaW50IGk7 DQorCXVuc2lnbmVkIGxvbmcgZmxhZ3M7DQorDQorCXAgPSAmZm9udF9kYXRh W3ZjLT52Y19udW1dWyhjaGFyYXR0ciAmIDB4ZmYpIDw8IDRdOw0KKwljaGFy YXR0ciA9IChjaGFyYXR0ciA+PiA4KSAmIDB4ZmY7DQorCXhwb3MgPDw9IDM7 DQorCXlwb3MgPDw9IDQ7DQorDQorCWlmICghbG9nb19hY3RpdmUpDQorCQlz Z2lhcmNzX2NsZWFyX3NjcmVlbih4cG9zLCB5cG9zLCB4cG9zICsgNywgeXBv cyArIDE1LCAoY2hhcmF0dHIgJiAweGYwKSA+PiA0KTsNCisJZm9yIChpID0g MDsgaSA8IDE2OyBpKyspDQorCQltWzE1IC0gaV0gPSBwW2ldIDw8IDg7DQor CWJtLmJpdG1hcCA9IG07DQorCWJtLndpZHRoID0gODsNCisJYm0uaGVpZ2h0 ID0gMTY7DQorCWJtLm9mZnggPSBibS5vZmZ5ID0gYm0ubW92ZXggPSBibS5t b3ZleSA9IDA7DQorCWJtLnNob3J0c3BlcmxpbmUgPSAxOw0KKwlTR0lBUkNT X1NUQVJUKGZsYWdzKTsNCisJU0dJQVJDU19DQUxMMShTZXRDb2xvciwgY2hh cmF0dHIgJiAweDBmKTsNCisJU0dJQVJDU19DQUxMMihTZXRQb3MsIHhwb3Ms IHNnaV9wcm9tZ2Z4LT5oZWlnaHQgLSAxNiAtIHlwb3MpOw0KKwlTR0lBUkNT X0NBTEwxKERyYXdCaXRtYXAsICZibSk7DQorCVNHSUFSQ1NfRU5EKGZsYWdz KTsNCit9DQorDQorc3RhdGljIHZvaWQgc2dpYXJjc19wdXRjKHN0cnVjdCB2 Y19kYXRhICp2YywgaW50IGNoYXJhdHRyLCBpbnQgeXBvcywNCisJCQkgaW50 IHhwb3MpDQorew0KKwlpbnQgcmVkcmF3X2N1cnNvciA9IDA7DQorCWlmICgo Y3Vyc29yX3ggPT0geHBvcykgJiYgKGN1cnNvcl95ID09IHlwb3MpKSB7DQor CQljdXJzb3JfdW5kcmF3bigpOw0KKwkJcmVkcmF3X2N1cnNvciA9IDE7DQor CX0NCisJc2dpYXJjc19wdXRjX3Jhdyh2YywgY2hhcmF0dHIsIHlwb3MsIHhw b3MpOw0KKwlpZiAocmVkcmF3X2N1cnNvcikNCisJCXZibF9jdXJzb3JfY250 ID0gQ1VSU09SX0RSQVdfREVMQVk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHNn aWFyY3NfcHV0Y3Moc3RydWN0IHZjX2RhdGEgKnZjLCBjb25zdCB1bnNpZ25l ZCBzaG9ydCAqcywNCisJCQkgIGludCBjb3VudCwgaW50IHlwb3MsIGludCB4 cG9zKQ0KK3sNCisJaW50IHJlZHJhd19jdXJzb3IgPSAwOw0KKwlpbnQgY2hh cmF0dHI7DQorCXN0cnVjdCBzZ2lfZ2Z4Yml0bWFwIGJtOw0KKwl1bnNpZ25l ZCBjaGFyICpwOw0KKwlpbnQgbGluZSwgYml0ZSwgaSwgajsNCisJVVNIT1JU IG1bMTYgKiAxNl07CS8qIDMyIGNoYXJzICovDQorCXVuc2lnbmVkIGxvbmcg ZmxhZ3M7DQorDQorCWlmICgoY3Vyc29yX3kgPT0geXBvcykgJiYgKHhwb3Mg PD0gY3Vyc29yX3gpICYmDQorCSAgICAoY3Vyc29yX3ggPCAoeHBvcyArIGNv dW50KSkpIHsNCisJCWN1cnNvcl91bmRyYXduKCk7DQorCQlyZWRyYXdfY3Vy c29yID0gMTsNCisJfQ0KKw0KKwl4cG9zIDw8PSAzOw0KKwl5cG9zIDw8PSA0 Ow0KKwljaGFyYXR0ciA9IChzY3JfcmVhZHcocykgPj4gOCkgJiAweGZmOw0K KwlpZiAoIWxvZ29fYWN0aXZlKQ0KKwkJc2dpYXJjc19jbGVhcl9zY3JlZW4o eHBvcywgeXBvcywgeHBvcyArIGNvdW50ICogOCAtIDEsIHlwb3MgKyAxNSwg KGNoYXJhdHRyICYgMHhmMCkgPj4gNCk7DQorCXdoaWxlIChjb3VudCA+IDAp IHsNCisJCWJpdGUgPSBjb3VudCA+IDMyID8gMzIgOiBjb3VudDsNCisJCWxp bmUgPSAoYml0ZSArIDEpICYgfjE7DQorCQlmb3IgKGkgPSAwOyBpIDwgYml0 ZTsgaSsrKSB7DQorCQkJcCA9ICZmb250X2RhdGFbdmMtPnZjX251bV1bKHNj cl9yZWFkdyhzKyspICYgMHhmZikgPDwgNF07DQorCQkJZm9yIChqID0gMTUg KiBsaW5lOyBqID49IDA7IGogLT0gbGluZSkNCisJCQkJKigodW5zaWduZWQg Y2hhciAqKW0gKyBqICsgaSkgPSAqcCsrOw0KKwkJfQ0KKwkJYm0uYml0bWFw ID0gbTsNCisJCWJtLndpZHRoID0gYml0ZSAqIDg7DQorCQlibS5oZWlnaHQg PSAxNjsNCisJCWJtLm9mZnggPSBibS5vZmZ5ID0gYm0ubW92ZXggPSBibS5t b3ZleSA9IDA7DQorCQlibS5zaG9ydHNwZXJsaW5lID0gbGluZSAvIDI7DQor CQlTR0lBUkNTX1NUQVJUKGZsYWdzKTsNCisJCVNHSUFSQ1NfQ0FMTDEoU2V0 Q29sb3IsIGNoYXJhdHRyICYgMHgwZik7DQorCQlTR0lBUkNTX0NBTEwyKFNl dFBvcywgeHBvcywgc2dpX3Byb21nZngtPmhlaWdodCAtIDE2IC0geXBvcyk7 DQorCQlTR0lBUkNTX0NBTEwxKERyYXdCaXRtYXAsICZibSk7DQorCQlTR0lB UkNTX0VORChmbGFncyk7DQorCQl4cG9zICs9IGJpdGUgKiA4Ow0KKwkJY291 bnQgLT0gYml0ZTsNCisJfQ0KKwlpZiAocmVkcmF3X2N1cnNvcikNCisJICAg IHZibF9jdXJzb3JfY250ID0gQ1VSU09SX0RSQVdfREVMQVk7DQorfQ0KKw0K K3N0YXRpYyB2b2lkIHNnaWFyY3NfY3Vyc29yX3JldmMoc3RydWN0IHZjX2Rh dGEgKnZjLCBpbnQgeCwgaW50IHkpDQorew0KKwl1bnNpZ25lZCBzaG9ydCBj ID0gKih1bnNpZ25lZCBzaG9ydCAqKSh2Yy0+dmNfb3JpZ2luICsgdmMtPnZj X3NpemVfcm93ICogeSArIHggKiAyKTsNCisJaWYgKCFjdXJzb3JfZHJhd24p DQorCQljIF49IDB4ZmYwMDsNCisJc2dpYXJjc19wdXRjX3Jhdyh2YywgYywg eSwgeCk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIHNnaWFyY3NfY3Vyc29yKHN0 cnVjdCB2Y19kYXRhICp2YywgaW50IG1vZGUpDQorew0KKwlpZiAoY3Vyc29y X3ggPT0gdmMtPnZjX3ggJiYgY3Vyc29yX3kgPT0gdmMtPnZjX3kgJiYNCisJ ICAgIChtb2RlID09IENNX0VSQVNFKSA9PSAhY3Vyc29yX29uKQ0KKwkJcmV0 dXJuOw0KKwljdXJzb3Jfb24gPSAwOw0KKwlpZiAoY3Vyc29yX2RyYXduKQ0K KwkgICAgc2dpYXJjc19jdXJzb3JfcmV2Yyh2YywgY3Vyc29yX3gsIGN1cnNv cl95KTsNCisJY3Vyc29yX3ggPSB2Yy0+dmNfeDsNCisJY3Vyc29yX3kgPSB2 Yy0+dmNfeTsNCisJc3dpdGNoIChtb2RlKSB7DQorCWNhc2UgQ01fRVJBU0U6 DQorCQljdXJzb3JfZHJhd24gPSAwOw0KKwkJYnJlYWs7DQorCWNhc2UgQ01f TU9WRToNCisJY2FzZSBDTV9EUkFXOg0KKwkJaWYgKGN1cnNvcl9kcmF3bikN CisJCSAgICBzZ2lhcmNzX2N1cnNvcl9yZXZjKHZjLCBjdXJzb3JfeCwgY3Vy c29yX3kpOw0KKwkJdmJsX2N1cnNvcl9jbnQgPSBDVVJTT1JfRFJBV19ERUxB WTsNCisJCWN1cnNvcl9vbiA9IDE7DQorCQlicmVhazsNCisJfQ0KK30NCisN CitzdGF0aWMgdm9pZCBmYmNvbl92YmxfaGFuZGxlcihpbnQgaXJxLCB2b2lk ICpkdW1teSwgc3RydWN0IHB0X3JlZ3MgKmZwKQ0KK3sNCisgICAgaWYgKCFj dXJzb3Jfb24pDQorCXJldHVybjsNCisgICAgaWYgKHZibF9jdXJzb3JfY250 ICYmIC0tdmJsX2N1cnNvcl9jbnQgPT0gMCkgew0KKwlzZ2lhcmNzX2N1cnNv cl9yZXZjKHZjX2NvbnNbZmdfY29uc29sZV0uZCwgY3Vyc29yX3gsIGN1cnNv cl95KTsNCisJY3Vyc29yX2RyYXduIF49IDE7DQorCXZibF9jdXJzb3JfY250 ID0gY3Vyc29yX2JsaW5rX3JhdGU7DQorICAgIH0NCit9DQorDQorDQorc3Rh dGljIGludCBzZ2lhcmNzX3N3aXRjaChzdHJ1Y3QgdmNfZGF0YSAqdmMpDQor ew0KKwlzdGF0aWMgaW50IGxvZ29fZHJhd24gPSAwOw0KKw0KKwlpZiAoIWxv Z29fZHJhd24pIHsNCisJCXNnaWFyY3Nfc2hvd19sb2dvKCk7DQorCQlsb2dv X2RyYXduID0gMTsNCisJCWxvZ29fYWN0aXZlID0gMTsNCisJfQ0KKwlyZXR1 cm4gMTsNCit9DQorDQorc3RhdGljIGludCBzZ2lhcmNzX2JsYW5rKHN0cnVj dCB2Y19kYXRhICpjLCBpbnQgYmxhbmspDQorew0KKwl1bnNpZ25lZCBsb25n IGZsYWdzOw0KKw0KKwlTR0lBUkNTX1NUQVJUKGZsYWdzKTsNCisJU0dJQVJD U19DQUxMMShCbGFua1NjcmVlbiwgYmxhbmspOw0KKwlTR0lBUkNTX0VORChm bGFncyk7DQorCXJldHVybiAxOw0KK30NCisNCitzdGF0aWMgaW50IHNnaWFy Y3Nfc2V0X2ZvbnQoaW50IHVuaXQsIHN0cnVjdCBjb25zb2xlX2ZvbnRfb3Ag Km9wKQ0KK3sNCisJaW50IHcgPSBvcC0+d2lkdGg7DQorCWludCBoID0gb3At PmhlaWdodDsNCisJaW50IHNpemUgPSBoICogb3AtPmNoYXJjb3VudDsNCisJ aW50IGk7DQorCXVuc2lnbmVkIGNoYXIgKm5ld19kYXRhLCAqZGF0YSA9IG9w LT5kYXRhLCAqcDsNCisNCisJLyogbGFkaXM6IHdoZW4gSSBncm93IHVwLCB0 aGVyZSB3aWxsIGJlIGEgZGF5Li4uIGFuZCBtb3JlIHNpemVzIHdpbGwNCisJ ICogYmUgc3VwcG9ydGVkIDstKSAqLw0KKwlpZiAoKHcgIT0gOCkgfHwgKGgg IT0gMTYpDQorCSAgICB8fCAob3AtPmNoYXJjb3VudCAhPSAyNTYgJiYgb3At PmNoYXJjb3VudCAhPSA1MTIpKQ0KKwkJcmV0dXJuIC1FSU5WQUw7DQorDQor CWlmICghKG5ld19kYXRhID0ga21hbGxvYyhGT05UX0VYVFJBX1dPUkRTICog c2l6ZW9mKGludCkgKyBzaXplLA0KKwkgICAgIEdGUF9VU0VSKSkpIHJldHVy biAtRU5PTUVNOw0KKw0KKwluZXdfZGF0YSArPSBGT05UX0VYVFJBX1dPUkRT ICogc2l6ZW9mKGludCk7DQorCUZOVFNJWkUobmV3X2RhdGEpID0gc2l6ZTsN CisJRk5UQ0hBUkNOVChuZXdfZGF0YSkgPSBvcC0+Y2hhcmNvdW50Ow0KKwlS RUZDT1VOVChuZXdfZGF0YSkgPSAwOwkvKiB1c2FnZSBjb3VudGVyICovDQor DQorCXAgPSBuZXdfZGF0YTsNCisJZm9yIChpID0gMDsgaSA8IG9wLT5jaGFy Y291bnQ7IGkrKykgew0KKwkJbWVtY3B5KHAsIGRhdGEsIGgpOw0KKwkJZGF0 YSArPSAzMjsNCisJCXAgKz0gaDsNCisJfQ0KKw0KKwkvKiBjaGVjayBpZiBm b250IGlzIGFscmVhZHkgdXNlZCBieSBvdGhlciBjb25zb2xlICovDQorCWZv ciAoaSA9IDA7IGkgPCBNQVhfTlJfQ09OU09MRVM7IGkrKykgew0KKwkJaWYg KGZvbnRfZGF0YVtpXSAhPSBGT05UX0RBVEENCisJCSAgICAmJiBGTlRTSVpF KGZvbnRfZGF0YVtpXSkgPT0gc2l6ZQ0KKwkJICAgICYmICFtZW1jbXAoZm9u dF9kYXRhW2ldLCBuZXdfZGF0YSwgc2l6ZSkpIHsNCisJCQlrZnJlZShuZXdf ZGF0YSAtIEZPTlRfRVhUUkFfV09SRFMgKiBzaXplb2YoaW50KSk7DQorCQkJ LyogY3VycmVudCBmb250IGlzIHRoZSBzYW1lIGFzIHRoZSBuZXcgb25lICov DQorCQkJaWYgKGkgPT0gdW5pdCkNCisJCQkJcmV0dXJuIDA7DQorCQkJbmV3 X2RhdGEgPSBmb250X2RhdGFbaV07DQorCQkJYnJlYWs7DQorCQl9DQorCX0N CisJLyogb2xkIGZvbnQgaXMgdXNlciBmb250ICovDQorCWlmIChmb250X2Rh dGFbdW5pdF0gIT0gRk9OVF9EQVRBKSB7DQorCQlpZiAoLS1SRUZDT1VOVChm b250X2RhdGFbdW5pdF0pID09IDApDQorCQkJa2ZyZWUoZm9udF9kYXRhW3Vu aXRdIC0NCisJCQkgICAgICBGT05UX0VYVFJBX1dPUkRTICogc2l6ZW9mKGlu dCkpOw0KKwl9DQorCVJFRkNPVU5UKG5ld19kYXRhKSsrOw0KKwlmb250X2Rh dGFbdW5pdF0gPSBuZXdfZGF0YTsNCisNCisJcmV0dXJuIDA7DQorfQ0KKw0K K3N0YXRpYyBpbnQgc2dpYXJjc19zZXRfZGVmX2ZvbnQoaW50IHVuaXQsIHN0 cnVjdCBjb25zb2xlX2ZvbnRfb3AgKm9wKQ0KK3sNCisJaWYgKGZvbnRfZGF0 YVt1bml0XSAhPSBGT05UX0RBVEEpIHsNCisJCWlmICgtLVJFRkNPVU5UKGZv bnRfZGF0YVt1bml0XSkgPT0gMCkNCisJCQlrZnJlZShmb250X2RhdGFbdW5p dF0gLQ0KKwkJCSAgICAgIEZPTlRfRVhUUkFfV09SRFMgKiBzaXplb2YoaW50 KSk7DQorCQlmb250X2RhdGFbdW5pdF0gPSBGT05UX0RBVEE7DQorCX0NCisN CisJcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2dpYXJjc19mb250 X29wKHN0cnVjdCB2Y19kYXRhICp2Yywgc3RydWN0IGNvbnNvbGVfZm9udF9v cCAqb3ApDQorew0KKwlpbnQgdW5pdCA9IHZjLT52Y19udW07DQorDQorCXN3 aXRjaCAob3AtPm9wKSB7DQorCWNhc2UgS0RfRk9OVF9PUF9TRVQ6DQorCQly ZXR1cm4gc2dpYXJjc19zZXRfZm9udCh1bml0LCBvcCk7DQorCWNhc2UgS0Rf Rk9OVF9PUF9TRVRfREVGQVVMVDoNCisJCXJldHVybiBzZ2lhcmNzX3NldF9k ZWZfZm9udCh1bml0LCBvcCk7DQorCWRlZmF1bHQ6DQorCQlyZXR1cm4gLUVO T1NZUzsNCisJfQ0KK30NCisNCitzdGF0aWMgaW50IHNnaWFyY3Nfc2V0X3Bh bGV0dGUoc3RydWN0IHZjX2RhdGEgKnZjLCB1bnNpZ25lZCBjaGFyICp0YWJs ZSkNCit7DQorCXJldHVybiAtRUlOVkFMOw0KK30NCisNCitzdGF0aWMgaW50 IHNnaWFyY3Nfc2Nyb2xsZGVsdGEoc3RydWN0IHZjX2RhdGEgKnZjLCBpbnQg bGluZXMpDQorew0KKwkvKiB0aGVyZSBpcyAobmVhcmx5KSBubyBvZmYtc2Ny ZWVuIG1lbW9yeSwgc28gd2UgY2FuJ3Qgc2Nyb2xsIGJhY2sgKi8NCisJcmV0 dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2dpYXJjc19zY3JvbGwoc3Ry dWN0IHZjX2RhdGEgKnZjLCBpbnQgdCwgaW50IGIsIGludCBkaXIsDQorCQkJ ICBpbnQgbGluZXMpDQorew0KKwlpbnQgY291bnQsIHgsIHk7DQorCXVuc2ln bmVkIHNob3J0ICpzLCAqZDsNCisJdW5zaWduZWQgc2hvcnQgY2hhdHRyOw0K Kw0KKwlzZ2lhcmNzX2N1cnNvcih2YywgQ01fRVJBU0UpOw0KKw0KKwlpZiAo bG9nb19hY3RpdmUpCXsNCisJCWxvZ29fYWN0aXZlID0gMDsNCisJCXNnaWFy Y3NfY2xlYXJfc2NyZWVuKHNnaV9wcm9tZ2Z4LT53aWR0aCAtIExPR09fVywg MCwgc2dpX3Byb21nZngtPndpZHRoIC0gMSwgTE9HT19IIC0gMSwgMCk7DQor CX0NCisJY291bnQgPSAoYiAtIHQgLSBsaW5lcykgKiB2Yy0+dmNfY29sczsN CisJaWYgKGRpciA9PSBTTV9VUCkgew0KKwkJeCA9IDA7DQorCQl5ID0gdDsN CisJCXMgPSAodW5zaWduZWQgc2hvcnQgKikgKHZjLT52Y19vcmlnaW4gKw0K KwkJCQkJdmMtPnZjX3NpemVfcm93ICogKHQgKyBsaW5lcykpOw0KKwkJZCA9 ICh1bnNpZ25lZCBzaG9ydCAqKSAodmMtPnZjX29yaWdpbiArDQorCQkJCQl2 Yy0+dmNfc2l6ZV9yb3cgKiB0KTsNCisJCXdoaWxlIChjb3VudC0tKSB7DQor CQkJY2hhdHRyID0gc2NyX3JlYWR3KHMrKyk7DQorCQkJaWYgKGNoYXR0ciAh PSBzY3JfcmVhZHcoZCkpIHsNCisJCQkJc2dpYXJjc19wdXRjKHZjLCBjaGF0 dHIsIHksIHgpOw0KKwkJCQlzY3Jfd3JpdGV3KGNoYXR0ciwgZCk7DQorCQkJ fQ0KKwkJCWQrKzsNCisJCQlpZiAoKyt4ID09IHZjLT52Y19jb2xzKSB7DQor CQkJCXggPSAwOw0KKwkJCQl5Kys7DQorCQkJfQ0KKwkJfQ0KKwkJZCA9ICh1 bnNpZ25lZCBzaG9ydCAqKSAodmMtPnZjX29yaWdpbiArDQorCQkJCQl2Yy0+ dmNfc2l6ZV9yb3cgKiAoYiAtIGxpbmVzKSk7DQorCQl4ID0gMDsNCisJCXkg PSBiIC0gbGluZXM7DQorCQlmb3IgKGNvdW50ID0gMDsgY291bnQgPCAobGlu ZXMgKiB2Yy0+dmNfY29scyk7IGNvdW50KyspIHsNCisJCQlpZiAoc2NyX3Jl YWR3KGQpICE9IHZjLT52Y192aWRlb19lcmFzZV9jaGFyKSB7DQorCQkJCXNn aWFyY3NfcHV0Yyh2YywgdmMtPnZjX3ZpZGVvX2VyYXNlX2NoYXIsDQorCQkJ CQkgICAgIHksIHgpOw0KKwkJCQlzY3Jfd3JpdGV3KHZjLT52Y192aWRlb19l cmFzZV9jaGFyLCBkKTsNCisJCQl9DQorCQkJZCsrOw0KKwkJCWlmICgrK3gg PT0gdmMtPnZjX2NvbHMpIHsNCisJCQkJeCA9IDA7DQorCQkJCXkrKzsNCisJ CQl9DQorCQl9DQorCX0gZWxzZSB7DQorCQl4ID0gdmMtPnZjX2NvbHMgLSAx Ow0KKwkJeSA9IGIgLSAxOw0KKwkJcyA9ICh1bnNpZ25lZCBzaG9ydCAqKSAo dmMtPnZjX29yaWdpbiArDQorCQkJCQl2Yy0+dmNfc2l6ZV9yb3cgKiAoYiAt IGxpbmVzKSAtIDIpOw0KKwkJZCA9ICh1bnNpZ25lZCBzaG9ydCAqKSAodmMt PnZjX29yaWdpbiArDQorCQkJCQl2Yy0+dmNfc2l6ZV9yb3cgKiBiIC0gMik7 DQorCQl3aGlsZSAoY291bnQtLSkgew0KKwkJCWNoYXR0ciA9IHNjcl9yZWFk dyhzLS0pOw0KKwkJCWlmIChjaGF0dHIgIT0gc2NyX3JlYWR3KGQpKSB7DQor CQkJCXNnaWFyY3NfcHV0Yyh2YywgY2hhdHRyLCB5LCB4KTsNCisJCQkJc2Ny X3dyaXRldyhjaGF0dHIsIGQpOw0KKwkJCX0NCisJCQlkLS07DQorCQkJaWYg KHgtLSA9PSAwKSB7DQorCQkJCXggPSB2Yy0+dmNfY29scyAtIDE7DQorCQkJ CXktLTsNCisJCQl9DQorCQl9DQorCQlkID0gKHVuc2lnbmVkIHNob3J0ICop ICh2Yy0+dmNfb3JpZ2luICsNCisJCQkJCXZjLT52Y19zaXplX3JvdyAqIHQp Ow0KKwkJeCA9IDA7DQorCQl5ID0gdDsNCisJCWZvciAoY291bnQgPSAwOyBj b3VudCA8IChsaW5lcyAqIHZjLT52Y19jb2xzKTsgY291bnQrKykgew0KKwkJ CWlmIChzY3JfcmVhZHcoZCkgIT0gdmMtPnZjX3ZpZGVvX2VyYXNlX2NoYXIp IHsNCisJCQkJc2dpYXJjc19wdXRjKHZjLCB2Yy0+dmNfdmlkZW9fZXJhc2Vf Y2hhciwNCisJCQkJCSAgICAgeSwgeCk7DQorCQkJCXNjcl93cml0ZXcodmMt PnZjX3ZpZGVvX2VyYXNlX2NoYXIsIGQpOw0KKwkJCX0NCisJCQlkKys7DQor CQkJaWYgKCsreCA9PSB2Yy0+dmNfY29scykgew0KKwkJCQl4ID0gMDsNCisJ CQkJeSsrOw0KKwkJCX0NCisJCX0NCisJfQ0KKwlyZXR1cm4gMTsNCit9DQor DQorc3RhdGljIHZvaWQgc2dpYXJjc19ibW92ZShzdHJ1Y3QgdmNfZGF0YSAq dmMsIGludCBzeSwgaW50IHN4LCBpbnQgZHksDQorCQkJICBpbnQgZHgsIGlu dCBoLCBpbnQgdykNCit7DQorCWlmIChzeSAhPSBkeSkNCisJCXBhbmljKCJz Z2lhcmNzX2Jtb3ZlIHdpZHRoIHN5ICE9IGR5Iik7DQorDQorCWlmICgoKHN5 IDw9IGN1cnNvcl95KSAmJiAoY3Vyc29yX3kgPCBzeStoKSAmJg0KKwkgICAg ICAoc3ggPD0gY3Vyc29yX3gpICYmIChjdXJzb3JfeCA8IHN4K3cpKSB8fA0K KwkgICAgICgoZHkgPD0gY3Vyc29yX3kpICYmIChjdXJzb3JfeSA8IGR5K2gp ICYmDQorCSAgICAgIChkeCA8PSBjdXJzb3JfeCkgJiYgKGN1cnNvcl94IDwg ZHgrdykpKQ0KKwkJc2dpYXJjc19jdXJzb3IodmMsIENNX0VSQVNFKTsNCisN CisJd2hpbGUgKGgtLSA+IDApIHsNCisJCXVuc2lnbmVkIHNob3J0ICpkID0g KHVuc2lnbmVkIHNob3J0ICopKHZjLT52Y19vcmlnaW4gKyB2Yy0+dmNfc2l6 ZV9yb3cgKiBkeSArIGR4ICogMik7DQorCQl1bnNpZ25lZCBzaG9ydCAqcyA9 IGQgKyAoZHggLSBzeCk7DQorCQl1bnNpZ25lZCBzaG9ydCAqc3RhcnQgPSBk Ow0KKwkJdW5zaWduZWQgc2hvcnQgKmxzID0gZDsNCisJCXVuc2lnbmVkIHNo b3J0ICpsZSA9IGQgKyB3Ow0KKwkJdW5zaWduZWQgc2hvcnQgYzsNCisJCWlu dCB4ID0gZHg7DQorCQl1bnNpZ25lZCBzaG9ydCBhdHRyID0gMTsNCisNCisJ CWRvIHsNCisJCQljID0gc2NyX3JlYWR3KGQpOw0KKwkJCWlmIChhdHRyICE9 IChjICYgMHhmZjAwKSkgew0KKwkJCSAgICBhdHRyID0gYyAmIDB4ZmYwMDsg DQorCQkJICAgIGlmIChkID4gc3RhcnQpIHsgDQorCQkJCXNnaWFyY3NfcHV0 Y3ModmMsIHN0YXJ0LCBkIC0gc3RhcnQsIGR5LCB4KTsNCisJCQkJeCArPSBk IC0gc3RhcnQ7DQorCQkJCXN0YXJ0ID0gZDsNCisJCQkgICAgfQ0KKwkJCX0N CisJCQlpZiAocyA+PSBscyAmJiBzIDwgbGUgJiYgYyA9PSBzY3JfcmVhZHco cykpIHsNCisJCQkgICAgaWYgKGQgPiBzdGFydCkgew0KKwkJCQlzZ2lhcmNz X3B1dGNzKHZjLCBzdGFydCwgZCAtIHN0YXJ0LCBkeSwgeCk7DQorCQkJCXgg Kz0gZCAtIHN0YXJ0ICsgMTsNCisJCQkJc3RhcnQgPSBkICsgMTsNCisJCQkg ICAgfSBlbHNlIHsNCisJCQkJeCsrOw0KKwkJCQlzdGFydCsrOw0KKwkJCSAg ICB9DQorCQkJfQ0KKwkJCXMrKzsNCisJCQlkKys7DQorCQl9IHdoaWxlIChk IDwgbGUpOw0KKwkJaWYgKGQgPiBzdGFydCkNCisJCSAgICBzZ2lhcmNzX3B1 dGNzKHZjLCBzdGFydCwgZCAtIHN0YXJ0LCBkeSwgeCk7DQorCQlzeSsrOw0K KwkJZHkrKzsNCisJfQ0KK30NCisNCitzdGF0aWMgaW50IHNnaWFyY3NfZHVt bXkoc3RydWN0IHZjX2RhdGEgKmMpDQorew0KKwlyZXR1cm4gMDsNCit9DQor DQorI2RlZmluZSBEVU1NWSAodm9pZCAqKSBzZ2lhcmNzX2R1bW15DQorDQor Y29uc3Qgc3RydWN0IGNvbnN3IHNnaWFyY3NfY29uID0gew0KKyAgICBjb25f c3RhcnR1cDoJc2dpYXJjc19zdGFydHVwLA0KKyAgICBjb25faW5pdDoJCXNn aWFyY3NfaW5pdCwNCisgICAgY29uX2RlaW5pdDoJCURVTU1ZLA0KKyAgICBj b25fY2xlYXI6CQlzZ2lhcmNzX2NsZWFyLA0KKyAgICBjb25fcHV0YzoJCXNn aWFyY3NfcHV0YywNCisgICAgY29uX3B1dGNzOgkJc2dpYXJjc19wdXRjcywN CisgICAgY29uX2N1cnNvcjoJCXNnaWFyY3NfY3Vyc29yLA0KKyAgICBjb25f c2Nyb2xsOgkJc2dpYXJjc19zY3JvbGwsDQorICAgIGNvbl9ibW92ZToJCXNn aWFyY3NfYm1vdmUsDQorICAgIGNvbl9zd2l0Y2g6CQlzZ2lhcmNzX3N3aXRj aCwNCisgICAgY29uX2JsYW5rOgkJc2dpYXJjc19ibGFuaywNCisgICAgY29u X2ZvbnRfb3A6CXNnaWFyY3NfZm9udF9vcCwNCisgICAgY29uX3NldF9wYWxl dHRlOglzZ2lhcmNzX3NldF9wYWxldHRlLA0KKyAgICBjb25fc2Nyb2xsZGVs dGE6CXNnaWFyY3Nfc2Nyb2xsZGVsdGEsDQorICAgIGNvbl9zZXRfb3JpZ2lu OglEVU1NWSwNCisgICAgY29uX3NhdmVfc2NyZWVuOglEVU1NWQ0KK307DQor DQorI2lmZGVmIE1PRFVMRQ0KK2ludCBpbml0X21vZHVsZSh2b2lkKQ0KK3sN CisJaWYgKCFzZ2lhcmNzX3N0YXJ0dXAoKSkNCisJCXByaW50aygiRXJyb3Ig bG9hZGluZyBTR0lBUkNTIENvbnNvbGUgZHJpdmVyXG4iKTsNCisJZWxzZQ0K KwkJcHJpbnRrKCJMb2FkaW5nIFNHSUFSQ1MgQ29uc29sZSBEcml2ZXJcbiIp Ow0KKwl0YWtlX292ZXJfY29uc29sZSgmc2dpYXJjc19jb24sIDAsIE1BWF9O Ul9DT05TT0xFUyAtIDEsIDEpOw0KKw0KKwlyZXR1cm4gMDsNCit9DQorDQor aW50IGNsZWFudXBfbW9kdWxlKHZvaWQpDQorew0KKwlpbnQgaTsNCisNCisJ cHJpbnRrKCJVbmxvYWRpbmcgU0dJQVJDUyBDb25zb2xlIERyaXZlclxuIik7 DQorCS8qIGZyZWUgbWVtb3J5IHVzZWQgYnkgdXNlciBmb250ICovDQorCWZv ciAoaSA9IDA7IGkgPCBNQVhfTlJfQ09OU09MRVM7IGkrKykNCisJCXNnaWFy Y3Nfc2V0X2RlZl9mb250KGksIE5VTEwpOw0KKw0KKwlyZXR1cm4gMDsNCit9 DQorI2VuZGlmDQotLS0gLi9pbmNsdWRlL2FzbS1taXBzL3NnaS9zZ2ltYy5o Lm9yaWcJMjAwMi0wNS0xMyAyMzowOToyOS4wMDAwMDAwMDAgKzAyMDANCisr KyAuL2luY2x1ZGUvYXNtLW1pcHMvc2dpL3NnaW1jLmgJMjAwMi0wNS0xMyAy MzowOTo0My4wMDAwMDAwMDAgKzAyMDANCkBAIC0yMjQsNSArMjI0LDYgQEAN CiAjZGVmaW5lIFNHSU1DX1NFRzFfU0laRV9JUDI2X0lQMjggICAweDIwMDAw MDAwIC8qIDUxMk1CICovDQogDQogZXh0ZXJuIHZvaWQgc2dpbWNfaW5pdCh2 b2lkKTsNCitleHRlcm4gdm9pZCBzZ2ltY19leHAwNjQodm9pZCk7DQogDQog I2VuZGlmIC8qIF9BU01fU0dJX1NHSU1DX0ggKi8NCi0tLSAuL2luY2x1ZGUv YXNtLW1pcHMvc2dpYXJjcy5oLm9yaWcJMjAwMi0wNS0xMSAxNjozMTo1MS4w MDAwMDAwMDAgKzAyMDANCisrKyAuL2luY2x1ZGUvYXNtLW1pcHMvc2dpYXJj cy5oCTIwMDItMDUtMTEgMjA6Mjk6MDguMDAwMDAwMDAwICswMjAwDQpAQCAt MzYwLDYgKzM2MCw1OCBAQA0KIAlpbnQgICAgICAgICAgICAgc21heDsgICAg ICAgICAgICAgIC8qIE1heCAjIG9mIHN5bWJvbHMuICovDQogfTsNCiANCitz dHJ1Y3Qgc2dpX3B2ZWN0b3Igew0KKwlMT05HCQlpb2N0bDsNCisJTE9ORwkJ Z2V0X252cmFtX3RhYjsNCisJTE9ORwkJbG9hZF9hYnM7DQorCUxPTkcJCWlu dm9rZV9hYnM7DQorCUxPTkcJCWV4ZWNfYWJzOw0KKwlMT05HCQlmc19yZWdp c3RlcjsNCisJTE9ORwkJZnNfdW5yZWdpc3RlcjsNCisJTE9ORwkJc2lnbmFs Ow0KKwlMT05HCQlnZXRfcHJvbWdmeDsNCit9Ow0KKw0KK3N0cnVjdCBzZ2lf cHJvbWdmeCB7DQorCUxPTkcJCWdmeHZlY3RvcjsNCisJTE9ORwkJZ2Z4YWRk cjsNCisJTE9ORwkJdW5rbm93bjFbOF07DQorCUxPTkcJCXdpZHRoOw0KKwlM T05HCQloZWlnaHQ7DQorCUxPTkcJCXVua25vd24yWzEwXTsNCisJTE9ORwkJ c3RhdGU7DQorfTsNCisNCitzdHJ1Y3Qgc2dpX3Byb21nZnhpbmZvIHsNCisJ aW50CQlhZGRyOw0KKwlpbnQJCXdpZHRoOw0KKwlpbnQJCWhlaWdodDsNCit9 Ow0KKw0KK3N0cnVjdCBzZ2lfZ2Z4dmVjdG9yIHsNCisJTE9ORwkJQmxhbmtT Y3JlZW47DQorCUxPTkcJCVNldENvbG9yOw0KKwlMT05HCQlTZXRDbWFwOw0K KwlMT05HCQlEcmF3QmxvY2s7DQorCUxPTkcJCURyYXdQaXhlbDsNCisJTE9O RwkJU2V0UG9zOw0KKwlMT05HCQlEcmF3Qml0bWFwOw0KKwlMT05HCQlNb3Zl QmxvY2s7DQorCUxPTkcJCUluaXRTY3JlZW47DQorCUxPTkcJCVNldEN1cnNv cjsNCit9Ow0KKw0KK3N0cnVjdCBzZ2lfZ2Z4Yml0bWFwIHsNCisJVVNIT1JU ICoJYml0bWFwOw0KKwlVU0hPUlQJCXdpZHRoOw0KKwlVU0hPUlQJCWhlaWdo dDsNCisJU0hPUlQJCW9mZng7DQorCVNIT1JUCQlvZmZ5Ow0KKwlTSE9SVAkJ bW92ZXg7DQorCVNIT1JUCQltb3ZleTsNCisJVVNIT1JUCQlzaG9ydHNwZXJs aW5lOw0KK307DQorDQogLyoNCiAgKiBNYWNyb3MgZm9yIGNhbGxpbmcgYSAz Mi1iaXQgQVJDIGltcGxlbWVudGF0aW9uIGZyb20gNjQtYml0IGNvZGUNCiAg Ki8NCkBAIC0zNzAsOSArNDIyLDkgQEANCiAJIiQyIiwiJDMiLCIkNCIsIiQ1 IiwiJDYiLCIkNyIsIiQ4IiwiJDkiLCIkMTAiLCIkMTEiLAkJXA0KIAkiJDEy IiwiJDEzIiwiJDE0IiwiJDE1IiwiJDE2IiwiJDI0IiwiMjUiLCIkMzEiDQog DQotI2RlZmluZSBBUkNfQ0FMTDAoZGVzdCkJCQkJCQkJXA0KKyNkZWZpbmUg QVJDX0NBTEwwX1ZFQyh2ZWMsZGVzdCkJCQkJCQkJXA0KICh7CWxvbmcgX19y ZXM7CQkJCQkJCVwNCi0JbG9uZyBfX3ZlYyA9IChsb25nKSByb212ZWMtPmRl c3Q7CQkJCVwNCisJbG9uZyBfX3ZlYyA9IChsb25nKSAodmVjKS0+ZGVzdDsJ CQkJXA0KIAlfX2FzbV9fIF9fdm9sYXRpbGVfXygJCQkJCQlcDQogCSJkc3Vi dVx0JDI5LCAzMlxuXHQiCQkJCQkJXA0KIAkiamFsclx0JTFcblx0IgkJCQkJ CQlcDQpAQCAtMzg0LDEwICs0MzYsMTAgQEANCiAJKHVuc2lnbmVkIGxvbmcp IF9fcmVzOwkJCQkJCVwNCiB9KQ0KIA0KLSNkZWZpbmUgQVJDX0NBTEwxKGRl c3QsYTEpCQkJCQkJXA0KKyNkZWZpbmUgQVJDX0NBTEwxX1ZFQyh2ZWMsZGVz dCxhMSkJCQkJCQlcDQogKHsJbG9uZyBfX3JlczsJCQkJCQkJXA0KIAlyZWdp c3RlciBzaWduZWQgaW50IF9fYTEgX19hc21fXygiJDQiKSA9IChpbnQpIChs b25nKSAoYTEpOwlcDQotCWxvbmcgX192ZWMgPSAobG9uZykgcm9tdmVjLT5k ZXN0OwkJCQlcDQorCWxvbmcgX192ZWMgPSAobG9uZykgKHZlYyktPmRlc3Q7 CQkJCVwNCiAJX19hc21fXyBfX3ZvbGF0aWxlX18oCQkJCQkJXA0KIAkiZHN1 YnVcdCQyOSwgMzJcblx0IgkJCQkJCVwNCiAJImphbHJcdCUxXG5cdCIJCQkJ CQkJXA0KQEAgLTM5OSwxMSArNDUxLDExIEBADQogCSh1bnNpZ25lZCBsb25n KSBfX3JlczsJCQkJCQlcDQogfSkNCiANCi0jZGVmaW5lIEFSQ19DQUxMMihk ZXN0LGExLGEyKQkJCQkJCVwNCisjZGVmaW5lIEFSQ19DQUxMMl9WRUModmVj LGRlc3QsYTEsYTIpCQkJCQkJXA0KICh7CWxvbmcgX19yZXM7CQkJCQkJCVwN CiAJcmVnaXN0ZXIgc2lnbmVkIGludCBfX2ExIF9fYXNtX18oIiQ0IikgPSAo aW50KSAobG9uZykgKGExKTsJXA0KIAlyZWdpc3RlciBzaWduZWQgaW50IF9f YTIgX19hc21fXygiJDUiKSA9IChpbnQpIChsb25nKSAoYTIpOwlcDQotCWxv bmcgX192ZWMgPSAobG9uZykgcm9tdmVjLT5kZXN0OwkJCQlcDQorCWxvbmcg X192ZWMgPSAobG9uZykgKHZlYyktPmRlc3Q7CQkJCVwNCiAJX19hc21fXyBf X3ZvbGF0aWxlX18oCQkJCQkJXA0KIAkiZHN1YnVcdCQyOSwgMzJcblx0IgkJ CQkJCVwNCiAJImphbHJcdCUxXG5cdCIJCQkJCQkJXA0KQEAgLTQxNSwxMiAr NDY3LDEyIEBADQogCV9fcmVzOwkJCQkJCQkJXA0KIH0pDQogDQotI2RlZmlu ZSBBUkNfQ0FMTDMoZGVzdCxhMSxhMixhMykJCQkJCVwNCisjZGVmaW5lIEFS Q19DQUxMM19WRUModmVjLGRlc3QsYTEsYTIsYTMpCQkJCQlcDQogKHsJbG9u ZyBfX3JlczsJCQkJCQkJXA0KIAlyZWdpc3RlciBzaWduZWQgaW50IF9fYTEg X19hc21fXygiJDQiKSA9IChpbnQpIChsb25nKSAoYTEpOwlcDQogCXJlZ2lz dGVyIHNpZ25lZCBpbnQgX19hMiBfX2FzbV9fKCIkNSIpID0gKGludCkgKGxv bmcpIChhMik7CVwNCiAJcmVnaXN0ZXIgc2lnbmVkIGludCBfX2EzIF9fYXNt X18oIiQ2IikgPSAoaW50KSAobG9uZykgKGEzKTsJXA0KLQlsb25nIF9fdmVj ID0gKGxvbmcpIHJvbXZlYy0+ZGVzdDsJCQkJXA0KKwlsb25nIF9fdmVjID0g KGxvbmcpICh2ZWMpLT5kZXN0OwkJCQlcDQogCV9fYXNtX18gX192b2xhdGls ZV9fKAkJCQkJCVwNCiAJImRzdWJ1XHQkMjksIDMyXG5cdCIJCQkJCQlcDQog CSJqYWxyXHQlMVxuXHQiCQkJCQkJCVwNCkBAIC00MzIsMTMgKzQ4NCwxMyBA QA0KIAlfX3JlczsJCQkJCQkJCVwNCiB9KQ0KIA0KLSNkZWZpbmUgQVJDX0NB TEw0KGRlc3QsYTEsYTIsYTMsYTQpCQkJCQlcDQorI2RlZmluZSBBUkNfQ0FM TDRfVkVDKHZlYyxkZXN0LGExLGEyLGEzLGE0KQkJCQkJXA0KICh7CWxvbmcg X19yZXM7CQkJCQkJCVwNCiAJcmVnaXN0ZXIgc2lnbmVkIGludCBfX2ExIF9f YXNtX18oIiQ0IikgPSAoaW50KSAobG9uZykgKGExKTsJXA0KIAlyZWdpc3Rl ciBzaWduZWQgaW50IF9fYTIgX19hc21fXygiJDUiKSA9IChpbnQpIChsb25n KSAoYTIpOwlcDQogCXJlZ2lzdGVyIHNpZ25lZCBpbnQgX19hMyBfX2FzbV9f KCIkNiIpID0gKGludCkgKGxvbmcpIChhMyk7CVwNCiAJcmVnaXN0ZXIgc2ln bmVkIGludCBfX2E0IF9fYXNtX18oIiQ3IikgPSAoaW50KSAobG9uZykgKGE0 KTsJXA0KLQlsb25nIF9fdmVjID0gKGxvbmcpIHJvbXZlYy0+ZGVzdDsJCQkJ XA0KKwlsb25nIF9fdmVjID0gKGxvbmcpICh2ZWMpLT5kZXN0OwkJCQlcDQog CV9fYXNtX18gX192b2xhdGlsZV9fKAkJCQkJCVwNCiAJImRzdWJ1XHQkMjks IDMyXG5cdCIJCQkJCQlcDQogCSJqYWxyXHQlMVxuXHQiCQkJCQkJCVwNCkBA IC00NTEsMTQgKzUwMywxNCBAQA0KIAlfX3JlczsJCQkJCQkJCVwNCiB9KQ0K IA0KLSNkZWZpbmUgQVJDX0NBTEw1KGRlc3QsYTEsYTIsYTMsYTQsYTUpCQkJ CQlcDQorI2RlZmluZSBBUkNfQ0FMTDVfVkVDKHZlYyxkZXN0LGExLGEyLGEz LGE0LGE1KQkJCQkJXA0KICh7CWxvbmcgX19yZXM7CQkJCQkJCVwNCiAJcmVn aXN0ZXIgc2lnbmVkIGludCBfX2ExIF9fYXNtX18oIiQ0IikgPSAoaW50KSAo bG9uZykgKGExKTsJXA0KIAlyZWdpc3RlciBzaWduZWQgaW50IF9fYTIgX19h c21fXygiJDUiKSA9IChpbnQpIChsb25nKSAoYTIpOwlcDQogCXJlZ2lzdGVy IHNpZ25lZCBpbnQgX19hMyBfX2FzbV9fKCIkNiIpID0gKGludCkgKGxvbmcp IChhMyk7CVwNCiAJcmVnaXN0ZXIgc2lnbmVkIGludCBfX2E0IF9fYXNtX18o IiQ3IikgPSAoaW50KSAobG9uZykgKGE0KTsJXA0KIAlyZWdpc3RlciBzaWdu ZWQgaW50IF9fYTUgPSAoYTUpOwkJCQlcDQotCWxvbmcgX192ZWMgPSAobG9u Zykgcm9tdmVjLT5kZXN0OwkJCQlcDQorCWxvbmcgX192ZWMgPSAobG9uZykg KHZlYyktPmRlc3Q7CQkJCVwNCiAJX19hc21fXyBfX3ZvbGF0aWxlX18oCQkJ CQkJXA0KIAkiZHN1YnVcdCQyOSwgMzJcblx0IgkJCQkJCVwNCiAJInN3XHQl NiwgMTYoJDI5KVxuXHQiCQkJCQkJXA0KQEAgLTQ3OCw1NyArNTMwLDU3IEBA DQogI2lmIChkZWZpbmVkKENPTkZJR19NSVBTMzIpICYmIGRlZmluZWQoQ09O RklHX0FSQzMyKSkgfHwJCVwNCiAgICAgKGRlZmluZWQoQ09ORklHX01JUFM2 NCkgJiYgZGVmaW5lZChDT05GSUdfQVJDMzIpKQ0KIA0KLSNkZWZpbmUgQVJD X0NBTEwwKGRlc3QpCQkJCQkJCVwNCisjZGVmaW5lIEFSQ19DQUxMMF9WRUMo dmVjLGRlc3QpCQkJCQkJCVwNCiAoewlsb25nIF9fcmVzOwkJCQkJCQlcDQot CWxvbmcgKCpfX3ZlYykodm9pZCkgPSAodm9pZCAqKSByb212ZWMtPmRlc3Q7 CQkJXA0KKwlsb25nICgqX192ZWMpKHZvaWQpID0gKHZvaWQgKikgKHZlYykt PmRlc3Q7CQkJXA0KIAkJCQkJCQkJCVwNCiAJX19yZXMgPSBfX3ZlYygpOwkJ CQkJCVwNCiAJX19yZXM7CQkJCQkJCQlcDQogfSkNCiANCi0jZGVmaW5lIEFS Q19DQUxMMShkZXN0LGExKQkJCQkJCVwNCisjZGVmaW5lIEFSQ19DQUxMMV9W RUModmVjLGRlc3QsYTEpCQkJCQkJXA0KICh7CWxvbmcgX19yZXM7CQkJCQkJ CVwNCiAJbG9uZyBfX2ExID0gKGxvbmcpIChhMSk7CQkJCQlcDQotCWxvbmcg KCpfX3ZlYykobG9uZykgPSAodm9pZCAqKSByb212ZWMtPmRlc3Q7CQkJXA0K Kwlsb25nICgqX192ZWMpKGxvbmcpID0gKHZvaWQgKikgKHZlYyktPmRlc3Q7 CQkJXA0KIAkJCQkJCQkJCVwNCiAJX19yZXMgPSBfX3ZlYyhfX2ExKTsJCQkJ CQlcDQogCV9fcmVzOwkJCQkJCQkJXA0KIH0pDQogDQotI2RlZmluZSBBUkNf Q0FMTDIoZGVzdCxhMSxhMikJCQkJCQlcDQorI2RlZmluZSBBUkNfQ0FMTDJf VkVDKHZlYyxkZXN0LGExLGEyKQkJCQkJCVwNCiAoewlsb25nIF9fcmVzOwkJ CQkJCQlcDQogCWxvbmcgX19hMSA9IChsb25nKSAoYTEpOwkJCQkJXA0KIAls b25nIF9fYTIgPSAobG9uZykgKGEyKTsJCQkJCVwNCi0JbG9uZyAoKl9fdmVj KShsb25nLCBsb25nKSA9ICh2b2lkICopIHJvbXZlYy0+ZGVzdDsJCVwNCisJ bG9uZyAoKl9fdmVjKShsb25nLCBsb25nKSA9ICh2b2lkICopICh2ZWMpLT5k ZXN0OwkJXA0KIAkJCQkJCQkJCVwNCiAJX19yZXMgPSBfX3ZlYyhfX2ExLCBf X2EyKTsJCQkJCVwNCiAJX19yZXM7CQkJCQkJCQlcDQogfSkNCiANCi0jZGVm aW5lIEFSQ19DQUxMMyhkZXN0LGExLGEyLGEzKQkJCQkJXA0KKyNkZWZpbmUg QVJDX0NBTEwzX1ZFQyh2ZWMsZGVzdCxhMSxhMixhMykJCQkJCVwNCiAoewls b25nIF9fcmVzOwkJCQkJCQlcDQogCWxvbmcgX19hMSA9IChsb25nKSAoYTEp OwkJCQkJXA0KIAlsb25nIF9fYTIgPSAobG9uZykgKGEyKTsJCQkJCVwNCiAJ bG9uZyBfX2EzID0gKGxvbmcpIChhMyk7CQkJCQlcDQotCWxvbmcgKCpfX3Zl YykobG9uZywgbG9uZywgbG9uZykJPSAodm9pZCAqKSByb212ZWMtPmRlc3Q7 CVwNCisJbG9uZyAoKl9fdmVjKShsb25nLCBsb25nLCBsb25nKQk9ICh2b2lk ICopICh2ZWMpLT5kZXN0OwlcDQogCQkJCQkJCQkJXA0KIAlfX3JlcyA9IF9f dmVjKF9fYTEsIF9fYTIsIF9fYTMpOwkJCQlcDQogCV9fcmVzOwkJCQkJCQkJ XA0KIH0pDQogDQotI2RlZmluZSBBUkNfQ0FMTDQoZGVzdCxhMSxhMixhMyxh NCkJCQkJCVwNCisjZGVmaW5lIEFSQ19DQUxMNF9WRUModmVjLGRlc3QsYTEs YTIsYTMsYTQpCQkJCQlcDQogKHsJbG9uZyBfX3JlczsJCQkJCQkJXA0KIAls b25nIF9fYTEgPSAobG9uZykgKGExKTsJCQkJCVwNCiAJbG9uZyBfX2EyID0g KGxvbmcpIChhMik7CQkJCQlcDQogCWxvbmcgX19hMyA9IChsb25nKSAoYTMp OwkJCQkJXA0KIAlsb25nIF9fYTQgPSAobG9uZykgKGE0KTsJCQkJCVwNCi0J bG9uZyAoKl9fdmVjKShsb25nLCBsb25nLCBsb25nLCBsb25nKSA9ICh2b2lk ICopIHJvbXZlYy0+ZGVzdDsJXA0KKwlsb25nICgqX192ZWMpKGxvbmcsIGxv bmcsIGxvbmcsIGxvbmcpID0gKHZvaWQgKikgKHZlYyktPmRlc3Q7CVwNCiAJ CQkJCQkJCQlcDQogCV9fcmVzID0gX192ZWMoX19hMSwgX19hMiwgX19hMywg X19hNCk7CQkJCVwNCiAJX19yZXM7CQkJCQkJCQlcDQogfSkNCiANCi0jZGVm aW5lIEFSQ19DQUxMNShkZXN0LGExLGEyLGEzLGE0LGE1KQkJCQkJXA0KKyNk ZWZpbmUgQVJDX0NBTEw1X1ZFQyh2ZWMsZGVzdCxhMSxhMixhMyxhNCxhNSkJ CQkJCVwNCiAoewlsb25nIF9fcmVzOwkJCQkJCQlcDQogCWxvbmcgX19hMSA9 IChsb25nKSAoYTEpOwkJCQkJXA0KIAlsb25nIF9fYTIgPSAobG9uZykgKGEy KTsJCQkJCVwNCkBAIC01MzYsMTEgKzU4OCwxOCBAQA0KIAlsb25nIF9fYTQg PSAobG9uZykgKGE0KTsJCQkJCVwNCiAJbG9uZyBfX2E1ID0gKGxvbmcpIChh NSk7CQkJCQlcDQogCWxvbmcgKCpfX3ZlYykobG9uZywgbG9uZywgbG9uZywg bG9uZywgbG9uZyk7CQkJXA0KLQlfX3ZlYyA9ICh2b2lkICopIHJvbXZlYy0+ ZGVzdDsJCQkJCVwNCisJX192ZWMgPSAodm9pZCAqKSAodmVjKS0+ZGVzdDsJ CQkJCVwNCiAJCQkJCQkJCQlcDQogCV9fcmVzID0gX192ZWMoX19hMSwgX19h MiwgX19hMywgX19hNCwgX19hNSk7CQkJXA0KIAlfX3JlczsJCQkJCQkJCVwN CiB9KQ0KICNlbmRpZiAvKiBib3RoIGtlcm5lbCBhbmQgQVJDIGVpdGhlciAz Mi1iaXQgb3IgNjQtYml0ICovDQogDQorI2RlZmluZSBBUkNfQ0FMTDAoZGVz dCkgQVJDX0NBTEwwX1ZFQyhyb212ZWMsZGVzdCkNCisjZGVmaW5lIEFSQ19D QUxMMShkZXN0LGExKSBBUkNfQ0FMTDFfVkVDKHJvbXZlYyxkZXN0LGExKQ0K KyNkZWZpbmUgQVJDX0NBTEwyKGRlc3QsYTEsYTIpIEFSQ19DQUxMMl9WRUMo cm9tdmVjLGRlc3QsYTEsYTIpDQorI2RlZmluZSBBUkNfQ0FMTDMoZGVzdCxh MSxhMixhMykgQVJDX0NBTEwzX1ZFQyhyb212ZWMsZGVzdCxhMSxhMixhMykN CisjZGVmaW5lIEFSQ19DQUxMNChkZXN0LGExLGEyLGEzLGE0KSBBUkNfQ0FM TDRfVkVDKHJvbXZlYyxkZXN0LGExLGEyLGEzLGE0KQ0KKyNkZWZpbmUgQVJD X0NBTEw1KGRlc3QsYTEsYTIsYTMsYTQsYTUpIEFSQ19DQUxMNV9WRUMocm9t dmVjLGRlc3QsYTEsYTIsYTMsYTQsYTUpDQorDQogI2VuZGlmIC8qIF9BU01f U0dJQVJDU19IICovDQo= --168484352-2043690147-1021368365=:14912-- From owner-linux-mips@oss.sgi.com Wed May 15 01:47:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4F8l3nC020718 for ; Wed, 15 May 2002 01:47:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4F8l3wA020717 for linux-mips-outgoing; Wed, 15 May 2002 01:47:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from brahma.intotoind.com ([202.56.196.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4F8kfnC020705 for ; Wed, 15 May 2002 01:46:46 -0700 Received: from localhost (rajeshbv@localhost) by brahma.intotoind.com (8.9.3/8.8.7) with ESMTP id OAA14608 for ; Wed, 15 May 2002 14:12:25 +0530 X-Authentication-Warning: brahma.intotoind.com: rajeshbv owned process doing -bs Date: Wed, 15 May 2002 14:12:25 +0530 (IST) From: Venkata Rajesh Bikkina X-Sender: rajeshbv@brahma.intotoind.com To: linux-mips@oss.sgi.com Subject: RAMDISK problem on 79s334A board. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi All, I am working on 79s334A board with 32MB RAM and Linux 2.4.13 kernel. I have module to be inserted into kernel. The size of the module will be around 1 MB. I am using two file systems while building kernel image, one is NFS and the other is RAMDISK. When i work with NFS i do not have any problem. But when i build RAMDISK image and insert the module, insmod is doing fine. But after that i could not invoke any other application ( even ps -ef is also giving segmentation fault.) The RAMDISK size choosen is 10MB and the memory on board is 32MB. When i did cat /proc/meminfo i found strange thing. All the figures are corrupted. The statistics before and after insmod are as follows: # cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 29237248 15319040 13918208 0 10240000 2908160 Swap: 0 0 0 MemTotal: 28552 kB MemFree: 13592 kB MemShared: 0 kB Buffers: 10000 kB Cached: 2840 kB Active: 12840 kB Inact_dirty: 0 kB Inact_clean: 0 kB Inact_target: 44 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 28552 kB LowFree: 13592 kB SwapTotal: 0 kB SwapFree: 0 kB # # # cd /igateway # /sbin/insmod igateway Intoto Firewall Installed. # # # /sbin/lsmod Module Size Used by igateway 967056 0 (unused) # # # cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: %8lu %8lu %8lu %8lu %8lu %8u Swap: %8lu %8lu %8lu MemTotal: %8lu kB MemFree: %8lu kB MemShared: %8lu kB Buffers: %8lu kB Cached: %8u kB Active: %8u kB Inact_dirty: %8u kB Inact_clean: %8u kB Inact_target: %8lu kB HighTotal: %8lu kB HighFree: %8lu kB LowTotal: %8lu kB LowFree: %8lu kB SwapTotal: %8lu kB SwapFree: %8lu kB # # # ps -ef PID Uid Gid State Command Segmentation fault # Can anybody give hint what is happening. Thanks and Regards, --Rajesh From owner-linux-mips@oss.sgi.com Wed May 15 04:24:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FBOHnC025952 for ; Wed, 15 May 2002 04:24:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FBOHBw025951 for linux-mips-outgoing; Wed, 15 May 2002 04:24:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FBOBnC025943 for ; Wed, 15 May 2002 04:24:15 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 177wWB-0001df-00; Wed, 15 May 2002 12:00:27 +0100 Subject: Re: RAMDISK problem on 79s334A board. To: rajeshbv@intotoinc.com (Venkata Rajesh Bikkina) Date: Wed, 15 May 2002 12:00:27 +0100 (BST) Cc: linux-mips@oss.sgi.com In-Reply-To: from "Venkata Rajesh Bikkina" at May 15, 2002 02:12:25 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 > But when i build RAMDISK image and insert the module, insmod is > doing fine. But after that i could not invoke any other application ( even > ps -ef is also giving segmentation fault.) Looks like your module corrupts the kernel. From owner-linux-mips@oss.sgi.com Wed May 15 05:05:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FC5knC029792 for ; Wed, 15 May 2002 05:05:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FC5kwG029791 for linux-mips-outgoing; Wed, 15 May 2002 05:05:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from brahma.intotoind.com ([202.56.196.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FC5anC029787 for ; Wed, 15 May 2002 05:05:40 -0700 Received: from localhost (rajeshbv@localhost) by brahma.intotoind.com (8.9.3/8.8.7) with ESMTP id RAA22405; Wed, 15 May 2002 17:30:50 +0530 X-Authentication-Warning: brahma.intotoind.com: rajeshbv owned process doing -bs Date: Wed, 15 May 2002 17:30:50 +0530 (IST) From: Venkata Rajesh Bikkina X-Sender: rajeshbv@brahma.intotoind.com To: Alan Cox cc: linux-mips@oss.sgi.com Subject: Re: RAMDISK problem on 79s334A board. 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 Hi Alan, Thankyou for your response. But the same module is working fine and kernel is also fine if i use NFS and insert the module. Any further info ? --Rajesh On Wed, 15 May 2002, Alan Cox wrote: > > But when i build RAMDISK image and insert the module, insmod is > > doing fine. But after that i could not invoke any other application ( even > > ps -ef is also giving segmentation fault.) > > Looks like your module corrupts the kernel. > From owner-linux-mips@oss.sgi.com Wed May 15 06:08:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FD8onC031945 for ; Wed, 15 May 2002 06:08:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FD8oTp031944 for linux-mips-outgoing; Wed, 15 May 2002 06:08:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from the-village.bc.nu (lightning.swansea.linux.org.uk [194.168.151.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FD8hnC031936 for ; Wed, 15 May 2002 06:08:46 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.33 #5) id 177ypv-0001up-00; Wed, 15 May 2002 14:28:59 +0100 Subject: Re: RAMDISK problem on 79s334A board. To: rajeshbv@intotoinc.com (Venkata Rajesh Bikkina) Date: Wed, 15 May 2002 14:28:59 +0100 (BST) Cc: alan@lxorguk.ukuu.org.uk (Alan Cox), linux-mips@oss.sgi.com In-Reply-To: from "Venkata Rajesh Bikkina" at May 15, 2002 05:30:50 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 > But the same module is working fine and kernel is also fine if i use NFS > and insert the module. > Any further info ? Not really. The fact it works with NFS and not ramdisk may simply be that in one case it corrupts memory that is used, and the other it corrupts memory that isnt From owner-linux-mips@oss.sgi.com Wed May 15 11:34:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FIYUnC015731 for ; Wed, 15 May 2002 11:34:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FIYUpB015730 for linux-mips-outgoing; Wed, 15 May 2002 11:34:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FIYPnC015724 for ; Wed, 15 May 2002 11:34:25 -0700 Received: from tip2 (ppp0613.va-tyo.hdd.co.jp [61.195.90.141]) 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 LAA02906 for ; Wed, 15 May 2002 11:34:45 -0700 (PDT) mail_from (complan27@hotmail.com) Received: from jobin ([192.168.0.90]) by tip2 (8.9.3+3.2W/3.7W) with SMTP id AAA12876 for linux-mips@oss.sgi.com; Sun, 6 May 2001 00:42:51 +0900 Message-Id: <200105051542.AAA12876@tip2> From: mail To: Date: Wed, 15 May 2002 16:22:07 +0900 Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISpFPj8mJVAlcyUvGyhC?= MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Oshirase-Mailer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk $B"#A49q$NM%NI?M:`>R2p2q?&EPO?$r9T$$$^$9!#(B http://snow.prohosting.com/tip4 http://webtips.is-here.net/ $B"($3$N%5!<%S%9$O40A4L5NA$G$9!#(B -------------------------------- $B"#E>?&%5%$%H$NJs=7@)%P%J!?&5a?&5G'(B $B?t$K1~$8$F!X(B1000$B1_(B/$B7o!Y99$KE>?&7h(B $BDj$G4pK\E*$K!X(B1O$BK|1_(B/$B7o!Y$r$*;YJ'(B $B$$CW$7$^$9!#(B $B"(1?1D\:Y$r$*Aw$j(B $BCW$7$^$9!#!c>\:Y4uK>!d(B jobveric@bigfoot.com$B!!(B -------------------------------- $B"(!Z2r=|![$O?=$7Lu$4$6$$$^$;$s$,(B $B!!!Z2r=|4uK>%a!<%k![$+$i2<5-$X(B $B!!!Z6u%a!<%k![$r$*Aw$j$/$@$5$k$h(B $B!!(B $B$&$*4j$$?=$7$"$2$^$9!#(B $B!!!J0c$&%a!<%k$+$iAwIU$5$l$k>l9g(B $B!!!!7oL>$K%"%I%l%9$r5-F~$/$@$5$$!K(B $B!!!!(Bremove.to@bigfoot.com $B%3%`%W%i%s4k2h(B($B%8%g%V%5!<%S%9(B) jobveric@bigfoot.com$B!!(B -------------------------------- From owner-linux-mips@oss.sgi.com Wed May 15 13:19:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FKJhnC031791 for ; Wed, 15 May 2002 13:19:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FKJhF7031790 for linux-mips-outgoing; Wed, 15 May 2002 13:19:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FKJQnC031780; Wed, 15 May 2002 13:19:26 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA29093; Wed, 15 May 2002 13:19:14 -0700 Message-ID: <3CE2C260.5070307@mvista.com> Date: Wed, 15 May 2002 13:17:36 -0700 From: Jun Sun 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: Linus Torvalds CC: Alan Cox , ralf@oss.sgi.com, linux-mips@oss.sgi.com, linuxppc-dev@lists.linuxppc.org Subject: [PATCH] smp sched typo Content-Type: multipart/mixed; boundary="------------000503080306050607030009" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------000503080306050607030009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Linus, I found this bug in 2.4 kernel. I have verified that the bug exists on MIPS SMP and PPC SMP, but not on i386 SMP. See the detailed explanation inside the patch. 2.5 sched.c has been re-written quite a bit and does not have this problem. http://linux.junsun.net/patches/generic/submitted/020515-2.4.18-smp-sched-typo.patch Jun --------------000503080306050607030009 Content-Type: text/plain; name="020515-2.4.18-smp-sched-typo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="020515-2.4.18-smp-sched-typo.patch" Gcc will optimizie out the whole 'if' branch on platforms where cycles_t is not unsigned long long (such as MIPS, PPC). The symptom for this bug is not fatal - perhaps that is ther reason why nobody has found it so far. Higher priority process will be delayed to start its execution. One of my tests shows on a heavy-loaded system the delay is about 5 to 6 jiffies. Jun, 020515 diff -Nru link/kernel/sched.c.orig link/kernel/sched.c --- link/kernel/sched.c.orig Fri Dec 21 09:42:04 2001 +++ link/kernel/sched.c Wed May 15 12:38:12 2002 @@ -282,7 +282,7 @@ target_tsk = tsk; } } else { - if (oldest_idle == -1ULL) { + if (oldest_idle == (cycles_t)-1) { int prio = preemption_goodness(tsk, p, cpu); if (prio > max_prio) { --------------000503080306050607030009-- From owner-linux-mips@oss.sgi.com Wed May 15 13:42:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FKgHnC032542 for ; Wed, 15 May 2002 13:42:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FKgHLM032541 for linux-mips-outgoing; Wed, 15 May 2002 13:42:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lars.roch.silverbacksystems.com ([209.180.49.225]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FKg5nC032535 for ; Wed, 15 May 2002 13:42:06 -0700 Received: from silverbacksystems.com (mars.roch.silverbacksystems.com [10.0.0.15]) by lars.roch.silverbacksystems.com (8.11.1/8.11.1) with ESMTP id g4FKgSU14382 for ; Wed, 15 May 2002 15:42:28 -0500 Message-ID: <3CE2C834.2010302@silverbacksystems.com> Date: Wed, 15 May 2002 15:42:28 -0500 From: Ken Aaker Organization: Silverback Systems User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Mangled struct hd_driveid with MIPSEB. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I've just run across an interesting problem building a big-endian MIPS kernel against the kernel source from the cvs tree. When the drive identity record is presented to the ide_fix_driveid() function in include/asm-mips/ide.h, it looks like its been byteswapped in 16 bit chunks. Needless to say, this causes a certain amount of confusion. I tried following the process back to the point where the data is read in, but I failed to find anything that seemed to be explicitly swapping the code. The older kernel that I have 2.4.3 works Ok, so it's something that's happened recently. Here's a little bit of debug information that I collected.. I messed around with the ide_fix_driveid function till I got the system to work, but I'm be embarassed to see that code escape into the wild. This is a dump of the id record before the call to ide_fix_driveid() in the 2.4.3 kernel. 0000: 7a42ff3f 00001000 00e15802 3f001000 "zB.?......X.?..." 0010: 00000e00 4457572d 41435441 34343430 "....DWW.ACTA4440" 0020: 33340034 00000000 03000010 28003630 "34.4..........60" 0030: 302e4734 36304457 20434457 30334530 "0.G460DW.CDW03E0" 0040: 2d423030 50433046 20202020 20202020 ".B00PC0F........" 0050: 20202020 20202020 20202020 20201080 "................" 0060: 0000002f 01408002 00000700 ff3f1000 ".....@.......?.." 0070: 3f0010fc fb000001 80ac7e03 00000704 "?.........~....." 0080: 03007800 78007800 78000000 00000000 "..x.x.x.x......." 0090: 00000000 00000000 00000000 00000000 "................" 00a0: 3e000000 6b34014b 00406934 01080040 ">...k4.K.@i4...@" 00b0: 3f000000 00000000 00004b60 fe800000 "?.........K`...." 00c0: 00000000 00000000 00000000 00000000 "................" 00d0: 00000000 00000000 00000000 00000000 "................" 00e0: 00000000 00000000 00000000 00000000 "................" 00f0: 00000000 00000000 00000000 00000000 "................" 0100: 01000000 00000000 00003300 00000000 "..........3....." 0110: 00000000 00000000 00000000 00000000 "................" 0120: 00000000 00000000 00000000 00000000 "................" 0130: 00000000 00000000 00000000 00001f00 "................" 0140: 00000000 00000000 00000000 00000000 "................" 0150: 00000000 00000000 00000000 00000000 "................" 0160: 00000000 00000000 00000000 00000000 "................" 0170: 00000000 00000000 00000000 00000000 "................" 0180: 00000000 00000000 00000000 00000000 "................" 0190: 00000000 00000000 00000000 00000000 "................" 01a0: 00000000 00000000 00000000 00000000 "................" 01b0: 00000000 00000000 00000000 00000000 "................" 01c0: 00000000 00000000 00000000 00000000 "................" 01d0: 00000000 00000000 00000000 00000000 "................" 01e0: 00000000 00000000 00000000 00000000 "................" 01f0: 00000000 00000000 00000000 0000a56e "...............n" This is a dump of the id record before the call to ide_fix_drived() in the 2.4.18 kernel from cvs. 0000: 427a3fff 00000010 e1000258 003f0010 "Bz?........X.?.." 0010: 0000000e 57442d57 43414154 34343034 "....WD.WCAAT4404" 0020: 34333400 00000000 00031000 00283036 "434...........06" 0030: 2e303447 30365744 43205744 33303045 ".04G06WDC.WD300E" 0040: 422d3030 43504630 20202020 20202020 "B.00CPF0........" 0050: 20202020 20202020 20202020 20208010 "................" 0060: 00002f00 40010280 00000007 3fff0010 "....@.......?..." 0070: 003ffc10 00fb0100 ac80037e 00000407 ".?.........~...." 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" 0090: 00000000 00000000 00000000 00000000 "................" 00a0: 003e0000 346b4b01 40003469 08014000 ".>..4kK.@.4i..@." 00b0: 003f0000 00000000 0000604b 80fe0000 ".?........`K...." 00c0: 00000000 00000000 00000000 00000000 "................" 00d0: 00000000 00000000 00000000 00000000 "................" 00e0: 00000000 00000000 00000000 00000000 "................" 00f0: 00000000 00000000 00000000 00000000 "................" 0100: 00010000 00000000 00000033 00000000 "...........3...." 0110: 00000000 00000000 00000000 00000000 "................" 0120: 00000000 00000000 00000000 00000000 "................" 0130: 00000000 00000000 00000000 0000001f "................" 0140: 00000000 00000000 00000000 00000000 "................" 0150: 00000000 00000000 00000000 00000000 "................" 0160: 00000000 00000000 00000000 00000000 "................" 0170: 00000000 00000000 00000000 00000000 "................" 0180: 00000000 00000000 00000000 00000000 "................" 0190: 00000000 00000000 00000000 00000000 "................" 01a0: 00000000 00000000 00000000 00000000 "................" 01b0: 00000000 00000000 00000000 00000000 "................" 01c0: 00000000 00000000 00000000 00000000 "................" 01d0: 00000000 00000000 00000000 00000000 "................" 01e0: 00000000 00000000 00000000 00000000 "................" 01f0: 00000000 00000000 00000000 00006ea5 "..............n." -- work -> kenaaker@silverbacksystems.com (507) 289-6910 ext 1 home -> kenaaker@screaminet.com From owner-linux-mips@oss.sgi.com Wed May 15 14:34:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FLYlnC002070 for ; Wed, 15 May 2002 14:34:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FLYlU6002069 for linux-mips-outgoing; Wed, 15 May 2002 14:34:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from host099.momenco.com (IDENT:root@jeeves.momenco.com [64.169.228.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FLYdnC002066 for ; Wed, 15 May 2002 14:34:44 -0700 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g4FLYm325834 for ; Wed, 15 May 2002 14:34:58 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: MIPS 64? Date: Wed, 15 May 2002 14:34:47 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk So... I'm looking at porting Linux to a system with 1.5GiB of RAM. That kinda blows the 32-bit MIPS port option right out of the water... What does it take to do a 64-bit port? The first problem I see is the boot loader -- do I have to be in 64-bit mode when the kernel starts, or can I start in 32-bit mode and then transfer to 64-bit mode? I looked in the arch/mips64/ directory, but I don't see much for specific boards there, but there are references to the Malta boards.... 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 From owner-linux-mips@oss.sgi.com Wed May 15 14:48:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FLmbnC002288 for ; Wed, 15 May 2002 14:48:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FLmbGb002287 for linux-mips-outgoing; Wed, 15 May 2002 14:48:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (mail@NEVYN.RES.CMU.EDU [128.2.145.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FLmWnC002284 for ; Wed, 15 May 2002 14:48:32 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 1786d8-0000WX-00; Wed, 15 May 2002 17:48:18 -0400 Date: Wed, 15 May 2002 17:48:18 -0400 From: Daniel Jacobowitz To: Matthew Dharm Cc: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020515214818.GA1991@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.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > That kinda blows the 32-bit MIPS port option right out of the water... Not unless you count bits differently than I do... 32-bit is 4 GiB. Is there any reason MIPS has special problems in this area? > > What does it take to do a 64-bit port? The first problem I see is the > boot loader -- do I have to be in 64-bit mode when the kernel starts, > or can I start in 32-bit mode and then transfer to 64-bit mode? > > I looked in the arch/mips64/ directory, but I don't see much for > specific boards there, but there are references to the Malta > boards.... > > 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 > > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed May 15 14:55:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FLtInC002410 for ; Wed, 15 May 2002 14:55:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FLtIt7002409 for linux-mips-outgoing; Wed, 15 May 2002 14:55:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FLtCnC002406 for ; Wed, 15 May 2002 14:55:12 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 15 May 2002 14:55:11 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA24404; Wed, 15 May 2002 14:55:40 -0700 (PDT) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id OAA19106; Wed, 15 May 2002 14:55:39 -0700 (PDT) Message-ID: <3CE2D95B.E1E43662@broadcom.com> Date: Wed, 15 May 2002 14:55:39 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew Dharm" cc: Linux-MIPS Subject: Re: MIPS 64? References: <20020515214818.GA1991@nevyn.them.org> X-WSS-ID: 10FC06B5660008-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Since traditionally the mips kernel could only manage RAM reachable by Kseg you were limited to 512MB, right? But now the High Memory stuff is stable enough that you can reach any RAM that's physically addressable in 32-bits. And after that, there's the 64bit-physical-address extension which allows you to reach physical pages that need > 32-bits to address. Kip Daniel Jacobowitz wrote: > > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > > That kinda blows the 32-bit MIPS port option right out of the water... > > Not unless you count bits differently than I do... 32-bit is 4 GiB. Is > there any reason MIPS has special problems in this area? > > > > > What does it take to do a 64-bit port? The first problem I see is the > > boot loader -- do I have to be in 64-bit mode when the kernel starts, > > or can I start in 32-bit mode and then transfer to 64-bit mode? > > > > I looked in the arch/mips64/ directory, but I don't see much for > > specific boards there, but there are references to the Malta > > boards.... > > > > 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 > > > > > > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed May 15 15:01:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FM1VnC002595 for ; Wed, 15 May 2002 15:01:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FM1VMU002594 for linux-mips-outgoing; Wed, 15 May 2002 15:01:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FM1QnC002591 for ; Wed, 15 May 2002 15:01:26 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA32360; Wed, 15 May 2002 15:01:12 -0700 Message-ID: <3CE2DA46.3070402@mvista.com> Date: Wed, 15 May 2002 14:59:34 -0700 From: Jun Sun 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: Daniel Jacobowitz CC: Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? References: <20020515214818.GA1991@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Daniel Jacobowitz wrote: > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > >>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. >>That kinda blows the 32-bit MIPS port option right out of the water... >> > > Not unless you count bits differently than I do... 32-bit is 4 GiB. Is > there any reason MIPS has special problems in this area? > MIPS has lower 2GB fixed for user space. Then you have kseg0, .5GB for cached physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping of the same area. You can map another 1GB of RAM into kseg2/3, but you will then have no space left for IO. So you really can't do 1.5GB on 32 bit kernel. It is interesting that PPC allows one to adjust user space size and kernel space size. So on PPC you can get up to 2.5GB system RAM with 1GB user space. Back to 64bit port, it seems to me much of the 32bit work we have done in the past a year or so needs to be moved over. Or better yet, if we can clean up integer/long issues, we might be able to use 32bit kernel code straight for 64bit kernel. Jun From owner-linux-mips@oss.sgi.com Wed May 15 15:08:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FM8fnC002729 for ; Wed, 15 May 2002 15:08:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FM8fEr002728 for linux-mips-outgoing; Wed, 15 May 2002 15:08:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from host099.momenco.com (IDENT:root@jeeves.momenco.com [64.169.228.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FM8RnC002725 for ; Wed, 15 May 2002 15:08:32 -0700 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g4FM85326028; Wed, 15 May 2002 15:08:25 -0700 From: "Matthew Dharm" To: Cc: "Linux-MIPS" Subject: RE: MIPS 64? Date: Wed, 15 May 2002 15:08:05 -0700 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) Importance: Normal In-Reply-To: <3CE2D95B.E1E43662@broadcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I don't suppose anyone has a primer or white paper on the High Memory stuff? i.e. Applications, requirements, or a quick HOWTO? 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: kwalker@broadcom.com [mailto:kwalker@broadcom.com] > Sent: Wednesday, May 15, 2002 2:56 PM > To: Matthew Dharm > Cc: Linux-MIPS > Subject: Re: MIPS 64? > > > > Since traditionally the mips kernel could only manage RAM > reachable by > Kseg you were limited to 512MB, right? But now the High > Memory stuff is > stable enough that you can reach any RAM that's physically > addressable > in 32-bits. And after that, there's the 64bit-physical-address > extension which allows you to reach physical pages that > need > 32-bits > to address. > > Kip > > Daniel Jacobowitz wrote: > > > > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > > So... I'm looking at porting Linux to a system with > 1.5GiB of RAM. > > > That kinda blows the 32-bit MIPS port option right out > of the water... > > > > Not unless you count bits differently than I do... 32-bit > is 4 GiB. Is > > there any reason MIPS has special problems in this area? > > > > > > > > What does it take to do a 64-bit port? The first > problem I see is the > > > boot loader -- do I have to be in 64-bit mode when the > kernel starts, > > > or can I start in 32-bit mode and then transfer to 64-bit mode? > > > > > > I looked in the arch/mips64/ directory, but I don't see much for > > > specific boards there, but there are references to the Malta > > > boards.... > > > > > > 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 > > > > > > > > > > -- > > Daniel Jacobowitz Carnegie > Mellon University > > MontaVista Software Debian > GNU/Linux Developer > From owner-linux-mips@oss.sgi.com Wed May 15 15:14:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMEhnC002818 for ; Wed, 15 May 2002 15:14:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMEhTP002817 for linux-mips-outgoing; Wed, 15 May 2002 15:14:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMEenC002814 for ; Wed, 15 May 2002 15:14:40 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 15 May 2002 15:14:39 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA27831; Wed, 15 May 2002 15:15:08 -0700 (PDT) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id PAA26148; Wed, 15 May 2002 15:15:07 -0700 (PDT) Message-ID: <3CE2DDEB.5DA6E868@broadcom.com> Date: Wed, 15 May 2002 15:15:07 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew Dharm" cc: Linux-MIPS Subject: Re: MIPS 64? References: X-WSS-ID: 10FC0245663904-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Matthew Dharm wrote: > > I don't suppose anyone has a primer or white paper on the High Memory > stuff? i.e. Applications, requirements, or a quick HOWTO? Well, the CONFIG option is at the bottom of the Machine Selection menu. With a fairly recent 2.4 or 2.5 kernel, it should build at work. Basically, if your firmware/boot code conveys info about regions above physical address 0x1fffffff, the kernel will allocate "struct page" entries for it, and add them to the pool of allocatable memory. The kernel gets at them by mapping them into Kseg2/Kseg3 temporarily. turn it on, see what happens! I haven't looked for a primer. Kip From owner-linux-mips@oss.sgi.com Wed May 15 15:17:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMHGnC002915 for ; Wed, 15 May 2002 15:17:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMHGBh002914 for linux-mips-outgoing; Wed, 15 May 2002 15:17:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from host099.momenco.com (IDENT:root@jeeves.momenco.com [64.169.228.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMH2nC002911 for ; Wed, 15 May 2002 15:17:07 -0700 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g4FMGT326080; Wed, 15 May 2002 15:16:39 -0700 From: "Matthew Dharm" To: "Jun Sun" , "Daniel Jacobowitz" Cc: "Linux-MIPS" Subject: RE: MIPS 64? Date: Wed, 15 May 2002 15:16:29 -0700 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) Importance: Normal In-Reply-To: <3CE2DA46.3070402@mvista.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I personally think it's long overdue that we really invest some time/effort in the 64-bit version. I mean, anything past 0.5 GiB is really a hack on 32-bit.... I, for one, am willing to lend a pair of hands to this... but I need to know what needs doing, first. Could someone give me an overview of how you're supposed to do a handoff between a 32-bit loader and a 64-bit app? I'm guessing there has to be a way to do it, but what I do know about the 64-bit stuff doesn't show me how this is accomplished (I have visions of UX bits floating in my head...) 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 Jun Sun > Sent: Wednesday, May 15, 2002 3:00 PM > To: Daniel Jacobowitz > Cc: Matthew Dharm; Linux-MIPS > Subject: Re: MIPS 64? > > > Daniel Jacobowitz wrote: > > > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > > >>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > >>That kinda blows the 32-bit MIPS port option right out of > the water... > >> > > > > Not unless you count bits differently than I do... 32-bit > is 4 GiB. Is > > there any reason MIPS has special problems in this area? > > > > > MIPS has lower 2GB fixed for user space. Then you have > kseg0, .5GB for cached > physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping > of the same area. > You can map another 1GB of RAM into kseg2/3, but you will > then have no space > left for IO. > > So you really can't do 1.5GB on 32 bit kernel. > > It is interesting that PPC allows one to adjust user space > size and kernel > space size. So on PPC you can get up to 2.5GB system RAM > with 1GB user space. > > Back to 64bit port, it seems to me much of the 32bit work > we have done in the > past a year or so needs to be moved over. Or better yet, > if we can clean up > integer/long issues, we might be able to use 32bit kernel > code straight for > 64bit kernel. > > > Jun > > From owner-linux-mips@oss.sgi.com Wed May 15 15:26:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMQVnC003045 for ; Wed, 15 May 2002 15:26:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMQVGb003044 for linux-mips-outgoing; Wed, 15 May 2002 15:26:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from host099.momenco.com (IDENT:root@jeeves.momenco.com [64.169.228.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMQKnC003039 for ; Wed, 15 May 2002 15:26:25 -0700 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g4FMQ8326132; Wed, 15 May 2002 15:26:18 -0700 From: "Matthew Dharm" To: "Kip Walker" Cc: "Linux-MIPS" Subject: RE: MIPS 64? Date: Wed, 15 May 2002 15:26:08 -0700 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) Importance: Normal In-Reply-To: <3CE2DDEB.5DA6E868@broadcom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Right.... So, how should my boot code convey that info? With more add_memory_region() calls? Is that really all I need? 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 Kip Walker > Sent: Wednesday, May 15, 2002 3:15 PM > To: Matthew Dharm > Cc: Linux-MIPS > Subject: Re: MIPS 64? > > > Matthew Dharm wrote: > > > > I don't suppose anyone has a primer or white paper on the > High Memory > > stuff? i.e. Applications, requirements, or a quick HOWTO? > > Well, the CONFIG option is at the bottom of the Machine > Selection menu. > With a fairly recent 2.4 or 2.5 kernel, it should build at work. > Basically, if your firmware/boot code conveys info about > regions above > physical address 0x1fffffff, the kernel will allocate "struct page" > entries for it, and add them to the pool of allocatable memory. The > kernel gets at them by mapping them into Kseg2/Kseg3 temporarily. > > turn it on, see what happens! I haven't looked for a primer. > > Kip > From owner-linux-mips@oss.sgi.com Wed May 15 15:28:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMSfnC003143 for ; Wed, 15 May 2002 15:28:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMSfIg003142 for linux-mips-outgoing; Wed, 15 May 2002 15:28:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMSYnC003139 for ; Wed, 15 May 2002 15:28:34 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Wed, 15 May 2002 15:28:59 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA00011; Wed, 15 May 2002 15:29:01 -0700 (PDT) Received: from broadcom.com (kwalker@dt-sj3-158 [10.21.64.158]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with ESMTP id PAA01292; Wed, 15 May 2002 15:29:01 -0700 (PDT) Message-ID: <3CE2E12D.89DD6545@broadcom.com> Date: Wed, 15 May 2002 15:29:01 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Matthew Dharm" cc: Linux-MIPS Subject: Re: MIPS 64? References: X-WSS-ID: 10FC3EA1704813-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Yes... in my environment, I have firmware calls to find out what physical memory exists, then I call add_memory_region as necessary. See arch/mips/sibyte/swarm/setup.c if you're interested. Nothing too interesting about it. Kip Matthew Dharm wrote: > > Right.... > > So, how should my boot code convey that info? With more > add_memory_region() calls? Is that really all I need? > > 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 Kip Walker > > Sent: Wednesday, May 15, 2002 3:15 PM > > To: Matthew Dharm > > Cc: Linux-MIPS > > Subject: Re: MIPS 64? > > > > > > Matthew Dharm wrote: > > > > > > I don't suppose anyone has a primer or white paper on the > > High Memory > > > stuff? i.e. Applications, requirements, or a quick HOWTO? > > > > Well, the CONFIG option is at the bottom of the Machine > > Selection menu. > > With a fairly recent 2.4 or 2.5 kernel, it should build at work. > > Basically, if your firmware/boot code conveys info about > > regions above > > physical address 0x1fffffff, the kernel will allocate "struct page" > > entries for it, and add them to the pool of allocatable memory. The > > kernel gets at them by mapping them into Kseg2/Kseg3 temporarily. > > > > turn it on, see what happens! I haven't looked for a primer. > > > > Kip > > From owner-linux-mips@oss.sgi.com Wed May 15 15:51:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FMponC003711 for ; Wed, 15 May 2002 15:51:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FMpokZ003710 for linux-mips-outgoing; Wed, 15 May 2002 15:51:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FMplnC003707 for ; Wed, 15 May 2002 15:51:48 -0700 Received: from nebulas.demon.co.uk ([194.222.197.186] helo=there) by anchor-post-34.mail.demon.net with smtp (Exim 3.35 #1) id 1787d0-0008kU-0Y for linux-mips@oss.sgi.com; Wed, 15 May 2002 23:52:14 +0100 Content-Type: text/plain; charset="iso-8859-15" From: "Luke A. Guest" To: linux-mips@oss.sgi.com Subject: Indigo2 status Date: Wed, 15 May 2002 23:53:31 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I was just wondering about the I2 graphic board situtation. AFAIK, there is currently no working code for them (although someon just posted a patch for ARC PROM console). I was wondering whether it is actually possible to write the necessary drivers, i.e. Are there people in SGI that are capable of giving the information necessary, considering that there are no documents available? Thanks, Luke. From owner-linux-mips@oss.sgi.com Wed May 15 16:38:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4FNcXnC004187 for ; Wed, 15 May 2002 16:38:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4FNcX9v004186 for linux-mips-outgoing; Wed, 15 May 2002 16:38:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4FNcSnC004182 for ; Wed, 15 May 2002 16:38:29 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7735A8CA; Thu, 16 May 2002 01:38:55 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id F087B3711E; Thu, 16 May 2002 01:38:23 +0200 (CEST) Date: Thu, 16 May 2002 01:38:23 +0200 From: Florian Lohoff To: "Luke A. Guest" Cc: linux-mips@oss.sgi.com Subject: Re: Indigo2 status Message-ID: <20020515233823.GA25140@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 15, 2002 at 11:53:31PM +0100, Luke A. Guest wrote: > drivers, i.e. Are there people in SGI that are capable of giving the=20 > information necessary, considering that there are no documents available? As long as nobody knows whats going on in Hard/Software noone can sue you over patent or copyright violation. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --8t9RHnE3ZwKMSgU+ 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 iD8DBQE84vFvUaz2rXW+gJcRAkXDAJ4pa7II2xH9PQnqHF1NG/sRh/wASgCfSU4+ cTHm3U3/sntLBG7CzTsTGpw= =wK19 -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-linux-mips@oss.sgi.com Wed May 15 20:30:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G3U2nC012304 for ; Wed, 15 May 2002 20:30:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G3U1B9012303 for linux-mips-outgoing; Wed, 15 May 2002 20:30:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from tibook.netx4.com (x1000-57.tellink.net [63.161.110.249]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G3TvnC012293 for ; Wed, 15 May 2002 20:29:57 -0700 Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1]) by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id g4G3SIP00680; Wed, 15 May 2002 23:28:22 -0400 Message-ID: <3CE32752.80109@embeddededge.com> Date: Wed, 15 May 2002 23:28:18 -0400 From: Dan Malek Organization: Embedded Edge, LLC. User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jun Sun CC: Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > So you really can't do 1.5GB on 32 bit kernel. > > It is interesting that PPC allows one to adjust user space size and > kernel space size. So on PPC you can get up to 2.5GB system RAM with > 1GB user space. Don't be confusing virtual/physical addressing. The highmem stuff allows access to larger physical address space by providing "windows" through the virtual space. The memory space configuration on PPC was done before highmem was working properly, but it has remained as an embedded configuration option. When using highmem, you obviously can't map all of the physical memory at once, so your applications and drivers have to coordinate what is mapped at a single instance. The PPC configuration option gives us a little flexibility to allow a little more kernel mapping for drivers when it is necessary (or to work around weird I/O mapping problems). Thanks. -- Dan From owner-linux-mips@oss.sgi.com Wed May 15 23:54:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G6s3nC014240 for ; Wed, 15 May 2002 23:54:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G6s3wD014239 for linux-mips-outgoing; Wed, 15 May 2002 23:54:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G6rmnC014235 for ; Wed, 15 May 2002 23:53:48 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id XAA28376; Wed, 15 May 2002 23:54:02 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA07807; Wed, 15 May 2002 23:54:04 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4G6s4b13486; Thu, 16 May 2002 08:54:05 +0200 (MEST) Message-ID: <3CE3578C.CF29A2D6@mips.com> Date: Thu, 16 May 2002 08:54:04 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ken Aaker CC: linux-mips@oss.sgi.com Subject: Re: Mangled struct hd_driveid with MIPSEB. References: <3CE2C834.2010302@silverbacksystems.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I send Ralf a fix a couple of weeks ago, which introduced the byteswapping, which really is necessary. This fix is probably only necessary for bigendian systems with large IDE disks (>8GB), which support LBA mode. I send this patch over a year ago. I discovered that when I ran on a disk, which was larger than 8GB, it was only treated as 8GB. The problem with the fix is, it is not backward compatible. After the fix I needed to reinstall my bigendian system. As I told Ralf, this fix will be a pain for everyone, but I guess we need the fix eventually. If you don't want to reinstall your system then get rid of the code in the "ifdef __MIPSEB__" statements in include/asm-mips/ide.h /Carsten Ken Aaker wrote: > I've just run across an interesting problem building a big-endian MIPS > kernel against the kernel source from the cvs tree. When the drive > identity record is presented to the ide_fix_driveid() function in > include/asm-mips/ide.h, it looks like its been byteswapped in 16 bit > chunks. Needless to say, this causes a certain amount of confusion. I > tried following the process back to the point where the data is read in, > but I failed to find anything that seemed to be explicitly swapping the > code. The older kernel that I have 2.4.3 works Ok, so it's something > that's happened recently. Here's a little bit of debug information that > I collected.. I messed around with the ide_fix_driveid function till I > got the system to work, but I'm be embarassed to see that code escape > into the wild. > > This is a dump of the id record before the call to ide_fix_driveid() in > the 2.4.3 kernel. > 0000: 7a42ff3f 00001000 00e15802 3f001000 "zB.?......X.?..." > 0010: 00000e00 4457572d 41435441 34343430 "....DWW.ACTA4440" > 0020: 33340034 00000000 03000010 28003630 "34.4..........60" > 0030: 302e4734 36304457 20434457 30334530 "0.G460DW.CDW03E0" > 0040: 2d423030 50433046 20202020 20202020 ".B00PC0F........" > 0050: 20202020 20202020 20202020 20201080 "................" > 0060: 0000002f 01408002 00000700 ff3f1000 ".....@.......?.." > 0070: 3f0010fc fb000001 80ac7e03 00000704 "?.........~....." > 0080: 03007800 78007800 78000000 00000000 "..x.x.x.x......." > 0090: 00000000 00000000 00000000 00000000 "................" > 00a0: 3e000000 6b34014b 00406934 01080040 ">...k4.K.@i4...@" > 00b0: 3f000000 00000000 00004b60 fe800000 "?.........K`...." > 00c0: 00000000 00000000 00000000 00000000 "................" > 00d0: 00000000 00000000 00000000 00000000 "................" > 00e0: 00000000 00000000 00000000 00000000 "................" > 00f0: 00000000 00000000 00000000 00000000 "................" > 0100: 01000000 00000000 00003300 00000000 "..........3....." > 0110: 00000000 00000000 00000000 00000000 "................" > 0120: 00000000 00000000 00000000 00000000 "................" > 0130: 00000000 00000000 00000000 00001f00 "................" > 0140: 00000000 00000000 00000000 00000000 "................" > 0150: 00000000 00000000 00000000 00000000 "................" > 0160: 00000000 00000000 00000000 00000000 "................" > 0170: 00000000 00000000 00000000 00000000 "................" > 0180: 00000000 00000000 00000000 00000000 "................" > 0190: 00000000 00000000 00000000 00000000 "................" > 01a0: 00000000 00000000 00000000 00000000 "................" > 01b0: 00000000 00000000 00000000 00000000 "................" > 01c0: 00000000 00000000 00000000 00000000 "................" > 01d0: 00000000 00000000 00000000 00000000 "................" > 01e0: 00000000 00000000 00000000 00000000 "................" > 01f0: 00000000 00000000 00000000 0000a56e "...............n" > > This is a dump of the id record before the call to ide_fix_drived() in > the 2.4.18 kernel from cvs. > > 0000: 427a3fff 00000010 e1000258 003f0010 "Bz?........X.?.." > 0010: 0000000e 57442d57 43414154 34343034 "....WD.WCAAT4404" > 0020: 34333400 00000000 00031000 00283036 "434...........06" > 0030: 2e303447 30365744 43205744 33303045 ".04G06WDC.WD300E" > 0040: 422d3030 43504630 20202020 20202020 "B.00CPF0........" > 0050: 20202020 20202020 20202020 20208010 "................" > 0060: 00002f00 40010280 00000007 3fff0010 "....@.......?..." > 0070: 003ffc10 00fb0100 ac80037e 00000407 ".?.........~...." > 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" > 0090: 00000000 00000000 00000000 00000000 "................" > 00a0: 003e0000 346b4b01 40003469 08014000 ".>..4kK.@.4i..@." > 00b0: 003f0000 00000000 0000604b 80fe0000 ".?........`K...." > 00c0: 00000000 00000000 00000000 00000000 "................" > 00d0: 00000000 00000000 00000000 00000000 "................" > 00e0: 00000000 00000000 00000000 00000000 "................" > 00f0: 00000000 00000000 00000000 00000000 "................" > 0100: 00010000 00000000 00000033 00000000 "...........3...." > 0110: 00000000 00000000 00000000 00000000 "................" > 0120: 00000000 00000000 00000000 00000000 "................" > 0130: 00000000 00000000 00000000 0000001f "................" > 0140: 00000000 00000000 00000000 00000000 "................" > 0150: 00000000 00000000 00000000 00000000 "................" > 0160: 00000000 00000000 00000000 00000000 "................" > 0170: 00000000 00000000 00000000 00000000 "................" > 0180: 00000000 00000000 00000000 00000000 "................" > 0190: 00000000 00000000 00000000 00000000 "................" > 01a0: 00000000 00000000 00000000 00000000 "................" > 01b0: 00000000 00000000 00000000 00000000 "................" > 01c0: 00000000 00000000 00000000 00000000 "................" > 01d0: 00000000 00000000 00000000 00000000 "................" > 01e0: 00000000 00000000 00000000 00000000 "................" > 01f0: 00000000 00000000 00000000 00006ea5 "..............n." > > -- > work -> kenaaker@silverbacksystems.com (507) 289-6910 ext 1 > home -> kenaaker@screaminet.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 May 16 00:09:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G79dnC014455 for ; Thu, 16 May 2002 00:09:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G79d5o014454 for linux-mips-outgoing; Thu, 16 May 2002 00:09:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G79XnC014451 for ; Thu, 16 May 2002 00:09:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA28705; Thu, 16 May 2002 00:09:53 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA08193; Thu, 16 May 2002 00:09:48 -0700 (PDT) Message-ID: <007a01c1fca9$86e14f70$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" , "Daniel Jacobowitz" Cc: "Matthew Dharm" , "Linux-MIPS" References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> Subject: Re: MIPS 64? Date: Thu, 16 May 2002 09:15:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > Daniel Jacobowitz wrote: > > > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > > >>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > >>That kinda blows the 32-bit MIPS port option right out of the water... > >> > > > > Not unless you count bits differently than I do... 32-bit is 4 GiB. Is > > there any reason MIPS has special problems in this area? > > > > > MIPS has lower 2GB fixed for user space. Then you have kseg0, .5GB for cached > physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping of the same area. > You can map another 1GB of RAM into kseg2/3, but you will then have no space > left for IO. > > So you really can't do 1.5GB on 32 bit kernel. Is this to say that Linux cannot function unless all physical memory on the system is mapped at all times into kernel space? I would have thought that (a) all that really needs to be mapped is all memory used by the kernel itself, plus that of the currently active process (which is mapped in the 2GB kuseg), and that (b) one could anyway manage kseg2 or 3 dynamically to provide a window into a larger physical memory, and that this window could be used for any functions that need to do arbitrary phys-to-phys copies. I'm not sure what people's definition of a "64-bit kernel" is around here, but to me, that's a kernel which supports 64-bit virtual addressing and 64-bit registers. It strikes me as being rather foolish to impose the overhead of all that on people whose only real requirement is 2G of RAM on a 32-bit CPU. Particularly when many of the new MIPS parts that could plausibly be connected to 2GB RAM arrays, such as the Alchemy/AMD and MIPS 4K parts, don't support 64-bit operation. So running away from the problem isn't really an option. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Thu May 16 01:42:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G8gjnC015503 for ; Thu, 16 May 2002 01:42:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G8gjts015502 for linux-mips-outgoing; Thu, 16 May 2002 01:42:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G8gZnC015499 for ; Thu, 16 May 2002 01:42:38 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA11675; Thu, 16 May 2002 10:39:16 +0200 (MET DST) Date: Thu, 16 May 2002 10:39:16 +0200 (MEST) From: Geert Uytterhoeven To: Carsten Langgaard cc: Ken Aaker , Linux/MIPS Development Subject: Re: Mangled struct hd_driveid with MIPSEB. In-Reply-To: <3CE3578C.CF29A2D6@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 16 May 2002, Carsten Langgaard wrote: > I send Ralf a fix a couple of weeks ago, which introduced the byteswapping, > which really is necessary. > This fix is probably only necessary for bigendian systems with large IDE > disks (>8GB), which support LBA mode. > I send this patch over a year ago. I discovered that when I ran on a disk, > which was larger than 8GB, it was only treated as 8GB. > The problem with the fix is, it is not backward compatible. After the fix > I needed to reinstall my bigendian system. > As I told Ralf, this fix will be a pain for everyone, but I guess we need > the fix eventually. Why would you have to reinstall the system? Isn't this just a problem with ide_fix_driveid() (new field for disks larger than 8 GiB, which we don't byteswap yet)? 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 May 16 01:52:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4G8qfnC015701 for ; Thu, 16 May 2002 01:52:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4G8qfSM015700 for linux-mips-outgoing; Thu, 16 May 2002 01:52:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4G8qbnC015697 for ; Thu, 16 May 2002 01:52:37 -0700 Received: from mail.avanticore.com (firewall.i-data.com [195.24.22.194]) 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 BAA04773 for ; Thu, 16 May 2002 01:52:58 -0700 (PDT) mail_from (tch@avanticore.com) Received: from avanticore.com ([172.17.159.1]) by mail.avanticore.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 16 May 2002 10:50:51 +0200 Message-ID: <3CE37364.945C40A7@avanticore.com> Date: Thu, 16 May 2002 10:52:52 +0200 From: "Tommy S. Christensen" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Venkata Rajesh Bikkina CC: Alan Cox , linux-mips@oss.sgi.com Subject: Re: RAMDISK problem on 79s334A board. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2002 08:50:51.0278 (UTC) FILETIME=[C80012E0:01C1FCB6] Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alan Cox wrote: > > > But the same module is working fine and kernel is also fine if i use NFS > > and insert the module. > > Any further info ? > > Not really. The fact it works with NFS and not ramdisk may simply be that > in one case it corrupts memory that is used, and the other it corrupts > memory that isnt Using a ramdisk increases the pressure on memory. So the difference could be that one case hits the cache aliasing problem, the other doesn't. Try this patch and see if it helps. -Tommy Index: mm/vmalloc.c =================================================================== RCS file: /cvs/linux/mm/vmalloc.c,v retrieving revision 1.28 retrieving revision 1.28.2.1 diff -u -r1.28 -r1.28.2.1 --- mm/vmalloc.c 2001/10/19 01:25:06 1.28 +++ mm/vmalloc.c 2001/12/28 21:06:01 1.28.2.1 @@ -163,6 +163,7 @@ ret = 0; } while (address && (address < end)); spin_unlock(&init_mm.page_table_lock); + flush_cache_all(); return ret; } From owner-linux-mips@oss.sgi.com Thu May 16 03:07:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GA7gnC016418 for ; Thu, 16 May 2002 03:07:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GA7g2I016417 for linux-mips-outgoing; Thu, 16 May 2002 03:07:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GA7anC016414 for ; Thu, 16 May 2002 03:07:36 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id DAA01114; Thu, 16 May 2002 03:06:36 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id DAA11608; Thu, 16 May 2002 03:06:37 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4GA6cb29525; Thu, 16 May 2002 12:06:38 +0200 (MEST) Message-ID: <3CE384AD.8DE96FEF@mips.com> Date: Thu, 16 May 2002 12:06:37 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Geert Uytterhoeven CC: Ken Aaker , Linux/MIPS Development Subject: Re: Mangled struct hd_driveid with MIPSEB. References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Geert Uytterhoeven wrote: > On Thu, 16 May 2002, Carsten Langgaard wrote: > > I send Ralf a fix a couple of weeks ago, which introduced the byteswapping, > > which really is necessary. > > This fix is probably only necessary for bigendian systems with large IDE > > disks (>8GB), which support LBA mode. > > I send this patch over a year ago. I discovered that when I ran on a disk, > > which was larger than 8GB, it was only treated as 8GB. > > The problem with the fix is, it is not backward compatible. After the fix > > I needed to reinstall my bigendian system. > > As I told Ralf, this fix will be a pain for everyone, but I guess we need > > the fix eventually. > > Why would you have to reinstall the system? > Isn't this just a problem with ide_fix_driveid() (new field for disks larger > than 8 GiB, which we don't byteswap yet)? I'm trying to do things like other bigendian architectures. I can see your mail address is linux-m68k and the fix is more or less stolen from the m68k part. > > 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 -- _ _ ____ ___ 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 May 16 03:28:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GAS3nC016614 for ; Thu, 16 May 2002 03:28:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GAS3U6016613 for linux-mips-outgoing; Thu, 16 May 2002 03:28:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from brahma.intotoind.com ([202.56.196.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GARpnC016610 for ; Thu, 16 May 2002 03:27:54 -0700 Received: from localhost (rajeshbv@localhost) by brahma.intotoind.com (8.9.3/8.8.7) with ESMTP id PAA01553; Thu, 16 May 2002 15:52:57 +0530 X-Authentication-Warning: brahma.intotoind.com: rajeshbv owned process doing -bs Date: Thu, 16 May 2002 15:52:57 +0530 (IST) From: Venkata Rajesh Bikkina X-Sender: rajeshbv@brahma.intotoind.com To: "Tommy S. Christensen" cc: Alan Cox , linux-mips@oss.sgi.com Subject: Re: RAMDISK problem on 79s334A board. In-Reply-To: <3CE37364.945C40A7@avanticore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi Tommy, I am using 2.4.3 code and in that linux/mm/vmallo.c contains the following code which is slightly different from the patch you gave. } while (address && (address < end)); unlock_kernel(); flush_tlb_all(); return ret; Can you please suggest how to modify this. Regards, --Rajesh On Thu, 16 May 2002, Tommy S. Christensen wrote: > Alan Cox wrote: > > > > > But the same module is working fine and kernel is also fine if i use NFS > > > and insert the module. > > > Any further info ? > > > > Not really. The fact it works with NFS and not ramdisk may simply be that > > in one case it corrupts memory that is used, and the other it corrupts > > memory that isnt > > Using a ramdisk increases the pressure on memory. So the difference could > be that one case hits the cache aliasing problem, the other doesn't. > > Try this patch and see if it helps. > > -Tommy > > > > Index: mm/vmalloc.c > =================================================================== > RCS file: /cvs/linux/mm/vmalloc.c,v > retrieving revision 1.28 > retrieving revision 1.28.2.1 > diff -u -r1.28 -r1.28.2.1 > --- mm/vmalloc.c 2001/10/19 01:25:06 1.28 > +++ mm/vmalloc.c 2001/12/28 21:06:01 1.28.2.1 > @@ -163,6 +163,7 @@ > ret = 0; > } while (address && (address < end)); > spin_unlock(&init_mm.page_table_lock); > + flush_cache_all(); > return ret; > } > From owner-linux-mips@oss.sgi.com Thu May 16 04:00:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GB0nnC016873 for ; Thu, 16 May 2002 04:00:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GB0nZU016872 for linux-mips-outgoing; Thu, 16 May 2002 04:00:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GB0hnC016869 for ; Thu, 16 May 2002 04:00:43 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA22725; Thu, 16 May 2002 12:57:41 +0200 (MET DST) Date: Thu, 16 May 2002 12:57:41 +0200 (MEST) From: Geert Uytterhoeven To: Carsten Langgaard cc: Ken Aaker , Linux/MIPS Development Subject: Re: Mangled struct hd_driveid with MIPSEB. In-Reply-To: <3CE384AD.8DE96FEF@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 16 May 2002, Carsten Langgaard wrote: > Geert Uytterhoeven wrote: > > On Thu, 16 May 2002, Carsten Langgaard wrote: > > > I send Ralf a fix a couple of weeks ago, which introduced the byteswapping, > > > which really is necessary. > > > This fix is probably only necessary for bigendian systems with large IDE > > > disks (>8GB), which support LBA mode. > > > I send this patch over a year ago. I discovered that when I ran on a disk, > > > which was larger than 8GB, it was only treated as 8GB. > > > The problem with the fix is, it is not backward compatible. After the fix > > > I needed to reinstall my bigendian system. > > > As I told Ralf, this fix will be a pain for everyone, but I guess we need > > > the fix eventually. > > > > Why would you have to reinstall the system? > > Isn't this just a problem with ide_fix_driveid() (new field for disks larger > > than 8 GiB, which we don't byteswap yet)? > > I'm trying to do things like other bigendian architectures. I can see your mail > address is linux-m68k and the fix is more or less stolen from the m68k part. However, I'm not sure anyone ever used a +8 GiB disk on Linux/m68k. IIRC, LBA uses an extra field in the drive info struct, which was initially not byteswapped. You can compare the MIPS/m68k ide_fix_driveid() with the version on PPC, which most probably works correctly with +8 GiB disks. 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 May 16 05:31:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GCVbnC020174 for ; Thu, 16 May 2002 05:31:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GCVbsL020173 for linux-mips-outgoing; Thu, 16 May 2002 05:31:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GCVXnC020169 for ; Thu, 16 May 2002 05:31:33 -0700 Received: from mail.avanticore.com (firewall.i-data.com [195.24.22.194]) 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 FAA05956 for ; Thu, 16 May 2002 05:31:48 -0700 (PDT) mail_from (tch@avanticore.com) Received: from avanticore.com ([172.17.159.1]) by mail.avanticore.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 16 May 2002 14:28:43 +0200 Message-ID: <3CE3A675.486BC12A@avanticore.com> Date: Thu, 16 May 2002 14:30:45 +0200 From: "Tommy S. Christensen" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Venkata Rajesh Bikkina CC: linux-mips@oss.sgi.com Subject: Re: RAMDISK problem on 79s334A board. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2002 12:28:44.0055 (UTC) FILETIME=[37FB8A70:01C1FCD5] Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Venkata Rajesh Bikkina wrote: > > Hi Tommy, > > I am using 2.4.3 code and in that linux/mm/vmallo.c contains the following > code which is slightly different from the patch you gave. > > } while (address && (address < end)); > unlock_kernel(); > flush_tlb_all(); > return ret; > > Can you please suggest how to modify this. > > Regards, > --Rajesh > 2.4.3 is quite old, so upgrading the kernel would clearly be a good idea. Anyway, if you want to try this fix then you should remove the call to flush_cache_all() at the top of vmalloc_area_pages() and change the line flush_tlb_all() to flush_cache_all(). -Tommy From owner-linux-mips@oss.sgi.com Thu May 16 07:33:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GEXtnC025058 for ; Thu, 16 May 2002 07:33:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GEXt4Z025057 for linux-mips-outgoing; Thu, 16 May 2002 07:33:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GEXenC025051 for ; Thu, 16 May 2002 07:33:40 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 95FC98D35; Thu, 16 May 2002 16:34:10 +0200 (CEST) Date: Thu, 16 May 2002 16:34:10 +0200 From: Guido Guenther To: ralf@gnu.org Cc: linux-mips@oss.sgi.com Subject: Re: howto pass ramdisk loaddress to kernel Message-ID: <20020516163410.A32622@gandalf.physik.uni-konstanz.de> Mail-Followup-To: ralf@gnu.org, linux-mips@oss.sgi.com References: <20020507123249.A9827@gandalf.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020507123249.A9827@gandalf.physik.uni-konstanz.de>; from agx@sigxcpu.org on Tue, May 07, 2002 at 12:32:49PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 07, 2002 at 12:32:49PM +0200, Guido Guenther wrote: > Hi, > in order to get rid of some ip22 specific hacks in setup.c as well as > addinitrd/elf2ecoff I've written a small tool that links kernel+initrd > as type "binary" into the data segment of the bootloader. This file can > then be fetched by the prom via tftp(or from a CD or whatever). The > bootloader copies the kernel to its loaddress and puts the initrd just > after the kernel. > My question is now: how do i properly pass the initrd's memory address > to the kernel? Choices are: > 1) on the commandline: rd_start=0x... > 2) a bootparameter block like on i386 or sparc in head.S > 3) rely on the kernel to identify if a radisk has > been loaded by a magic number Attached is a patch that implements (1). Arguments used are rd_start & rd_size. Ralf, please apply if suitable. -- Guido --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ramdisk-cmdline-2002-05-09.diff" Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96.2.12 diff -u -u -r1.96.2.12 setup.c --- arch/mips/kernel/setup.c 2002/02/15 21:05:48 1.96.2.12 +++ arch/mips/kernel/setup.c 2002/05/10 18:32:09 @@ -650,6 +650,38 @@ } } +static inline void parse_rd_cmdline(unsigned long* rd_start, unsigned long* rd_end) +{ + char c = ' ', *to = command_line, *from = saved_command_line; + int len = 0; + unsigned long rd_size = 0; + + for (;;) { + /* + * "rd_start=0xNNNNNNNN" defines the memory address of an initrd + * "rd_size=0xNN" it's size + */ + if (c == ' ' && !memcmp(from, "rd_start=", 9)) { + if (to != command_line) + to--; + (*rd_start) = memparse(from + 9, &from); + } + if (c == ' ' && !memcmp(from, "rd_size=", 8)) { + if (to != command_line) + to--; + rd_size = memparse(from + 8, &from); + } + c = *(from++); + if (!c) + break; + if (CL_SIZE <= ++len) + break; + *(to++) = c; + } + *to = '\0'; + (*rd_end) = (*rd_start) + rd_size; +} + void __init setup_arch(char **cmdline_p) { void atlas_setup(void); @@ -674,10 +706,7 @@ unsigned long bootmap_size; unsigned long start_pfn, max_pfn, max_low_pfn, first_usable_pfn; -#ifdef CONFIG_BLK_DEV_INITRD - unsigned long tmp; - unsigned long* initrd_header; -#endif + unsigned long end = &_end; int i; @@ -828,22 +857,18 @@ #define MAXMEM_PFN PFN_DOWN(MAXMEM) #ifdef CONFIG_BLK_DEV_INITRD - tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8; - if (tmp < (unsigned long)&_end) - tmp += PAGE_SIZE; - initrd_header = (unsigned long *)tmp; - if (initrd_header[0] == 0x494E5244) { - initrd_start = (unsigned long)&initrd_header[2]; - initrd_end = initrd_start + initrd_header[1]; + parse_rd_cmdline(&initrd_start, &initrd_end); + if(initrd_start && initrd_end) + end = initrd_end; + else { + initrd_start = initrd_end = 0; } - start_pfn = PFN_UP(__pa((&_end)+(initrd_end - initrd_start) + PAGE_SIZE)); -#else +#endif /* CONFIG_BLK_DEV_INITRD */ /* * Partially used pages are not usable - thus * we are rounding upwards. */ - start_pfn = PFN_UP(__pa(&_end)); -#endif /* CONFIG_BLK_DEV_INITRD */ + start_pfn = PFN_UP(__pa(end)); /* Find the highest page frame number we have available. */ max_pfn = 0; --KsGdsel6WgEHnImy-- From owner-linux-mips@oss.sgi.com Thu May 16 08:06:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GF6fnC026368 for ; Thu, 16 May 2002 08:06:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GF6f9e026367 for linux-mips-outgoing; Thu, 16 May 2002 08:06:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lars.roch.silverbacksystems.com ([209.180.49.225]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GF6bnC026364 for ; Thu, 16 May 2002 08:06:37 -0700 Received: from silverbacksystems.com (mars.roch.silverbacksystems.com [10.0.0.15]) by lars.roch.silverbacksystems.com (8.11.1/8.11.1) with ESMTP id g4GF73U24765 for ; Thu, 16 May 2002 10:07:03 -0500 Message-ID: <3CE3CB16.1040503@silverbacksystems.com> Date: Thu, 16 May 2002 10:07:02 -0500 From: Ken Aaker User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: Mangled struct hd_driveid with MIPSEB. References: <3CE2C834.2010302@silverbacksystems.com> <3CE3578C.CF29A2D6@mips.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The problem with the difference isn't that it's byte swapped, its that the byte swapping isn't respecting the data types inside the structure. It fixes all of the "short" entities, but it re-orders the fields that happen to be two chars next to each other, and the "shorts" that are part of the two "ints" for lba capacity and capacity values are in the wrong order, even though the bytes within the "shorts" are in the right order. So, when the fixup code in ide.h is run, the values are still wrong. old ---- 0070: 3f0010fc fb000001 80ac7e03 00000704 "?.........~....." 0080: 03007800 78007800 78000000 00000000 "..x.x.x.x......." new--- 0070: 003ffc10 00fb0100 ac80037e 00000407 ".?.........~...." 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" proper--- (after fix up). 0070: 003f00fb fc100001 037eac80 00000407 ".?.......~......" 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" Ken From owner-linux-mips@oss.sgi.com Thu May 16 10:16:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4GHGTnC004291 for ; Thu, 16 May 2002 10:16:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4GHGTQv004290 for linux-mips-outgoing; Thu, 16 May 2002 10:16:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4GHGMnC004287 for ; Thu, 16 May 2002 10:16:23 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA22517; Thu, 16 May 2002 10:15:08 -0700 Message-ID: <3CE3E8BA.8080002@mvista.com> Date: Thu, 16 May 2002 10:13:30 -0700 From: Jun Sun 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: "Kevin D. Kissell" CC: Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> <007a01c1fca9$86e14f70$10eca8c0@grendel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Kevin D. Kissell wrote: > Jun Sun wrote: > >>Daniel Jacobowitz wrote: >> >> >>>On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: >>> >>> >>>>So... I'm looking at porting Linux to a system with 1.5GiB of RAM. >>>>That kinda blows the 32-bit MIPS port option right out of the water... >>>> >>>> >>>Not unless you count bits differently than I do... 32-bit is 4 GiB. Is >>>there any reason MIPS has special problems in this area? >>> >>> >> >>MIPS has lower 2GB fixed for user space. Then you have kseg0, .5GB for cached >>physical address 0-0.5GB, and kseg1, 0.5GB uncached mapping of the same area. >> You can map another 1GB of RAM into kseg2/3, but you will then have no space >>left for IO. >> >>So you really can't do 1.5GB on 32 bit kernel. >> > > Is this to say that Linux cannot function unless all physical memory > on the system is mapped at all times into kernel space? I would > have thought that (a) all that really needs to be mapped is all > memory used by the kernel itself, plus that of the currently active > process (which is mapped in the 2GB kuseg), and that (b) one > could anyway manage kseg2 or 3 dynamically to provide a window > into a larger physical memory, and that this window could be > used for any functions that need to do arbitrary phys-to-phys > copies. > You are right - my above statement is a grossly simplified way of saying "You can't really have 1.5GB system RAM accessible to kernel at the same time on a 32bit MIPS kernel". There is nothing preventing you from having more physical RAM and use dynamically by using HIGHMEM support. BTW, I have been under the impression that demand for larger system RAM mainly comes from large router/switches to store routing table. Does anybody know on such systems whether the routing code runs in kernel or user space and whether it requires all the memory space accessible at the same time or can live with dynamically managed memory space? Jun From owner-linux-mips@oss.sgi.com Fri May 17 05:40:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HCelnC032702 for ; Fri, 17 May 2002 05:40:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HCelpE032701 for linux-mips-outgoing; Fri, 17 May 2002 05:40:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HCeenC032698 for ; Fri, 17 May 2002 05:40:40 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id FAA25524 for ; Fri, 17 May 2002 05:40:52 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA18961 for ; Fri, 17 May 2002 04:50:32 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4HBoVb00900 for ; Fri, 17 May 2002 13:50:31 +0200 (MEST) Message-ID: <3CE4EE87.EF515C92@mips.com> Date: Fri, 17 May 2002 13:50:31 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Hazard problem in tlb-r4k.c Content-Type: multipart/mixed; boundary="------------8694013FE14C5535C2FAF4F3" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------8694013FE14C5535C2FAF4F3 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit There seems to be a hazard problem in the local_flush_tlb_range function in tlb-r4k.c, which the patch below will fix. It could hit anyone, but it probably only a problem on CPUs, which doesn't allow matching entries in the TLB. /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 --------------8694013FE14C5535C2FAF4F3 Content-Type: text/plain; charset=iso-8859-15; name="tlb-r4k.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tlb-r4k.c.patch" Index: arch/mips/mm/tlb-r4k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/tlb-r4k.c,v retrieving revision 1.6.2.3 diff -u -r1.6.2.3 tlb-r4k.c --- arch/mips/mm/tlb-r4k.c 2002/01/18 03:16:24 1.6.2.3 +++ arch/mips/mm/tlb-r4k.c 2002/05/17 11:36:58 @@ -119,12 +119,11 @@ idx = get_index(); set_entrylo0(0); set_entrylo1(0); - set_entryhi(KSEG0); if (idx < 0) continue; - BARRIER; /* Make sure all entries differ. */ set_entryhi(KSEG0+idx*0x2000); + BARRIER; tlb_write_indexed(); BARRIER; } --------------8694013FE14C5535C2FAF4F3-- From owner-linux-mips@oss.sgi.com Fri May 17 07:04:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4HE4DnC004632 for ; Fri, 17 May 2002 07:04:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4HE4DiM004631 for linux-mips-outgoing; Fri, 17 May 2002 07:04:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin19.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4HE3xnC004623 for ; Fri, 17 May 2002 07:04:00 -0700 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g4HE4Mh14353; Fri, 17 May 2002 16:04:22 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Fri, 17 May 2002 16:04:22 +0200 (CEST) From: Kjeld Borch Egevang To: Mark Salter cc: linux-mips@oss.sgi.com Subject: Re: math emulator patch 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 discovered that the fix (from last year) does not work for cvt.w.d of e.g. 0xc1e0000000000001. Here is a patch: Index: dp_tint.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/dp_tint.c,v retrieving revision 1.5 diff -u -r1.5 dp_tint.c --- dp_tint.c 2001/12/02 14:21:29 1.5 +++ dp_tint.c 2002/05/17 13:58:03 @@ -49,10 +49,7 @@ case IEEE754_CLASS_NORM: break; } - if (xe >= 31) { - /* look for valid corner case */ - if (xe == 31 && xs && xm == DP_HIDDEN_BIT) - return -2147483648; + if (xe > 31) { /* Set invalid. We will only use overflow for floating point overflow */ SETCX(IEEE754_INVALID_OPERATION); @@ -98,7 +95,8 @@ xm++; break; } - if ((xm >> 31) != 0) { + /* look for valid corner case 0x80000000 */ + if ((xm >> 31) != 0 && (xs == 0 || xm != 0x80000000)) { /* This can happen after rounding */ SETCX(IEEE754_INVALID_OPERATION); return ieee754si_xcpt(ieee754si_indef(), "dp_tint", x); /Kjeld On Sat, 1 Dec 2001, Kjeld Borch Egevang wrote: > 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 May 17 20:05:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I35EnC023031 for ; Fri, 17 May 2002 20:05:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I35E7H023030 for linux-mips-outgoing; Fri, 17 May 2002 20:05:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from web11708.mail.yahoo.com (web11708.mail.yahoo.com [216.136.172.74]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I35BnC023027 for ; Fri, 17 May 2002 20:05:11 -0700 Message-ID: <20020518030549.15874.qmail@web11708.mail.yahoo.com> Received: from [12.235.80.60] by web11708.mail.yahoo.com via HTTP; Fri, 17 May 2002 20:05:49 PDT Date: Fri, 17 May 2002 20:05:49 -0700 (PDT) From: Michael Anburaj Subject: cygwin for MIPS & ARM7 To: linux-mips@oss.sgi.com, linux-arm@lists.arm.linux.org.uk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I am trying to set-up cygwin tool chain (gcc, gdb, gc++) on my Windows 98 for targets: ARM7 (EP7312) & MIPS (ATLAS- 4Kc). This is get ecos running on these platforms. Is there free GNU tools (gcc,gdb, gc++) available for these platforms on the net that can be used to build ecos? If so, please help me find them & install them & sucessfuly build ecoa… This is just for serious hobby purpose. when responding cc to my ID: michaelanburaj@yahoo.com Thanks a lot, -Mike. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-linux-mips@oss.sgi.com Fri May 17 23:36:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I6aLnC026863 for ; Fri, 17 May 2002 23:36:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I6aLuI026862 for linux-mips-outgoing; Fri, 17 May 2002 23:36:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I6aDnC026859 for ; Fri, 17 May 2002 23:36:13 -0700 Received: from free.fr (aboukir-101-1-18-ericleboeuf.adsl.nerim.net [62.212.106.189]) by kraid.nerim.net (Postfix) with ESMTP id AF71540EF3 for ; Fri, 17 May 2002 22:09:18 +0200 (CEST) Message-ID: <3CE5649A.5080206@free.fr> Date: Fri, 17 May 2002 22:14:18 +0200 From: Eric LEBOEUF Reply-To: eric.leboeuf@free.fr Organization: MDS Forever User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: French [fr],en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Kernel snapshot ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello everybody, I'm trying to get my indy to boot linux, but I've got some problem. When I do compile my own kernel, it crash with this message: ---------------------------------------------------------------------- sda:<1>Unable to handle kernel paging request at virtual address 00000000, epc == 880e7f3c, ra == 880e8120 Oops in fault.c:do_page_fault, line 205: $0 : 00000000 1004cc00 bfbc0007 0000000b bfbc0003 bfbc0007 00000025 00000019 $8 : 88674a00 88596c80 00000001 886c25a0 00001000 00000001 00000050 00000000 $16: 00000000 bfbc0007 00000400 00000001 00000049 0000003a 1004cc00 88596c00 $24: 00000004 88596e18 881a2000 881a3c88 00000001 880e8120 Hi : 00000000 Lo : 00000500 epc : 880e7f3c Not tainted Status: 1004cc02 Cause : 0000000c Proccess swapper (pid: 0, stackpage=881a2000) Stack: bfbc0003 bfbc0007 00000001 88019c74 bfbc0003 bfbc0007 4748494a 4b4c4d4e bfbc0003 bfbc0007 00000be0 0000003e bfbc0003 bfbc0007 881d654a 00000002 bfbc0007 88674a00 88596c80 00000001 880e8120 880e80f0 bfbc0003 bfbc0007 0000000c 0000003e 00000001 88596c80 bfbc0003 bfbc0007 88596c80 00000080 00000016 00000060 1004cc00 88596c80 00000001 8800b114 00000000 00000000 bfbc0003 ... Call Trace: [<88019c74>] [<880e8120>] [<880e80f0>] [<8800b114>] [<880dee54>] [<880e86a4>] [<880e9584>] [<8802386c>] [<880ddfe8>] [<880e7150>] [<880df1b4>] [<880def28>] [<88018c90>] [<8800a48c>] [<88000d30>] [<880bd6fc>] [<8800b810>] [<880be218>] [<880be200>] [<8800c024>] [<88005208>] [<880051dc>] [<8800280c>] [<88165480>] [<88166dac>] [<880027d8>] Code 00000000 0fa20034 90430000 26100001 30c20080 1040ffe9 8fbf0050 0a039ff8 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ----------------------------------------------------------------------- I did get a 2.4.1 kernel, which works, but do not have good support for scsi disks. How can I do to compile my how kernel ? I've got the toolchain-20020423-1.i386.rpm on a RedHat 7.3 Thanks a lot ! Eric LEBOEUF From owner-linux-mips@oss.sgi.com Sat May 18 01:19:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4I8J9nC031236 for ; Sat, 18 May 2002 01:19:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4I8J9Nr031235 for linux-mips-outgoing; Sat, 18 May 2002 01:19:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4I8J2nC031227 for ; Sat, 18 May 2002 01:19:03 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id C717883C; Sat, 18 May 2002 10:19:39 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id DAD9637115; Sat, 18 May 2002 10:18:55 +0200 (CEST) Date: Sat, 18 May 2002 10:18:55 +0200 From: Florian Lohoff To: Eric LEBOEUF Cc: linux-mips@oss.sgi.com Subject: Re: Kernel snapshot ? Message-ID: <20020518081855.GA11227@paradigm.rfc822.org> References: <3CE5649A.5080206@free.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <3CE5649A.5080206@free.fr> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 17, 2002 at 10:14:18PM +0200, Eric LEBOEUF wrote: > Hello everybody, >=20 > I'm trying to get my indy to boot linux, but I've got some problem. > When I do compile my own kernel, it crash with this message: I guess you compiled HEAD from the oss.sgi.com cvs ? This is something in the 2.5 area and not "ready to run(tm)" as at least the scsi driver is broken and is known to oops on boot. [ ... oops ... ] > I did get a 2.4.1 kernel, which works, but do not have good support for= =20 > scsi disks. How can I do to compile my how kernel ? You need to get the linux_2_4 branch from the cvs - That one should work. Flo PS: When sending in oopses please make shure you parse them through ksymoops with the correct System.map. --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --CE+1k2dSO48ffgeK 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 iD8DBQE85g5vUaz2rXW+gJcRAkC8AJ0dlYI+qqyUis2nx2pp2a8mnMRTTQCgzg6k 5v/RZgmT0hJXZJpknfIxiaE= =ZLS7 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-linux-mips@oss.sgi.com Sat May 18 03:52:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4IAqwnC006760 for ; Sat, 18 May 2002 03:52:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4IAqwtJ006759 for linux-mips-outgoing; Sat, 18 May 2002 03:52:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4IAqtnC006742; Sat, 18 May 2002 03:52:55 -0700 Received: from post.com ([211.46.57.56]) by deliverator.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 SMTP id DAA07342; Sat, 18 May 2002 03:53:26 -0700 (PDT) mail_from (dan@post.com) From: dan@post.com Received: from unknown (101.190.85.61) by q4.quickslow.com with local; Sat, 18 May 0102 09:01:49 -0300 Received: from mailout2-eri1.midmouth.com ([165.127.99.90]) by mx.loxsystems.net with esmtp; Sat, 18 May 0102 05:58:18 +1000 Received: from unknown (27.30.117.63) by mta21.bigpong.com with asmtp; Sat, 18 May 0102 15:54:47 -0800 Received: from unknown (HELO mailout2-eri1.midmouth.com) (46.202.36.192) by rly-xr01.nihuyatut.net with QMQP; 18 May 0102 07:51:16 -0700 Received: from unknown (HELO asy100.as122.sol-superunderline.com) (159.28.80.133) by asy100.as122.sol-superunderline.com with smtp; 18 May 0102 00:47:45 +1000 Reply-To: Message-ID: <027d41d74e4c$5325c6e2$4ac12cd5@mfwflg> To: dan@post.com Subject: good idea! Date: Sat, 18 May 0102 19:56:53 -0900 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E2_32A76C3A.A2216A85" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ------=_NextPart_000_00E2_32A76C3A.A2216A85 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 aGkNCg0Kd2hhdCBhIGdvb2QgaWRlYSB0byBtYWtlIGEgbGlzdCBvZiB0aGUg YmVzdCBmcmVlIHBvcm4gc2l0ZXMgb2YgdGhlIHdlYiENCmFuZCB5b3UgYXJl IHN1cmUgdG8gZmluZCB3aGF0IHlvdSBsaWtlOiByZWFsIGFtYXRldXJzLCBm ZXRpc2hpc20sIGdheSwgYmxhY2tzLi4uDQp5b3UgbXVzdCB2aXNpdCB0aGlz IGZyZWUgd2ViIHNpdGU6ICh5ZXMgcmVhbGx5IGZyZWUhISkNCg0KaHR0cDov L3VrLnNleC1hbm51YWlyZS5jb20NCg0KRGFuDQo5MDc3aFJlZTgtOTI4Rmd1 czU3MjFRbDIx From owner-linux-mips@oss.sgi.com Sat May 18 16:55:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4INtsnC005995 for ; Sat, 18 May 2002 16:55:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4INts0W005994 for linux-mips-outgoing; Sat, 18 May 2002 16:55:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from florz.dyndns.org (dialin-80141.ewetel.net [212.6.80.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4INtlnC005991 for ; Sat, 18 May 2002 16:55:48 -0700 Received: from florz by florz.dyndns.org with local (Exim 3.12 #1 (Debian)) id 179E3j-000469-00 for ; Sun, 19 May 2002 01:56:23 +0200 Date: Sun, 19 May 2002 01:56:23 +0200 From: Florian Zumbiehl To: linux-mips@oss.sgi.com Subject: SNI RM600 Message-ID: <20020519015623.C1437@florz.dyndns.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 Hi, I last week had the pleasure to fiddle about a bit with an SNI RM600 (I hope it's not to my disadvantage to mention that it was at school, but this fact might get important... ;-), though the pleasure was limited a bit by the system installed on the machine being Reliant UNIX =;-) So after all I thought it would be nice to install Linux (or some other free OS, but Linux would be best for this environment I think) on this machine. After doing some research on the topic I came to the conclusion that it wasn't a thing possible yet... :-/ As far as Woglinde (Henning Heinold or whatever name you know him under, he pointed me to this ml) told me, the main problem in getting Linux running on the RM600 is a lack of documentation - that's mostly all I know. However I'd really like to get Linux running on the machine, as I'd like to help with this - it's just that I currently don't have much of a clue what to start with or whether it possibly is completely pointless to try at all. So, I'd appreciate quite much if you could just give me some hints on what to read to get a clue or if you could tell me what the problems are in getting Linux running on the RM600 and what you think it would need to get around these problems, and possibly in which way I could help you with this, or just whatever you think that it could be useful for me ;-) I'm sorry if this all has already been answered extensively - the mailing list archive apparently isn't available atm, so I had no chance to check it yet. Also sorry if this mail looks a bit like I'm not totally clear in my mind about what I'm writing about, actually that's just why I'm doing so... ;-) cyas, florz From owner-linux-mips@oss.sgi.com Sun May 19 12:23:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJN9nC007751 for ; Sun, 19 May 2002 12:23:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJN9xF007750 for linux-mips-outgoing; Sun, 19 May 2002 12:23:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJN5nC007739 for ; Sun, 19 May 2002 12:23:06 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJNb902998; Sun, 19 May 2002 12:23:37 -0700 Date: Sun, 19 May 2002 12:23:37 -0700 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519122336.A20670@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mdharm@momenco.com on Wed, May 15, 2002 at 02:34:47PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > That kinda blows the 32-bit MIPS port option right out of the water... Not really, there is still highmem though that certainly a sucky solution as compared to a 64-bit kernel. > What does it take to do a 64-bit port? The first problem I see is the > boot loader -- do I have to be in 64-bit mode when the kernel starts, > or can I start in 32-bit mode and then transfer to 64-bit mode? Same loader as before - the build procedure will result in a 32-bit kernel binary which is loaded to the same old KSEG0 addresses. > I looked in the arch/mips64/ directory, but I don't see much for > specific boards there, but there are references to the Malta > boards.... Exactly. The aim is to support both kernels without replicating the board support code. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:23:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJNmnC007913 for ; Sun, 19 May 2002 12:23:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJNmUm007912 for linux-mips-outgoing; Sun, 19 May 2002 12:23:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJNknC007900 for ; Sun, 19 May 2002 12:23:46 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJOJT03014; Sun, 19 May 2002 12:24:19 -0700 Date: Sun, 19 May 2002 12:24:19 -0700 From: Ralf Baechle To: Daniel Jacobowitz Cc: Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519122419.B20670@dea.linux-mips.net> References: <20020515214818.GA1991@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020515214818.GA1991@nevyn.them.org>; from dan@debian.org on Wed, May 15, 2002 at 05:48:18PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 05:48:18PM -0400, Daniel Jacobowitz wrote: > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > So... I'm looking at porting Linux to a system with 1.5GiB of RAM. > > That kinda blows the 32-bit MIPS port option right out of the water... > > Not unless you count bits differently than I do... 32-bit is 4 GiB. Is > there any reason MIPS has special problems in this area? The basic assumption is that we can address all memory through KSEG0. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:24:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJOTnC008092 for ; Sun, 19 May 2002 12:24:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJOTN0008091 for linux-mips-outgoing; Sun, 19 May 2002 12:24:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJOSnC008082 for ; Sun, 19 May 2002 12:24:28 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJP1C03025; Sun, 19 May 2002 12:25:01 -0700 Date: Sun, 19 May 2002 12:25:01 -0700 From: Ralf Baechle To: Matthew Dharm Cc: kwalker@broadcom.com, Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519122501.C20670@dea.linux-mips.net> References: <3CE2D95B.E1E43662@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mdharm@momenco.com on Wed, May 15, 2002 at 03:08:05PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 03:08:05PM -0700, Matthew Dharm wrote: > I don't suppose anyone has a primer or white paper on the High Memory > stuff? i.e. Applications, requirements, or a quick HOWTO? Same old technology as on Intel, so also the same old limitions ... Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:28:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJSenC009144 for ; Sun, 19 May 2002 12:28:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJSeqe009143 for linux-mips-outgoing; Sun, 19 May 2002 12:28:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJScnC009133 for ; Sun, 19 May 2002 12:28:38 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJTBM03131; Sun, 19 May 2002 12:29:11 -0700 Date: Sun, 19 May 2002 12:29:11 -0700 From: Ralf Baechle To: Matthew Dharm Cc: Kip Walker , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519122911.D20670@dea.linux-mips.net> References: <3CE2DDEB.5DA6E868@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mdharm@momenco.com on Wed, May 15, 2002 at 03:26:08PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 03:26:08PM -0700, Matthew Dharm wrote: > So, how should my boot code convey that info? With more > add_memory_region() calls? Is that really all I need? Yes. At this time you just have to make sure you don't add_memory_region() areas which aren't supported by your particular kernel configuration. There is also a second limit which is memory above physical address 4GB; if you need that you have to enable CONFIG_64BIT_PHYS_ADDR as well. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:30:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJUSnC009663 for ; Sun, 19 May 2002 12:30:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJUSBQ009662 for linux-mips-outgoing; Sun, 19 May 2002 12:30:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJUQnC009649 for ; Sun, 19 May 2002 12:30:26 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJUxd03165; Sun, 19 May 2002 12:30:59 -0700 Date: Sun, 19 May 2002 12:30:59 -0700 From: Ralf Baechle To: Jun Sun Cc: Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519123059.E20670@dea.linux-mips.net> References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CE2DA46.3070402@mvista.com>; from jsun@mvista.com on Wed, May 15, 2002 at 02:59:34PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 02:59:34PM -0700, Jun Sun wrote: > Back to 64bit port, it seems to me much of the 32bit work we have done in the > past a year or so needs to be moved over. Or better yet, if we can clean up > integer/long issues, we might be able to use 32bit kernel code straight for > 64bit kernel. Int vs. long was a very small issue as I discovered during porting for the first 64-bit machines, the IP22 and IP27. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:31:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJVmnC010063 for ; Sun, 19 May 2002 12:31:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJVmxW010062 for linux-mips-outgoing; Sun, 19 May 2002 12:31:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJVknC010052 for ; Sun, 19 May 2002 12:31:46 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJWJT03189; Sun, 19 May 2002 12:32:19 -0700 Date: Sun, 19 May 2002 12:32:19 -0700 From: Ralf Baechle To: Matthew Dharm Cc: Jun Sun , Daniel Jacobowitz , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519123219.F20670@dea.linux-mips.net> References: <3CE2DA46.3070402@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mdharm@momenco.com on Wed, May 15, 2002 at 03:16:29PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 15, 2002 at 03:16:29PM -0700, Matthew Dharm wrote: > Could someone give me an overview of how you're supposed to do a > handoff between a 32-bit loader and a 64-bit app? I'm guessing there > has to be a way to do it, but what I do know about the 64-bit stuff > doesn't show me how this is accomplished (I have visions of UX bits > floating in my head...) If you're placing the kernel in KSEG0 like all other current targets are doing then your 32-bit pointers are valid 64-bit pointers, no magic, no thinking necessary. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:40:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJeZnC012469 for ; Sun, 19 May 2002 12:40:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJeZ0Y012468 for linux-mips-outgoing; Sun, 19 May 2002 12:40:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJeUnC012444 for ; Sun, 19 May 2002 12:40:30 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJf3F03292; Sun, 19 May 2002 12:41:03 -0700 Date: Sun, 19 May 2002 12:41:03 -0700 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Jun Sun , Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519124103.G20670@dea.linux-mips.net> References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> <007a01c1fca9$86e14f70$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <007a01c1fca9$86e14f70$10eca8c0@grendel>; from kevink@mips.com on Thu, May 16, 2002 at 09:15:40AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 09:15:40AM +0200, Kevin D. Kissell wrote: > Is this to say that Linux cannot function unless all physical memory > on the system is mapped at all times into kernel space? I would > have thought that (a) all that really needs to be mapped is all > memory used by the kernel itself, plus that of the currently active > process (which is mapped in the 2GB kuseg), and that (b) one > could anyway manage kseg2 or 3 dynamically to provide a window > into a larger physical memory, and that this window could be > used for any functions that need to do arbitrary phys-to-phys > copies. Highmem is your dynamic 4MB window into all memory that's not low memory. KSEG2/3 are currently mostly reserved for vmalloc / ioremap and these 4MB of highmem mapping space - a usage that's certainly wasteful. As opposed to that all the permanently mapped kernel memory in Linux is called lowmem. > I'm not sure what people's definition of a "64-bit kernel" > is around here, but to me, that's a kernel which supports > 64-bit virtual addressing and 64-bit registers. It strikes > me as being rather foolish to impose the overhead of all > that on people whose only real requirement is 2G of RAM > on a 32-bit CPU. Particularly when many of the new > MIPS parts that could plausibly be connected to 2GB > RAM arrays, such as the Alchemy/AMD and MIPS 4K > parts, don't support 64-bit operation. So running away > from the problem isn't really an option. Highmem doesn't come without a price either - in particular processes doing heavy I/O will possibly as much as 40% performance penalty (numbers from Intel systems) and for sanity's sake - 64-bit is keeping people from going nuts :) A solution that will use most of KSEG2/3 for mapping more lowmemory is in the works but it turned out to be drastically more complex that originally thought so will still take a bit. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 12:44:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJi4nC013441 for ; Sun, 19 May 2002 12:44:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4JJi4n6013440 for linux-mips-outgoing; Sun, 19 May 2002 12:44:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4JJi2nC013427 for ; Sun, 19 May 2002 12:44:02 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4JJiZd03340; Sun, 19 May 2002 12:44:35 -0700 Date: Sun, 19 May 2002 12:44:35 -0700 From: Ralf Baechle To: Jun Sun Cc: "Kevin D. Kissell" , Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519124435.H20670@dea.linux-mips.net> References: <20020515214818.GA1991@nevyn.them.org> <3CE2DA46.3070402@mvista.com> <007a01c1fca9$86e14f70$10eca8c0@grendel> <3CE3E8BA.8080002@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CE3E8BA.8080002@mvista.com>; from jsun@mvista.com on Thu, May 16, 2002 at 10:13:30AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 16, 2002 at 10:13:30AM -0700, Jun Sun wrote: > BTW, I have been under the impression that demand for larger system RAM > mainly comes from large router/switches to store routing table. Does > anybody know on such systems whether the routing code runs in kernel or > user space and whether it requires all the memory space accessible at > the same time or can live with dynamically managed memory space? Kernel routing is more for the lower end systems; the highend systems use hardware assisted routing / switching where software only handles the boundary cases; such software might either live in user or in kernel space. Ralf From owner-linux-mips@oss.sgi.com Sun May 19 23:05:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4K65BnC016385 for ; Sun, 19 May 2002 23:05:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4K65B2M016383 for linux-mips-outgoing; Sun, 19 May 2002 23:05:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from host099.momenco.com (IDENT:root@jeeves.momenco.com [64.169.228.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4K654nC016337; Sun, 19 May 2002 23:05:04 -0700 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g4K65qb17191; Sun, 19 May 2002 23:05:52 -0700 Date: Sun, 19 May 2002 23:05:52 -0700 From: Matthew Dharm To: Ralf Baechle Cc: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020519230552.A17175@momenco.com> References: <20020519122336.A20670@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020519122336.A20670@dea.linux-mips.net>; from ralf@oss.sgi.com on Sun, May 19, 2002 at 12:23:37PM -0700 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, May 19, 2002 at 12:23:37PM -0700, Ralf Baechle wrote: > On Wed, May 15, 2002 at 02:34:47PM -0700, Matthew Dharm wrote: > > What does it take to do a 64-bit port? The first problem I see is the > > boot loader -- do I have to be in 64-bit mode when the kernel starts, > > or can I start in 32-bit mode and then transfer to 64-bit mode? > > Same loader as before - the build procedure will result in a 32-bit kernel > binary which is loaded to the same old KSEG0 addresses. Call me a bit slow, but... Are you saying that my 32-bit loader (which is designed to load a 32-bit ELF file) will do exactly that... but this 32-bit ELF file has the magic in it to switch to 64-bit internally? Nice... Very nice. I'm used to slick Open Source solutions, but I have to admit that this is a pretty elegant one that solves a great many problems... Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From owner-linux-mips@oss.sgi.com Mon May 20 03:05:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KA5gnC019672 for ; Mon, 20 May 2002 03:05:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KA5gNZ019671 for linux-mips-outgoing; Mon, 20 May 2002 03:05:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KA5anC019668; Mon, 20 May 2002 03:05:37 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA23620; Mon, 20 May 2002 12:06:45 +0200 (MET DST) Date: Mon, 20 May 2002 12:06:45 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? In-Reply-To: <20020519123059.E20670@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 Sun, 19 May 2002, Ralf Baechle wrote: > Int vs. long was a very small issue as I discovered during porting for the > first 64-bit machines, the IP22 and IP27. Well, the surprise is going to happen in drivers, I'm afraid... -- + 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 May 20 08:56:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KFuhnC017371 for ; Mon, 20 May 2002 08:56:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KFuhN8017366 for linux-mips-outgoing; Mon, 20 May 2002 08:56:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KFuenC017355 for ; Mon, 20 May 2002 08:56:40 -0700 Received: (qmail 3095 invoked from network); 20 May 2002 15:57:28 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 20 May 2002 15:57:28 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g4KFvis01763 for linux-mips@oss.sgi.com; Mon, 20 May 2002 08:57:44 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Mon, 20 May 2002 08:57:44 -0700 From: Greg Lindahl To: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020520085743.A1748@wumpus.keyresearch.com> Mail-Followup-To: Linux-MIPS References: <20020519123059.E20670@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, May 20, 2002 at 12:06:45PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 12:06:45PM +0200, Maciej W. Rozycki wrote: > Well, the surprise is going to happen in drivers, I'm afraid... Linux drivers as a whole are 64-bit clean; alpha's been around for a long time. MIPS-only devices might be dirtier. greg From owner-linux-mips@oss.sgi.com Mon May 20 09:05:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KG50nC018610 for ; Mon, 20 May 2002 09:05:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KG4xb7018608 for linux-mips-outgoing; Mon, 20 May 2002 09:04:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KG4snC018596 for ; Mon, 20 May 2002 09:04:55 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA01973; Mon, 20 May 2002 18:05:58 +0200 (MET DST) Date: Mon, 20 May 2002 18:05:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Greg Lindahl cc: Linux-MIPS Subject: Re: MIPS 64? In-Reply-To: <20020520085743.A1748@wumpus.keyresearch.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, 20 May 2002, Greg Lindahl wrote: > > Well, the surprise is going to happen in drivers, I'm afraid... > > Linux drivers as a whole are 64-bit clean; alpha's been around for a > long time. MIPS-only devices might be dirtier. Well, that is wishful thinking. Obviously if a driver is actually used on a 64-bit system, one can be moderately confident the driver is clean, although there might still be corner cases. Otherwise expect all kinds of weirdness. See e.g. the ISA stuff. -- + 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 May 20 10:42:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KHgAnC001515 for ; Mon, 20 May 2002 10:42:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KHgAAX001514 for linux-mips-outgoing; Mon, 20 May 2002 10:42:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from portal.wmi.com (wmi.com [66.105.85.211]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KHg8nC001511 for ; Mon, 20 May 2002 10:42:09 -0700 Received: from cac0.wmi.com (cac0.wmi.com [66.105.85.220]) by portal.wmi.com (8.11.6/8.11.6) with ESMTP id g4KHhPR02928 for ; Mon, 20 May 2002 13:43:25 -0400 Received: from wmiddm (wmiddm.wmi.com [192.168.1.139]) by cac0.wmi.com (8.11.0/8.11.0) with SMTP id g4KHhPe19856 for ; Mon, 20 May 2002 13:43:25 -0400 Message-ID: <000e01c20025$d6216d20$8b01a8c0@wmiddm> From: "David D. McCoach" To: Subject: 2.4.3 bss alignment bug Date: Mon, 20 May 2002 13:43:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Does anyone know of a bug the cause an unaligned access in the kernel when the alignment of the bss segment os changed? Thanks From owner-linux-mips@oss.sgi.com Mon May 20 12:05:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJ59nC013104 for ; Mon, 20 May 2002 12:05:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJ58vP013100 for linux-mips-outgoing; Mon, 20 May 2002 12:05:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJ55nC013088 for ; Mon, 20 May 2002 12:05:05 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4KJ5qE14959; Mon, 20 May 2002 12:05:52 -0700 Date: Mon, 20 May 2002 12:05:52 -0700 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , Daniel Jacobowitz , Matthew Dharm , Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020520120552.C14066@dea.linux-mips.net> References: <20020519123059.E20670@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, May 20, 2002 at 12:06:45PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 20, 2002 at 12:06:45PM +0200, Maciej W. Rozycki wrote: > > Int vs. long was a very small issue as I discovered during porting for the > > first 64-bit machines, the IP22 and IP27. > > Well, the surprise is going to happen in drivers, I'm afraid... That depends on how much people were thinking ahead when writing drivers. Ralf From owner-linux-mips@oss.sgi.com Mon May 20 12:23:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KJNfnC016600 for ; Mon, 20 May 2002 12:23:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KJNfsm016596 for linux-mips-outgoing; Mon, 20 May 2002 12:23:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sentinel.sanera.net (ns1.sanera.net [208.253.254.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4KJNdnC016542 for ; Mon, 20 May 2002 12:23:39 -0700 Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id g4KJONM15472 for ; Mon, 20 May 2002 12:24:23 -0700 Received: from exceed1.sanera.net (exceed1.sanera.net [172.16.2.31]) by icarus.sanera.net (8.11.6/8.11.6) with SMTP id g4KJOI910711 for ; Mon, 20 May 2002 12:24:18 -0700 Message-Id: <200205201924.g4KJOI910711@icarus.sanera.net> Date: Mon, 20 May 2002 12:24:18 -0700 (PDT) From: Krishna Kondaka Reply-To: Krishna Kondaka Subject: Mailing list archive To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3LOQPCLlRC4yyTnytM65vw== 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, When I try to look at this mailing list archive at http://oss.sgi.com/mips/archive, I am getting "You don't have permission to access /mips/archive on this server" error. I was previously able to access this archive and only recently I am getting this error. Is there any other place where I can access the archive? Thanks Krishna Kondaka Sanera Systems From owner-linux-mips@oss.sgi.com Mon May 20 13:30:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKUDnC025375 for ; Mon, 20 May 2002 13:30:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4KKUD6N025374 for linux-mips-outgoing; Mon, 20 May 2002 13:30:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4KKU8nC025371 for ; Mon, 20 May 2002 13:30:08 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4KKUuh15905; Mon, 20 May 2002 13:30:56 -0700 Date: Mon, 20 May 2002 13:30:56 -0700 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020520133056.D14066@dea.linux-mips.net> References: <20020519122336.A20670@dea.linux-mips.net> <20020519230552.A17175@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020519230552.A17175@momenco.com>; from mdharm@momenco.com on Sun, May 19, 2002 at 11:05:52PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sun, May 19, 2002 at 11:05:52PM -0700, Matthew Dharm wrote: > > > What does it take to do a 64-bit port? The first problem I see is the > > > boot loader -- do I have to be in 64-bit mode when the kernel starts, > > > or can I start in 32-bit mode and then transfer to 64-bit mode? > > > > Same loader as before - the build procedure will result in a 32-bit kernel > > binary which is loaded to the same old KSEG0 addresses. > > Call me a bit slow, but... > > Are you saying that my 32-bit loader (which is designed to load a 32-bit > ELF file) will do exactly that... but this 32-bit ELF file has the magic in > it to switch to 64-bit internally? > > Nice... Very nice. I'm used to slick Open Source solutions, but I have to > admit that this is a pretty elegant one that solves a great many > problems... It's a fairly natural solution to the problem we had. The scenario we had to deal with was - a machine (SGI Origin 200/2000 aka IP27) where configurations are commonly way too large for a 32-bit kernel. - 64-bit MIPS/ELF support that was close to entierly unusable - fixing binutils fully would have taken a serious amount of time which we didn't have. As it turned out gas is perfectly able to assemble the assembler code that is generated for the N64 ABI by gcc into 32-bit ELF and linking that. That code model still uses 64-bit pointers just all intra-kernel refernces that were generated from la or dla macros get expanded into just the two instruction sequence for 32-bit code, not the upto 7 instruction used for 64-bit code. Result: much less tools work necessary yet better code. Ralf From owner-linux-mips@oss.sgi.com Mon May 20 17:13:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L0DhnC030783 for ; Mon, 20 May 2002 17:13:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L0DhFt030782 for linux-mips-outgoing; Mon, 20 May 2002 17:13:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L0DcnC030777 for ; Mon, 20 May 2002 17:13:38 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4L0DKg26560 for linux-mips@oss.sgi.com; Mon, 20 May 2002 17:13:20 -0700 Date: Mon, 20 May 2002 17:13:20 -0700 From: William Jhun To: linux-mips@oss.sgi.com Subject: [PATCH] arch/mips/kernel/irq.c: do_IRQ() return value Message-ID: <20020520171320.J20837@ayrnetworks.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 Though a comment in arch/i386/kernel/irq.c: do_IRQ() clearly states: * 0 return value means that this irq is already being * handled by some other CPU. (or is disabled) it seems that the function can only ever return (1). We wrote some low-level interrupt handling code that depends on the correct value of this function. Is the following patch what was initially desired? Clearly this code came from (or vice-versa) arch/i386/kernel/irq.c. I've sent a patch out for that version to linux-kernel. Thanks, William Jhun Index: arch/mips/kernel/irq.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/irq.c,v retrieving revision 1.38.2.6 diff -c -r1.38.2.6 irq.c *** arch/mips/kernel/irq.c 2002/05/15 20:41:13 1.38.2.6 --- arch/mips/kernel/irq.c 2002/05/21 00:10:11 *************** *** 488,494 **** if (softirq_pending(cpu)) do_softirq(); ! return 1; } /** --- 488,494 ---- if (softirq_pending(cpu)) do_softirq(); ! return (action != NULL); } /** From owner-linux-mips@oss.sgi.com Mon May 20 18:42:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L1gLnC032520 for ; Mon, 20 May 2002 18:42:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L1gLaZ032519 for linux-mips-outgoing; Mon, 20 May 2002 18:42:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L1g9nC032513 for ; Mon, 20 May 2002 18:42:09 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4L1fp626655 for linux-mips@oss.sgi.com; Mon, 20 May 2002 18:41:51 -0700 Date: Mon, 20 May 2002 18:41:51 -0700 From: William Jhun To: linux-mips@oss.sgi.com Subject: [PATCH] arch/mips/kernel/irq_cpu.c interrupt safety? Message-ID: <20020520184151.C26598@ayrnetworks.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 The mips_cpu_irq_*() routines in arch/mips/kernel/irq_cpu.c seem to not be safe; {clear,set}_cp0_*() don't provide interrupt safety while changing the cp0 register. Is this not wrong? Is there a case where an interrupt handler may change CP0 status? If so, the patch below (against linux_2_4) simply disables interrupts during these operations. Thanks, Will --- Index: arch/mips/kernel/irq_cpu.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/irq_cpu.c,v retrieving revision 1.2.2.2 diff -c -r1.2.2.2 irq_cpu.c *** arch/mips/kernel/irq_cpu.c 2002/04/09 02:27:12 1.2.2.2 --- arch/mips/kernel/irq_cpu.c 2002/05/21 01:16:30 *************** *** 31,45 **** static void mips_cpu_irq_enable(unsigned int irq) { clear_cp0_cause( 1 << (irq - mips_cpu_irq_base + 8)); set_cp0_status(1 << (irq - mips_cpu_irq_base + 8)); } ! static void mips_cpu_irq_disable(unsigned int irq) { clear_cp0_status(1 << (irq - mips_cpu_irq_base + 8)); } static unsigned int mips_cpu_irq_startup(unsigned int irq) { mips_cpu_irq_enable(irq); --- 31,56 ---- static void mips_cpu_irq_enable(unsigned int irq) { + unsigned long flags; + save_and_cli(flags); clear_cp0_cause( 1 << (irq - mips_cpu_irq_base + 8)); set_cp0_status(1 << (irq - mips_cpu_irq_base + 8)); + restore_flags(flags); } ! static void __mips_cpu_irq_disable(unsigned int irq) { clear_cp0_status(1 << (irq - mips_cpu_irq_base + 8)); } + static void mips_cpu_irq_disable(unsigned int irq) + { + unsigned long flags; + save_and_cli(flags); + __mips_cpu_irq_disable(irq); + restore_flags(flags); + } + static unsigned int mips_cpu_irq_startup(unsigned int irq) { mips_cpu_irq_enable(irq); *************** *** 51,63 **** static void mips_cpu_irq_ack(unsigned int irq) { ! /* although we attemp to clear the IP bit in cause reigster, I think * usually it is cleared by device (irq source) */ clear_cp0_cause(1 << (irq - mips_cpu_irq_base + 8)); /* disable this interrupt - so that we safe proceed to the handler */ ! mips_cpu_irq_disable(irq); } static void mips_cpu_irq_end(unsigned int irq) --- 62,78 ---- static void mips_cpu_irq_ack(unsigned int irq) { ! unsigned long flags; ! save_and_cli(flags); ! ! /* although we attempt to clear the IP bit in cause register, I think * usually it is cleared by device (irq source) */ clear_cp0_cause(1 << (irq - mips_cpu_irq_base + 8)); /* disable this interrupt - so that we safe proceed to the handler */ ! __mips_cpu_irq_disable(irq); ! restore_flags(flags); } static void mips_cpu_irq_end(unsigned int irq) From owner-linux-mips@oss.sgi.com Mon May 20 21:56:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L4uKnC025961 for ; Mon, 20 May 2002 21:56:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L4uJ18025960 for linux-mips-outgoing; Mon, 20 May 2002 21:56:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L4uInC025957 for ; Mon, 20 May 2002 21:56:18 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4L4v9d21433 for linux-mips@oss.sgi.com; Mon, 20 May 2002 21:57:09 -0700 Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4H0FYnC019070 for ; Thu, 16 May 2002 17:15:34 -0700 Received: from resel.enst-bretagne.fr (UNKNOWN@maisel-gw.enst-bretagne.fr [192.44.76.8]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4H0Fsc30296 for ; Fri, 17 May 2002 02:15:54 +0200 Received: from melkor (mail@melkor.maisel.enst-bretagne.fr [172.16.20.65]) by resel.enst-bretagne.fr (8.12.3/8.12.3/Debian -4) with ESMTP id g4H0FsO4032499 for ; Fri, 17 May 2002 02:15:54 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.34 #1 (Debian)) id 178VPW-0006bk-00 for ; Fri, 17 May 2002 02:15:54 +0200 Date: Fri, 17 May 2002 02:15:54 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: linux-mips@oss.sgi.com Subject: [PATCH] experimental O2 framebuffer driver Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1159884594-1021594554=:25304" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --279724308-1159884594-1021594554=:25304 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here are two patch for testing framebuffer support on O2. linux-O2-console.diff just adds dummy console/keyboard so that virtual consoles can be compiled. linux-O2-fb.diff is an experimental O2 framebuffer driver based on the sgivwfb driver. It currently supports 8 bit modes, except 800x600 (I tested 640x480,1024x768,1280x1024,1600x1200 @ 60Hz). 16 bit and 32 bit modes have wrong colors, but the pixels are in the right place ;) Feel free to test... You'll probably need all other patches I've sent to the list some time ago to get O2 booting. I've also included a patch needed to get the mips64 kernel compile on r4k with the new icache functions, that I've just sent to Ralf too for integration. Patches are against CVS/HEAD. regards, Vivien. --279724308-1159884594-1021594554=:25304 Content-Type: TEXT/plain; name="linux-O2-console.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-console.diff" ZGlmZiAtTmF1ciBsaW51eDY0L2FyY2gvbWlwczY0L2NvbmZpZy5pbiBsaW51 eDY0Lm5ldy9hcmNoL21pcHM2NC9jb25maWcuaW4NCi0tLSBsaW51eDY0L2Fy Y2gvbWlwczY0L2NvbmZpZy5pbglUaHUgTWF5IDE2IDE5OjU1OjU3IDIwMDIN CisrKyBsaW51eDY0Lm5ldy9hcmNoL21pcHM2NC9jb25maWcuaW4JVHVlIE1h eSAgNyAwMDo0MjozMSAyMDAyDQpAQCAtMjkzLDYgKzI5Myw5IEBADQogICAg ICAgZWxzZQ0KIAkgZGVmaW5lX2Jvb2wgQ09ORklHX0ZPTlRfOHgxNiB5DQog ICAgICAgZmkNCisgICBmaQ0KKyAgIGlmIFsgIiRDT05GSUdfU0dJX0lQMzIi ID0gInkiIF07IHRoZW4NCisgICAJIGRlZmluZV9ib29sIENPTkZJR19EVU1N WV9DT05TT0xFIHkNCiAgICBmaQ0KICAgZW5kbWVudQ0KIGZpDQpkaWZmIC1O YXVyIGxpbnV4NjQvYXJjaC9taXBzNjQva2VybmVsL3NldHVwLmMgbGludXg2 NC5uZXcvYXJjaC9taXBzNjQva2VybmVsL3NldHVwLmMNCi0tLSBsaW51eDY0 L2FyY2gvbWlwczY0L2tlcm5lbC9zZXR1cC5jCVRodSBNYXkgMTYgMTk6NTU6 NTkgMjAwMg0KKysrIGxpbnV4NjQubmV3L2FyY2gvbWlwczY0L2tlcm5lbC9z ZXR1cC5jCVR1ZSBNYXkgIDcgMDA6NDM6NTcgMjAwMg0KQEAgLTc4LDggKzc4 LDEwIEBADQogZXh0ZXJuIHN0cnVjdCBydGNfb3BzIG5vX3J0Y19vcHM7DQog c3RydWN0IHJ0Y19vcHMgKnJ0Y19vcHM7DQogDQorI2lmZGVmIENPTkZJR19Q Q19LRVlCDQogZXh0ZXJuIHN0cnVjdCBrYmRfb3BzIG5vX2tiZF9vcHM7DQog c3RydWN0IGtiZF9vcHMgKmtiZF9vcHM7DQorI2VuZGlmDQogDQogLyoNCiAg KiBTZXR1cCBpbmZvcm1hdGlvbg0KQEAgLTcyMSw2ICs3MjMsMTAgQEANCiAN CiB2b2lkIF9faW5pdCBzZXR1cF9hcmNoKGNoYXIgKipjbWRsaW5lX3ApDQog ew0KKyNpZmRlZiBDT05GSUdfUENfS0VZQg0KKwlrYmRfb3BzID0gJm5vX2ti ZF9vcHM7CQ0KKyNlbmRpZg0KKw0KICNpZmRlZiBDT05GSUdfU0dJX0lQMjIN CiAJaXAyMl9zZXR1cCgpOw0KICNlbmRpZg0KZGlmZiAtTmF1ciBsaW51eDY0 L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzItc2V0dXAuYyBsaW51eDY0Lm5l dy9hcmNoL21pcHM2NC9zZ2ktaXAzMi9pcDMyLXNldHVwLmMNCi0tLSBsaW51 eDY0L2FyY2gvbWlwczY0L3NnaS1pcDMyL2lwMzItc2V0dXAuYwlUaHUgTWF5 IDE2IDE5OjU2OjA2IDIwMDINCisrKyBsaW51eDY0Lm5ldy9hcmNoL21pcHM2 NC9zZ2ktaXAzMi9pcDMyLXNldHVwLmMJU3VuIE1heSAxMiAyMjozNzo1MSAy MDAyDQpAQCAtMTIsNiArMTIsNyBAQA0KICNpbmNsdWRlIDxsaW51eC9tYzE0 NjgxOHJ0Yy5oPg0KICNpbmNsdWRlIDxsaW51eC9wYXJhbS5oPg0KICNpbmNs dWRlIDxsaW51eC9pbml0Lmg+DQorI2luY2x1ZGUgPGxpbnV4L2NvbnNvbGUu aD4NCiANCiAjaW5jbHVkZSA8YXNtL3RpbWUuaD4NCiAjaW5jbHVkZSA8YXNt L21pcHNyZWdzLmg+DQo= --279724308-1159884594-1021594554=:25304 Content-Type: TEXT/plain; name="linux-O2-fb.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-O2-fb.diff" LS0tIGxpbnV4NjQvaW5jbHVkZS9hc20tbWlwczY0L3BndGFibGUuaAlUaHUg TWF5IDE2IDIwOjAxOjEyIDIwMDINCisrKyBsaW51eDY0Lm5ldy9pbmNsdWRl L2FzbS1taXBzNjQvcGd0YWJsZS5oCVN1biBNYXkgIDUgMjE6NTI6MTggMjAw Mg0KQEAgLTU1MSw2ICs1NTEsOCBAQA0KICNkZWZpbmUga2Vybl9hZGRyX3Zh bGlkKGFkZHIpCSgxKQ0KICNlbmRpZg0KIA0KKyNkZWZpbmUgaW9fcmVtYXBf cGFnZV9yYW5nZSByZW1hcF9wYWdlX3JhbmdlDQorDQogLyoNCiAgKiBObyBw YWdlIHRhYmxlIGNhY2hlcyB0byBpbml0aWFsaXNlDQogICovDQpkaWZmIC1O YXVyIGxpbnV4NjQvZHJpdmVycy92aWRlby9Db25maWcuaW4gbGludXg2NC5u ZXcvZHJpdmVycy92aWRlby9Db25maWcuaW4NCi0tLSBsaW51eDY0L2RyaXZl cnMvdmlkZW8vQ29uZmlnLmluCVRodSBNYXkgMTYgMTk6NTk6NDkgMjAwMg0K KysrIGxpbnV4NjQubmV3L2RyaXZlcnMvdmlkZW8vQ29uZmlnLmluCVR1ZSBN YXkgMTQgMjM6Mzg6MzQgMjAwMg0KQEAgLTk3LDYgKzk3LDkgQEANCiAgICAg ICB0cmlzdGF0ZSAnICBTR0kgVmlzdWFsIFdvcmtzdGF0aW9uIGZyYW1lYnVm ZmVyIHN1cHBvcnQnIENPTkZJR19GQl9TR0lWVw0KICAgICAgIGRlZmluZV9i b29sIENPTkZJR19CVVNfSTJDIHkNCiAgICBmaQ0KKyAgIGlmIFsgIiRDT05G SUdfU0dJX0lQMzIiID0gInkiIF07IHRoZW4NCisgICAgICBib29sICcgIFNH SSBPMiBmcmFtZSBidWZmZXIgc3VwcG9ydCcgQ09ORklHX0ZCX1NHSU8yDQor ICAgZmkNCiAgICBpZiBbICIkQ09ORklHX1NVTjMiID0gInkiIC1vICIkQ09O RklHX1NVTjNYIiA9ICJ5IiBdOyB0aGVuDQogICAgICAgYm9vbCAnICBTdW4z IGZyYW1lYnVmZmVyIHN1cHBvcnQnIENPTkZJR19GQl9TVU4zDQogICAgICAg aWYgWyAiJENPTkZJR19GQl9TVU4zIiAhPSAibiIgXTsgdGhlbg0KQEAgLTE5 Niw2ICsxOTksNyBAQA0KICAgIGlmIFsgIiRDT05GSUdfTklOTyIgPSAieSIg XTsgdGhlbg0KICAgICAgIGJvb2wgJyAgVE1QVFgzOTEyL1BSMzE3MDAgZnJh bWUgYnVmZmVyIHN1cHBvcnQnIENPTkZJR19GQl9UWDM5MTINCiAgICBmaQ0K Kw0KICAgIGlmIFsgIiRDT05GSUdfRVhQRVJJTUVOVEFMIiA9ICJ5IiBdOyB0 aGVuDQogICAgICAgdHJpc3RhdGUgJyAgVmlydHVhbCBGcmFtZSBCdWZmZXIg c3VwcG9ydCAoT05MWSBGT1IgVEVTVElORyEpJyBDT05GSUdfRkJfVklSVFVB TA0KICAgIGZpDQpAQCAtMjY0LDExICsyNjgsMTEgQEANCiAJICAgIiRDT05G SUdfRkJfQ1Q2NTU1MCIgPSAieSIgLW8gIiRDT05GSUdfRkJfUE0yIiA9ICJ5 IiAtbyBcDQogCSAgICIkQ09ORklHX0ZCX1A5MTAwIiA9ICJ5IiAtbyAiJENP TkZJR19GQl9BVFkxMjgiID0gInkiIC1vIFwNCiAJICAgIiRDT05GSUdfRkJf UklWQSIgPSAieSIgLW8gIiRDT05GSUdfRkJfUkFERU9OIiA9ICJ5IiAtbyBc DQotCSAgICIkQ09ORklHX0ZCX1NHSVZXIiA9ICJ5IiAtbyAiJENPTkZJR19G Ql9DWUJFUjIwMDAiID0gInkiIC1vIFwNCisJICAgIiRDT05GSUdfRkJfU0dJ VlciID0gInkiIC1vICIkQ09ORklHX0ZCX0NZQkVSMjAwMCIgPSAieSIgXA0K IAkgICAiJENPTkZJR19GQl9TQTExMDAiID0gInkiIC1vICIkQ09ORklHX0ZC XzNERlgiID0gInkiIC1vIFwNCiAJICAgIiRDT05GSUdfRkJfUE1BR19CQSIg PSAieSIgLW8gIiRDT05GSUdfRkJfUE1BR0JfQiIgPSAieSIgLW8gXA0KIAkg ICAiJENPTkZJR19GQl9NQVhJTkUiID0gInkiIC1vICIkQ09ORklHX0ZCX1RY MzkxMiIgPSAieSIgLW8gXA0KLQkgICAiJENPTkZJR19GQl9TSVMiID0gInki IF07IHRoZW4NCisJICAgIiRDT05GSUdfRkJfU0lTIiA9ICJ5IiAgLW8gIiRD T05GSUdfRkJfU0dJTzIiID0gInkiXTsgdGhlbg0KIAkgZGVmaW5lX3RyaXN0 YXRlIENPTkZJR19GQkNPTl9DRkI4IHkNCiAgICAgICBlbHNlDQogCSBpZiBb ICIkQ09ORklHX0ZCX0FDT1JOIiA9ICJtIiAtbyAiJENPTkZJR19GQl9BVEFS SSIgPSAibSIgLW8gXA0KQEAgLTI4NCwxMSArMjg4LDExIEBADQogCSAgICAg ICIkQ09ORklHX0ZCX0NUNjU1NTAiID0gIm0iIC1vICIkQ09ORklHX0ZCX1BN MiIgPSAibSIgLW8gXA0KIAkgICAgICAiJENPTkZJR19GQl9QOTEwMCIgPSAi bSIgLW8gIiRDT05GSUdfRkJfQVRZMTI4IiA9ICJtIiAtbyBcDQogCSAgICAg ICIkQ09ORklHX0ZCX1JJVkEiID0gIm0iIC1vICIkQ09ORklHX0ZCXzNERlgi ID0gIm0iIC1vIFwNCi0JICAgICAgIiRDT05GSUdfRkJfU0dJVlciID0gIm0i IC1vICIkQ09ORklHX0ZCX0NZQkVSMjAwMCIgPSAibSIgLW8gXA0KKwkgICAg ICAiJENPTkZJR19GQl9TR0lWVyIgPSAibSIgIC1vICIkQ09ORklHX0ZCX0NZ QkVSMjAwMCIgPSAibSIgXA0KIAkgICAgICAiJENPTkZJR19GQl9QTUFHX0JB IiA9ICJtIiAtbyAiJENPTkZJR19GQl9QTUFHQl9CIiA9ICJtIiAtbyBcDQog CSAgICAgICIkQ09ORklHX0ZCX01BWElORSIgPSAibSIgLW8gIiRDT05GSUdf RkJfUkFERU9OIiA9ICJtIiAtbyBcDQogCSAgICAgICIkQ09ORklHX0ZCX1NB MTEwMCIgPSAibSIgLW8gIiRDT05GSUdfRkJfU0lTIiA9ICJtIiAtbyBcDQot CSAgICAgICIkQ09ORklHX0ZCX1RYMzkxMiIgPSAibSIgXTsgdGhlbg0KKwkg ICAgICAiJENPTkZJR19GQl9UWDM5MTIiID0gIm0iIC1vICIkQ09ORklHX0ZC X1NHSU8yIiA9ICJtIl07IHRoZW4NCiAJICAgIGRlZmluZV90cmlzdGF0ZSBD T05GSUdfRkJDT05fQ0ZCOCBtDQogCSBmaQ0KICAgICAgIGZpDQpAQCAtMzA0 LDcgKzMwOCw4IEBADQogCSAgICIkQ09ORklHX0ZCX1JJVkEiID0gInkiIC1v ICIkQ09ORklHX0ZCX0FUWTEyOCIgPSAieSIgLW8gXA0KIAkgICAiJENPTkZJ R19GQl9DWUJFUjIwMDAiID0gInkiIC1vICIkQ09ORklHX0ZCXzNERlgiID0g InkiICAtbyBcDQogCSAgICIkQ09ORklHX0ZCX1NJUyIgPSAieSIgLW8gIiRD T05GSUdfRkJfU0ExMTAwIiA9ICJ5IiAtbyBcDQotCSAgICIkQ09ORklHX0ZC X1BWUjIiID0gInkiIC1vICIkQ09ORklHX0ZCX1ZPT0RPTzEiID0gInkiIF07 IHRoZW4NCisJICAgIiRDT05GSUdfRkJfUFZSMiIgPSAieSIgLW8gIiRDT05G SUdfRkJfVk9PRE9PMSIgPSAieSIgLW8gXA0KKwkgICAiJENPTkZJR19GQl9T R0lPMiIgPSAieSJdOyB0aGVuDQogCSBkZWZpbmVfdHJpc3RhdGUgQ09ORklH X0ZCQ09OX0NGQjE2IHkNCiAgICAgICBlbHNlDQogCSBpZiBbICIkQ09ORklH X0ZCX0FUQVJJIiA9ICJtIiAtbyAiJENPTkZJR19GQl9BVFkiID0gIm0iIC1v IFwNCkBAIC0zMTksNyArMzI0LDggQEANCiAJICAgICAgIiRDT05GSUdfRkJf UklWQSIgPSAibSIgLW8gIiRDT05GSUdfRkJfQVRZMTI4IiA9ICJtIiAtbyBc DQogCSAgICAgICIkQ09ORklHX0ZCX0NZQkVSMjAwMCIgPSAibSIgLW8gIiRD T05GSUdfRkJfU0lTIiA9ICJtIiAtbyBcDQogCSAgICAgICIkQ09ORklHX0ZC X1NBMTEwMCIgPSAibSIgLW8gIiRDT05GSUdfRkJfUkFERU9OIiA9ICJtIiAt byBcDQotCSAgICAgICIkQ09ORklHX0ZCX1BWUjIiID0gIm0iIC1vICIkQ09O RklHX0ZCX1ZPT0RPTzEiID0gIm0iIF07IHRoZW4NCisJICAgICAgIiRDT05G SUdfRkJfUFZSMiIgPSAibSIgLW8gIiRDT05GSUdfRkJfVk9PRE9PMSIgPSAi bSIgLW8gXA0KKwkgICAgICAiJENPTkZJR19GQl9TR0lPMiIgPSAibSJdOyB0 aGVuDQogCSAgICBkZWZpbmVfdHJpc3RhdGUgQ09ORklHX0ZCQ09OX0NGQjE2 IG0NCiAJIGZpDQogICAgICAgZmkNCkBAIC0zNDksNyArMzU1LDcgQEANCiAJ ICAgIiRDT05GSUdfRkJfRk0yIiA9ICJ5IiAtbyAiJENPTkZJR19GQl9TR0lW VyIgPSAieSIgLW8gXA0KIAkgICAiJENPTkZJR19GQl9SQURFT04iID0gInki IC1vICIkQ09ORklHX0ZCX1BWUjIiID0gInkiIC1vIFwNCiAJICAgIiRDT05G SUdfRkJfM0RGWCIgPSAieSIgLW8gIiRDT05GSUdfRkJfU0lTIiA9ICJ5IiAt byBcDQotCSAgICIkQ09ORklHX0ZCX1ZPT0RPTzEiID0gInkiIF07IHRoZW4N CisJICAgIiRDT05GSUdfRkJfVk9PRE9PMSIgPSAieSIgLW8gIiRDT05GSUdf RkJfU0dJTzIiID0gInkiXTsgdGhlbg0KIAkgZGVmaW5lX3RyaXN0YXRlIENP TkZJR19GQkNPTl9DRkIzMiB5DQogICAgICAgZWxzZQ0KIAkgaWYgWyAiJENP TkZJR19GQl9BVEFSSSIgPSAibSIgLW8gIiRDT05GSUdfRkJfQVRZIiA9ICJt IiAtbyBcDQpAQCAtMzYwLDcgKzM2Niw4IEBADQogCSAgICAgICIkQ09ORklH X0ZCX1JJVkEiID0gIm0iIC1vICIkQ09ORklHX0ZCX0FUWTEyOCIgPSAibSIg LW8gXA0KIAkgICAgICAiJENPTkZJR19GQl8zREZYIiA9ICJtIiAtbyAiJENP TkZJR19GQl9SQURFT04iID0gIm0iIC1vIFwNCiAJICAgICAgIiRDT05GSUdf RkJfU0dJVlciID0gIm0iIC1vICIkQ09ORklHX0ZCX1NJUyIgPSAibSIgLW8g XA0KLQkgICAgICAiJENPTkZJR19GQl9QVlIyIiA9ICJtIiAtbyAiJENPTkZJ R19GQl9WT09ET08xIiA9ICJtIiBdOyB0aGVuDQorCSAgICAgICIkQ09ORklH X0ZCX1BWUjIiID0gIm0iIC1vICIkQ09ORklHX0ZCX1ZPT0RPTzEiID0gIm0i IC1vIFwNCisJICAgICAgIiRDT05GSUdfRkJfU0dJTzIiID0gIm0iIF07IHRo ZW4NCiAJICAgIGRlZmluZV90cmlzdGF0ZSBDT05GSUdfRkJDT05fQ0ZCMzIg bQ0KIAkgZmkNCiAgICAgICBmaQ0KZGlmZiAtTmF1ciBsaW51eDY0L2RyaXZl cnMvdmlkZW8vTWFrZWZpbGUgbGludXg2NC5uZXcvZHJpdmVycy92aWRlby9N YWtlZmlsZQ0KLS0tIGxpbnV4NjQvZHJpdmVycy92aWRlby9NYWtlZmlsZQlU aHUgTWF5IDE2IDE5OjU5OjQ5IDIwMDINCisrKyBsaW51eDY0Lm5ldy9kcml2 ZXJzL3ZpZGVvL01ha2VmaWxlCVR1ZSBNYXkgIDcgMjI6MDI6MzIgMjAwMg0K QEAgLTU3LDYgKzU3LDcgQEANCiBvYmotJChDT05GSUdfRkJfQ1lCRVIpICAg ICAgICAgICAgKz0gY3liZXJmYi5vDQogb2JqLSQoQ09ORklHX0ZCX0NZQkVS MjAwMCkgICAgICAgICs9IGN5YmVyMjAwMGZiLm8NCiBvYmotJChDT05GSUdf RkJfU0dJVlcpICAgICAgICAgICAgKz0gc2dpdndmYi5vDQorb2JqLSQoQ09O RklHX0ZCX1NHSU8yKSAgICAgICAgICAgICs9IHNnaW8yZmIubw0KIG9iai0k KENPTkZJR19GQl8zREZYKSAgICAgICAgICAgICArPSB0ZGZ4ZmIubw0KIG9i ai0kKENPTkZJR19GQl9NQUMpICAgICAgICAgICAgICArPSBtYWNmYi5vIG1h Y21vZGVzLm8NCiBvYmotJChDT05GSUdfRkJfSFAzMDApICAgICAgICAgICAg Kz0gaHBmYi5vDQpAQCAtODQsNyArODUsNiBAQA0KIG9iai0kKENPTkZJR19G Ql9QTUFHQl9CKSAgICAgICAgICArPSBwbWFnYi1iLWZiLm8NCiBvYmotJChD T05GSUdfRkJfTUFYSU5FKSAgICAgICAgICAgKz0gbWF4aW5lZmIubw0KIG9i ai0kKENPTkZJR19GQl9UWDM5MTIpICAgICAgICAgICArPSB0eDM5MTJmYi5v DQotDQogDQogc3ViZGlyLSQoQ09ORklHX0ZCX01BVFJPWCkJICArPSBtYXRy b3gNCiBpZmVxICgkKENPTkZJR19GQl9NQVRST1gpLHkpDQpkaWZmIC1OYXVy IGxpbnV4NjQvZHJpdmVycy92aWRlby9mYm1lbS5jIGxpbnV4NjQubmV3L2Ry aXZlcnMvdmlkZW8vZmJtZW0uYw0KLS0tIGxpbnV4NjQvZHJpdmVycy92aWRl by9mYm1lbS5jCVRodSBNYXkgMTYgMTk6NTk6NTMgMjAwMg0KKysrIGxpbnV4 NjQubmV3L2RyaXZlcnMvdmlkZW8vZmJtZW0uYwlUaHUgTWF5IDE2IDE5OjQ3 OjM3IDIwMDINCkBAIC0xMTAsNiArMTEwLDggQEANCiBleHRlcm4gaW50IHN1 bjNmYl9zZXR1cChjaGFyICopOw0KIGV4dGVybiBpbnQgc2dpdndmYl9pbml0 KHZvaWQpOw0KIGV4dGVybiBpbnQgc2dpdndmYl9zZXR1cChjaGFyKik7DQor ZXh0ZXJuIGludCBzZ2lvMmZiX2luaXQodm9pZCk7DQorZXh0ZXJuIGludCBz Z2lvMmZiX3NldHVwKGNoYXIqKTsNCiBleHRlcm4gaW50IHJpdmFmYl9pbml0 KHZvaWQpOw0KIGV4dGVybiBpbnQgcml2YWZiX3NldHVwKGNoYXIqKTsNCiBl eHRlcm4gaW50IHRkZnhmYl9pbml0KHZvaWQpOw0KQEAgLTIzNyw2ICsyMzks OSBAQA0KICNpZmRlZiBDT05GSUdfRkJfU0dJVlcNCiAJeyAic2dpdnciLCBz Z2l2d2ZiX2luaXQsIHNnaXZ3ZmJfc2V0dXAgfSwNCiAjZW5kaWYNCisjaWZk ZWYgQ09ORklHX0ZCX1NHSU8yDQorCXsgInNnaW8yIiwgc2dpbzJmYl9pbml0 LCBzZ2lvMmZiX3NldHVwIH0sDQorI2VuZGlmDQogI2lmZGVmIENPTkZJR19G Ql9BQ09STg0KIAl7ICJhY29ybiIsIGFjb3JuZmJfaW5pdCwgYWNvcm5mYl9z ZXR1cCB9LA0KICNlbmRpZg0KZGlmZiAtTmF1ciBsaW51eDY0L2RyaXZlcnMv dmlkZW8vc2dpbzJmYi5jIGxpbnV4NjQubmV3L2RyaXZlcnMvdmlkZW8vc2dp bzJmYi5jDQotLS0gbGludXg2NC9kcml2ZXJzL3ZpZGVvL3NnaW8yZmIuYwlU aHUgSmFuICAxIDAxOjAwOjAwIDE5NzANCisrKyBsaW51eDY0Lm5ldy9kcml2 ZXJzL3ZpZGVvL3NnaW8yZmIuYwlUaHUgTWF5IDE2IDE5OjQ2OjI5IDIwMDIN CkBAIC0wLDAgKzEsMTE5OSBAQA0KKy8qDQorICogIGxpbnV4L2RyaXZlcnMv dmlkZW8vc2dpbzJmYi5jIC0tIFNHSSBHQkUgZnJhbWUgYnVmZmVyIGRldmlj ZQ0KKyAqDQorICoJQ29weXJpZ2h0IChDKSAxOTk5IFNpbGljb24gR3JhcGhp Y3MsIEluYy4NCisgKiAgICAgIEplZmZyZXkgTmV3cXVpc3QsIG5ld3F1aXN0 QGVuZ3Iuc2dpLnNvbQ0KKyAqICAgICBDb3B5cmlnaHQgKEMpIDIwMDIgVml2 aWVuIENoYXBwZWxpZXIsIHZpdmllbi5jaGFwcGVsaWVyQGVuc3QtYnJldGFn bmUuZnIgDQorICogICAgICBtb2RpZmllZCBmcm9tIHRoZSBvcmlnaW5hbCBT R0kgVlcgREJFIGRyaXZlciB0byBzdXBwb3J0IHRoZSBPMiBHQkUNCisgKg0K KyAqICBUaGlzIGZpbGUgaXMgc3ViamVjdCB0byB0aGUgdGVybXMgYW5kIGNv bmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYw0KKyAqICBMaWNl bnNlLiBTZWUgdGhlIGZpbGUgQ09QWUlORyBpbiB0aGUgbWFpbiBkaXJlY3Rv cnkgb2YgdGhpcyBhcmNoaXZlIGZvcg0KKyAqICBtb3JlIGRldGFpbHMuDQor ICovDQorDQorI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5oPg0KKyNpbmNsdWRl IDxsaW51eC9tb2R1bGUuaD4NCisjaW5jbHVkZSA8bGludXgva2VybmVsLmg+ DQorI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+DQorI2luY2x1ZGUgPGxpbnV4 L3N0cmluZy5oPg0KKyNpbmNsdWRlIDxsaW51eC9tbS5oPg0KKyNpbmNsdWRl IDxsaW51eC90dHkuaD4NCisjaW5jbHVkZSA8bGludXgvc2xhYi5oPg0KKyNp bmNsdWRlIDxsaW51eC92bWFsbG9jLmg+DQorI2luY2x1ZGUgPGxpbnV4L2Rl bGF5Lmg+DQorI2luY2x1ZGUgPGxpbnV4L2ludGVycnVwdC5oPg0KKyNpbmNs dWRlIDxhc20vdWFjY2Vzcy5oPg0KKyNpbmNsdWRlIDxsaW51eC9mYi5oPg0K KyNpbmNsdWRlIDxsaW51eC9pbml0Lmg+DQorI2luY2x1ZGUgPGFzbS9pby5o Pg0KKw0KKyNpbmNsdWRlIDx2aWRlby9mYmNvbi5oPg0KKyNpbmNsdWRlIDx2 aWRlby9mYmNvbi1jZmI4Lmg+DQorI2luY2x1ZGUgPHZpZGVvL2ZiY29uLWNm YjE2Lmg+DQorI2luY2x1ZGUgPHZpZGVvL2ZiY29uLWNmYjMyLmg+DQorDQor I2RlZmluZSBJTkNMVURFX1RJTUlOR19UQUJMRV9EQVRBDQorI2RlZmluZSBH QkVfUkVHX0JBU0UgcmVncw0KKyNpbmNsdWRlICJzZ2lvMmZiLmgiDQorDQor c3RydWN0IHNnaW8yZmJfcGFyIHsNCisgIHN0cnVjdCBmYl92YXJfc2NyZWVu aW5mbyB2YXI7DQorICB1X2xvbmcgdGltaW5nX251bTsNCisgIGludCB2YWxp ZDsNCit9Ow0KKw0KKy8qDQorICogIFJBTSB3ZSByZXNlcnZlIGZvciB0aGUg ZnJhbWUgYnVmZmVyLiBUaGlzIGRlZmluZXMgdGhlIG1heGltdW0gc2NyZWVu DQorICogIHNpemUNCisgKg0KKyAqICBUaGUgZGVmYXVsdCBjYW4gYmUgb3Zl cnJpZGRlbiBpZiB0aGUgZHJpdmVyIGlzIGNvbXBpbGVkIGFzIGEgbW9kdWxl DQorICovDQorDQorLyogVE9ETzogYWRkIGFuIG9wdGlvbiAqLw0KKyNkZWZp bmUgVklERU9NRU1TSVpFCSgyKjEwMjQqMTAyNCkJLyogMiBNQiAqLw0KKw0K K3N0YXRpYyB1MTYgKnNnaW8yZmJfdGlsZXNfdGFibGU7DQorc3RhdGljIHVf bG9uZyBzZ2lvMmZiX21lbV9waHlzOw0KK3N0YXRpYyB1X2xvbmcgc2dpbzJm Yl9tZW1fc2l6ZTsNCisNCitzdGF0aWMgdm9sYXRpbGUgY2hhciAgKmZibWVt Ow0KK3N0YXRpYyBhc3JlZ3MgICAgICAgICAqcmVnczsNCitzdGF0aWMgc3Ry dWN0IGZiX2luZm8gZmJfaW5mbzsNCitzdGF0aWMgc3RydWN0IHsgdV9jaGFy IHJlZCwgZ3JlZW4sIGJsdWUsIHBhZDsgfSBwYWxldHRlWzI1Nl07DQorc3Rh dGljIGNoYXIgICAgICAgICAgIHNnaW8yZmJfbmFtZVsxNl0gPSAiU0dJIE8y IEZCIjsNCitzdGF0aWMgdTMyICAgICAgICAgICAgY21hcF9maWZvOw0KK3N0 YXRpYyBpbnQgICAgICAgICAgICB5cGFuICAgICAgID0gMDsNCitzdGF0aWMg aW50ICAgICAgICAgICAgeXdyYXAgICAgICA9IDA7DQorc3RhdGljIGludCAg ICAgICAgICAgIHZpZGVvX2JwcDsNCisNCisvKiBjb25zb2xlIHJlbGF0ZWQg dmFyaWFibGVzICovDQorc3RhdGljIGludCBjdXJyY29uID0gMDsNCitzdGF0 aWMgc3RydWN0IGRpc3BsYXkgZGlzcDsNCisNCitzdGF0aWMgdW5pb24gew0K KyNpZmRlZiBGQkNPTl9IQVNfQ0ZCMTYNCisgIHUxNiBjZmIxNlsxNl07DQor I2VuZGlmDQorI2lmZGVmIEZCQ09OX0hBU19DRkIzMg0KKyAgdTMyIGNmYjMy WzE2XTsNCisjZW5kaWYNCit9IGZiY29uX2NtYXA7DQorDQorc3RhdGljIHN0 cnVjdCBzZ2lvMmZiX3BhciBwYXJfY3VycmVudCA9IHsNCisgIC8vIFRFTVA6 IGZvciB0ZXN0aW5nIHZhcmlvdXMgbW9kZXMNCisjaWYgMA0KKyAgeyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLyogdmFyIChzY3JlZW5pbmZvKSAq Lw0KKyAgICAvKiA2NDB4NDgwLCAzMiBicHAgKi8NCisgICAgNjQwLCA0ODAs IDY0MCwgNDgwLCAwLCAwLCAzMiwgMCwNCisgICAgezI0LCA4LCAwfSwgezE2 LCA4LCAwfSwgezgsIDgsIDB9LCB7MCwgOCwgMH0sDQorICAgIDAsIDAsIC0x LCAtMSwgMCwgMjAwMDAsIDY0LCA2NCwgMzIsIDMyLCA2NCwgMiwNCisgICAg MCwgRkJfVk1PREVfTk9OSU5URVJMQUNFRA0KKyAgfSwNCisgIDAsICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8qIHRpbWluZ19udW0gKi8NCisgIDAJ CQkJLyogcGFyIG5vdCBhY3RpdmF0ZWQgKi8NCisjZW5kaWYNCisjaWYgMA0K KyAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogdmFyIChzY3Jl ZW5pbmZvKSAqLw0KKyAgICAvKiA2NDB4NDgwLCAxNiBicHAgKi8NCisgICAg NjQwLCA0ODAsIDY0MCwgNDgwLCAwLCAwLCAxNiwgMCwNCisgICAgezEwLCA1 LCAwfSwgezUsIDUsIDB9LCB7MCwgNSwgMH0sIHswLCAwLCAwfSwNCisgICAg MCwgMCwgLTEsIC0xLCAwLCAyMDAwMCwgNjQsIDY0LCAzMiwgMzIsIDY0LCAy LA0KKyAgICAwLCBGQl9WTU9ERV9OT05JTlRFUkxBQ0VEDQorICB9LA0KKyAg MCwgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogdGltaW5nX251bSAq Lw0KKyAgMAkJCQkvKiBwYXIgbm90IGFjdGl2YXRlZCAqLw0KKyNlbmRpZg0K KyNpZiAxDQorICB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiB2 YXIgKHNjcmVlbmluZm8pICovDQorICAgIC8qIDY0MHg0ODAsIDggYnBwICov DQorICAgIDY0MCwgNDgwLCA2NDAsIDQ4MCwgMCwgMCwgOCwgMCwNCisgICAg ezAsIDgsIDB9LCB7MCwgOCwgMH0sIHswLCA4LCAwfSwgezAsIDAsIDB9LA0K KyAgICAwLCAwLCAtMSwgLTEsIDAsIDIwMDAwLCA2NCwgNjQsIDMyLCAzMiwg NjQsIDIsDQorICAgIDAsIEZCX1ZNT0RFX05PTklOVEVSTEFDRUQNCisgIH0s DQorICAwLCAgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiB0aW1pbmdf bnVtICovDQorICAwCQkJCS8qIHBhciBub3QgYWN0aXZhdGVkICovDQorI2Vu ZGlmDQorI2lmIDANCisgIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC8qIHZhciAoc2NyZWVuaW5mbykgKi8NCisgICAgLyogODAweDYwMCwgOCBi cHAgKi8NCisgICAgODAwLCA2MDAsIDgwMCwgNjAwLCAwLCAwLCA4LCAwLA0K KyAgICB7MCwgOCwgMH0sIHswLCA4LCAwfSwgezAsIDgsIDB9LCB7MCwgMCwg MH0sDQorICAgIDAsIDAsIC0xLCAtMSwgMCwgMjAwMDAsIDY0LCA2NCwgMzIs IDMyLCA2NCwgMiwNCisgICAgMCwgRkJfVk1PREVfTk9OSU5URVJMQUNFRA0K KyAgfSwNCisgIEdCRV9WVF84MDBfNjAwXzc1LCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvKiB0aW1pbmdfbnVtICovDQorICAwCQkJCS8qIHBhciBu b3QgYWN0aXZhdGVkICovDQorI2VuZGlmDQorI2lmIDANCisgIHsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8qIHZhciAoc2NyZWVuaW5mbykgKi8N CisgICAgLyogODAweDYwMCwgMTYgYnBwICovDQorICAgIDgwMCwgNjAwLCA4 MDAsIDYwMCwgMCwgMCwgMTYsIDAsDQorICAgIHswLCA4LCAwfSwgezAsIDgs IDB9LCB7MCwgOCwgMH0sIHswLCAwLCAwfSwNCisgICAgMCwgMCwgLTEsIC0x LCAwLCAyMDAwMCwgNjQsIDY0LCAzMiwgMzIsIDY0LCAyLA0KKyAgICAwLCBG Ql9WTU9ERV9OT05JTlRFUkxBQ0VEDQorICB9LA0KKyAgR0JFX1ZUXzgwMF82 MDBfNzUsICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIHRpbWluZ19u dW0gKi8NCisgIDAJCQkJLyogcGFyIG5vdCBhY3RpdmF0ZWQgKi8NCisjZW5k aWYNCisjaWYgMA0KK3sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q IHZhciAoc2NyZWVuaW5mbykgKi8NCisgICAgLyogMTAyNHg3NjgsIDggYnBw ICovDQorICAgIDEwMjQsIDc2OCwgMTAyNCwgNzY4LCAwLCAwLCA4LCAwLA0K KyAgICB7MCwgOCwgMH0sIHswLCA4LCAwfSwgezAsIDgsIDB9LCB7MCwgMCwg MH0sDQorICAgIDAsIDAsIC0xLCAtMSwgMCwgMTUzODQsIDY0LCA2NCwgMzIs IDMyLCA2NCwgMiwNCisgICAgMCwgRkJfVk1PREVfTk9OSU5URVJMQUNFRA0K KyAgfSwNCisgIEdCRV9WVF8xMDI0Xzc2OF82MCwNCisgIDAJCQkJLyogcGFy IG5vdCBhY3RpdmF0ZWQgKi8NCisjZW5kaWYNCisjaWYgMA0KK3sgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC8qIHZhciAoc2NyZWVuaW5mbykgKi8N CisgICAgLyogMTI4MHgxMDI0LCA4IGJwcCAqLw0KKyAgICAxMjgwLCAxMDI0 LCAxMjgwLCAxMDI0LCAwLCAwLCA4LCAwLA0KKyAgICB7MCwgOCwgMH0sIHsw LCA4LCAwfSwgezAsIDgsIDB9LCB7MCwgMCwgMH0sDQorICAgIDAsIDAsIC0x LCAtMSwgMCwgMTUzODQsIDY0LCA2NCwgMzIsIDMyLCA2NCwgMiwNCisgICAg MCwgRkJfVk1PREVfTk9OSU5URVJMQUNFRA0KKyAgfSwNCisgIEdCRV9WVF8x MjgwXzEwMjRfNjAsDQorICAwCQkJCS8qIHBhciBub3QgYWN0aXZhdGVkICov DQorI2VuZGlmDQorI2lmIDANCit7ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAvKiB2YXIgKHNjcmVlbmluZm8pICovDQorICAgIC8qIDEyODB4MTAy NCwgOCBicHAgKi8NCisgICAgMTYwMCwgMTIwMCwgMTYwMCwgMTIwMCwgMCwg MCwgOCwgMCwNCisgICAgezAsIDgsIDB9LCB7MCwgOCwgMH0sIHswLCA4LCAw fSwgezAsIDAsIDB9LA0KKyAgICAwLCAwLCAtMSwgLTEsIDAsIDE1Mzg0LCA2 NCwgNjQsIDMyLCAzMiwgNjQsIDIsDQorICAgIDAsIEZCX1ZNT0RFX05PTklO VEVSTEFDRUQNCisgIH0sDQorICBHQkVfVlRfMTYwMF8xMjAwXzYwLA0KKyAg MAkJCQkvKiBwYXIgbm90IGFjdGl2YXRlZCAqLw0KKyNlbmRpZg0KK307DQor DQorLyoNCisgKiAgSW50ZXJmYWNlIHVzZWQgYnkgdGhlIHdvcmxkDQorICov DQoraW50IHNnaW8yZmJfc2V0dXAoY2hhciopOw0KKw0KK3N0YXRpYyBpbnQg c2dpbzJmYl9nZXRfZml4KHN0cnVjdCBmYl9maXhfc2NyZWVuaW5mbyAqZml4 LCBpbnQgY29uLA0KKwkJCSAgIHN0cnVjdCBmYl9pbmZvICppbmZvKTsNCitz dGF0aWMgaW50IHNnaW8yZmJfZ2V0X3ZhcihzdHJ1Y3QgZmJfdmFyX3NjcmVl bmluZm8gKnZhciwgaW50IGNvbiwNCisJCQkgICBzdHJ1Y3QgZmJfaW5mbyAq aW5mbyk7DQorc3RhdGljIGludCBzZ2lvMmZiX3NldF92YXIoc3RydWN0IGZi X3Zhcl9zY3JlZW5pbmZvICp2YXIsIGludCBjb24sDQorCQkJICAgc3RydWN0 IGZiX2luZm8gKmluZm8pOw0KK3N0YXRpYyBpbnQgc2dpbzJmYl9nZXRfY21h cChzdHJ1Y3QgZmJfY21hcCAqY21hcCwgaW50IGtzcGMsIGludCBjb24sDQor CQkJICAgIHN0cnVjdCBmYl9pbmZvICppbmZvKTsNCitzdGF0aWMgaW50IHNn aW8yZmJfc2V0X2NtYXAoc3RydWN0IGZiX2NtYXAgKmNtYXAsIGludCBrc3Bj LCBpbnQgY29uLA0KKwkJCSAgICBzdHJ1Y3QgZmJfaW5mbyAqaW5mbyk7DQor c3RhdGljIGludCBzZ2lvMmZiX21tYXAoc3RydWN0IGZiX2luZm8gKmluZm8s IHN0cnVjdCBmaWxlICpmaWxlLA0KKyAgICAgICAgICAgICAgICAgICAgICAg IHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqdm1hKTsNCisNCitzdGF0aWMgc3Ry dWN0IGZiX29wcyBzZ2lvMmZiX29wcyA9IHsNCisJb3duZXI6CQlUSElTX01P RFVMRSwNCisJZmJfZ2V0X2ZpeDoJc2dpbzJmYl9nZXRfZml4LA0KKwlmYl9n ZXRfdmFyOglzZ2lvMmZiX2dldF92YXIsDQorCWZiX3NldF92YXI6CXNnaW8y ZmJfc2V0X3ZhciwNCisJZmJfZ2V0X2NtYXA6CXNnaW8yZmJfZ2V0X2NtYXAs DQorCWZiX3NldF9jbWFwOglzZ2lvMmZiX3NldF9jbWFwLA0KKwlmYl9tbWFw OglzZ2lvMmZiX21tYXAsDQorfTsNCisNCisvKg0KKyAqICBJbnRlcmZhY2Ug dG8gdGhlIGxvdyBsZXZlbCBjb25zb2xlIGRyaXZlcg0KKyAqLw0KK2ludCBz Z2lvMmZiX2luaXQodm9pZCk7DQorc3RhdGljIGludCBzZ2lvMmZiY29uX3N3 aXRjaChpbnQgY29uLCBzdHJ1Y3QgZmJfaW5mbyAqaW5mbyk7DQorc3RhdGlj IGludCBzZ2lvMmZiY29uX3VwZGF0ZXZhcihpbnQgY29uLCBzdHJ1Y3QgZmJf aW5mbyAqaW5mbyk7DQorc3RhdGljIHZvaWQgc2dpbzJmYmNvbl9ibGFuayhp bnQgYmxhbmssIHN0cnVjdCBmYl9pbmZvICppbmZvKTsNCisNCisvKg0KKyAq ICBJbnRlcm5hbCByb3V0aW5lcw0KKyAqLw0KK3N0YXRpYyB1X2xvbmcgZ2V0 X2xpbmVfbGVuZ3RoKGludCB4cmVzX3ZpcnR1YWwsIGludCBicHApOw0KK3N0 YXRpYyB1bnNpZ25lZCBsb25nIGJ5dGVzX3Blcl9waXhlbChpbnQgYnBwKTsN CitzdGF0aWMgdm9pZCBhY3RpdmF0ZV9wYXIoc3RydWN0IHNnaW8yZmJfcGFy ICpwYXIpOw0KK3N0YXRpYyB2b2lkIHNnaW8yZmJfZW5jb2RlX2ZpeChzdHJ1 Y3QgZmJfZml4X3NjcmVlbmluZm8gKmZpeCwNCisJCQkgICAgICAgc3RydWN0 IGZiX3Zhcl9zY3JlZW5pbmZvICp2YXIpOw0KK3N0YXRpYyBpbnQgc2dpbzJm Yl9nZXRjb2xyZWcodV9pbnQgcmVnbm8sIHVfaW50ICpyZWQsIHVfaW50ICpn cmVlbiwgdV9pbnQgKmJsdWUsDQorCQkJICAgICB1X2ludCAqdHJhbnNwLCBz dHJ1Y3QgZmJfaW5mbyAqaW5mbyk7DQorc3RhdGljIGludCBzZ2lvMmZiX3Nl dGNvbHJlZyh1X2ludCByZWdubywgdV9pbnQgcmVkLCB1X2ludCBncmVlbiwg dV9pbnQgYmx1ZSwNCisJCQkgICAgIHVfaW50IHRyYW5zcCwgc3RydWN0IGZi X2luZm8gKmluZm8pOw0KK3N0YXRpYyB2b2lkIGRvX2luc3RhbGxfY21hcChp bnQgY29uLCBzdHJ1Y3QgZmJfaW5mbyAqaW5mbyk7DQorDQorc3RhdGljIHVu c2lnbmVkIGxvbmcgZ2V0X2xpbmVfbGVuZ3RoKGludCB4cmVzX3ZpcnR1YWws IGludCBicHApDQorew0KKyAgcmV0dXJuKHhyZXNfdmlydHVhbCAqIGJ5dGVz X3Blcl9waXhlbChicHApKTsNCit9DQorDQorc3RhdGljIHVuc2lnbmVkIGxv bmcgYnl0ZXNfcGVyX3BpeGVsKGludCBicHApDQorew0KKyAgdW5zaWduZWQg bG9uZyBsZW5ndGg7DQorDQorICBzd2l0Y2ggKGJwcCkgew0KKyAgY2FzZSA4 Og0KKyAgICBsZW5ndGggPSAxOw0KKyAgICBicmVhazsNCisgIGNhc2UgMTY6 DQorICAgIGxlbmd0aCA9IDI7DQorICAgIGJyZWFrOw0KKyAgY2FzZSAzMjoN CisgICAgbGVuZ3RoID0gNDsNCisgICAgYnJlYWs7DQorICBkZWZhdWx0Og0K KyAgICBwcmludGsoS0VSTl9JTkZPICJzZ2lvMmZiOiB1bnN1cHBvcnRlZCBi cHA9JWRcbiIsIGJwcCk7DQorICAgIGxlbmd0aCA9IDA7DQorICAgIGJyZWFr Ow0KKyAgfQ0KKyAgcmV0dXJuKGxlbmd0aCk7DQorfQ0KKw0KKy8qDQorICog RnVuY3Rpb246CWdiZV9UdXJuT2ZmRG1hDQorICogUGFyYW1ldGVyczoJKE5v bmUpDQorICogRGVzY3JpcHRpb246CVRoaXMgc2hvdWxkIHR1cm4gb2ZmIHRo ZSBtb25pdG9yIGFuZCBnYmUuICBUaGlzIGlzIHVzZWQNCisgKiAgICAgICAg ICAgICAgd2hlbiBzd2l0Y2hpbmcgYmV0d2VlbiB0aGUgc2VyaWFsIGNvbnNv bGUgYW5kIHRoZSBncmFwaGljcw0KKyAqICAgICAgICAgICAgICBjb25zb2xl Lg0KKyAqLw0KKw0KK3N0YXRpYyB2b2lkIGdiZV9UdXJuT2ZmRG1hKHZvaWQp DQorew0KKyAgaW50IGk7DQorICB1bnNpZ25lZCBpbnQgcmVhZFZhbDsNCisN CisgIC8vIENoZWNrIHRvIHNlZSBpZiB0aGluZ3MgYXJlIGFscmVhZHkgdHVy bmVkIG9mZjoNCisgIC8vIDEpIENoZWNrIHRvIHNlZSBpZiBnYmUgaXMgbm90 IHVzaW5nIHRoZSBpbnRlcm5hbCBkb3RjbG9jay4NCisgIC8vIDIpIENoZWNr IHRvIHNlZSBpZiB0aGUgeHkgY291bnRlciBpbiBnYmUgaXMgYWxyZWFkeSBv ZmYuDQorDQorICBHQkVfR0VUUkVHKGN0cmxzdGF0LCByZWFkVmFsKTsNCisg IGlmIChHRVRfR0JFX0ZJRUxEKENUUkxTVEFULCBQQ0xLU0VMLCByZWFkVmFs KSA8IDIpDQorICAgIHJldHVybjsNCisNCisgIEdCRV9HRVRSRUcodnRfeHks IHJlYWRWYWwpOw0KKyAgaWYgKEdFVF9HQkVfRklFTEQoVlRfWFksIFZUX0ZS RUVaRSwgcmVhZFZhbCkgPT0gMSkNCisgICAgcmV0dXJuOw0KKw0KKyAgLy8g T3RoZXJ3aXNlLCB0dXJuIG9mZiBnYmUNCisgIEdCRV9HRVRSRUcob3ZyX2Nv bnRyb2wsIHJlYWRWYWwpOw0KKyAgU0VUX0dCRV9GSUVMRChPVlJfQ09OVFJP TCwgT1ZSX0RNQV9FTkFCTEUsIHJlYWRWYWwsIDApOw0KKyAgR0JFX1NFVFJF RyhvdnJfY29udHJvbCwgcmVhZFZhbCk7DQorICB1ZGVsYXkoMTAwMCk7DQor ICBHQkVfR0VUUkVHKGZybV9jb250cm9sLCByZWFkVmFsKTsNCisgIFNFVF9H QkVfRklFTEQoRlJNX0NPTlRST0wsIEZSTV9ETUFfRU5BQkxFLCByZWFkVmFs LCAwKTsNCisgIEdCRV9TRVRSRUcoZnJtX2NvbnRyb2wsIHJlYWRWYWwpOw0K KyAgdWRlbGF5KDEwMDApOw0KKyAgR0JFX0dFVFJFRyhkaWRfY29udHJvbCwg cmVhZFZhbCk7DQorICBTRVRfR0JFX0ZJRUxEKERJRF9DT05UUk9MLCBESURf RE1BX0VOQUJMRSwgcmVhZFZhbCwgMCk7DQorICBHQkVfU0VUUkVHKGRpZF9j b250cm9sLCByZWFkVmFsKTsNCisgIHVkZWxheSgxMDAwKTsNCisNCisgIC8v IFhYWCBIQUNLOg0KKyAgLy8NCisgIC8vICAgIFRoaXMgd2FzIG5lY2Vzc2Fy eSBmb3IgR0JFLS13ZSBoYWQgdG8gd2FpdCB0aHJvdWdoIHR3bw0KKyAgLy8g ICAgdmVydGljYWwgcmV0cmFjZSBwZXJpb2RzIGJlZm9yZSB0aGUgcGl4ZWwg RE1BIHdhcw0KKyAgLy8gICAgdHVybmVkIG9mZiBmb3Igc3VyZS4gIEkndmUg bGVmdCB0aGlzIGluIGZvciBub3csIGluDQorICAvLyAgICBjYXNlIGRiZSBu ZWVkcyBpdC4NCisgIC8vIFtWQ10uLiB3ZWxsIG5vdyB0aGlzIGlzIEdCRSA7 KQ0KKw0KKyAgZm9yIChpID0gMDsgaSA8IDEwMDAwOyBpKyspDQorICAgIHsN CisgICAgICBHQkVfR0VUUkVHKGZybV9pbmh3Y3RybCwgcmVhZFZhbCk7DQor ICAgICAgaWYgKEdFVF9HQkVfRklFTEQoRlJNX0lOSFdDVFJMLCBGUk1fRE1B X0VOQUJMRSwgcmVhZFZhbCkgPT0gMCkgew0KKyAgICAgICAgdWRlbGF5KDEw KTsNCisgICAgICB9DQorICAgICAgZWxzZQ0KKyAgICAgICAgew0KKyAgICAg ICAgICBHQkVfR0VUUkVHKG92cl9pbmh3Y3RybCwgcmVhZFZhbCk7DQorICAg ICAgICAgIGlmIChHRVRfR0JFX0ZJRUxEKE9WUl9JTkhXQ1RSTCwgT1ZSX0RN QV9FTkFCTEUsIHJlYWRWYWwpID09IDApIHsNCisgICAgICAgICAgICB1ZGVs YXkoMTApOw0KKwkgIH0NCisgICAgICAgICAgZWxzZQ0KKyAgICAgICAgICAg IHsNCisgICAgICAgICAgICAgIEdCRV9HRVRSRUcoZGlkX2luaHdjdHJsLCBy ZWFkVmFsKTsNCisgICAgICAgICAgICAgIGlmIChHRVRfR0JFX0ZJRUxEKERJ RF9JTkhXQ1RSTCwgRElEX0RNQV9FTkFCTEUsIHJlYWRWYWwpID09IDApIHsN CisgICAgICAgICAgICAgICAgdWRlbGF5KDEwKTsNCisJICAgICAgfQ0KKyAg ICAgICAgICAgICAgZWxzZQ0KKyAgICAgICAgICAgICAgICBicmVhazsNCisg ICAgICAgICAgICB9DQorICAgICAgICB9DQorICAgIH0NCit9DQorDQorLyoN CisgKiAgU2V0IHRoZSBoYXJkd2FyZSBhY2NvcmRpbmcgdG8gJ3BhcicuDQor ICovDQorc3RhdGljIHZvaWQgYWN0aXZhdGVfcGFyKHN0cnVjdCBzZ2lvMmZi X3BhciAqcGFyKQ0KK3sNCisgIGludCBpLGosIGh0bXAsIHRlbXA7DQorICB1 MzIgcmVhZFZhbCwgb3V0cHV0VmFsOw0KKyAgaW50IHdob2xlVGlsZXNYLCBw YXJ0VGlsZXNYLCBtYXhQaXhlbHNQZXJUaWxlWDsNCisgIGludCBoZWlnaHRf cGl4Ow0KKyAgaW50IGZybVdyaXRlMSwgZnJtV3JpdGUyLCBmcm1Xcml0ZTNi Ow0KKyAgZ2JlX3RpbWluZ19pbmZvX3QgKmN1cnJlbnRUaW1pbmc7ICAgIC8q IEN1cnJlbnQgVmlkZW8gVGltaW5nICovDQorICBpbnQgeHBtYXgsIHlwbWF4 OyAgICAgICAgICAgICAgICAgICAgICAgLy8gTW9uaXRvciByZXNvbHV0aW9u DQorICBpbnQgYnl0ZXNQZXJQaXhlbDsgICAgICAgICAgICAgICAgICAgICAg Ly8gQnl0ZXMgcGVyIHBpeGVsDQorDQorICBjdXJyZW50VGltaW5nID0gJmdi ZVZUaW1pbmdzW3Bhci0+dGltaW5nX251bV07DQorICBieXRlc1BlclBpeGVs ID0gYnl0ZXNfcGVyX3BpeGVsKHBhci0+dmFyLmJpdHNfcGVyX3BpeGVsKTsN CisgIHhwbWF4ID0gY3VycmVudFRpbWluZy0+d2lkdGg7DQorICB5cG1heCA9 IGN1cnJlbnRUaW1pbmctPmhlaWdodDsNCisNCisgIC8qIGdiZV9Jbml0R3Jh cGhpY3NCYXNlKCk7ICovDQorICAvKiBUdXJuIG9uIGRvdGNsb2NrIFBMTCAq Lw0KKyAgR0JFX1NFVFJFRyhjdHJsc3RhdCwgMHgzMDAwMDAwMCk7DQorDQor ICBnYmVfVHVybk9mZkRtYSgpOw0KKw0KKyAgLyogZ2JlX0NhbGN1bGF0ZVNj cmVlblBhcmFtcygpOyAqLw0KKyAgLyogSEFDSzoNCisgICAgICAgVGhlIEdC RSBoYXJkd2FyZSB1c2VzIGEgdGlsZWQgbWVtb3J5IHRvIHNjcmVlbiBtYXBw aW5nLiBUaWxlcyBhcmUgYmxvY2tzIG9mDQorICAgICAgIDUxMngxMjgsIDI1 NngxMjggb3IgMTI4eDEyOCBwaXhlbHMsIHJlc3BlY3RpdmVseSBmb3IgOGJp dCwgMTZiaXQgYW5kIDMyIGJpdA0KKyAgICAgICBtb2RlcyAoNjQga0IpLiBU aGV5IGNvdmVyIHRoZSBzY3JlZW4gd2l0aCBwYXJ0aWFsIHRpbGVzIG9uIHRo ZSByaWdodCBhbmQvb3INCisgICAgICAgYm90dG9tIG9mIHRoZSBzY3JlZW4g aWYgbmVlZGVkLiBGb3IgZXhlbXBsZSBpbiA2NDB4NDgwIDggYml0IG1vZGUg dGhlIG1hcHBpbmcNCisgICAgICAgaXM6DQorCSANCisgICAgICAgICA8LS0t LS0tLS0gNjQwIC0tLS0tPg0KKyAgICAgICAgIDwtLS0tIDUxMiAtLS0tPjwx Mjh8Mzg0IG9mZnNjcmVlbj4NCisgICAgXiAgXg0KKyAgICB8IDEyOCAgICBb dGlsZSAwXSAgICAgICAgW3RpbGUgMV0NCisgICAgfCAgdg0KKyAgICAgICBe DQorICAgIDQgMTI4ICAgIFt0aWxlIDJdICAgICAgICBbdGlsZSAzXQ0KKyAg ICA4ICB2DQorICAgIDAgIF4NCisgICAgICAxMjggICAgW3RpbGUgNF0gICAg ICAgIFt0aWxlIDVdDQorICAgIHwgIHYNCisgICAgfCAgXg0KKyAgICB2ICA5 NiAgICBbdGlsZSA2XSAgICAgICAgW3RpbGUgN10NCisgICAgICAgMzIgb2Zm c2NyZWVuDQorDQorICAgICAgIFRpbGVzIGhhdmUgdGhlIGFkdmFudGFnZSB0 aGF0IHRoZXkgY2FuIGJlIGFsbG9jYXRlZCBpbmRpdmlkdWFsbHkgaW4gbWVt b3J5Lg0KKyAgICAgICBIb3dldmVyLCB0aGlzIG1hcHBpbmcgaXMgbm90IGxp bmVhciBhdCBhbGwsIHdoaWNoIGlzIG5vdCByZWFsbHkgY29udmllbmllbnQu DQorICAgICAgIEluIG9yZGVyIHRvIHN1cHBvcnQgbGluZWFyIGFkZHJlc3Np bmcsIHRoZSBHQkUgRE1BIGhhcmR3YXJlIGlzIGZvb2xlZCBpbnRvDQorICAg ICAgIHRoaW5raW5nIHRoZSBzY3JlZW4gaXMgb25seSBvbmUgdGlsZSBsYXJn ZSBhbmQgYnV0IGhhcyBhIGdyZWF0ZXIgaGVpZ2h0LCBzbyANCisgICAgICAg dGhhdCB0aGUgRE1BIHRyYW5zZmVyIGNvdmVycyB0aGUgc2FtZSByZWdpb24u DQorICAgICAgIEZpcnN0IGEgY29udGlub3VzIHJlZ2lvbiBpcyBhbGxvY2F0 ZWQgaW4gbWVtb3J5IHRvIHNlcnZlIGFzIHRoZSBmcmFtZWJ1ZmZlci4NCisg ICAgICAgVGhlbiB0aGUgdGlsZSB0YWJsZSBpcyBzZXQgdXAgc28gdGhhdCBl YWNoIHRpbGUgcmVmZXJlbmNlIGEgNjRrIGJsb2NrIGluIHRoaXMNCisgICAg ICAgbWVtb3J5Og0KKyAgICAgICBHQkUgRE1BIC0tLT4gdGlsZSBsaXN0ICAg ICAgICAgICAgIGZyYW1lYnVmZmVyDQorICAgICAgICAgICAgICAgICAgIFsg dGlsZSAwIF0gLS0tPiBbIDB4MDAwMDAwMDA6MHgwMDAwZmZmZiBdDQorICAg ICAgICAgICAgICAgICAgIFsgdGlsZSAxIF0gLS0tPiBbIDB4MDAwMTAwMDA6 MHgwMDAxZmZmZiBdDQorICAgICAgICAgICAgICAgICAgIFsgdGlsZSAyIF0g LS0tPiBbIDB4MDAwMjAwMDA6MHgwMDAyZmZmZiBdDQorICAgICAgICAgICAg ICAgICAgIFsgdGlsZSAzIF0gLS0tPiBbIDB4MDAwMzAwMDA6MHgwMDAzZmZm ZiBdDQorCQkgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAuLi4NCisg ICAgICAgICAgICAgICAgICAgWyB0aWxlIG4gXSAtLS0+IFsgMHgwMDBuMDAw MDoweDAwMG5mZmZmIF0NCisNCisJVGhlIEdCRSBoYXJkd2FyZSBpcyB0aGVu IHRvbGQgdGhhdCB0aGUgYnVmZmVyIGlzIDUxMnh0d2Vha2VkX2hlaWdodCwg d2l0aCANCisJdHdlYWtlZF9oZWlnaHQgPSByZWFsX3dpZHRoeHJlYWxfaGVp Z2h0L3BpeGVsc19wZXJfdGlsZQ0KKwlUaHVzIHRoZSBHQkUgaGFyZHdhcmUg d2lsbCBzY2FuIHRoZSBmaXJzdCB0aWxlLCBmaWxpbmcgdGhlIGZpcnN0IDY0 ayBjb3ZlcmVkDQorCXJlZ2lvbiBvZiB0aGUgc2NyZWVuLCBhbmQgdGhlbiB3 aWxsIHByb2NlZWQgdG8gdGhlIG5leHQgdGlsZSwgd2hpY2ggaXMganVzdA0K KwlhZnRlciB0aGUgZmlyc3Qgb25lIGluIG1lbW9yeSwgdW50aWwgdGhlIHdo b2xlIHNjcmVlbiBpcyBjb3ZlcmVkLg0KKw0KKwlIZXJlIGlzIHdoYXQgd291 bGQgaGFwcGVuIGF0IDY0MHg0ODAgOGJpdDoNCisNCisJICAgICBub3JtYWwg dGlsaW5nICAgICAgICAgICAgICAgbGluZWFyDQorICAgICAgXiAgIDExMTEx MTExMTExMTExMTEyMjIyICAgIDExMTExMTExMTExMTExMTExMTExICBeDQor ICAgICAxMjggIDExMTExMTExMTExMTExMTEyMjIyICAgIDExMTExMTExMTEx MTExMTExMTExIDEwMiBsaW5lcw0KKyAgICAgICAgICAxMTExMTExMTExMTEx MTExMjIyMiAgICAxMTExMTExMTExMTExMTExMTExMSAgdg0KKyAgICAgIFYg ICAxMTExMTExMTExMTExMTExMjIyMiAgICAxMTExMTExMTIyMjIyMjIyMjIy Mg0KKwkgIDMzMzMzMzMzMzMzMzMzMzM0NDQ0ICAgIDIyMjIyMjIyMjIyMjIy MjIyMjIyDQorCSAgMzMzMzMzMzMzMzMzMzMzMzQ0NDQgICAgMjIyMjIyMjIy MjIyMjIyMjIyMjINCisJICA8ICAgICAgNTEyICAgICA+ICAgICAgICA8ICAy NTYgPiAgICAgICAgICAgICAgIDEwMio2NDArMjU2ID0gNjRrDQorDQorICAg ICBOT1RFOiBUaGUgb25seSBtb2RlIGZvciB3aGljaCB0aGlzIGlzIG5vdCB3 b3JraW5nIGlzIDgwMHg2MDAgOGJpdCwgYXMNCisgICAgICAgICAgIDgwMCo2 MDAvNTEyID0gOTM3LjUgd2hpY2ggaXMgbm90IGludGVnZXIgYW5kIHRodXMg Y2F1c2VzIGZsaWNrZXJpbmcuDQorCSAgIEkgZ3Vlc3MgdGhpcyBpcyBub3Qg c28gaW1wb3J0YW50IGFzIG9uZSBjYW4gdXNlIDY0MHg0ODAgOGJpdCBvcg0K KwkgICA4MDB4NjAwIDE2Yml0IGFueXdheS4NCisgICovDQorICBtYXhQaXhl bHNQZXJUaWxlWCA9IDUxMi9ieXRlc1BlclBpeGVsOw0KKyAgd2hvbGVUaWxl c1ggPSAxOw0KKyAgcGFydFRpbGVzWCA9IDA7DQorDQorICAvKiBJbml0aWFs aXplIHRpbGUgcG9pbnRlcnMgKi8NCisgIGZvcihpID0gMDsgaSA8IDEyODsg aSsrKQ0KKyAgICBzZ2lvMmZiX3RpbGVzX3RhYmxlW2ldID0gKHUxNikgKENQ SFlTQUREUihzZ2lvMmZiX21lbV9waHlzKSA+PiAxNikgKyBpOw0KKw0KKyAg LyogZ2JlX0luaXRHYW1tYU1hcCgpOyAqLw0KKyAgdWRlbGF5KDEwKTsNCisg IGZvciAoaSA9IDA7IGkgPCAyNTY7IGkrKykNCisgICAgR0JFX0lTRVRSRUco Z21hcCwgaSwgKGkgPDwgMjQpIHwgKGkgPDwgMTYpIHwgKGkgPDwgOCkpOw0K Kw0KKyAgLyogZ2JlX1R1cm5PbigpOyAqLw0KKyAgR0JFX0dFVFJFRyh2dF94 eSwgcmVhZFZhbCk7DQorICBpZiAoR0VUX0dCRV9GSUVMRChWVF9YWSwgVlRf RlJFRVpFLCByZWFkVmFsKSA9PSAxKQ0KKyAgew0KKyAgICAgIEdCRV9TRVRS RUcodnRfeHksIDB4MDAwMDAwMDApOw0KKyAgICAgIHVkZWxheSgxKTsNCisg IH0NCisgIGVsc2UNCisgICAgZ2JlX1R1cm5PZmZEbWEoKTsNCisNCisgIC8q IGdiZV9Jbml0Z2JlKCk7ICovDQorICBmb3IgKGkgPSAwOyBpIDwgMjU2OyBp KyspDQorICB7DQorICAgIC8qIFhYWDogbm90IHdvcmtpbmcNCisgICAgICBm b3IgKGogPSAwOyBqIDwgMTAwOyBqKyspDQorICAgICAgew0KKyAgICAgICAg ICBHQkVfR0VUUkVHKGNtX2ZpZm8sIGNtYXBfZmlmbyk7DQorICAgICAgICAg IGlmIChjbWFwX2ZpZm8gIT0gMHgwMDAwMDAwMCkNCisgICAgICAgICAgICBi cmVhazsNCisgICAgICAgICAgZWxzZQ0KKyAgICAgICAgICAgIHVkZWxheSgx MCk7DQorICAgICAgfQ0KKyAgICAqLw0KKyAgICBHQkVfSVNFVFJFRyhjbWFw LCBpLCAoaTw8OCl8KGk8PDE2KXwoaTw8MjQpKTsNCisgICAgdWRlbGF5KDEw MDApOyAvKiBsZWF2ZSBzb21lIGRlbGF5IGluc3RlYWQgKi8NCisgIH0NCisN CisgIC8qIGdiZV9Jbml0RnJhbWVidWZmZXIoKTsgKi8NCisgIGZybVdyaXRl MSA9IDA7DQorICBTRVRfR0JFX0ZJRUxEKEZSTV9TSVpFX1RJTEUsIEZSTV9X SURUSF9USUxFLCBmcm1Xcml0ZTEsIHdob2xlVGlsZXNYKTsNCisgIFNFVF9H QkVfRklFTEQoRlJNX1NJWkVfVElMRSwgRlJNX1JIUywgZnJtV3JpdGUxLCBw YXJ0VGlsZXNYKTsNCisNCisgIHN3aXRjaChieXRlc1BlclBpeGVsKQ0KKyAg ICB7DQorICAgICAgY2FzZSAxOg0KKyAgICAgICAgU0VUX0dCRV9GSUVMRChG Uk1fU0laRV9USUxFLCBGUk1fREVQVEgsIGZybVdyaXRlMSwgR0JFX0ZSTV9E RVBUSF84KTsNCisgICAgICAgIGJyZWFrOw0KKyAgICAgIGNhc2UgMjoNCisg ICAgICAgIFNFVF9HQkVfRklFTEQoRlJNX1NJWkVfVElMRSwgRlJNX0RFUFRI LCBmcm1Xcml0ZTEsIEdCRV9GUk1fREVQVEhfMTYpOw0KKyAgICAgICAgYnJl YWs7DQorICAgICAgY2FzZSA0Og0KKyAgICAgICAgU0VUX0dCRV9GSUVMRChG Uk1fU0laRV9USUxFLCBGUk1fREVQVEgsIGZybVdyaXRlMSwgR0JFX0ZSTV9E RVBUSF8zMik7DQorICAgICAgICBicmVhazsNCisgICAgfQ0KKw0KKyAgZnJt V3JpdGUyID0gMDsNCisgIC8vIFNFVF9HQkVfRklFTEQoRlJNX1NJWkVfUElY RUwsIEZCX0hFSUdIVF9QSVgsIGZybVdyaXRlMiwgeXBtYXgpOw0KKw0KKyAg LyogY29tcHV0ZSB0d2Vha2VkIGhlaWdodCA9IHJlYWwgd2lkdGggeCByZWFs IGhlaWdodCAvIHBpeGVscyBwZXIgdGlsZSAqLw0KKyAgaGVpZ2h0X3BpeCA9 IHhwbWF4KnlwbWF4L21heFBpeGVsc1BlclRpbGVYOw0KKw0KKyAgaWYoaGVp Z2h0X3BpeCAqIG1heFBpeGVsc1BlclRpbGVYICE9IHhwbWF4KnlwbWF4KQ0K KyAgICBwcmludGsoS0VSTl9ERUJVRyAic2dpbzJmYjogdGhpcyBtb2RlIGNh bm5vdCBiZSBtYXBwZWQgbGluZWFybHkuIFBsZWFzZSB1c2UgYW5vdGhlciBv bmUuXG4iKTsNCisNCisgIFNFVF9HQkVfRklFTEQoRlJNX1NJWkVfUElYRUws IEZCX0hFSUdIVF9QSVgsIGZybVdyaXRlMiwgaGVpZ2h0X3BpeCk7DQorDQor ICAvLyBUZWxsIGdiZSBhYm91dCB0aGUgZnJhbWVidWZmZXIgbG9jYXRpb24g YW5kIHR5cGUNCisgIC8qIHRpbGVfcHRyIC0+IFsgdGlsZSAxIF0gLT4gRkIg bWVtICovDQorICAvKiAgICAgICAgICAgICBbIHRpbGUgMiBdIC0+IEZCIG1l bSAqLw0KKyAgLyogICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAg Ki8NCisgIGZybVdyaXRlM2IgPSAwOw0KKyAgU0VUX0dCRV9GSUVMRChGUk1f Q09OVFJPTCwgRlJNX1RJTEVfUFRSLCBmcm1Xcml0ZTNiLCAoKHUzMilDUEhZ U0FERFIoc2dpbzJmYl90aWxlc190YWJsZSkpPj45KTsNCisgIFNFVF9HQkVf RklFTEQoRlJNX0NPTlRST0wsIEZSTV9ETUFfRU5BQkxFLCBmcm1Xcml0ZTNi LCAxKTsNCisNCisgIC8qIEluaXRpYWxpemUgRElEcyAqLw0KKyAgb3V0cHV0 VmFsID0gMDsNCisgIHN3aXRjaChieXRlc1BlclBpeGVsKQ0KKyAgew0KKyAg ICAgIGNhc2UgMToNCisgICAgICAgIFNFVF9HQkVfRklFTEQoV0lELCBUWVAs IG91dHB1dFZhbCwgR0JFX0NNT0RFX0k4KTsNCisgICAgICAgIGJyZWFrOw0K KyAgICAgIGNhc2UgMjoNCisgICAgICAgIFNFVF9HQkVfRklFTEQoV0lELCBU WVAsIG91dHB1dFZhbCwgR0JFX0NNT0RFX1JHQkE1KTsNCisgICAgICAgIGJy ZWFrOw0KKyAgICAgIGNhc2UgNDoNCisgICAgICAgIFNFVF9HQkVfRklFTEQo V0lELCBUWVAsIG91dHB1dFZhbCwgR0JFX0NNT0RFX1JHQjgpOw0KKyAgICAg ICAgYnJlYWs7DQorICB9DQorICBTRVRfR0JFX0ZJRUxEKFdJRCwgQlVGLCBv dXRwdXRWYWwsIEdCRV9CTU9ERV9CT1RIKTsNCisgIC8vICBTRVRfR0JFX0ZJ RUxEKFdJRCwgR0FNTUEsIG91dHB1dFZhbCwgMSk7IC8qIGRpc2FibGUgZ2Ft bWEgY29ycmVjdGlvbiAqLw0KKw0KKyAgZm9yIChpID0gMDsgaSA8IDMyOyBp KyspDQorICAgIHsNCisgICAgICBHQkVfSVNFVFJFRyhtb2RlX3JlZ3MsIGks IG91dHB1dFZhbCk7DQorICAgIH0NCisNCisgIC8qIGdiZV9Jbml0VGltaW5n KCk7ICovDQorICBHQkVfU0VUUkVHKHZ0X2ludHIwMSwgMHhmZmZmZmZmZik7 DQorICBHQkVfU0VUUkVHKHZ0X2ludHIyMywgMHhmZmZmZmZmZik7DQorDQor ICBHQkVfR0VUUkVHKGRvdGNsb2NrLCByZWFkVmFsKTsNCisgIEdCRV9TRVRS RUcoZG90Y2xvY2ssIHJlYWRWYWwgJiAweGZmZmYpOw0KKw0KKyAgR0JFX1NF VFJFRyh2dF94eW1heCwgMHgwMDAwMDAwMCk7DQorICBvdXRwdXRWYWwgPSAw Ow0KKyAgU0VUX0dCRV9GSUVMRChWVF9WU1lOQywgVlRfVlNZTkNfT04sIG91 dHB1dFZhbCwgY3VycmVudFRpbWluZy0+dnN5bmNfc3RhcnQpOw0KKyAgU0VU X0dCRV9GSUVMRChWVF9WU1lOQywgVlRfVlNZTkNfT0ZGLCBvdXRwdXRWYWws IGN1cnJlbnRUaW1pbmctPnZzeW5jX2VuZCk7DQorICBHQkVfU0VUUkVHKHZ0 X3ZzeW5jLCBvdXRwdXRWYWwpOw0KKyAgb3V0cHV0VmFsID0gMDsNCisgIFNF VF9HQkVfRklFTEQoVlRfSFNZTkMsIFZUX0hTWU5DX09OLCBvdXRwdXRWYWws IGN1cnJlbnRUaW1pbmctPmhzeW5jX3N0YXJ0KTsNCisgIFNFVF9HQkVfRklF TEQoVlRfSFNZTkMsIFZUX0hTWU5DX09GRiwgb3V0cHV0VmFsLCBjdXJyZW50 VGltaW5nLT5oc3luY19lbmQpOw0KKyAgR0JFX1NFVFJFRyh2dF9oc3luYywg b3V0cHV0VmFsKTsNCisgIG91dHB1dFZhbCA9IDA7DQorICBTRVRfR0JFX0ZJ RUxEKFZUX1ZCTEFOSywgVlRfVkJMQU5LX09OLCBvdXRwdXRWYWwsIGN1cnJl bnRUaW1pbmctPnZibGFua19zdGFydCk7DQorICBTRVRfR0JFX0ZJRUxEKFZU X1ZCTEFOSywgVlRfVkJMQU5LX09GRiwgb3V0cHV0VmFsLCBjdXJyZW50VGlt aW5nLT52YmxhbmtfZW5kKTsNCisgIEdCRV9TRVRSRUcodnRfdmJsYW5rLCBv dXRwdXRWYWwpOw0KKyAgb3V0cHV0VmFsID0gMDsNCisgIFNFVF9HQkVfRklF TEQoVlRfSEJMQU5LLCBWVF9IQkxBTktfT04sIG91dHB1dFZhbCwgY3VycmVu dFRpbWluZy0+aGJsYW5rX3N0YXJ0LTUpOw0KKyAgU0VUX0dCRV9GSUVMRChW VF9IQkxBTkssIFZUX0hCTEFOS19PRkYsIG91dHB1dFZhbCwgY3VycmVudFRp bWluZy0+aGJsYW5rX2VuZC0zKTsNCisgIEdCRV9TRVRSRUcodnRfaGJsYW5r LCBvdXRwdXRWYWwpOw0KKyAgb3V0cHV0VmFsID0gMDsNCisgIFNFVF9HQkVf RklFTEQoVlRfVkNNQVAsIFZUX1ZDTUFQX09OLCBvdXRwdXRWYWwsIGN1cnJl bnRUaW1pbmctPnZibGFua19zdGFydCk7DQorICBTRVRfR0JFX0ZJRUxEKFZU X1ZDTUFQLCBWVF9WQ01BUF9PRkYsIG91dHB1dFZhbCwgY3VycmVudFRpbWlu Zy0+dmJsYW5rX2VuZCk7DQorICBHQkVfU0VUUkVHKHZ0X3ZjbWFwLCBvdXRw dXRWYWwpOw0KKyAgb3V0cHV0VmFsID0gMDsNCisgIFNFVF9HQkVfRklFTEQo VlRfSENNQVAsIFZUX0hDTUFQX09OLCBvdXRwdXRWYWwsIGN1cnJlbnRUaW1p bmctPmhibGFua19zdGFydCk7DQorICBTRVRfR0JFX0ZJRUxEKFZUX0hDTUFQ LCBWVF9IQ01BUF9PRkYsIG91dHB1dFZhbCwgY3VycmVudFRpbWluZy0+aGJs YW5rX2VuZC0zKTsNCisgIEdCRV9TRVRSRUcodnRfaGNtYXAsIG91dHB1dFZh bCk7DQorDQorICAvKiB0dXJuIG9mZiBzeW5jIG9uIGdyZWVuICovDQorICBv dXRwdXRWYWwgPSAwOw0KKyAgU0VUX0dCRV9GSUVMRChWVF9GTEFHUywgVlRf U1lOQ19MT1csIG91dHB1dFZhbCwgMSk7DQorICBHQkVfU0VUUkVHKHZ0X2Zs YWdzLCBvdXRwdXRWYWwpOw0KKw0KKyAgb3V0cHV0VmFsID0gMDsNCisgIHRl bXAgPSBjdXJyZW50VGltaW5nLT52Ymxhbmtfc3RhcnQgLSBjdXJyZW50VGlt aW5nLT52YmxhbmtfZW5kIC0gMTsNCisgIGlmICh0ZW1wID4gMCkNCisgICAg dGVtcCA9IC10ZW1wOw0KKw0KKyAgU0VUX0dCRV9GSUVMRChESURfU1RBUlRf WFksIERJRF9TVEFSVFksIG91dHB1dFZhbCwgKHUzMil0ZW1wKTsNCisgIGlm IChjdXJyZW50VGltaW5nLT5oYmxhbmtfZW5kID49IDIwKQ0KKyAgICBTRVRf R0JFX0ZJRUxEKERJRF9TVEFSVF9YWSwgRElEX1NUQVJUWCwgb3V0cHV0VmFs LA0KKyAgICAgICAgICAgICAgICAgICAgICBjdXJyZW50VGltaW5nLT5oYmxh bmtfZW5kIC0gMjApOw0KKyAgZWxzZQ0KKyAgICBTRVRfR0JFX0ZJRUxEKERJ RF9TVEFSVF9YWSwgRElEX1NUQVJUWCwgb3V0cHV0VmFsLA0KKyAgICAgICAg ICAgICAgICAgICAgICBjdXJyZW50VGltaW5nLT5odG90YWwgLSAoMjAgLSBj dXJyZW50VGltaW5nLT5oYmxhbmtfZW5kKSk7DQorICBHQkVfU0VUUkVHKGRp ZF9zdGFydF94eSwgb3V0cHV0VmFsKTsNCisNCisgIG91dHB1dFZhbCA9IDA7 DQorICBTRVRfR0JFX0ZJRUxEKENSU19TVEFSVF9YWSwgQ1JTX1NUQVJUWSwg b3V0cHV0VmFsLCAodTMyKSh0ZW1wKzEpKTsNCisgIGlmIChjdXJyZW50VGlt aW5nLT5oYmxhbmtfZW5kID49IEdCRV9DUlNfTUFHSUMpDQorICAgIFNFVF9H QkVfRklFTEQoQ1JTX1NUQVJUX1hZLCBDUlNfU1RBUlRYLCBvdXRwdXRWYWws DQorICAgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRUaW1pbmctPmhibGFu a19lbmQgLSBHQkVfQ1JTX01BR0lDKTsNCisgIGVsc2UNCisgICAgU0VUX0dC RV9GSUVMRChDUlNfU1RBUlRfWFksIENSU19TVEFSVFgsIG91dHB1dFZhbCwN CisgICAgICAgICAgICAgICAgICAgICAgY3VycmVudFRpbWluZy0+aHRvdGFs IC0gKEdCRV9DUlNfTUFHSUMgLSBjdXJyZW50VGltaW5nLT5oYmxhbmtfZW5k KSk7DQorICBHQkVfU0VUUkVHKGNyc19zdGFydF94eSwgb3V0cHV0VmFsKTsN CisNCisgIG91dHB1dFZhbCA9IDA7DQorICBTRVRfR0JFX0ZJRUxEKFZDX1NU QVJUX1hZLCBWQ19TVEFSVFksIG91dHB1dFZhbCwgKHUzMil0ZW1wKTsNCisg IFNFVF9HQkVfRklFTEQoVkNfU1RBUlRfWFksIFZDX1NUQVJUWCwgb3V0cHV0 VmFsLA0KKyAgICAgICAgICAgICAgICAgICAgY3VycmVudFRpbWluZy0+aGJs YW5rX2VuZCAtIDQpOw0KKyAgR0JFX1NFVFJFRyh2Y19zdGFydF94eSwgb3V0 cHV0VmFsKTsNCisNCisgIEdCRV9TRVRSRUcoZnJtX3NpemVfdGlsZSwgZnJt V3JpdGUxKTsNCisgIEdCRV9TRVRSRUcoZnJtX3NpemVfcGl4ZWwsIGZybVdy aXRlMik7DQorDQorICBvdXRwdXRWYWwgPSAwOw0KKyAgU0VUX0dCRV9GSUVM RChET1RDTEssIE0sIG91dHB1dFZhbCwgY3VycmVudFRpbWluZy0+cGxsX20t MSk7DQorICBTRVRfR0JFX0ZJRUxEKERPVENMSywgTiwgb3V0cHV0VmFsLCBj dXJyZW50VGltaW5nLT5wbGxfbi0xKTsNCisgIFNFVF9HQkVfRklFTEQoRE9U Q0xLLCBQLCBvdXRwdXRWYWwsIGN1cnJlbnRUaW1pbmctPnBsbF9wKTsNCisg IFNFVF9HQkVfRklFTEQoRE9UQ0xLLCBSVU4sIG91dHB1dFZhbCwgMSk7DQor ICBHQkVfU0VUUkVHKGRvdGNsb2NrLCBvdXRwdXRWYWwpOw0KKw0KKyAgdWRl bGF5KDExKjEwMDApOw0KKw0KKyAgR0JFX1NFVFJFRyh2dF92cGl4ZW4sIDB4 ZmZmZmZmKTsNCisgIEdCRV9TRVRSRUcodnRfaHBpeGVuLCAweGZmZmZmZik7 DQorDQorICBvdXRwdXRWYWwgPSAwOw0KKyAgU0VUX0dCRV9GSUVMRChWVF9Y WU1BWCwgVlRfTUFYWCwgb3V0cHV0VmFsLCBjdXJyZW50VGltaW5nLT5odG90 YWwpOw0KKyAgU0VUX0dCRV9GSUVMRChWVF9YWU1BWCwgVlRfTUFYWSwgb3V0 cHV0VmFsLCBjdXJyZW50VGltaW5nLT52dG90YWwpOw0KKyAgR0JFX1NFVFJF Ryh2dF94eW1heCwgb3V0cHV0VmFsKTsNCisNCisgIG91dHB1dFZhbCA9IGZy bVdyaXRlMTsNCisgIC8vIFNFVF9HQkVfRklFTEQoRlJNX1NJWkVfVElMRSwg RlJNX0ZJRk9fUkVTRVQsIG91dHB1dFZhbCwgMSk7DQorICBHQkVfU0VUUkVH KGZybV9zaXplX3RpbGUsIG91dHB1dFZhbCk7DQorICBHQkVfU0VUUkVHKGZy bV9zaXplX3RpbGUsIGZybVdyaXRlMSk7DQorDQorICBvdXRwdXRWYWwgPSAw Ow0KKyAgLy8gIFNFVF9HQkVfRklFTEQoT1ZSX1dJRFRIX1RJTEUsIE9WUl9G SUZPX1JFU0VULCBvdXRwdXRWYWwsIDEpOw0KKyAgR0JFX1NFVFJFRyhvdnJf d2lkdGhfdGlsZSwgb3V0cHV0VmFsKTsNCisgIEdCRV9TRVRSRUcob3ZyX3dp ZHRoX3RpbGUsIDApOw0KKw0KKyAgR0JFX1NFVFJFRyhmcm1fY29udHJvbCwg ZnJtV3JpdGUzYik7DQorICBHQkVfU0VUUkVHKGRpZF9jb250cm9sLCAwKTsN CisNCisgIC8vIFdhaXQgZm9yIGdiZSB0byB0YWtlIGZyYW1lIHNldHRpbmdz DQorICBmb3IgKGk9MDsgaTwxMDAwMDA7IGkrKykNCisgICAgew0KKyAgICAg IEdCRV9HRVRSRUcoZnJtX2luaHdjdHJsLCByZWFkVmFsKTsNCisgICAgICBp ZiAoR0VUX0dCRV9GSUVMRChGUk1fSU5IV0NUUkwsIEZSTV9ETUFfRU5BQkxF LCByZWFkVmFsKSAhPSAwKQ0KKyAgICAgICAgYnJlYWs7DQorICAgICAgZWxz ZQ0KKyAgICAgICAgdWRlbGF5KDEpOw0KKyAgICB9DQorDQorICBpZiAoaT09 MTAwMDAwKQ0KKyAgICBwcmludGsoS0VSTl9JTkZPICJzZ2lvMmZiOiB0aW1l b3V0IHdhaXRpbmcgZm9yIGZyYW1lIERNQSBlbmFibGUuXG4iKTsNCisNCisg IG91dHB1dFZhbCA9IDA7DQorICBodG1wID0gY3VycmVudFRpbWluZy0+aGJs YW5rX2VuZCAtIDE5Ow0KKyAgaWYgKGh0bXAgPCAwKQ0KKyAgICBodG1wICs9 IGN1cnJlbnRUaW1pbmctPmh0b3RhbDsgICAgLyogYWxsb3cgYmxhbmsgdG8g d3JhcCBhcm91bmQgKi8NCisgIFNFVF9HQkVfRklFTEQoVlRfSFBJWEVOLCBW VF9IUElYRU5fT04sIG91dHB1dFZhbCwgaHRtcCk7DQorICBTRVRfR0JFX0ZJ RUxEKFZUX0hQSVhFTiwgVlRfSFBJWEVOX09GRiwgb3V0cHV0VmFsLA0KKyAg ICAgICAgICAgICAgICAgICAgKChodG1wICsgY3VycmVudFRpbWluZy0+d2lk dGggLSAyKSAlIGN1cnJlbnRUaW1pbmctPmh0b3RhbCkpOw0KKyAgR0JFX1NF VFJFRyh2dF9ocGl4ZW4sIG91dHB1dFZhbCk7DQorDQorICBvdXRwdXRWYWwg PSAwOw0KKyAgU0VUX0dCRV9GSUVMRChWVF9WUElYRU4sIFZUX1ZQSVhFTl9P RkYsIG91dHB1dFZhbCwNCisgICAgICAgICAgICAgICAgICAgIGN1cnJlbnRU aW1pbmctPnZibGFua19zdGFydCk7DQorICBTRVRfR0JFX0ZJRUxEKFZUX1ZQ SVhFTiwgVlRfVlBJWEVOX09OLCBvdXRwdXRWYWwsDQorICAgICAgICAgICAg ICAgICAgICBjdXJyZW50VGltaW5nLT52YmxhbmtfZW5kKTsNCisgIEdCRV9T RVRSRUcodnRfdnBpeGVuLCBvdXRwdXRWYWwpOw0KKw0KKyAgLy8gVHVybiBv ZmYgbW91c2UgY3Vyc29yDQorICByZWdzLT5jcnNfY3RsID0gMDsNCisNCisg IC8vIFhYWCBXaGF0J3MgdGhpcyBzZWN0aW9uIGZvcj8/DQorICBHQkVfR0VU UkVHKGN0cmxzdGF0LCByZWFkVmFsKTsNCisgIHJlYWRWYWwgJj0gMHgwMjAw MDAwMDsNCisNCisgIGlmIChyZWFkVmFsICE9IDApDQorICB7DQorICAgICAg R0JFX1NFVFJFRyhjdHJsc3RhdCwgMHgzMDAwMDAwMCk7DQorICB9DQorfQ0K Kw0KK3N0YXRpYyB2b2lkIHNnaW8yZmJfZW5jb2RlX2ZpeChzdHJ1Y3QgZmJf Zml4X3NjcmVlbmluZm8gKmZpeCwNCisJCQkgICAgICAgc3RydWN0IGZiX3Zh cl9zY3JlZW5pbmZvICp2YXIpDQorew0KKyAgbWVtc2V0KGZpeCwgMCwgc2l6 ZW9mKHN0cnVjdCBmYl9maXhfc2NyZWVuaW5mbykpOw0KKyAgc3RyY3B5KGZp eC0+aWQsIHNnaW8yZmJfbmFtZSk7DQorICBmaXgtPnNtZW1fc3RhcnQgPSBz Z2lvMmZiX21lbV9waHlzOw0KKyAgZml4LT5zbWVtX2xlbiA9IHNnaW8yZmJf bWVtX3NpemU7DQorICBmaXgtPnR5cGUgPSBGQl9UWVBFX1BBQ0tFRF9QSVhF TFM7DQorICBmaXgtPnR5cGVfYXV4ID0gMDsNCisgIHN3aXRjaCAodmFyLT5i aXRzX3Blcl9waXhlbCkgew0KKyAgY2FzZSA4Og0KKyAgICBmaXgtPnZpc3Vh bCA9IEZCX1ZJU1VBTF9QU0VVRE9DT0xPUjsNCisgICAgYnJlYWs7DQorICBk ZWZhdWx0Og0KKyAgICBmaXgtPnZpc3VhbCA9IEZCX1ZJU1VBTF9UUlVFQ09M T1I7DQorICAgIGJyZWFrOw0KKyAgfQ0KKyAgZml4LT55d3JhcHN0ZXAgPSB5 d3JhcDsNCisgIGZpeC0+eHBhbnN0ZXAgPSAwOw0KKyAgZml4LT55cGFuc3Rl cCA9IHlwYW47DQorICBmaXgtPmxpbmVfbGVuZ3RoID0gZ2V0X2xpbmVfbGVu Z3RoKHZhci0+eHJlc192aXJ0dWFsLCB2YXItPmJpdHNfcGVyX3BpeGVsKTsN CisgIGZpeC0+bW1pb19zdGFydCA9IEdCRV9SRUdfUEhZUzsNCisgIGZpeC0+ bW1pb19sZW4gPSBHQkVfUkVHX1NJWkU7DQorfQ0KKw0KKy8qDQorICogIFJl YWQgYSBzaW5nbGUgY29sb3IgcmVnaXN0ZXIgYW5kIHNwbGl0IGl0IGludG8N CisgKiAgY29sb3JzL3RyYW5zcGFyZW50LiBSZXR1cm4gIT0gMCBmb3IgaW52 YWxpZCByZWduby4NCisgKi8NCitzdGF0aWMgaW50IHNnaW8yZmJfZ2V0Y29s cmVnKHVfaW50IHJlZ25vLCB1X2ludCAqcmVkLCB1X2ludCAqZ3JlZW4sIHVf aW50ICpibHVlLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdV9p bnQgKnRyYW5zcCwgc3RydWN0IGZiX2luZm8gKmluZm8pDQorew0KKyAgaWYg KHJlZ25vID4gMjU1KQ0KKyAgICByZXR1cm4gMTsNCisNCisgICpyZWQgPSAg IHBhbGV0dGVbcmVnbm9dLnJlZCA8PCA4Ow0KKyAgKmdyZWVuID0gcGFsZXR0 ZVtyZWdub10uZ3JlZW4gPDwgODsNCisgICpibHVlID0gIHBhbGV0dGVbcmVn bm9dLmJsdWUgPDwgODsNCisgICp0cmFuc3AgPSAwOw0KKyAgcmV0dXJuIDA7 DQorfQ0KKw0KKy8qDQorICogIFNldCBhIHNpbmdsZSBjb2xvciByZWdpc3Rl ci4gVGhlIHZhbHVlcyBzdXBwbGllZCBhcmUgYWxyZWFkeQ0KKyAqICByb3Vu ZGVkIGRvd24gdG8gdGhlIGhhcmR3YXJlJ3MgY2FwYWJpbGl0aWVzIChhY2Nv cmRpbmcgdG8gdGhlDQorICogIGVudHJpZXMgaW4gdGhlIHZhciBzdHJ1Y3R1 cmUpLiBSZXR1cm4gIT0gMCBmb3IgaW52YWxpZCByZWduby4NCisgKi8NCisN CitzdGF0aWMgaW50IHNnaW8yZmJfc2V0Y29scmVnKHVfaW50IHJlZ25vLCB1 X2ludCByZWQsIHVfaW50IGdyZWVuLCB1X2ludCBibHVlLA0KKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdV9pbnQgdHJhbnNwLCBzdHJ1Y3QgZmJf aW5mbyAqaW5mbykNCit7DQorICBpbnQgaTsNCisNCisgIGlmIChyZWdubyA+ IDI1NSkNCisgICAgcmV0dXJuIDE7DQorICByZWQgPj49IDg7DQorICBncmVl biA+Pj0gODsNCisgIGJsdWUgPj49IDg7DQorICBwYWxldHRlW3JlZ25vXS5y ZWQgPSByZWQ7DQorICBwYWxldHRlW3JlZ25vXS5ncmVlbiA9IGdyZWVuOw0K KyAgcGFsZXR0ZVtyZWdub10uYmx1ZSA9IGJsdWU7DQorDQorICBzd2l0Y2gg KHZpZGVvX2JwcCkgew0KKyNpZmRlZiBGQkNPTl9IQVNfQ0ZCOA0KKyAgICBj YXNlIDg6DQorICAgICAgLyogd2FpdCBmb3IgdGhlIGNvbG9yIG1hcCBGSUZP IHRvIGhhdmUgYSBmcmVlIGVudHJ5ICovDQorICAgICAgLyogWFhYOiBkb2Vz bid0IHNlZW0gdG8gd29yaywgaWdub3JpbmcgZmlmbyBzdGF0ZSANCisJICh0 aGlzIG1heSBjYXVzZSAnc25vdycgYXJ0aWZhY3RzIG9uIGNvbG9ybWFwIGNo YW5nZSkNCisJIGZvcihpID0gMDsgaSA8IDEwMDAwICYmIGNtYXBfZmlmbyA9 PSAwOyBpKyspIHsNCisJICAgdWRlbGF5KDEwKTsNCisJICAgY21hcF9maWZv ID0gcmVncy0+Y21fZmlmbzsNCisJIH0gDQorICAgICAgIGlmKGkgPT0gMTAw MDApIHsNCisgICAgICAgICBwcmludGsoS0VSTl9FUlIgInNnaW8yZmI6IGNt YXAgRklGTyB0aW1lb3V0XG4iKTsNCisgICAgICAgICByZXR1cm4gMTsNCisg ICAgICAgfQ0KKyAgICAgICovDQorICAgICAgcmVncy0+Y21hcFtyZWdub10g PSAocmVkIDw8IDI0KSB8IChncmVlbiA8PCAxNikgfCAoYmx1ZSA8PCA4KTsN CisgICAgICB1ZGVsYXkoMTAwMCk7IC8qIGxlYXZlIHNvbWUgZGVsYXkgaW5z dGVhZCAqLw0KKyAgICAgIGNtYXBfZmlmby0tOwkJCS8qIGFzc3VtZSBGSUZP IGlzIGZpbGxpbmcgdXAgKi8NCisgICAgICBicmVhazsNCisjZW5kaWYNCisj aWZkZWYgRkJDT05fSEFTX0NGQjE2DQorICAgIGNhc2UgMTU6DQorICAgIGNh c2UgMTY6DQorICAgICAgaWYocmVnbm8gPiAxNSkgcmV0dXJuIDE7DQorICAg ICAgZmJjb25fY21hcC5jZmIxNltyZWdub10gPQ0KKwkoKHJlZCAgICYgMHhm OCkgPDwgIDcpIHwNCisJKChncmVlbiAmIDB4ZjgpIDw8ICAyKSB8DQorCSgo Ymx1ZSAgJiAweGY4KSA+PiAgMyk7DQorICAgICAgYnJlYWs7DQorI2VuZGlm DQorI2lmZGVmIEZCQ09OX0hBU19DRkIzMg0KKyAgICBjYXNlIDMyOg0KKyAg ICAgIGlmKHJlZ25vID4gMTUpIHJldHVybiAxOw0KKyAgICAgIGZiY29uX2Nt YXAuY2ZiMzJbcmVnbm9dID0NCisJKHJlZCAgIDw8IDI0KSB8DQorCShncmVl biA8PCAxNikgfA0KKwkoYmx1ZSAgPDwgOCk7DQorICAgICAgYnJlYWs7DQor I2VuZGlmDQorICB9DQorDQorICByZXR1cm4gMDsNCit9DQorDQorc3RhdGlj IHZvaWQgZG9faW5zdGFsbF9jbWFwKGludCBjb24sIHN0cnVjdCBmYl9pbmZv ICppbmZvKQ0KK3sNCisgICAgaWYgKGNvbiAhPSBjdXJyY29uKQ0KKwlyZXR1 cm47DQorICAgIGlmIChmYl9kaXNwbGF5W2Nvbl0uY21hcC5sZW4pDQorCWZi X3NldF9jbWFwKCZmYl9kaXNwbGF5W2Nvbl0uY21hcCwgMSwgc2dpbzJmYl9z ZXRjb2xyZWcsIGluZm8pOw0KKyAgICBlbHNlDQorCWZiX3NldF9jbWFwKGZi X2RlZmF1bHRfY21hcCgxPDxmYl9kaXNwbGF5W2Nvbl0udmFyLmJpdHNfcGVy X3BpeGVsKSwgMSwNCisJCSAgICBzZ2lvMmZiX3NldGNvbHJlZywgaW5mbyk7 DQorfQ0KKw0KKy8qIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gKi8NCisNCisvKg0KKyAqICBHZXQgdGhl IEZpeGVkIFBhcnQgb2YgdGhlIERpc3BsYXkNCisgKi8NCitzdGF0aWMgaW50 IHNnaW8yZmJfZ2V0X2ZpeChzdHJ1Y3QgZmJfZml4X3NjcmVlbmluZm8gKmZp eCwgaW50IGNvbiwNCisJCQkgICBzdHJ1Y3QgZmJfaW5mbyAqaW5mbykNCit7 DQorICBzdHJ1Y3QgZmJfdmFyX3NjcmVlbmluZm8gKnZhcjsNCisNCisgIGlm IChjb24gPT0gLTEpDQorICAgIHZhciA9ICZwYXJfY3VycmVudC52YXI7DQor ICBlbHNlDQorICAgIHZhciA9ICZmYl9kaXNwbGF5W2Nvbl0udmFyOw0KKyAg c2dpbzJmYl9lbmNvZGVfZml4KGZpeCwgdmFyKTsNCisgIHJldHVybiAwOw0K K30NCisNCisvKg0KKyAqICBHZXQgdGhlIFVzZXIgRGVmaW5lZCBQYXJ0IG9m IHRoZSBEaXNwbGF5LiBJZiBhIHJlYWwgcGFyIGdldCBpdCBmb3JtIHRoZXJl DQorICovDQorc3RhdGljIGludCBzZ2lvMmZiX2dldF92YXIoc3RydWN0IGZi X3Zhcl9zY3JlZW5pbmZvICp2YXIsIGludCBjb24sDQorCQkJICAgc3RydWN0 IGZiX2luZm8gKmluZm8pDQorew0KKyAgaWYgKGNvbiA9PSAtMSkNCisgICAg KnZhciA9IHBhcl9jdXJyZW50LnZhcjsNCisgIGVsc2UNCisgICAgKnZhciA9 IGZiX2Rpc3BsYXlbY29uXS52YXI7DQorICByZXR1cm4gMDsNCit9DQorDQor LyoNCisgKiAgU2V0IHRoZSBVc2VyIERlZmluZWQgUGFydCBvZiB0aGUgRGlz cGxheS4gQWdhaW4gaWYgcGFyIHVzZSBpdCB0byBnZXQNCisgKiAgcmVhbCB2 aWRlbyBtb2RlLg0KKyAqLw0KK3N0YXRpYyBpbnQgc2dpbzJmYl9zZXRfdmFy KHN0cnVjdCBmYl92YXJfc2NyZWVuaW5mbyAqdmFyLCBpbnQgY29uLA0KKwkJ CSAgIHN0cnVjdCBmYl9pbmZvICppbmZvKQ0KK3sNCisgIGludCBlcnIsIGFj dGl2YXRlID0gdmFyLT5hY3RpdmF0ZTsNCisgIGludCBvbGR4cmVzLCBvbGR5 cmVzLCBvbGR2eHJlcywgb2xkdnlyZXMsIG9sZGJwcDsNCisgIHVfbG9uZyBs aW5lX2xlbmd0aDsNCisgIHVfbG9uZyBtaW5fbW9kZTsNCisgIGludCByZXFf ZG90Ow0KKyAgaW50IHRlc3RfbW9kZTsNCisNCisgIHN0cnVjdCBnYmVfdGlt aW5nX2luZm8gKnRpbWluZzsNCisNCisgIHN0cnVjdCBkaXNwbGF5ICpkaXNw bGF5Ow0KKw0KKyAgaWYgKGNvbiA+PSAwKQ0KKyAgICBkaXNwbGF5ID0gJmZi X2Rpc3BsYXlbY29uXTsNCisgIGVsc2UNCisgICAgZGlzcGxheSA9ICZkaXNw OwkvKiB1c2VkIGR1cmluZyBpbml0aWFsaXphdGlvbiAqLw0KKw0KKyAgLyoN CisgICAqICBGQl9WTU9ERV9DT05VUERBVEUgYW5kIEZCX1ZNT0RFX1NNT09U SF9YUEFOIGFyZSBlcXVhbCENCisgICAqICBhcyBGQl9WTU9ERV9TTU9PVEhf WFBBTiBpcyBvbmx5IHVzZWQgaW50ZXJuYWxseQ0KKyAgICovDQorDQorICBp ZiAodmFyLT52bW9kZSAmIEZCX1ZNT0RFX0NPTlVQREFURSkgew0KKyAgICB2 YXItPnZtb2RlIHw9IEZCX1ZNT0RFX1lXUkFQOw0KKyAgICB2YXItPnhvZmZz ZXQgPSBkaXNwbGF5LT52YXIueG9mZnNldDsNCisgICAgdmFyLT55b2Zmc2V0 ID0gZGlzcGxheS0+dmFyLnlvZmZzZXQ7DQorICB9DQorDQorICAvKiBYWFgg RklYTUUgLSBmb3JjaW5nIHZhcidzICovDQorICB2YXItPnhvZmZzZXQgPSAw Ow0KKyAgdmFyLT55b2Zmc2V0ID0gMDsNCisNCisgIC8qIExpbWl0IGJwcCB0 byA4LCAxNiwgYW5kIDMyICovDQorICBpZiAodmFyLT5iaXRzX3Blcl9waXhl bCA8PSA4KQ0KKyAgICB2YXItPmJpdHNfcGVyX3BpeGVsID0gODsNCisgIGVs c2UgaWYgKHZhci0+Yml0c19wZXJfcGl4ZWwgPD0gMTYpDQorICAgIHZhci0+ Yml0c19wZXJfcGl4ZWwgPSAxNjsNCisgIGVsc2UgaWYgKHZhci0+Yml0c19w ZXJfcGl4ZWwgPD0gMzIpDQorICAgIHZhci0+Yml0c19wZXJfcGl4ZWwgPSAz MjsNCisgIGVsc2UNCisgICAgcmV0dXJuIC1FSU5WQUw7DQorDQorICB2aWRl b19icHAgPSB2YXItPmJpdHNfcGVyX3BpeGVsOw0KKw0KKyAgdmFyLT5ncmF5 c2NhbGUgPSAwOyAgICAgICAgICAgLyogTm8gZ3JheXNjYWxlIGZvciBub3cg Ki8NCisNCisgIC8qIGRldGVybWluZSB2YWxpZCByZXNvbHV0aW9uIGFuZCB0 aW1pbmcgKi8NCisgIGZvciAobWluX21vZGU9MDsgbWluX21vZGU8R0JFX1ZU X1NJWkU7IG1pbl9tb2RlKyspIHsNCisgICAgaWYgKGdiZVZUaW1pbmdzW21p bl9tb2RlXS53aWR0aCA+PSB2YXItPnhyZXMgJiYNCisgICAgICAgIGdiZVZU aW1pbmdzW21pbl9tb2RlXS5oZWlnaHQgPj0gdmFyLT55cmVzKQ0KKyAgICAg IGJyZWFrOw0KKyAgfQ0KKw0KKyAgaWYgKG1pbl9tb2RlID09IEdCRV9WVF9T SVpFKQ0KKyAgICByZXR1cm4gLUVJTlZBTDsgICAgICAgICAgICAgLyogUmVz b2x1dGlvbiB0byBoaWdoICovDQorDQorICAvKiBYWFggRklYTUUgLSBzaG91 bGQgdHJ5IHRvIHBpY2sgYmVzdCByZWZyZXNoIHJhdGUgKi8NCisgIC8qIGZv ciBub3csIHBpY2sgY2xvc2VzdCBkb3QtY2xvY2sgd2l0aGluIDNNSHoqLw0K KyAgcmVxX2RvdCA9IDEwMDAwMDAwMDAgLyB2YXItPnBpeGNsb2NrOw0KKyAg cHJpbnRrKEtFUk5fSU5GTyAic2dpbzJmYjogcmVxdWVzdGVkIHBpeGNsb2Nr PSVkIHBzICglZCBLSHopXG4iLCB2YXItPnBpeGNsb2NrLA0KKwkgcmVxX2Rv dCk7DQorICB0ZXN0X21vZGU9bWluX21vZGU7DQorICB3aGlsZSAoZ2JlVlRp bWluZ3NbbWluX21vZGVdLndpZHRoID09IGdiZVZUaW1pbmdzW3Rlc3RfbW9k ZV0ud2lkdGgpIHsNCisgICAgaWYgKGdiZVZUaW1pbmdzW3Rlc3RfbW9kZV0u Y2ZyZXErMzAwMCA+IHJlcV9kb3QpDQorICAgICAgYnJlYWs7DQorICAgIHRl c3RfbW9kZSsrOw0KKyAgfQ0KKyAgaWYgKGdiZVZUaW1pbmdzW21pbl9tb2Rl XS53aWR0aCAhPSBnYmVWVGltaW5nc1t0ZXN0X21vZGVdLndpZHRoKQ0KKyAg ICB0ZXN0X21vZGUtLTsNCisgIG1pbl9tb2RlID0gdGVzdF9tb2RlOw0KKyAg dGltaW5nID0gJmdiZVZUaW1pbmdzW21pbl9tb2RlXTsNCisgIHByaW50ayhL RVJOX0lORk8gInNnaW8yZmI6IGdyYW50ZWQgZG90LWNsb2NrPSVkIEtIelxu IiwgdGltaW5nLT5jZnJlcSk7DQorDQorICAvKiBBZGp1c3QgdmlydHVhbCBy ZXNvbHV0aW9uLCBpZiBuZWNlc3NhcnkgKi8NCisgIGlmICh2YXItPnhyZXMg PiB2YXItPnhyZXNfdmlydHVhbCB8fCAoIXl3cmFwICYmICF5cGFuKSkNCisg ICAgdmFyLT54cmVzX3ZpcnR1YWwgPSB2YXItPnhyZXM7DQorICBpZiAodmFy LT55cmVzID4gdmFyLT55cmVzX3ZpcnR1YWwgfHwgKCF5d3JhcCAmJiAheXBh bikpDQorICAgIHZhci0+eXJlc192aXJ0dWFsID0gdmFyLT55cmVzOw0KKw0K KyAgLyoNCisgICAqICBNZW1vcnkgbGltaXQNCisgICAqLw0KKyAgbGluZV9s ZW5ndGggPSBnZXRfbGluZV9sZW5ndGgodmFyLT54cmVzX3ZpcnR1YWwsIHZh ci0+Yml0c19wZXJfcGl4ZWwpOw0KKyAgaWYgKGxpbmVfbGVuZ3RoKnZhci0+ eXJlc192aXJ0dWFsID4gc2dpbzJmYl9tZW1fc2l6ZSkNCisgICAgcmV0dXJu IC1FTk9NRU07ICAgICAgICAgICAgIC8qIFZpcnR1YWwgcmVzb2x1dGlvbiB0 byBoaWdoICovDQorDQorICBzd2l0Y2ggKHZhci0+Yml0c19wZXJfcGl4ZWwp DQorICAgIHsNCisgICAgY2FzZSA4Og0KKyAgICAgIHZhci0+cmVkLm9mZnNl dCA9IDA7DQorICAgICAgdmFyLT5yZWQubGVuZ3RoID0gODsNCisgICAgICB2 YXItPmdyZWVuLm9mZnNldCA9IDA7DQorICAgICAgdmFyLT5ncmVlbi5sZW5n dGggPSA4Ow0KKyAgICAgIHZhci0+Ymx1ZS5vZmZzZXQgPSAwOw0KKyAgICAg IHZhci0+Ymx1ZS5sZW5ndGggPSA4Ow0KKyAgICAgIHZhci0+dHJhbnNwLm9m ZnNldCA9IDA7DQorICAgICAgdmFyLT50cmFuc3AubGVuZ3RoID0gMDsNCisg ICAgICBicmVhazsNCisgICAgY2FzZSAxNjoJLyogUkdCQSA1NTUxICovDQor ICAgICAgdmFyLT5yZWQub2Zmc2V0ID0gMTE7DQorICAgICAgdmFyLT5yZWQu bGVuZ3RoID0gNTsNCisgICAgICB2YXItPmdyZWVuLm9mZnNldCA9IDY7DQor ICAgICAgdmFyLT5ncmVlbi5sZW5ndGggPSA1Ow0KKyAgICAgIHZhci0+Ymx1 ZS5vZmZzZXQgPSAxOw0KKyAgICAgIHZhci0+Ymx1ZS5sZW5ndGggPSA1Ow0K KyAgICAgIHZhci0+dHJhbnNwLm9mZnNldCA9IDA7DQorICAgICAgdmFyLT50 cmFuc3AubGVuZ3RoID0gMDsNCisgICAgICBicmVhazsNCisgICAgY2FzZSAz MjoJLyogUkdCIDg4ODggKi8NCisgICAgICB2YXItPnJlZC5vZmZzZXQgPSAw Ow0KKyAgICAgIHZhci0+cmVkLmxlbmd0aCA9IDg7DQorICAgICAgdmFyLT5n cmVlbi5vZmZzZXQgPSA4Ow0KKyAgICAgIHZhci0+Z3JlZW4ubGVuZ3RoID0g ODsNCisgICAgICB2YXItPmJsdWUub2Zmc2V0ID0gMTY7DQorICAgICAgdmFy LT5ibHVlLmxlbmd0aCA9IDg7DQorICAgICAgdmFyLT50cmFuc3Aub2Zmc2V0 ID0gMjQ7DQorICAgICAgdmFyLT50cmFuc3AubGVuZ3RoID0gODsNCisgICAg ICBicmVhazsNCisgICAgfQ0KKyAgdmFyLT5yZWQubXNiX3JpZ2h0ID0gMDsN CisgIHZhci0+Z3JlZW4ubXNiX3JpZ2h0ID0gMDsNCisgIHZhci0+Ymx1ZS5t c2JfcmlnaHQgPSAwOw0KKyAgdmFyLT50cmFuc3AubXNiX3JpZ2h0ID0gMDsN CisNCisgIC8qIHNldCB2aWRlbyB0aW1pbmcgaW5mb3JtYXRpb24gKi8NCisg IHZhci0+cGl4Y2xvY2sgPSAoX191MzIpKDEwMDAwMDAwMDAvdGltaW5nLT5j ZnJlcSk7DQorICB2YXItPmxlZnRfbWFyZ2luID0gdGltaW5nLT5odG90YWwg LSB0aW1pbmctPmhzeW5jX2VuZDsNCisgIHZhci0+cmlnaHRfbWFyZ2luID0g dGltaW5nLT5oc3luY19zdGFydCAtIHRpbWluZy0+d2lkdGg7DQorICB2YXIt PnVwcGVyX21hcmdpbiA9IHRpbWluZy0+dnRvdGFsIC0gdGltaW5nLT52c3lu Y19lbmQ7DQorICB2YXItPmxvd2VyX21hcmdpbiA9IHRpbWluZy0+dnN5bmNf c3RhcnQgLSB0aW1pbmctPmhlaWdodDsNCisgIHZhci0+aHN5bmNfbGVuID0g dGltaW5nLT5oc3luY19lbmQgLSB0aW1pbmctPmhzeW5jX3N0YXJ0Ow0KKyAg dmFyLT52c3luY19sZW4gPSB0aW1pbmctPnZzeW5jX2VuZCAtICB0aW1pbmct PnZzeW5jX3N0YXJ0Ow0KKw0KKyAgaWYgKChhY3RpdmF0ZSAmIEZCX0FDVElW QVRFX01BU0spID09IEZCX0FDVElWQVRFX05PVykgew0KKyAgICBvbGR4cmVz ID0gZGlzcGxheS0+dmFyLnhyZXM7DQorICAgIG9sZHlyZXMgPSBkaXNwbGF5 LT52YXIueXJlczsNCisgICAgb2xkdnhyZXMgPSBkaXNwbGF5LT52YXIueHJl c192aXJ0dWFsOw0KKyAgICBvbGR2eXJlcyA9IGRpc3BsYXktPnZhci55cmVz X3ZpcnR1YWw7DQorICAgIG9sZGJwcCA9IGRpc3BsYXktPnZhci5iaXRzX3Bl cl9waXhlbDsNCisgICAgZGlzcGxheS0+dmFyID0gKnZhcjsNCisgICAgcGFy X2N1cnJlbnQudmFyID0gKnZhcjsNCisgICAgcGFyX2N1cnJlbnQudGltaW5n X251bSA9IG1pbl9tb2RlOw0KKyAgICBpZiAob2xkeHJlcyAhPSB2YXItPnhy ZXMgfHwgb2xkeXJlcyAhPSB2YXItPnlyZXMgfHwNCisJb2xkdnhyZXMgIT0g dmFyLT54cmVzX3ZpcnR1YWwgfHwgb2xkdnlyZXMgIT0gdmFyLT55cmVzX3Zp cnR1YWwgfHwNCisJb2xkYnBwICE9IHZhci0+Yml0c19wZXJfcGl4ZWwgfHwg IXBhcl9jdXJyZW50LnZhbGlkKSB7DQorICAgICAgc3RydWN0IGZiX2ZpeF9z Y3JlZW5pbmZvIGZpeDsNCisgICAgICBwcmludGsoS0VSTl9JTkZPICJzZ2lv MmZiOiBuZXcgdmlkZW8gbW9kZSB4cmVzPSVkIHlyZXM9JWQgYnBwPSVkXG4i LA0KKwkgICAgIHZhci0+eHJlcywgdmFyLT55cmVzLCB2YXItPmJpdHNfcGVy X3BpeGVsKTsNCisgICAgICBwcmludGsoS0VSTl9JTkZPICIgICAgICAgICB2 eHJlcz0lZCB2eXJlcz0lZFxuIiwNCisJICAgICB2YXItPnhyZXNfdmlydHVh bCwgdmFyLT55cmVzX3ZpcnR1YWwpOw0KKyAgICAgIGFjdGl2YXRlX3Bhcigm cGFyX2N1cnJlbnQpOw0KKyAgICAgIHNnaW8yZmJfZW5jb2RlX2ZpeCgmZml4 LCB2YXIpOw0KKw0KKyAgICAgIGRpc3BsYXktPnNjcmVlbl9iYXNlID0gKGNo YXIgKilmYm1lbTsNCisgICAgICBkaXNwbGF5LT52aXN1YWwgPSBmaXgudmlz dWFsOw0KKyAgICAgIGRpc3BsYXktPnR5cGUgPSBmaXgudHlwZTsNCisgICAg ICBkaXNwbGF5LT50eXBlX2F1eCA9IGZpeC50eXBlX2F1eDsNCisgICAgICBk aXNwbGF5LT55cGFuc3RlcCA9IGZpeC55cGFuc3RlcDsNCisgICAgICBkaXNw bGF5LT55d3JhcHN0ZXAgPSBmaXgueXdyYXBzdGVwOw0KKyAgICAgIGRpc3Bs YXktPmxpbmVfbGVuZ3RoID0gZml4LmxpbmVfbGVuZ3RoOw0KKyAgICAgIGRp c3BsYXktPmNhbl9zb2Z0X2JsYW5rID0gMTsNCisgICAgICBkaXNwbGF5LT5p bnZlcnNlID0gMDsNCisgICAgICBpZiAob2xkYnBwICE9IHZhci0+Yml0c19w ZXJfcGl4ZWwgfHwgIXBhcl9jdXJyZW50LnZhbGlkKSB7DQorCWlmICgoZXJy ID0gZmJfYWxsb2NfY21hcCgmZGlzcGxheS0+Y21hcCwgMCwgMCkpKQ0KKwkg IHJldHVybiBlcnI7DQorCWRvX2luc3RhbGxfY21hcChjb24sIGluZm8pOw0K KyAgICAgIH0NCisgICAgICBzd2l0Y2ggKHZhci0+Yml0c19wZXJfcGl4ZWwp IHsNCisjaWZkZWYgRkJDT05fSEFTX0NGQjgNCisgICAgICBjYXNlIDg6DQor CWRpc3BsYXktPmRpc3BzdyA9ICZmYmNvbl9jZmI4Ow0KKwlicmVhazsNCisj ZW5kaWYNCisjaWZkZWYgRkJDT05fSEFTX0NGQjE2DQorICAgICAgY2FzZSAx NjoNCisJZGlzcGxheS0+ZGlzcHN3ID0gJmZiY29uX2NmYjE2Ow0KKwlkaXNw bGF5LT5kaXNwc3dfZGF0YSA9IGZiY29uX2NtYXAuY2ZiMTY7DQorCWJyZWFr Ow0KKyNlbmRpZg0KKyNpZmRlZiBGQkNPTl9IQVNfQ0ZCMzINCisgICAgICBj YXNlIDMyOg0KKwlkaXNwbGF5LT5kaXNwc3cgPSAmZmJjb25fY2ZiMzI7DQor CWRpc3BsYXktPmRpc3Bzd19kYXRhID0gZmJjb25fY21hcC5jZmIzMjsNCisJ YnJlYWs7DQorI2VuZGlmDQorICAgICAgZGVmYXVsdDoNCisJZGlzcGxheS0+ ZGlzcHN3ID0gJmZiY29uX2R1bW15Ow0KKwlicmVhazsNCisgICAgICB9DQor ICAgICAgcGFyX2N1cnJlbnQudmFsaWQgPSAxOw0KKyAgICAgIGlmIChmYl9p bmZvLmNoYW5nZXZhcikNCisJKCpmYl9pbmZvLmNoYW5nZXZhcikoY29uKTsN CisgICAgfQ0KKyAgfQ0KKw0KKyAgcmV0dXJuIDA7DQorfQ0KKw0KKy8qDQor ICogIEdldCB0aGUgQ29sb3JtYXANCisgKi8NCitzdGF0aWMgaW50IHNnaW8y ZmJfZ2V0X2NtYXAoc3RydWN0IGZiX2NtYXAgKmNtYXAsIGludCBrc3BjLCBp bnQgY29uLA0KKwkJCSAgICBzdHJ1Y3QgZmJfaW5mbyAqaW5mbykNCit7DQor ICBpZiAoY29uID09IGN1cnJjb24pIC8qIGN1cnJlbnQgY29uc29sZT8gKi8N CisgICAgcmV0dXJuIGZiX2dldF9jbWFwKGNtYXAsIGtzcGMsIHNnaW8yZmJf Z2V0Y29scmVnLCBpbmZvKTsNCisgIGVsc2UgaWYgKGZiX2Rpc3BsYXlbY29u XS5jbWFwLmxlbikgLyogbm9uIGRlZmF1bHQgY29sb3JtYXA/ICovDQorICAg IGZiX2NvcHlfY21hcCgmZmJfZGlzcGxheVtjb25dLmNtYXAsIGNtYXAsIGtz cGMgPyAwIDogMik7DQorICBlbHNlDQorICAgIGZiX2NvcHlfY21hcChmYl9k ZWZhdWx0X2NtYXAoMTw8ZmJfZGlzcGxheVtjb25dLnZhci5iaXRzX3Blcl9w aXhlbCksDQorCQkgY21hcCwga3NwYyA/IDAgOiAyKTsNCisgIHJldHVybiAw Ow0KK30NCisNCisvKg0KKyAqICBTZXQgdGhlIENvbG9ybWFwDQorICovDQor c3RhdGljIGludCBzZ2lvMmZiX3NldF9jbWFwKHN0cnVjdCBmYl9jbWFwICpj bWFwLCBpbnQga3NwYywgaW50IGNvbiwNCisJCQkgICAgc3RydWN0IGZiX2lu Zm8gKmluZm8pDQorew0KKyAgaW50IGVycjsNCisNCisgIGlmICghZmJfZGlz cGxheVtjb25dLmNtYXAubGVuKSB7CS8qIG5vIGNvbG9ybWFwIGFsbG9jYXRl ZD8gKi8NCisgICAgaW50IHNpemUgPSBmYl9kaXNwbGF5W2Nvbl0udmFyLmJp dHNfcGVyX3BpeGVsID09IDggPyAyNTYgOiAxNjsNCisgICAgaWYgKChlcnIg PSBmYl9hbGxvY19jbWFwKCZmYl9kaXNwbGF5W2Nvbl0uY21hcCwgc2l6ZSwg MCkpKQ0KKyAgICAgIHJldHVybiBlcnI7DQorICB9DQorICBpZiAoY29uID09 IGN1cnJjb24pCQkJLyogY3VycmVudCBjb25zb2xlPyAqLw0KKyAgICByZXR1 cm4gZmJfc2V0X2NtYXAoY21hcCwga3NwYywgc2dpbzJmYl9zZXRjb2xyZWcs IGluZm8pOw0KKyAgZWxzZQ0KKyAgICBmYl9jb3B5X2NtYXAoY21hcCwgJmZi X2Rpc3BsYXlbY29uXS5jbWFwLCBrc3BjID8gMCA6IDEpOw0KKyAgcmV0dXJu IDA7DQorfQ0KKw0KK3N0YXRpYyBpbnQgc2dpbzJmYl9tbWFwKHN0cnVjdCBm Yl9pbmZvICppbmZvLCBzdHJ1Y3QgZmlsZSAqZmlsZSwNCisgICAgICAgICAg ICAgICAgICAgICAgICBzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSkNCit7 DQorICB1bnNpZ25lZCBsb25nIHNpemUgPSB2bWEtPnZtX2VuZCAtIHZtYS0+ dm1fc3RhcnQ7DQorICB1bnNpZ25lZCBsb25nIG9mZnNldCA9IHZtYS0+dm1f cGdvZmYgPDwgUEFHRV9TSElGVDsNCisNCisgIGlmICh2bWEtPnZtX3Bnb2Zm ID4gKH4wVUwgPj4gUEFHRV9TSElGVCkpDQorCXJldHVybiAtRUlOVkFMOw0K KyAgaWYgKG9mZnNldCtzaXplID4gc2dpbzJmYl9tZW1fc2l6ZSkNCisgICAg cmV0dXJuIC1FSU5WQUw7DQorICBvZmZzZXQgKz0gc2dpbzJmYl9tZW1fcGh5 czsNCisgIHBncHJvdF92YWwodm1hLT52bV9wYWdlX3Byb3QpID0gDQorICAg IChwZ3Byb3RfdmFsKHZtYS0+dm1fcGFnZV9wcm90KSAmICh+X0NBQ0hFX01B U0spKSB8IF9DQUNIRV9VTkNBQ0hFRDsNCisgIHZtYS0+dm1fZmxhZ3MgfD0g Vk1fSU87DQorICBpZiAocmVtYXBfcGFnZV9yYW5nZSh2bWEtPnZtX3N0YXJ0 LCBvZmZzZXQsIHNpemUsIHZtYS0+dm1fcGFnZV9wcm90KSkNCisgICAgcmV0 dXJuIC1FQUdBSU47DQorICB2bWEtPnZtX2ZpbGUgPSBmaWxlOw0KKyAgcHJp bnRrKEtFUk5fREVCVUcgInNnaW8yZmI6IG1tYXAgZnJhbWVidWZmZXIgUCgl bHgpLT5WKCVseClcbiIsIG9mZnNldCwgdm1hLT52bV9zdGFydCk7DQorICBy ZXR1cm4gMDsNCit9DQorDQoraW50IF9faW5pdCBzZ2lvMmZiX3NldHVwKGNo YXIgKm9wdGlvbnMpDQorew0KKyAgY2hhciAqdGhpc19vcHQ7DQorDQorICBm Yl9pbmZvLmZvbnRuYW1lWzBdID0gJ1wwJzsNCisNCisgIGlmICghb3B0aW9u cyB8fCAhKm9wdGlvbnMpDQorICAgIHJldHVybiAwOw0KKw0KKyAgd2hpbGUg KCh0aGlzX29wdCA9IHN0cnNlcCgmb3B0aW9ucywgIiwiKSkgIT0gTlVMTCkg ew0KKyAgICBpZiAoIXN0cm5jbXAodGhpc19vcHQsICJmb250OiIsIDUpKQ0K KyAgICAgIHN0cmNweShmYl9pbmZvLmZvbnRuYW1lLCB0aGlzX29wdCs1KTsN CisgIH0NCisgIHJldHVybiAwOw0KK30NCisNCisvKg0KKyAqICBJbml0aWFs aXNhdGlvbg0KKyAqLw0KK2ludCBfX2luaXQgc2dpbzJmYl9pbml0KHZvaWQp DQorew0KKyAgcHJpbnRrKEtFUk5fSU5GTyAic2dpbzJmYjogaW5pdGlhbGl6 aW5nXG4iKTsNCisNCisgIHNnaW8yZmJfbWVtX3NpemUgPSBWSURFT01FTVNJ WkU7DQorDQorICBpZiAoIShzZ2lvMmZiX21lbV9waHlzID0gKHVfbG9uZylf X2dldF9mcmVlX3BhZ2VzKEdGUF9ETUEsIGdldF9vcmRlcihzZ2lvMmZiX21l bV9zaXplKSkpKSB7DQorICAgIHByaW50ayhLRVJOX0VSUiAic2dpbzJmYjog Y291bGRuJ3QgYWxsb2NhdGUgJWxkIGJ5dGVzIGZvciB0aGUgZnJhbWVidWZm ZXJcbiIsDQorCSAgIHNnaW8yZmJfbWVtX3NpemUpOw0KKyAgICByZXR1cm4g LUVOT01FTTsNCisgIH0NCisNCisgIC8qIFRFTVA6IE1ha2Ugc3VyZSB0aGUg ZnJhbWVidWZmZXIgaXMgdW5jYWNoZWQgKi8NCisgIHNnaW8yZmJfbWVtX3Bo eXMgPSBLU0VHMUFERFIoQ1BIWVNBRERSKHNnaW8yZmJfbWVtX3BoeXMpKTsN CisNCisgIGlmICghKHNnaW8yZmJfdGlsZXNfdGFibGUgPSAodTE2ICopX19n ZXRfZnJlZV9wYWdlKEdGUF9ETUEpKSkgew0KKyAgICAgIHByaW50aygic2dp bzJmYjogY291bGQgbm90IGFsbG9jYXRlIHRpbGVzIHRhYmxlXG4iKTsNCisg ICAgICByZXR1cm4gLUVOT01FTTsNCisgIH0NCisNCisgIC8qIFRFTVA6IE1h a2Ugc3VyZSB0aWxlcyBhcmUgdW5jYWNoZWQgdG9vICovDQorICBzZ2lvMmZi X3RpbGVzX3RhYmxlID0gKHUxNiAqKUtTRUcxQUREUihDUEhZU0FERFIoc2dp bzJmYl90aWxlc190YWJsZSkpOw0KKw0KKyAgbWVtc2V0KHNnaW8yZmJfdGls ZXNfdGFibGUsIDAsIDEyOCpzaXplb2YodTE2KSk7DQorDQorICBwcmludGso S0VSTl9JTkZPICJzZ2lvMmZiOiBJL08gYXQgMHglMDh4XG4iLCBHQkVfUkVH X1BIWVMpOw0KKyAgcHJpbnRrKEtFUk5fSU5GTyAic2dpbzJmYjogZnJhbWVi dWZmZXIgYXQgMHglbHgsIHNpemUgJWxka1xuIiwNCisJIHNnaW8yZmJfbWVt X3BoeXMsIHNnaW8yZmJfbWVtX3NpemUvMTAyNCk7DQorICBwcmludGsoS0VS Tl9JTkZPICJzZ2lvMmZiOiB0aWxlcyBhdCAlcFxuIiwNCisJIHNnaW8yZmJf dGlsZXNfdGFibGUpOw0KKw0KKyAgcmVncyA9IChhc3JlZ3MqKUdCRV9SRUdf UEhZUzsNCisgIGlmICghcmVncykgew0KKyAgICBwcmludGsoS0VSTl9FUlIg InNnaW8yZmI6IGNvdWxkbid0IGlvcmVtYXAgcmVnaXN0ZXJzXG4iKTsNCisg ICAgZ290byBmYWlsX2lvcmVtYXBfcmVnczsNCisgIH0NCisNCisgIC8qIFtW Q10gVE9ETzogY2hhbmdlIGNhY2hpbmcgYXR0cmlidXRlcyB0byB3cml0ZSBj b21iaW5lZD8NCisgIG10cnJfYWRkKCh1bnNpZ25lZCBsb25nKXNnaW8yZmJf bWVtX3BoeXMsIHNnaW8yZmJfbWVtX3NpemUsIE1UUlJfVFlQRV9XUkNPTUIs IDEpOw0KKyAgKi8NCisNCisgIHN0cmNweShmYl9pbmZvLm1vZGVuYW1lLCBz Z2lvMmZiX25hbWUpOw0KKyAgZmJfaW5mby5jaGFuZ2V2YXIgPSBOVUxMOw0K KyAgZmJfaW5mby5ub2RlID0gLTE7DQorICBmYl9pbmZvLmZib3BzID0gJnNn aW8yZmJfb3BzOw0KKyAgZmJfaW5mby5kaXNwID0gJmRpc3A7DQorICBmYl9p bmZvLnN3aXRjaF9jb24gPSAmc2dpbzJmYmNvbl9zd2l0Y2g7DQorICBmYl9p bmZvLnVwZGF0ZXZhciA9ICZzZ2lvMmZiY29uX3VwZGF0ZXZhcjsNCisgIGZi X2luZm8uYmxhbmsgPSAmc2dpbzJmYmNvbl9ibGFuazsNCisgIGZiX2luZm8u ZmxhZ3MgPSBGQklORk9fRkxBR19ERUZBVUxUOw0KKw0KKyAgLyogVE9ETzog bWFyayBwYWdlcyBhcyB1bmNhY2hlZCAob3Igd3JpdGUgY29tYmluZWQpICov DQorICBmYm1lbSA9IChjaGFyKilzZ2lvMmZiX21lbV9waHlzOw0KKw0KKyAg LyogdHVybiBvbiBkZWZhdWx0IHZpZGVvIG1vZGUgKi8NCisgIHNnaW8yZmJf c2V0X3ZhcigmcGFyX2N1cnJlbnQudmFyLCAtMSwgJmZiX2luZm8pOw0KKw0K KyAgaWYgKHJlZ2lzdGVyX2ZyYW1lYnVmZmVyKCZmYl9pbmZvKSA8IDApIHsN CisgICAgcHJpbnRrKEtFUk5fRVJSICJzZ2lvMmZiOiBjb3VsZG4ndCByZWdp c3RlciBmcmFtZWJ1ZmZlclxuIik7DQorICAgIGdvdG8gZmFpbF9yZWdpc3Rl cl9mcmFtZWJ1ZmZlcjsNCisgIH0NCisNCisgIHByaW50ayhLRVJOX0lORk8g ImZiJWQ6IFZpcnR1YWwgZnJhbWUgYnVmZmVyIGRldmljZSwgdXNpbmcgJWxk SyBvZiB2aWRlbyBtZW1vcnlcbiIsDQorCSBHRVRfRkJfSURYKGZiX2luZm8u bm9kZSksIHNnaW8yZmJfbWVtX3NpemU+PjEwKTsNCisNCisgIHJldHVybiAw Ow0KKw0KKyBmYWlsX3JlZ2lzdGVyX2ZyYW1lYnVmZmVyOg0KKyBmYWlsX2lv cmVtYXBfcmVnczoNCisgIHJldHVybiAtRU5YSU87DQorfQ0KKw0KK3N0YXRp YyBpbnQgc2dpbzJmYmNvbl9zd2l0Y2goaW50IGNvbiwgc3RydWN0IGZiX2lu Zm8gKmluZm8pDQorew0KKyAgLyogRG8gd2UgaGF2ZSB0byBzYXZlIHRoZSBj b2xvcm1hcD8gKi8NCisgIGlmIChmYl9kaXNwbGF5W2N1cnJjb25dLmNtYXAu bGVuKQ0KKyAgICBmYl9nZXRfY21hcCgmZmJfZGlzcGxheVtjdXJyY29uXS5j bWFwLCAxLCBzZ2lvMmZiX2dldGNvbHJlZywgaW5mbyk7DQorDQorICBjdXJy Y29uID0gY29uOw0KKw0KKyAgLyogSW5zdGFsbCBuZXcgY29sb3JtYXAgKi8N CisgIGRvX2luc3RhbGxfY21hcChjb24sIGluZm8pOw0KKw0KKyAgcmV0dXJu IDA7DQorfQ0KKw0KKy8qDQorICogIFVwZGF0ZSB0aGUgYHZhcicgc3RydWN0 dXJlIChjYWxsZWQgYnkgZmJjb24uYykNCisgKi8NCitzdGF0aWMgaW50IHNn aW8yZmJjb25fdXBkYXRldmFyKGludCBjb24sIHN0cnVjdCBmYl9pbmZvICpp bmZvKQ0KK3sNCisgICAgLyogTm90aGluZyAqLw0KKyAgICByZXR1cm4gMDsN Cit9DQorDQorLyoNCisgKiAgQmxhbmsgdGhlIGRpc3BsYXkuDQorICovDQor c3RhdGljIHZvaWQgc2dpbzJmYmNvbl9ibGFuayhpbnQgYmxhbmssIHN0cnVj dCBmYl9pbmZvICppbmZvKQ0KK3sNCisgICAgLyogTm90aGluZyAqLw0KKyAg ICAvKiBUT0RPOiB0dXJuIG9mZiBETUEgKi8NCit9DQorDQorI2lmZGVmIE1P RFVMRQ0KK01PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCisNCitpbnQgaW5pdF9t b2R1bGUodm9pZCkNCit7DQorICByZXR1cm4gc2dpbzJmYl9pbml0KCk7DQor fQ0KKw0KK3ZvaWQgY2xlYW51cF9tb2R1bGUodm9pZCkNCit7DQorICB1bnJl Z2lzdGVyX2ZyYW1lYnVmZmVyKCZmYl9pbmZvKTsNCisgIGdiZV9UdXJuT2Zm RG1hKCk7DQorICBpb3VubWFwKHJlZ3MpOw0KKyAgaW91bm1hcChmYm1lbSk7 DQorfQ0KKw0KKyNlbmRpZiAvKiBNT0RVTEUgKi8NCmRpZmYgLU5hdXIgbGlu dXg2NC9kcml2ZXJzL3ZpZGVvL3NnaW8yZmIuaCBsaW51eDY0Lm5ldy9kcml2 ZXJzL3ZpZGVvL3NnaW8yZmIuaA0KLS0tIGxpbnV4NjQvZHJpdmVycy92aWRl by9zZ2lvMmZiLmgJVGh1IEphbiAgMSAwMTowMDowMCAxOTcwDQorKysgbGlu dXg2NC5uZXcvZHJpdmVycy92aWRlby9zZ2lvMmZiLmgJV2VkIE1heSAxNSAy MzoxMjoyNCAyMDAyDQpAQCAtMCwwICsxLDU2MCBAQA0KKy8qDQorICogIGxp bnV4L2RyaXZlcnMvdmlkZW8vc2dpdndmYi5oIC0tIFNHSSBHQkUgZnJhbWUg YnVmZmVyIGRldmljZSBoZWFkZXINCisgKg0KKyAqICAgICAgQ29weXJpZ2h0 IChDKSAxOTk5IFNpbGljb24gR3JhcGhpY3MsIEluYy4NCisgKiAgICAgIEpl ZmZyZXkgTmV3cXVpc3QsIG5ld3F1aXN0QGVuZ3Iuc2dpLnNvbQ0KKyAqDQor ICogIFRoaXMgZmlsZSBpcyBzdWJqZWN0IHRvIHRoZSB0ZXJtcyBhbmQgY29u ZGl0aW9ucyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljDQorICogIExpY2Vu c2UuIFNlZSB0aGUgZmlsZSBDT1BZSU5HIGluIHRoZSBtYWluIGRpcmVjdG9y eSBvZiB0aGlzIGFyY2hpdmUgZm9yDQorICogIG1vcmUgZGV0YWlscy4NCisg Ki8NCisNCisjaWZuZGVmIF9fU0dJTzJGQl9IX18NCisjZGVmaW5lIF9fU0dJ TzJGQl9IX18NCisNCisjaW5jbHVkZSA8YXNtL2lwMzIvY3JpbWUuaD4NCisj aW5jbHVkZSA8YXNtL2FkZHJzcGFjZS5oPg0KKw0KKyNkZWZpbmUgQ1JJTUVf RkxVU0ggY3JpbWVfcmVhZF82NChDUklNRV9DT05UUk9MKQ0KKw0KKyNkZWZp bmUgR0JFX0dFVFJFRyhyZWcsIGRlc3QpICAgICAgICgoZGVzdCkgPSBHQkVf UkVHX0JBU0UtPiMjcmVnKQ0KKyNkZWZpbmUgR0JFX1NFVFJFRyhyZWcsIHNy YykgICAgICAgIChHQkVfUkVHX0JBU0UtPiMjcmVnID0gKHNyYykpO0NSSU1F X0ZMVVNIDQorI2RlZmluZSBHQkVfSUdFVFJFRyhyZWcsIGlkeCwgZGVzdCkg KChkZXN0KSA9IEdCRV9SRUdfQkFTRS0+IyNyZWcjI1tpZHhdKQ0KKyNkZWZp bmUgR0JFX0lTRVRSRUcocmVnLCBpZHgsIHNyYykgIChHQkVfUkVHX0JBU0Ut PiMjcmVnIyNbaWR4XSA9IChzcmMpKTtDUklNRV9GTFVTSA0KKw0KKyNkZWZp bmUgTUFTSyhtc2IsIGxzYikgICAgICAgICAgKCAoKCh1MzIpMTw8KChtc2Ip LShsc2IpKzEpKS0xKSA8PCAobHNiKSApDQorI2RlZmluZSBHRVQodiwgbXNi LCBsc2IpICAgICAgICAoICgodTMyKSh2KSAmIE1BU0sobXNiLGxzYikpID4+ IChsc2IpICkNCisjZGVmaW5lIFNFVCh2LCBmLCBtc2IsIGxzYikgICAgICgg KHYpID0gKCh2KSZ+TUFTSyhtc2IsbHNiKSkgfCAoKCAodTMyKShmKTw8KGxz YikgKSAmIE1BU0sobXNiLGxzYikpICkNCisNCisjZGVmaW5lIEdFVF9HQkVf RklFTEQocmVnLCBmaWVsZCwgdikgICAgICAgIEdFVCgodiksIEdCRV8jI3Jl ZyMjXyMjZmllbGQjI19NU0IsIEdCRV8jI3JlZyMjXyMjZmllbGQjI19MU0Ip DQorI2RlZmluZSBTRVRfR0JFX0ZJRUxEKHJlZywgZmllbGQsIHYsIGYpICAg ICBTRVQoKHYpLCAoZiksIEdCRV8jI3JlZyMjXyMjZmllbGQjI19NU0IsIEdC RV8jI3JlZyMjXyMjZmllbGQjI19MU0IpDQorDQorLyogTk9URTogQWxsIGxv YWRzL3N0b3JlcyBtdXN0IGJlIDMyIGJpdHMgYW5kIHVuY2FjaGVkICovDQor DQorI2RlZmluZSBHQkVfUkVHX1BIWVMJS1NFRzFBRERSKDB4MTYwMDAwMDAp DQorI2RlZmluZSBHQkVfUkVHX1NJWkUgICAgMHgwMTAwMDAwMA0KKw0KK3R5 cGVkZWYgc3RydWN0IHsNCisgIHZvbGF0aWxlIHUzMiBjdHJsc3RhdDsgICAg IC8qIDB4MDAwMDAwIGdlbmVyYWwgY29udHJvbCAqLw0KKyAgdm9sYXRpbGUg dTMyIGRvdGNsb2NrOyAgICAgLyogMHgwMDAwMDQgZG90IGNsb2NrIFBMTCBj b250cm9sICovDQorICB2b2xhdGlsZSB1MzIgaTJjOyAgICAgICAgICAvKiAw eDAwMDAwOCBjcnQgSTJDIGNvbnRyb2wgKi8NCisgIHZvbGF0aWxlIHUzMiBz eXNjbGs7ICAgICAgIC8qIDB4MDAwMDBjIHN5c3RlbSBjbG9jayBQTEwgY29u dHJvbCAqLw0KKyAgdm9sYXRpbGUgdTMyIGkyY2ZwOyAgICAgICAgLyogMHgw MDAwMTAgZmxhdCBwYW5lbCBJMkMgY29udHJvbCAqLw0KKyAgdm9sYXRpbGUg dTMyIGlkOyAgICAgICAgICAgLyogMHgwMDAwMTQgZGV2aWNlIGlkL2NoaXAg cmV2aXNpb24gKi8NCisgIHZvbGF0aWxlIHUzMiBjb25maWc7ICAgICAgIC8q IDB4MDAwMDE4IHBvd2VyIG9uIGNvbmZpZ3VyYXRpb24gKi8NCisgIHZvbGF0 aWxlIHUzMiBiaXN0OyAgICAgICAgIC8qIDB4MDAwMDFjIGludGVybmFsIGJp c3Qgc3RhdHVzICovDQorDQorICBjaGFyIF9wYWQwWyAweDAxMDAwMCAtIDB4 MDAwMDIwIF07DQorDQorICB2b2xhdGlsZSB1MzIgdnRfeHk7ICAgICAgICAv KiAweDAxMDAwMCBjdXJyZW50IGRvdCBjb29yZHMgKi8NCisgIHZvbGF0aWxl IHUzMiB2dF94eW1heDsgICAgIC8qIDB4MDEwMDA0IG1heGltdW0gZG90IGNv b3JkcyAqLw0KKyAgdm9sYXRpbGUgdTMyIHZ0X3ZzeW5jOyAgICAgLyogMHgw MTAwMDggdnN5bmMgb24vb2ZmICovDQorICB2b2xhdGlsZSB1MzIgdnRfaHN5 bmM7ICAgICAvKiAweDAxMDAwYyBoc3luYyBvbi9vZmYgKi8NCisgIHZvbGF0 aWxlIHUzMiB2dF92Ymxhbms7ICAgIC8qIDB4MDEwMDEwIHZibGFuayBvbi9v ZmYgKi8NCisgIHZvbGF0aWxlIHUzMiB2dF9oYmxhbms7ICAgIC8qIDB4MDEw MDE0IGhibGFuayBvbi9vZmYgKi8NCisgIHZvbGF0aWxlIHUzMiB2dF9mbGFn czsgICAgIC8qIDB4MDEwMDE4IHBvbGFyaXR5IG9mIHZ0IHNpZ25hbHMgKi8N CisgIHZvbGF0aWxlIHUzMiB2dF9mMnJmX2xvY2s7IC8qIDB4MDEwMDFjIGYy cmYgJiBmcmFtZWxjayB5IGNvb3JkICovDQorICB2b2xhdGlsZSB1MzIgdnRf aW50cjAxOyAgICAvKiAweDAxMDAyMCBpbnRyIDAsMSB5IGNvb3JkcyAqLw0K KyAgdm9sYXRpbGUgdTMyIHZ0X2ludHIyMzsgICAgLyogMHgwMTAwMjQgaW50 ciAyLDMgeSBjb29yZHMgKi8NCisgIHZvbGF0aWxlIHUzMiBmcF9oZHJ2OyAg ICAgIC8qIDB4MDEwMDI4IGZsYXQgcGFuZWwgaGRydiBvbi9vZmYgKi8NCisg IHZvbGF0aWxlIHUzMiBmcF92ZHJ2OyAgICAgIC8qIDB4MDEwMDJjIGZsYXQg cGFuZWwgdmRydiBvbi9vZmYgKi8NCisgIHZvbGF0aWxlIHUzMiBmcF9kZTsg ICAgICAgIC8qIDB4MDEwMDMwIGZsYXQgcGFuZWwgZGUgb24vb2ZmICovDQor ICB2b2xhdGlsZSB1MzIgdnRfaHBpeGVuOyAgICAvKiAweDAxMDAzNCBpbnRy bmwgaG9yaXogcGl4ZWwgb24vb2ZmKi8NCisgIHZvbGF0aWxlIHUzMiB2dF92 cGl4ZW47ICAgIC8qIDB4MDEwMDM4IGludHJubCB2ZXJ0IHBpeGVsIG9uL29m ZiAqLw0KKyAgdm9sYXRpbGUgdTMyIHZ0X2hjbWFwOyAgICAgLyogMHgwMTAw M2MgY21hcCB3cml0ZSAoaG9yaXopICovDQorICB2b2xhdGlsZSB1MzIgdnRf dmNtYXA7ICAgICAvKiAweDAxMDA0MCBjbWFwIHdyaXRlICh2ZXJ0KSAqLw0K KyAgdm9sYXRpbGUgdTMyIGRpZF9zdGFydF94eTsgLyogMHgwMTAwNDQgZW9s L2YgZGlkL3h5IHJlc2V0IHZhbCAqLw0KKyAgdm9sYXRpbGUgdTMyIGNyc19z dGFydF94eTsgLyogMHgwMTAwNDggZW9sL2YgY3JzL3h5IHJlc2V0IHZhbCAq Lw0KKyAgdm9sYXRpbGUgdTMyIHZjX3N0YXJ0X3h5OyAgLyogMHgwMTAwNGMg ZW9sL2YgdmMveHkgcmVzZXQgdmFsICovDQorDQorICBjaGFyIF9wYWQxWyAw eDAyMDAwMCAtIDB4MDEwMDUwIF07DQorDQorICB2b2xhdGlsZSB1MzIgb3Zy X3dpZHRoX3RpbGU7IC8qIDB4MDIwMDAwIG92ZXJsYXkgcGxhbmUgY3RybCAw ICovDQorICB2b2xhdGlsZSB1MzIgb3ZyX2luaHdjdHJsOyAgIC8qIDB4MDIw MDA0IG92ZXJsYXkgcGxhbmUgY3RybCAxICovDQorICB2b2xhdGlsZSB1MzIg b3ZyX2NvbnRyb2w7ICAgIC8qIDB4MDIwMDA4IG92ZXJsYXkgcGxhbmUgY3Ry bCAxICovDQorDQorICBjaGFyIF9wYWQyWyAweDAzMDAwMCAtIDB4MDIwMDBD IF07DQorDQorICB2b2xhdGlsZSB1MzIgZnJtX3NpemVfdGlsZTsgIC8qIDB4 MDMwMDAwIG5vcm1hbCBwbGFuZSBjdHJsIDAgKi8NCisgIHZvbGF0aWxlIHUz MiBmcm1fc2l6ZV9waXhlbDsgLyogMHgwMzAwMDQgbm9ybWFsIHBsYW5lIGN0 cmwgMSAqLw0KKyAgdm9sYXRpbGUgdTMyIGZybV9pbmh3Y3RybDsgICAvKiAw eDAzMDAwOCBub3JtYWwgcGxhbmUgY3RybCAyICovDQorICB2b2xhdGlsZSB1 MzIgZnJtX2NvbnRyb2w7ICAgIC8qIDB4MDMwMDBDIG5vcm1hbCBwbGFuZSBj dHJsIDMgKi8NCisNCisgIGNoYXIgX3BhZDNbIDB4MDQwMDAwIC0gMHgwMzAw MTAgXTsNCisNCisgIHZvbGF0aWxlIHUzMiBkaWRfaW5od2N0cmw7ICAgLyog MHgwNDAwMDAgRElEIGNvbnRyb2wgKi8NCisgIHZvbGF0aWxlIHUzMiBkaWRf Y29udHJvbDsgICAgLyogMHgwNDAwMDQgRElEIHNoYWRvdyAqLw0KKw0KKyAg Y2hhciBfcGFkNFsgMHgwNDgwMDAgLSAweDA0MDAwOCBdOw0KKw0KKyAgdm9s YXRpbGUgdTMyIG1vZGVfcmVnc1szMl07ICAvKiAweDA0ODAwMCAtIDB4MDQ4 MDdjIFdJRCB0YWJsZSAqLw0KKw0KKyAgY2hhciBfcGFkNVsgMHgwNTAwMDAg LSAweDA0ODA4MCBdOw0KKw0KKyAgdm9sYXRpbGUgdTMyIGNtYXBbNjE0NF07 ICAgICAvKiAweDA1MDAwMCAtIDB4MDU1ZmZjIGNvbG9yIG1hcCAqLw0KKw0K KyAgY2hhciBfcGFkNlsgMHgwNTgwMDAgLSAweDA1NjAwMCBdOw0KKw0KKyAg dm9sYXRpbGUgdTMyIGNtX2ZpZm87ICAgICAgICAvKiAweDA1ODAwMCBjb2xv ciBtYXAgZmlmbyBzdGF0dXMgKi8NCisNCisgIGNoYXIgX3BhZDdbIDB4MDYw MDAwIC0gMHgwNTgwMDQgXTsNCisNCisgIHZvbGF0aWxlIHUzMiBnbWFwWzI1 Nl07ICAgICAgLyogMHgwNjAwMDAgLSAweDA2MDNmYyBnYW1tYSBtYXAgKi8N CisNCisgIGNoYXIgX3BhZDhbIDB4MDY4MDAwIC0gMHgwNjA0MDAgXTsNCisN CisgIHZvbGF0aWxlIHUzMiBnbWFwMTBbMTAyNF07ICAgLyogMHgwNjgwMDAg LSAweDA2OGZmYyBnYW1tYSBtYXAgKi8NCisNCisgIGNoYXIgX3BhZDlbIDB4 MDcwMDAwIC0gMHgwNjkwMDAgXTsNCisNCisgIHZvbGF0aWxlIHUzMiBjcnNf cG9zOyAgICAgICAgLyogMHgwNzAwMDAgY3Vzcm9yIGNvbnRyb2wgMCAqLw0K KyAgdm9sYXRpbGUgdTMyIGNyc19jdGw7ICAgICAgICAvKiAweDA3MDAwNCBj dXNyb3IgY29udHJvbCAxICovDQorICB2b2xhdGlsZSB1MzIgY3JzX2NtYXBb M107ICAgIC8qIDB4MDcwMDA4IC0gMHgwNzAwMTAgY3JzIGNtYXAgKi8NCisN CisgIGNoYXIgX3BhZDEwWyAweDA3ODAwMCAtIDB4MDcwMDE0IF07DQorDQor ICB2b2xhdGlsZSB1MzIgY3JzX2dseXBoWzY0XTsgIC8qIDB4MDc4MDAwIC0g MHgwNzgwZmMgY3JzIGdseXBoICovDQorDQorICBjaGFyIF9wYWQxMVsgMHgw ODAwMDAgLSAweDA3ODEwMCBdOw0KKw0KKyAgdm9sYXRpbGUgdTMyIHZjXzA7 ICAgICAgICAgICAvKiAweDA4MDAwMCB2aWRlbyBjYXB0dXJlIGNydGwgMCAq Lw0KKyAgdm9sYXRpbGUgdTMyIHZjXzE7ICAgICAgICAgICAvKiAweDA4MDAw NCB2aWRlbyBjYXB0dXJlIGNydGwgMSAqLw0KKyAgdm9sYXRpbGUgdTMyIHZj XzI7ICAgICAgICAgICAvKiAweDA4MDAwOCB2aWRlbyBjYXB0dXJlIGNydGwg MiAqLw0KKyAgdm9sYXRpbGUgdTMyIHZjXzM7ICAgICAgICAgICAvKiAweDA4 MDAwYyB2aWRlbyBjYXB0dXJlIGNydGwgMyAqLw0KKyAgdm9sYXRpbGUgdTMy IHZjXzQ7ICAgICAgICAgICAvKiAweDA4MDAxMCB2aWRlbyBjYXB0dXJlIGNy dGwgMyAqLw0KKyAgdm9sYXRpbGUgdTMyIHZjXzU7ICAgICAgICAgICAvKiAw eDA4MDAxNCB2aWRlbyBjYXB0dXJlIGNydGwgMyAqLw0KKyAgdm9sYXRpbGUg dTMyIHZjXzY7ICAgICAgICAgICAvKiAweDA4MDAxOCB2aWRlbyBjYXB0dXJl IGNydGwgMyAqLw0KKyAgdm9sYXRpbGUgdTMyIHZjXzc7ICAgICAgICAgICAv KiAweDA4MDAxYyB2aWRlbyBjYXB0dXJlIGNydGwgMyAqLw0KKyAgdm9sYXRp bGUgdTMyIHZjXzg7ICAgICAgICAgICAvKiAweDA4MDAwYyB2aWRlbyBjYXB0 dXJlIGNydGwgMyAqLw0KK30gYXNyZWdzOw0KKw0KKy8qIEJpdCBtYXNrIGlu Zm9ybWF0aW9uICovDQorDQorI2RlZmluZSBHQkVfQ1RSTFNUQVRfQ0hJUElE X01TQiAgICAgMw0KKyNkZWZpbmUgR0JFX0NUUkxTVEFUX0NISVBJRF9MU0Ig ICAgIDANCisjZGVmaW5lIEdCRV9DVFJMU1RBVF9TRU5TRV9OX01TQiAgICA0 DQorI2RlZmluZSBHQkVfQ1RSTFNUQVRfU0VOU0VfTl9MU0IgICAgNA0KKyNk ZWZpbmUgR0JFX0NUUkxTVEFUX1BDTEtTRUxfTVNCICAgIDI5DQorI2RlZmlu ZSBHQkVfQ1RSTFNUQVRfUENMS1NFTF9MU0IgICAgMjgNCisNCisjZGVmaW5l IEdCRV9ET1RDTEtfTV9NU0IgICAgICAgICAgICA3DQorI2RlZmluZSBHQkVf RE9UQ0xLX01fTFNCICAgICAgICAgICAgMA0KKyNkZWZpbmUgR0JFX0RPVENM S19OX01TQiAgICAgICAgICAgIDEzDQorI2RlZmluZSBHQkVfRE9UQ0xLX05f TFNCICAgICAgICAgICAgOA0KKyNkZWZpbmUgR0JFX0RPVENMS19QX01TQiAg ICAgICAgICAgIDE1DQorI2RlZmluZSBHQkVfRE9UQ0xLX1BfTFNCICAgICAg ICAgICAgMTQNCisjZGVmaW5lIEdCRV9ET1RDTEtfUlVOX01TQiAgICAgICAg ICAyMA0KKyNkZWZpbmUgR0JFX0RPVENMS19SVU5fTFNCICAgICAgICAgIDIw DQorDQorI2RlZmluZSBHQkVfVlRfWFlfVlRfRlJFRVpFX01TQiAgICAgMzEN CisjZGVmaW5lIEdCRV9WVF9YWV9WVF9GUkVFWkVfTFNCICAgICAzMQ0KKw0K KyNkZWZpbmUgR0JFX1ZUX1ZTWU5DX1ZUX1ZTWU5DX09OX01TQiAgICAgICAg MjMNCisjZGVmaW5lIEdCRV9WVF9WU1lOQ19WVF9WU1lOQ19PTl9MU0IgICAg ICAgIDEyDQorI2RlZmluZSBHQkVfVlRfVlNZTkNfVlRfVlNZTkNfT0ZGX01T QiAgICAgICAxMQ0KKyNkZWZpbmUgR0JFX1ZUX1ZTWU5DX1ZUX1ZTWU5DX09G Rl9MU0IgICAgICAgMA0KKw0KKyNkZWZpbmUgR0JFX1ZUX0hTWU5DX1ZUX0hT WU5DX09OX01TQiAgICAgICAgMjMNCisjZGVmaW5lIEdCRV9WVF9IU1lOQ19W VF9IU1lOQ19PTl9MU0IgICAgICAgIDEyDQorI2RlZmluZSBHQkVfVlRfSFNZ TkNfVlRfSFNZTkNfT0ZGX01TQiAgICAgICAxMQ0KKyNkZWZpbmUgR0JFX1ZU X0hTWU5DX1ZUX0hTWU5DX09GRl9MU0IgICAgICAgMA0KKw0KKyNkZWZpbmUg R0JFX1ZUX1ZCTEFOS19WVF9WQkxBTktfT05fTVNCICAgICAgICAyMw0KKyNk ZWZpbmUgR0JFX1ZUX1ZCTEFOS19WVF9WQkxBTktfT05fTFNCICAgICAgICAx Mg0KKyNkZWZpbmUgR0JFX1ZUX1ZCTEFOS19WVF9WQkxBTktfT0ZGX01TQiAg ICAgICAxMQ0KKyNkZWZpbmUgR0JFX1ZUX1ZCTEFOS19WVF9WQkxBTktfT0ZG X0xTQiAgICAgICAwDQorDQorI2RlZmluZSBHQkVfVlRfSEJMQU5LX1ZUX0hC TEFOS19PTl9NU0IgICAgICAgIDIzDQorI2RlZmluZSBHQkVfVlRfSEJMQU5L X1ZUX0hCTEFOS19PTl9MU0IgICAgICAgIDEyDQorI2RlZmluZSBHQkVfVlRf SEJMQU5LX1ZUX0hCTEFOS19PRkZfTVNCICAgICAgIDExDQorI2RlZmluZSBH QkVfVlRfSEJMQU5LX1ZUX0hCTEFOS19PRkZfTFNCICAgICAgIDANCisNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9GMlJGX0hJR0hfTVNCICAgIDYNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9GMlJGX0hJR0hfTFNCICAgIDYNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9TWU5DX0xPV19NU0IgICAgIDUNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9TWU5DX0xPV19MU0IgICAgIDUNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9TWU5DX0hJR0hfTVNCICAgIDQNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9TWU5DX0hJR0hfTFNCICAgIDQNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9IRFJWX0xPV19NU0IgICAgIDMNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9IRFJWX0xPV19MU0IgICAgIDMNCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9IRFJWX0lOVkVSVF9NU0IgIDINCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9IRFJWX0lOVkVSVF9MU0IgIDINCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9WRFJWX0xPV19NU0IgICAgIDENCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9WRFJWX0xPV19MU0IgICAgIDENCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9WRFJWX0lOVkVSVF9NU0IgIDANCisj ZGVmaW5lIEdCRV9WVF9GTEFHU19WVF9WRFJWX0lOVkVSVF9MU0IgIDANCisN CisjZGVmaW5lIEdCRV9WVF9WQ01BUF9WVF9WQ01BUF9PTl9NU0IgICAgICAg IDIzDQorI2RlZmluZSBHQkVfVlRfVkNNQVBfVlRfVkNNQVBfT05fTFNCICAg ICAgICAxMg0KKyNkZWZpbmUgR0JFX1ZUX1ZDTUFQX1ZUX1ZDTUFQX09GRl9N U0IgICAgICAgMTENCisjZGVmaW5lIEdCRV9WVF9WQ01BUF9WVF9WQ01BUF9P RkZfTFNCICAgICAgIDANCisNCisjZGVmaW5lIEdCRV9WVF9IQ01BUF9WVF9I Q01BUF9PTl9NU0IgICAgICAgIDIzDQorI2RlZmluZSBHQkVfVlRfSENNQVBf VlRfSENNQVBfT05fTFNCICAgICAgICAxMg0KKyNkZWZpbmUgR0JFX1ZUX0hD TUFQX1ZUX0hDTUFQX09GRl9NU0IgICAgICAgMTENCisjZGVmaW5lIEdCRV9W VF9IQ01BUF9WVF9IQ01BUF9PRkZfTFNCICAgICAgIDANCisNCisjZGVmaW5l IEdCRV9WVF9YWU1BWF9WVF9NQVhYX01TQiAgICAxMQ0KKyNkZWZpbmUgR0JF X1ZUX1hZTUFYX1ZUX01BWFhfTFNCICAgIDANCisjZGVmaW5lIEdCRV9WVF9Y WU1BWF9WVF9NQVhZX01TQiAgICAyMw0KKyNkZWZpbmUgR0JFX1ZUX1hZTUFY X1ZUX01BWFlfTFNCICAgIDEyDQorDQorI2RlZmluZSBHQkVfVlRfSFBJWEVO X1ZUX0hQSVhFTl9PTl9NU0IgICAgICAyMw0KKyNkZWZpbmUgR0JFX1ZUX0hQ SVhFTl9WVF9IUElYRU5fT05fTFNCICAgICAgMTINCisjZGVmaW5lIEdCRV9W VF9IUElYRU5fVlRfSFBJWEVOX09GRl9NU0IgICAgIDExDQorI2RlZmluZSBH QkVfVlRfSFBJWEVOX1ZUX0hQSVhFTl9PRkZfTFNCICAgICAwDQorDQorI2Rl ZmluZSBHQkVfVlRfVlBJWEVOX1ZUX1ZQSVhFTl9PTl9NU0IgICAgICAyMw0K KyNkZWZpbmUgR0JFX1ZUX1ZQSVhFTl9WVF9WUElYRU5fT05fTFNCICAgICAg MTINCisjZGVmaW5lIEdCRV9WVF9WUElYRU5fVlRfVlBJWEVOX09GRl9NU0Ig ICAgIDExDQorI2RlZmluZSBHQkVfVlRfVlBJWEVOX1ZUX1ZQSVhFTl9PRkZf TFNCICAgICAwDQorDQorI2RlZmluZSBHQkVfT1ZSX0NPTlRST0xfT1ZSX0RN QV9FTkFCTEVfTVNCICAwDQorI2RlZmluZSBHQkVfT1ZSX0NPTlRST0xfT1ZS X0RNQV9FTkFCTEVfTFNCICAwDQorDQorI2RlZmluZSBHQkVfT1ZSX0lOSFdD VFJMX09WUl9ETUFfRU5BQkxFX01TQiAwDQorI2RlZmluZSBHQkVfT1ZSX0lO SFdDVFJMX09WUl9ETUFfRU5BQkxFX0xTQiAwDQorDQorI2RlZmluZSBHQkVf T1ZSX1dJRFRIX1RJTEVfT1ZSX0ZJRk9fUkVTRVRfTVNCICAgICAgIDEzDQor I2RlZmluZSBHQkVfT1ZSX1dJRFRIX1RJTEVfT1ZSX0ZJRk9fUkVTRVRfTFNC ICAgICAgIDEzDQorDQorI2RlZmluZSBHQkVfRlJNX0NPTlRST0xfRlJNX0RN QV9FTkFCTEVfTVNCICAwDQorI2RlZmluZSBHQkVfRlJNX0NPTlRST0xfRlJN X0RNQV9FTkFCTEVfTFNCICAwDQorI2RlZmluZSBHQkVfRlJNX0NPTlRST0xf RlJNX1RJTEVfUFRSX01TQiAgICAzMQ0KKyNkZWZpbmUgR0JFX0ZSTV9DT05U Uk9MX0ZSTV9USUxFX1BUUl9MU0IgICAgOQ0KKyNkZWZpbmUgR0JFX0ZSTV9D T05UUk9MX0ZSTV9MSU5FQVJfTVNCICAgICAgMQ0KKyNkZWZpbmUgR0JFX0ZS TV9DT05UUk9MX0ZSTV9MSU5FQVJfTFNCICAgICAgMQ0KKw0KKyNkZWZpbmUg R0JFX0ZSTV9JTkhXQ1RSTF9GUk1fRE1BX0VOQUJMRV9NU0IgMA0KKyNkZWZp bmUgR0JFX0ZSTV9JTkhXQ1RSTF9GUk1fRE1BX0VOQUJMRV9MU0IgMA0KKw0K KyNkZWZpbmUgR0JFX0ZSTV9TSVpFX1RJTEVfRlJNX1dJRFRIX1RJTEVfTVNC ICAgICAgICAxMg0KKyNkZWZpbmUgR0JFX0ZSTV9TSVpFX1RJTEVfRlJNX1dJ RFRIX1RJTEVfTFNCICAgICAgICA1DQorI2RlZmluZSBHQkVfRlJNX1NJWkVf VElMRV9GUk1fUkhTX01TQiAgICAgICA0DQorI2RlZmluZSBHQkVfRlJNX1NJ WkVfVElMRV9GUk1fUkhTX0xTQiAgICAgICAwDQorI2RlZmluZSBHQkVfRlJN X1NJWkVfVElMRV9GUk1fREVQVEhfTVNCICAgICAxNA0KKyNkZWZpbmUgR0JF X0ZSTV9TSVpFX1RJTEVfRlJNX0RFUFRIX0xTQiAgICAgMTMNCisjZGVmaW5l IEdCRV9GUk1fU0laRV9USUxFX0ZSTV9GSUZPX1JFU0VUX01TQiAgICAgICAg MTUNCisjZGVmaW5lIEdCRV9GUk1fU0laRV9USUxFX0ZSTV9GSUZPX1JFU0VU X0xTQiAgICAgICAgMTUNCisNCisjZGVmaW5lIEdCRV9GUk1fU0laRV9QSVhF TF9GQl9IRUlHSFRfUElYX01TQiAgICAgICAgMzENCisjZGVmaW5lIEdCRV9G Uk1fU0laRV9QSVhFTF9GQl9IRUlHSFRfUElYX0xTQiAgICAgICAgMTYNCisN CisjZGVmaW5lIEdCRV9ESURfQ09OVFJPTF9ESURfRE1BX0VOQUJMRV9NU0Ig IDANCisjZGVmaW5lIEdCRV9ESURfQ09OVFJPTF9ESURfRE1BX0VOQUJMRV9M U0IgIDANCisjZGVmaW5lIEdCRV9ESURfSU5IV0NUUkxfRElEX0RNQV9FTkFC TEVfTVNCIDANCisjZGVmaW5lIEdCRV9ESURfSU5IV0NUUkxfRElEX0RNQV9F TkFCTEVfTFNCIDANCisNCisjZGVmaW5lIEdCRV9ESURfU1RBUlRfWFlfRElE X1NUQVJUWV9NU0IgICAgIDIzDQorI2RlZmluZSBHQkVfRElEX1NUQVJUX1hZ X0RJRF9TVEFSVFlfTFNCICAgICAxMg0KKyNkZWZpbmUgR0JFX0RJRF9TVEFS VF9YWV9ESURfU1RBUlRYX01TQiAgICAgMTENCisjZGVmaW5lIEdCRV9ESURf U1RBUlRfWFlfRElEX1NUQVJUWF9MU0IgICAgIDANCisNCisjZGVmaW5lIEdC RV9DUlNfU1RBUlRfWFlfQ1JTX1NUQVJUWV9NU0IgICAgIDIzDQorI2RlZmlu ZSBHQkVfQ1JTX1NUQVJUX1hZX0NSU19TVEFSVFlfTFNCICAgICAxMg0KKyNk ZWZpbmUgR0JFX0NSU19TVEFSVF9YWV9DUlNfU1RBUlRYX01TQiAgICAgMTEN CisjZGVmaW5lIEdCRV9DUlNfU1RBUlRfWFlfQ1JTX1NUQVJUWF9MU0IgICAg IDANCisNCisjZGVmaW5lIEdCRV9XSURfQVVYX01TQiAgICAxMg0KKyNkZWZp bmUgR0JFX1dJRF9BVVhfTFNCICAgIDExDQorI2RlZmluZSBHQkVfV0lEX0dB TU1BX01TQiAgMTANCisjZGVmaW5lIEdCRV9XSURfR0FNTUFfTFNCICAxMA0K KyNkZWZpbmUgR0JFX1dJRF9DTV9NU0IgICAgICA5DQorI2RlZmluZSBHQkVf V0lEX0NNX0xTQiAgICAgIDUNCisjZGVmaW5lIEdCRV9XSURfVFlQX01TQiAg ICAgNA0KKyNkZWZpbmUgR0JFX1dJRF9UWVBfTFNCICAgICAyDQorI2RlZmlu ZSBHQkVfV0lEX0JVRl9NU0IgICAgIDENCisjZGVmaW5lIEdCRV9XSURfQlVG X0xTQiAgICAgMA0KKw0KKyNkZWZpbmUgR0JFX1ZDX1NUQVJUX1hZX1ZDX1NU QVJUWV9NU0IgICAgICAgMjMNCisjZGVmaW5lIEdCRV9WQ19TVEFSVF9YWV9W Q19TVEFSVFlfTFNCICAgICAgIDEyDQorI2RlZmluZSBHQkVfVkNfU1RBUlRf WFlfVkNfU1RBUlRYX01TQiAgICAgICAxMQ0KKyNkZWZpbmUgR0JFX1ZDX1NU QVJUX1hZX1ZDX1NUQVJUWF9MU0IgICAgICAgMA0KKw0KKy8qIENvbnN0YW50 cyAqLw0KKw0KKyNkZWZpbmUgR0JFX0ZSTV9ERVBUSF84ICAgICAwDQorI2Rl ZmluZSBHQkVfRlJNX0RFUFRIXzE2ICAgIDENCisjZGVmaW5lIEdCRV9GUk1f REVQVEhfMzIgICAgMg0KKw0KKyNkZWZpbmUgR0JFX0NNT0RFX0k4ICAgICAg ICAwDQorI2RlZmluZSBHQkVfQ01PREVfSTEyICAgICAgIDENCisjZGVmaW5l IEdCRV9DTU9ERV9SRzNCMiAgICAgMg0KKyNkZWZpbmUgR0JFX0NNT0RFX1JH QjQgICAgICAzDQorI2RlZmluZSBHQkVfQ01PREVfQVJHQjUgICAgIDQNCisj ZGVmaW5lIEdCRV9DTU9ERV9SR0I4ICAgICAgNQ0KKyNkZWZpbmUgR0JFX0NN T0RFX1JHQkE1ICAgICA2DQorI2RlZmluZSBHQkVfQ01PREVfUkdCMTAgICAg IDcNCisNCisjZGVmaW5lIEdCRV9CTU9ERV9CT1RIICAgICAgMw0KKw0KKyNk ZWZpbmUgR0JFX0NSU19NQUdJQyAgICAgICA1NA0KKw0KKy8qIENvbmZpZyBS ZWdpc3RlciAoR0JFIE9ubHkpIERlZmluaXRpb25zICovDQorDQorI2RlZmlu ZSBHQkVfQ09ORklHX1ZEQUNfRU5BQkxFICAgICAgIDB4MDAwMDAwMDENCisj ZGVmaW5lIEdCRV9DT05GSUdfVkRBQ19HU1lOQyAgICAgICAgMHgwMDAwMDAw Mg0KKyNkZWZpbmUgR0JFX0NPTkZJR19WREFDX1BCTEFOSyAgICAgICAweDAw MDAwMDA0DQorI2RlZmluZSBHQkVfQ09ORklHX0ZQRU5BQkxFICAgICAgICAg IDB4MDAwMDAwMDgNCisjZGVmaW5lIEdCRV9DT05GSUdfTEVORElBTiAgICAg ICAgICAgMHgwMDAwMDAyMA0KKyNkZWZpbmUgR0JFX0NPTkZJR19USUxFSElT VCAgICAgICAgICAweDAwMDAwMDQwDQorI2RlZmluZSBHQkVfQ09ORklHX0VY VF9BRERSICAgICAgICAgIDB4MDAwMDAwODANCisNCisjZGVmaW5lIEdCRV9D T05GSUdfRkJERVYgICAgICAgICggR0JFX0NPTkZJR19WREFDX0VOQUJMRSB8 IFwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdC RV9DT05GSUdfVkRBQ19HU1lOQyAgfCBcDQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBHQkVfQ09ORklHX1ZEQUNfUEJMQU5LIHwg XA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR0JF X0NPTkZJR19MRU5ESUFOICAgICB8IFwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdCRV9DT05GSUdfRVhUX0FERFIgKQ0KKw0K Ky8qDQorICogQXZhaWxhYmxlIFZpZGVvIFRpbWluZ3MgYW5kIENvcnJlc3Bv bmRpbmcgSW5kaWNlcw0KKyAqLw0KKw0KK3R5cGVkZWYgZW51bSB7DQorICBH QkVfVlRfNjQwXzQ4MF82MCwNCisgIEdCRV9WVF84MDBfNjAwXzYwLA0KKyAg R0JFX1ZUXzgwMF82MDBfNzUsDQorDQorICBHQkVfVlRfMTAyNF83NjhfNjAs DQorICBHQkVfVlRfMTAyNF83NjhfNzUsDQorICBHQkVfVlRfMTAyNF83Njhf ODUsDQorDQorICBHQkVfVlRfMTI4MF8xMDI0XzUwLA0KKyAgR0JFX1ZUXzEy ODBfMTAyNF82MCwNCisgIEdCRV9WVF8xMjgwXzEwMjRfNzUsDQorICBHQkVf VlRfMTI4MF8xMDI0Xzg1LA0KKw0KKyAgR0JFX1ZUXzE2MDBfMTAyNF82MCwN CisNCisgIEdCRV9WVF8xNjAwXzEyMDBfNjAsDQorICBHQkVfVlRfMTYwMF8x MjAwXzc1LA0KKw0KKyAgR0JFX1ZUXzE5MjBfMTA4MF82MCwNCisNCisgIEdC RV9WVF9VTktOT1dODQorfSBnYmVfdGltaW5nX3Q7DQorDQorDQorDQorLyoN CisgKiBDcmltZSBWaWRlbyBUaW1pbmcgRGF0YSBTdHJ1Y3R1cmUNCisgKi8N CisNCit0eXBlZGVmIHN0cnVjdCBnYmVfdGltaW5nX2luZm8NCit7DQorICBn YmVfdGltaW5nX3QgdHlwZTsNCisgIGludCBmbGFnczsJCQkJDQorICBzaG9y dCB3aWR0aDsJCSAgICAvKiBNb25pdG9yIHJlc29sdXRpb24JCSovDQorICBz aG9ydCBoZWlnaHQ7DQorICBpbnQgZmllbGRzX3NlYzsJICAgIC8qIGZpZWxk cy9zZWMgIChIeiAtMyBkZWMuIHBsYWNlcyAqLw0KKyAgaW50IGNmcmVxOwkJ ICAgIC8qIHBpeGVsIGNsb2NrIGZyZXF1ZW5jeSAoTUh6IC0zIGRlYy4gcGxh Y2VzKSAqLw0KKyAgc2hvcnQgaHRvdGFsOwkJICAgIC8qIEhvcml6b250YWwg dG90YWwgcGl4ZWxzCSovDQorICBzaG9ydCBoYmxhbmtfc3RhcnQ7CSAgICAv KiBIb3Jpem9udGFsIGJsYW5rIHN0YXJ0CSovDQorICBzaG9ydCBoYmxhbmtf ZW5kOwkgICAgLyogSG9yaXpvbnRhbCBibGFuayBlbmQJCSovDQorICBzaG9y dCBoc3luY19zdGFydDsJICAgIC8qIEhvcml6b250YWwgc3luYyBzdGFydAkq Lw0KKyAgc2hvcnQgaHN5bmNfZW5kOwkgICAgLyogSG9yaXpvbnRhbCBzeW5j IGVuZAkJKi8NCisgIHNob3J0IHZ0b3RhbDsJCSAgICAvKiBWZXJ0aWNhbCB0 b3RhbCBsaW5lcwkJKi8NCisgIHNob3J0IHZibGFua19zdGFydDsJICAgIC8q IFZlcnRpY2FsIGJsYW5rIHN0YXJ0CQkqLw0KKyAgc2hvcnQgdmJsYW5rX2Vu ZDsJICAgIC8qIFZlcnRpY2FsIGJsYW5rIGVuZAkJKi8NCisgIHNob3J0IHZz eW5jX3N0YXJ0OwkgICAgLyogVmVydGljYWwgc3luYyBzdGFydAkJKi8NCisg IHNob3J0IHZzeW5jX2VuZDsJICAgIC8qIFZlcnRpY2FsIHN5bmMgZW5kCQkq Lw0KKyAgc2hvcnQgcGxsX207CQkgICAgLyogUExMIE0gcGFyYW1ldGVyCQkq Lw0KKyAgc2hvcnQgcGxsX247CQkgICAgLyogUExMIFAgcGFyYW1ldGVyCQkq Lw0KKyAgc2hvcnQgcGxsX3A7CQkgICAgLyogUExMIE4gcGFyYW1ldGVyCQkq Lw0KK30gZ2JlX3RpbWluZ19pbmZvX3Q7DQorDQorLyogRGVmaW5lcyBmb3Ig Z2JlX3ZvZl9pbmZvX3QgZmxhZ3MgKi8NCisNCisjZGVmaW5lIEdCRV9WT0Zf VU5LTk9XTk1PTiAgICAxDQorI2RlZmluZSBHQkVfVk9GX1NURVJFTyAgICAg ICAgMg0KKyNkZWZpbmUgR0JFX1ZPRl9ET19HRU5TWU5DICAgIDQgICAgICAg ICAgLyogZW5hYmxlIGluY29taW5nIHN5bmMgKi8NCisjZGVmaW5lIEdCRV9W T0ZfU1lOQ19PTl9HUkVFTiA4ICAgICAgICAgIC8qIHN5bmMgb24gZ3JlZW4g Ki8NCisjZGVmaW5lIEdCRV9WT0ZfRkxBVFBBTkVMICAgICAweDEwMDAgICAg IC8qIEZMQVRQQU5FTCBUaW1pbmcgKi8NCisjZGVmaW5lIEdCRV9WT0ZfTUFH SUNLRVkgICAgICAweDIwMDAgICAgIC8qIEJhY2tkb29yIGtleSAqLw0KKw0K Ky8qDQorICogR0JFIFRpbWluZyBUYWJsZXMNCisgKi8NCisNCisjaWZkZWYg SU5DTFVERV9USU1JTkdfVEFCTEVfREFUQQ0KKw0KKy8qIEdCRSBjcnlzdGFs IHJ1bnMgYXQgMjBNaHogKi8NCisvKiBwbGxfbSwgcGxsX24sIHBsbF9wIGRl ZmluZSB0aGUgZm9sbG93aW5nIGZyZXF1ZW5jaWVzICovDQorLyogZnZjbyA9 IHBsbF9tICogMjBNaHogLyBwbGxfbiAqLw0KKy8qIGZvdXQgPSBmdmNvIC8g KDIqKnBsbF9wKSAqLw0KKw0KK3N0cnVjdCBnYmVfdGltaW5nX2luZm8gZ2Jl VlRpbWluZ3NbXSA9IHsNCisgIC8qIFRPRE86IHVwZGF0ZSB0aW1pbmdzLCBz aW5jZSBjcnlzdGFsIGNsb2NrIGlzIDIwTWh6IGluc3RlYWQgb2YgMjdNaHog Ki8NCisgIHsNCisgICAgR0JFX1ZUXzY0MF80ODBfNjAsDQorICAgIC8qCWZs YWdzLAl3aWR0aCwJCQloZWlnaHQsCQlmaWVsZHNfc2VjLAkJY2ZyZXEgKi8N CisgICAgMCwgIAk2NDAsCQkJNDgwLAkJNTk5MzQsCQkJMjUxNzIsDQorICAg IC8qCWh0b3RhbCwJaGJsYW5rX3N0YXJ0LAloYmxhbmtfZW5kLAloc3luY19z dGFydCwJaHN5bmNfZW5kICovDQorICAgIDgwMCwJNjQwLAkJICAgIDgwMCwJ CTY2NCwJICAgIAk3NjAsDQorICAgIC8qCXZ0b3RhbCwJdmJsYW5rX3N0YXJ0 LAl2YmxhbmtfZW5kLAl2c3luY19zdGFydCwJdnN5bmNfZW5kICovDQorICAg IDUyNSwJNDgwLAkJICAgIDUyNSwJCTQ5MSwJCTQ5MywNCisgICAgLyoJcGxs X20sCXBsbF9uLAkJCXBsbF9wICovDQorICAgIDE0NiwJIDI5LAkJCTINCisg IH0sDQorDQorICB7DQorICAgIEdCRV9WVF84MDBfNjAwXzYwLA0KKyAgICAv KglmbGFncywJd2lkdGgsCQkJaGVpZ2h0LAkJZmllbGRzX3NlYywJCWNmcmVx ICovDQorICAgIDAsCSAgICA4MDAsCQkJNjAwLAkJNjAzMTcsCQkJNDAwMDAs DQorICAgIC8qCWh0b3RhbCwJaGJsYW5rX3N0YXJ0LAloYmxhbmtfZW5kLAlo c3luY19zdGFydCwJaHN5bmNfZW5kICovDQorICAgIDEwNTYsCTgwMCwJCSAg ICAxMDU2LAkJODQwLAkJICAgIDk2OCwNCisgICAgLyoJdnRvdGFsLAl2Ymxh bmtfc3RhcnQsCXZibGFua19lbmQsCXZzeW5jX3N0YXJ0LAl2c3luY19lbmQg Ki8NCisgICAgNjI4LAk2MDAsCQkgICAgNjI4LAkJNjAxLAkJICAgIDYwNSwN CisgICAgLyoJcGxsX20sCXBsbF9uLAkJCXBsbF9wICovDQorICAgIDI0MCwJ MzAsCQkJMg0KKyAgfSwNCisNCisgIHsNCisgICAgR0JFX1ZUXzgwMF82MDBf NzUsDQorICAgIC8qCWZsYWdzLAl3aWR0aCwJCSAgICBoZWlnaHQsCQlmaWVs ZHNfc2VjLAkgICAgY2ZyZXEgKi8NCisgICAgMCwJICAgIDgwMCwJCSAgICA2 MDAsCQk3NTAwMCwJCSAgICA1MDAwMCwNCisgICAgLyoJaHRvdGFsLAloYmxh bmtfc3RhcnQsCWhibGFua19lbmQsCWhzeW5jX3N0YXJ0LAloc3luY19lbmQg Ki8NCisgICAgMTA1NiwJODAwLAkJICAgIDEwNTYsCQk4MTYsCQkgICAgODk2 LA0KKyAgICAvKgl2dG90YWwsCXZibGFua19zdGFydCwJdmJsYW5rX2VuZCwJ dnN5bmNfc3RhcnQsCXZzeW5jX2VuZCAqLw0KKyAgICA2MjUsCTYwMCwJCSAg ICA2MjUsCQk2MDEsCQkgICAgNjA0LA0KKyAgICAvKglwbGxfbSwJcGxsX24s CQkgICAgcGxsX3AgKi8NCisgICAgMTUwLAkgMzAsCQkgICAgICAgIDENCisg IH0sDQorDQorICB7DQorICAgIEdCRV9WVF8xMDI0Xzc2OF82MCwNCisgICAg LyoJZmxhZ3MsCXdpZHRoLAkJCWhlaWdodCwJCWZpZWxkc19zZWMsCQljZnJl cSAqLw0KKyAgICAwLAkgICAgMTAyNCwJCQk3NjgsCQk1ODY2MywJCQk2MzU0 OCwNCisgICAgLyoJaHRvdGFsLAloYmxhbmtfc3RhcnQsCWhibGFua19lbmQs CWhzeW5jX3N0YXJ0LAloc3luY19lbmQgKi8NCisgICAgMTM0NCwJMTAyNCwJ CSAgICAxMzQ0LAkJMTA0OCwJCSAgICAxMTg0LA0KKyAgICAvKgl2dG90YWws CXZibGFua19zdGFydCwJdmJsYW5rX2VuZCwJdnN5bmNfc3RhcnQsCXZzeW5j X2VuZCAqLw0KKyAgICA4MDYsCTc2OCwJCSAgICA4MDYsCQk3NzEsCQkgICAg Nzc3LA0KKyAgICAvKglwbGxfbSwJcGxsX24sCQkJcGxsX3AgKi8NCisgICAg MTk3LAkgMzEsCQkJMQ0KKyAgfSwNCisNCisgIHsNCisgICAgR0JFX1ZUXzEw MjRfNzY4Xzc1LA0KKyAgICAvKglmbGFncywJd2lkdGgsCQkJaGVpZ2h0LAkJ ZmllbGRzX3NlYywJCWNmcmVxICovDQorICAgIDAsCSAgICAxMDI0LAkJCTc2 OCwJCTc1MDI5LAkJCTc4NzUwLA0KKyAgICAvKglodG90YWwsCWhibGFua19z dGFydCwJaGJsYW5rX2VuZCwJaHN5bmNfc3RhcnQsCWhzeW5jX2VuZCAqLw0K KyAgICAxMzEyLAkxMDI0LAkJICAgIDEzMTIsCQkxMDQwLAkJICAgIDExMzYs DQorICAgIC8qCXZ0b3RhbCwJdmJsYW5rX3N0YXJ0LAl2YmxhbmtfZW5kLAl2 c3luY19zdGFydCwJdnN5bmNfZW5kICovDQorICAgIDgwMCwJNzY4LAkJICAg IDgwMCwJCTc2OSwJCSAgICA3NzIsDQorICAgIC8qCXBsbF9tLAlwbGxfbiwJ CQlwbGxfcCAqLw0KKyAgICAyNTIsCSAzMiwJCQkxDQorICB9LA0KKw0KKyAg ew0KKyAgICBHQkVfVlRfMTAyNF83NjhfODUsDQorICAgIC8qCWZsYWdzLAl3 aWR0aCwJCQloZWlnaHQsCQlmaWVsZHNfc2VjLAkJY2ZyZXEgKi8NCisgICAg MCwJICAgIDEwMjQsCQkJNzY4LAkJODQ5OTcsCQkJOTQ1MDAsDQorICAgIC8q CWh0b3RhbCwJaGJsYW5rX3N0YXJ0LAloYmxhbmtfZW5kLAloc3luY19zdGFy dCwJaHN5bmNfZW5kICovDQorICAgIDEzNzYsCTEwMjQsCQkgICAgMTM3NiwJ CTEwNzIsCQkgICAgMTE2OCwNCisgICAgLyoJdnRvdGFsLAl2Ymxhbmtfc3Rh cnQsCXZibGFua19lbmQsCXZzeW5jX3N0YXJ0LAl2c3luY19lbmQgKi8NCisg ICAgODA4LAk3NjgsCQkgICAgODA4LAkJNzY5LAkJICAgIDc3MiwNCisgICAg LyoJcGxsX20sCXBsbF9uLAkJCXBsbF9wICovDQorICAgIDE4OSwJIDIwLAkJ CTENCisgIH0sDQorDQorICB7IA0KKyAgICBHQkVfVlRfMTI4MF8xMDI0XzUw LA0KKyAgICAvKglmbGFncywJd2lkdGgsCQkJaGVpZ2h0LAkJZmllbGRzX3Nl YywJCWNmcmVxICovDQorICAgIDAsCSAgICAxMjgwLAkJCTEwMjQsCQk1MDAw MCwJCQk4OTU0NCwNCisgICAgLyoJaHRvdGFsLAloYmxhbmtfc3RhcnQsCWhi bGFua19lbmQsCWhzeW5jX3N0YXJ0LAloc3luY19lbmQgKi8NCisgICAgMTY4 MCwJMTI4MCwJCSAgICAxNjgwLAkJMTM2MCwJCSAgICAxNDgwLA0KKyAgICAv Kgl2dG90YWwsCXZibGFua19zdGFydCwJdmJsYW5rX2VuZCwJdnN5bmNfc3Rh cnQsCXZzeW5jX2VuZCAqLw0KKyAgICAxMDY1LAkxMDI0LAkJICAgIDEwNjUs CQkxMDI3LAkJICAgIDEwMzAsDQorICAgIC8qCXBsbF9tLAlwbGxfbiwJCQlw bGxfcCAqLw0KKyAgICAxOTcsCSAgNDQsCQkJMA0KKyAgfSwNCisNCisgIHsN CisgICAgR0JFX1ZUXzEyODBfMTAyNF82MCwNCisgICAgLyoJZmxhZ3MsCXdp ZHRoLAkJCWhlaWdodCwJCWZpZWxkc19zZWMsCQljZnJlcSAqLw0KKyAgICAw LAkgICAgMTI4MCwJCQkxMDI0LAkJNTk5MTYsCQkJMTA3MjcyLA0KKyAgICAv KglodG90YWwsCWhibGFua19zdGFydCwJaGJsYW5rX2VuZCwJaHN5bmNfc3Rh cnQsCWhzeW5jX2VuZCAqLw0KKyAgICAxNjg4LAkxMjgwLAkJICAgIDE2ODgs CQkxMzI4LAkJICAgIDE0NDAsDQorICAgIC8qCXZ0b3RhbCwJdmJsYW5rX3N0 YXJ0LAl2YmxhbmtfZW5kLAl2c3luY19zdGFydCwJdnN5bmNfZW5kICovDQor ICAgIDEwNjYsCTEwMjQsCQkgICAgMTA2NiwJCTEwMjUsCQkgICAgMTAyOCwN CisgICAgLyoJcGxsX20sCXBsbF9uLAkJCXBsbF9wICovDQorICAgIDE3Nywg ICAgICAgMzMsCQkJMA0KKyAgfSwNCisNCisgIHsNCisgICAgR0JFX1ZUXzEy ODBfMTAyNF83NSwNCisgICAgLyoJZmxhZ3MsCXdpZHRoLAkJCWhlaWdodCwJ CWZpZWxkc19zZWMsCQljZnJlcSAqLw0KKyAgICAwLAkgICAgMTI4MCwJCQkx MDI0LAkJNzUwMjUsCQkJMTM1MDAwLA0KKyAgICAvKglodG90YWwsCWhibGFu a19zdGFydCwJaGJsYW5rX2VuZCwJaHN5bmNfc3RhcnQsCWhzeW5jX2VuZCAq Lw0KKyAgICAxNjg4LAkxMjgwLAkJICAgIDE2ODgsCQkxMjk2LAkJICAgIDE0 NDAsDQorICAgIC8qCXZ0b3RhbCwJdmJsYW5rX3N0YXJ0LAl2YmxhbmtfZW5k LAl2c3luY19zdGFydCwJdnN5bmNfZW5kICovDQorICAgIDEwNjYsCTEwMjQs CQkgICAgMTA2NiwJCTEwMjUsCQkgICAgMTAyOCwNCisgICAgLyoJcGxsX20s CXBsbF9uLAkJCXBsbF9wICovDQorICAgIDIxNiwJICAzMiwJCQkwDQorICB9 LA0KKw0KKyAgew0KKyAgICBHQkVfVlRfMTI4MF8xMDI0Xzg1LA0KKyAgICAv KglmbGFncywJd2lkdGgsCQkgICAgaGVpZ2h0LAkJZmllbGRzX3NlYywJICAg IGNmcmVxICovDQorICAgIDAsCSAgICAxMjgwLAkJICAgIDEwMjQsCQk4NTAy NCwJCSAgICAxNTc1MDAsDQorICAgIC8qCWh0b3RhbCwJaGJsYW5rX3N0YXJ0 LAloYmxhbmtfZW5kLAloc3luY19zdGFydCwJaHN5bmNfZW5kICovDQorICAg IDE3MjgsCTEyODAsCQkgICAgMTcyOCwJCTEzNDQsCQkgICAgMTUwNCwNCisg ICAgLyoJdnRvdGFsLAl2Ymxhbmtfc3RhcnQsCXZibGFua19lbmQsCXZzeW5j X3N0YXJ0LAl2c3luY19lbmQgKi8NCisgICAgMTA3MiwJMTAyNCwJCSAgICAx MDcyLAkJMTAyNSwJCSAgICAxMDI4LA0KKyAgICAvKglwbGxfbSwJcGxsX24s CQkgICAgcGxsX3AgKi8NCisgICAgNjMsCSAgICAgICAgICAgOCwJCSAgICAg ICAgMA0KKyAgfSwNCisNCisgIHsNCisgICAgR0JFX1ZUXzE2MDBfMTAyNF82 MCwNCisgICAgLyogZmxhZ3MsCQkJCQl3aWR0aCwgICAgICAgICAgaGVpZ2h0 LAkJCWZpZWxkc19zZWMsICAgICBjZnJlcSAqLw0KKyAgICBHQkVfVk9GX0ZM QVRQQU5FTCwgICAxNjAwLCAgICAgICAgICAgMTAyNCwJCQk2MDAwMCwgICAg ICAgICAgMTYyOTI1LA0KKyAgICAvKiBodG90YWwsIGhibGFua19zdGFydCwg ICBoYmxhbmtfZW5kLCAgICAgaHN5bmNfc3RhcnQsICAgIGhzeW5jX2VuZCAq Lw0KKyAgICAxNjcwLCAgIDE2MDAsICAgICAgICAgICAxNjcwLCAgICAgICAg ICAgMTYzMCwgICAgICAgICAgIDE2NTAsDQorICAgIC8qIHZ0b3RhbCwgdmJs YW5rX3N0YXJ0LCAgIHZibGFua19lbmQsICAgICB2c3luY19zdGFydCwgICAg dnN5bmNfZW5kICovDQorICAgIDEwNjcsICAgMTAyNCwgICAgICAgICAgIDEw NjcsICAgICAgICAgICAxMDI3LCAgICAgICAgICAgMTAzMCwNCisgICAgLyog cGxsX20sICBwbGxfbiwgICAgICAgICAgcGxsX3AgKi8NCisgICAgMjI0LCAg ICAgIDI3LCAgICAgICAgICAgICAgMA0KKyAgfSwNCisNCisgIHsNCisgICAg R0JFX1ZUXzE2MDBfMTIwMF82MCwNCisgICAgLyogZmxhZ3MsICB3aWR0aCwg ICAgICAgICAgaGVpZ2h0LCAgICAgICAgIGZpZWxkc19zZWMsICAgICBjZnJl cSAqLw0KKyAgICAwLCAgICAgIDE2MDAsICAgICAgICAgICAxMjAwLCAgICAg ICAgICAgNTk5NDAsICAgICAgICAgIDE2MjAwMCwNCisgICAgLyogaHRvdGFs LCBoYmxhbmtfc3RhcnQsICAgaGJsYW5rX2VuZCwgICAgIGhzeW5jX3N0YXJ0 LCAgICBoc3luY19lbmQgKi8NCisgICAgMjE2MCwgICAxNjAwLCAgICAgICAg ICAgMjE2MCwgICAgICAgICAgIDE2NDQsICAgICAgICAgICAxODU2LA0KKyAg ICAvKiB2dG90YWwsIHZibGFua19zdGFydCwgICB2YmxhbmtfZW5kLCAgICAg dnN5bmNfc3RhcnQsICAgIHZzeW5jX2VuZCAqLw0KKyAgICAxMjUwLCAgIDEy MDAsICAgICAgICAgICAxMjUwLCAgICAgICAgICAgMTIwMSwgICAgICAgICAg IDEyMDQsDQorICAgIC8qIHBsbF9tLCAgcGxsX24sICAgICAgICAgIHBsbF9w ICovDQorICAgICA4MSwgICAgICAxMCwgICAgICAgICAgICAgMA0KKyAgfSwN CisNCisgIHsNCisgICAgR0JFX1ZUXzE2MDBfMTIwMF83NSwNCisgICAgLyog ZmxhZ3MsICB3aWR0aCwgICAgICAgICAgaGVpZ2h0LCAgICAgICAgIGZpZWxk c19zZWMsICAgICBjZnJlcSAqLw0KKyAgICAwLCAgICAgIDE2MDAsICAgICAg ICAgICAxMjAwLCAgICAgICAgICAgNzUwMDAsICAgICAgICAgIDIwMjUwMCwN CisgICAgLyogaHRvdGFsLCBoYmxhbmtfc3RhcnQsICAgaGJsYW5rX2VuZCwg ICAgIGhzeW5jX3N0YXJ0LCAgICBoc3luY19lbmQgKi8NCisgICAgMjE2MCwg ICAxNjAwLCAgICAgICAgICAgMjE2MCwgICAgICAgICAgIDE2NDQsICAgICAg ICAgICAxODU2LA0KKyAgICAvKiB2dG90YWwsIHZibGFua19zdGFydCwgICB2 YmxhbmtfZW5kLCAgICAgdnN5bmNfc3RhcnQsICAgIHZzeW5jX2VuZCAqLw0K KyAgICAxMjUwLCAgIDEyMDAsICAgICAgICAgICAxMjUwLCAgICAgICAgICAg MTIwMSwgICAgICAgICAgIDEyMDQsDQorICAgIC8qIHBsbF9tLCAgcGxsX24s ICAgICAgICAgIHBsbF9wICovDQorICAgICA4MSwgICAgICAgOCwgICAgICAg ICAgICAgIDANCisgIH0sDQorDQorICB7DQorICAgIEdCRV9WVF8xOTIwXzEw ODBfNjAsDQorICAgIC8qIGZsYWdzLCAgd2lkdGgsICAgICAgICAgIGhlaWdo dCwgICAgICAgICBmaWVsZHNfc2VjLCAgICAgY2ZyZXEgKi8NCisgICAgMCwg ICAgICAxOTIwLCAgICAgICAgICAgMTA4MCwgICAgICAgICAgIDYwMDYwLCAg ICAgICAgICAxNjAwMDAsDQorICAgIC8qIGh0b3RhbCwgaGJsYW5rX3N0YXJ0 LCAgIGhibGFua19lbmQsICAgICBoc3luY19zdGFydCwgICAgaHN5bmNfZW5k ICovDQorICAgIDIzNjgsICAgMTkyMCwgICAgICAgICAgIDIzNjgsICAgICAg ICAgICAxOTUyLCAgICAgICAgICAgMjA5NiwNCisgICAgLyogdnRvdGFsLCB2 Ymxhbmtfc3RhcnQsICAgdmJsYW5rX2VuZCwgICAgIHZzeW5jX3N0YXJ0LCAg ICB2c3luY19lbmQgKi8NCisgICAgMTEyNSwgICAxMDgwLCAgICAgICAgICAg MTEyNSwgICAgICAgICAgIDEwODMsICAgICAgICAgICAxMDg2LA0KKyAgICAv KiBwbGxfbSwgIHBsbF9uLCAgICAgICAgICBwbGxfcCAqLw0KKyAgICA4LCAg ICAgIDEsICAgICAgICAgICAgICAwDQorICB9LA0KK307DQorDQorI2RlZmlu ZSBHQkVfVlRfU0laRSAgKHNpemVvZihnYmVWVGltaW5ncykvc2l6ZW9mKGdi ZVZUaW1pbmdzWzBdKSkNCisjZW5kaWYgLy8gSU5DTFVERV9USU1JTkdfVEFC TEVfREFUQQ0KKw0KKyNlbmRpZiAvLyAhIF9fU0dJTzJGQl9IX18NCiANCg== --279724308-1159884594-1021594554=:25304 Content-Type: TEXT/plain; name="linux-mips64-r4k_icache.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-mips64-r4k_icache.diff" ZGlmZiAtTmF1ciAvc2hhcmUvbGludXguY3ZzL2FyY2gvbWlwczY0L21tL2xv YWRtbXUuYyBsaW51eC5wYXRjaGVkL2FyY2gvbWlwczY0L21tL2xvYWRtbXUu Yw0KLS0tIC9zaGFyZS9saW51eC5jdnMvYXJjaC9taXBzNjQvbW0vbG9hZG1t dS5jCVN1biBNYXIgIDMgMTk6NTA6MzkgMjAwMg0KKysrIGxpbnV4LnBhdGNo ZWQvYXJjaC9taXBzNjQvbW0vbG9hZG1tdS5jCVRodSBNYXkgMTYgMjM6MTI6 MjEgMjAwMg0KQEAgLTMwLDExICszMCwxNCBAQA0KIHZvaWQgKCpfZmx1c2hf Y2FjaGVfcGFnZSkoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsIHVuc2ln bmVkIGxvbmcgcGFnZSk7DQogdm9pZCAoKl9mbHVzaF9wYWdlX3RvX3JhbSko c3RydWN0IHBhZ2UgKiBwYWdlKTsNCiANCit2b2lkICgqX2ZsdXNoX2ljYWNo ZV9yYW5nZSkodW5zaWduZWQgbG9uZyBzdGFydCwgdW5zaWduZWQgbG9uZyBl bmQpOw0KK3ZvaWQgKCpfZmx1c2hfaWNhY2hlX3BhZ2UpKHN0cnVjdCB2bV9h cmVhX3N0cnVjdCAqdm1hLCBzdHJ1Y3QgcGFnZSAqcGFnZSk7DQordm9pZCAo Kl9mbHVzaF9pY2FjaGVfYWxsKSh2b2lkKTsNCisNCiAvKiBNSVBTIHNwZWNp ZmljIGNhY2hlIG9wZXJhdGlvbnMgKi8NCiB2b2lkICgqX2ZsdXNoX2NhY2hl X3NpZ3RyYW1wKSh1bnNpZ25lZCBsb25nIGFkZHIpOw0KIHZvaWQgKCpfZmx1 c2hfY2FjaGVfbDIpKHZvaWQpOw0KIHZvaWQgKCpfZmx1c2hfY2FjaGVfbDEp KHZvaWQpOw0KLQ0KIA0KIC8qIERNQSBjYWNoZSBvcGVyYXRpb25zLiAqLw0K IHZvaWQgKCpfZG1hX2NhY2hlX3diYWNrX2ludikodW5zaWduZWQgbG9uZyBz dGFydCwgdW5zaWduZWQgbG9uZyBzaXplKTsNCmRpZmYgLU5hdXIgL3NoYXJl L2xpbnV4LmN2cy9hcmNoL21pcHM2NC9tbS9yNHh4MC5jIGxpbnV4LnBhdGNo ZWQvYXJjaC9taXBzNjQvbW0vcjR4eDAuYw0KLS0tIC9zaGFyZS9saW51eC5j dnMvYXJjaC9taXBzNjQvbW0vcjR4eDAuYwlTdW4gTWF5ICA1IDE1OjAzOjE3 IDIwMDINCisrKyBsaW51eC5wYXRjaGVkL2FyY2gvbWlwczY0L21tL3I0eHgw LmMJVGh1IE1heSAxNiAyMzowNTo1MyAyMDAyDQpAQCAtMTYyMSw2ICsxNjIx LDM0IEBADQogCWJsYXN0X2RjYWNoZTMyX3BhZ2UoKHVuc2lnbmVkIGxvbmcp cGFnZV9hZGRyZXNzKHBhZ2UpKTsNCiB9DQogDQorc3RhdGljIHZvaWQNCity NGtfZmx1c2hfaWNhY2hlX3JhbmdlKHVuc2lnbmVkIGxvbmcgc3RhcnQsIHVu c2lnbmVkIGxvbmcgZW5kKQ0KK3sNCisJZmx1c2hfY2FjaGVfYWxsKCk7DQor fQ0KKw0KK3N0YXRpYyB2b2lkDQorcjRrX2ZsdXNoX2ljYWNoZV9wYWdlX3Mo c3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsIHN0cnVjdCBwYWdlICpwYWdl KQ0KK3sNCisJLyoNCisJICogV2UgZGlkIGFuIHNjYWNoZSBmbHVzaCB0aGVy ZWZvcmUgUEkgaXMgYWxyZWFkeSBjbGVhbi4NCisJICovDQorfQ0KKw0KKy8q DQorICogT2ssIHRoaXMgc2VyaW91c2x5IHN1Y2tzLiAgV2UgdXNlIHRoZW0g dG8gZmx1c2ggYSB1c2VyIHBhZ2UgYnV0IGRvbid0DQorICoga25vdyB0aGUg dmlydHVhbCBhZGRyZXNzLCBzbyB3ZSBoYXZlIHRvIGJsYXN0IGF3YXkgdGhl IHdob2xlIGljYWNoZQ0KKyAqIHdoaWNoIGlzIHNpZ25pZmljYW50bHkgbW9y ZSBleHBlbnNpdmUgdGhhbiB0aGUgcmVhbCB0aGluZy4NCisgKi8NCitzdGF0 aWMgdm9pZA0KK3I0a19mbHVzaF9pY2FjaGVfcGFnZV9wKHN0cnVjdCB2bV9h cmVhX3N0cnVjdCAqdm1hLCBzdHJ1Y3QgcGFnZSAqcGFnZSkNCit7DQorCWlm ICghKHZtYS0+dm1fZmxhZ3MgJiBWTV9FWEVDKSkNCisJCXJldHVybjsNCisN CisJZmx1c2hfY2FjaGVfYWxsKCk7DQorfQ0KKw0KIC8qDQogICogV3JpdGVi YWNrIGFuZCBpbnZhbGlkYXRlIHRoZSBwcmltYXJ5IGNhY2hlIGRjYWNoZSBi ZWZvcmUgRE1BLg0KICAqDQpAQCAtMjExOSw3ICsyMTQ3LDcgQEANCiAJCV9m bHVzaF9wYWdlX3RvX3JhbSA9IHI0a19mbHVzaF9wYWdlX3RvX3JhbV9kMzI7 DQogCQlicmVhazsNCiAJfQ0KLQ0KKwlfZmx1c2hfaWNhY2hlX3BhZ2UgPSBy NGtfZmx1c2hfaWNhY2hlX3BhZ2VfcDsNCiAJX2RtYV9jYWNoZV93YmFja19p bnYgPSByNGtfZG1hX2NhY2hlX3diYWNrX2ludl9wYzsNCiAJX2RtYV9jYWNo ZV93YmFjayA9IHI0a19kbWFfY2FjaGVfd2JhY2s7DQogCV9kbWFfY2FjaGVf aW52ID0gcjRrX2RtYV9jYWNoZV9pbnZfcGM7DQpAQCAtMjIwMSw2ICsyMjI5 LDcgQEANCiAJCV9jb3B5X3BhZ2UgPSByNGtfY29weV9wYWdlX3MxMjg7DQog CQlicmVhazsNCiAJfQ0KKwlfZmx1c2hfaWNhY2hlX3BhZ2UgPSByNGtfZmx1 c2hfaWNhY2hlX3BhZ2VfczsNCiAJX2RtYV9jYWNoZV93YmFja19pbnYgPSBy NGtfZG1hX2NhY2hlX3diYWNrX2ludl9zYzsNCiAJX2RtYV9jYWNoZV93YmFj ayA9IHI0a19kbWFfY2FjaGVfd2JhY2s7DQogCV9kbWFfY2FjaGVfaW52ID0g cjRrX2RtYV9jYWNoZV9pbnZfc2M7DQpAQCAtMjI1Myw2ICsyMjgyLDcgQEAN CiAJaWYgKChyZWFkXzMyYml0X2NwMF9yZWdpc3RlcihDUDBfUFJJRCkgJiAw eGZmZjApID09IDB4MjAyMCkgew0KIAkJX2ZsdXNoX2NhY2hlX3NpZ3RyYW1w ID0gcjQ2MDB2MjBrX2ZsdXNoX2NhY2hlX3NpZ3RyYW1wOw0KIAl9DQorCV9m bHVzaF9pY2FjaGVfcmFuZ2UgPSByNGtfZmx1c2hfaWNhY2hlX3JhbmdlOwkv KiBPdWNoICovDQogDQogCV9mbHVzaF9jYWNoZV9sMiA9IHI0a19mbHVzaF9j YWNoZV9sMjsNCiANCmRpZmYgLU5hdXIgL3NoYXJlL2xpbnV4LmN2cy9pbmNs dWRlL2FzbS1taXBzNjQvcGd0YWJsZS5oIGxpbnV4LnBhdGNoZWQvaW5jbHVk ZS9hc20tbWlwczY0L3BndGFibGUuaA0KLS0tIC9zaGFyZS9saW51eC5jdnMv aW5jbHVkZS9hc20tbWlwczY0L3BndGFibGUuaAlTdW4gTWF5ICA1IDE1OjAz OjM5IDIwMDINCisrKyBsaW51eC5wYXRjaGVkL2luY2x1ZGUvYXNtLW1pcHM2 NC9wZ3RhYmxlLmgJVGh1IE1heSAxNiAyMzowMTo0NiAyMDAyDQpAQCAtNjAs MTIgKzYwLDIyIEBADQogDQogI2Vsc2UNCiANCitleHRlcm4gdm9pZCAoKl9m bHVzaF9pY2FjaGVfYWxsKSh2b2lkKTsNCitleHRlcm4gdm9pZCAoKl9mbHVz aF9pY2FjaGVfcmFuZ2UpKHVuc2lnbmVkIGxvbmcgc3RhcnQsIHVuc2lnbmVk IGxvbmcgZW5kKTsNCitleHRlcm4gdm9pZCAoKl9mbHVzaF9pY2FjaGVfcGFn ZSkoc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsIHN0cnVjdCBwYWdlICpw YWdlKTsNCisNCiAjZGVmaW5lIGZsdXNoX2NhY2hlX21tKG1tKQkJX2ZsdXNo X2NhY2hlX21tKG1tKQ0KICNkZWZpbmUgZmx1c2hfY2FjaGVfcmFuZ2UobW0s c3RhcnQsZW5kKQlfZmx1c2hfY2FjaGVfcmFuZ2UobW0sc3RhcnQsZW5kKQ0K ICNkZWZpbmUgZmx1c2hfY2FjaGVfcGFnZSh2bWEscGFnZSkJX2ZsdXNoX2Nh Y2hlX3BhZ2Uodm1hLCBwYWdlKQ0KICNkZWZpbmUgZmx1c2hfcGFnZV90b19y YW0ocGFnZSkJCV9mbHVzaF9wYWdlX3RvX3JhbShwYWdlKQ0KICNkZWZpbmUg Zmx1c2hfaWNhY2hlX3JhbmdlKHN0YXJ0LCBlbmQpCV9mbHVzaF9pY2FjaGVf cmFuZ2Uoc3RhcnQsIGVuZCkNCiAjZGVmaW5lIGZsdXNoX2ljYWNoZV9wYWdl KHZtYSwgcGFnZSkJX2ZsdXNoX2ljYWNoZV9wYWdlKHZtYSwgcGFnZSkNCisj aWZkZWYgQ09ORklHX1ZUQUdfSUNBQ0hFDQorI2RlZmluZSBmbHVzaF9pY2Fj aGVfYWxsKCkJCV9mbHVzaF9pY2FjaGVfYWxsKCkNCisjZWxzZQ0KKyNkZWZp bmUgZmx1c2hfaWNhY2hlX2FsbCgpCQlkbyB7IH0gd2hpbGUoMCkNCisjZW5k aWYNCisNCiANCiAjZW5kaWYgLyogIUNPTkZJR19DUFVfUjEwMDAwICovDQog DQo= --279724308-1159884594-1021594554=:25304-- From owner-linux-mips@oss.sgi.com Tue May 21 01:11:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4L8BgnC028752 for ; Tue, 21 May 2002 01:11:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4L8BgSx028751 for linux-mips-outgoing; Tue, 21 May 2002 01:11:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4L8BbnC028748 for ; Tue, 21 May 2002 01:11:37 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id BAA09440; Tue, 21 May 2002 01:12:14 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA04846; Tue, 21 May 2002 01:12:14 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4L8CEb12172; Tue, 21 May 2002 10:12:15 +0200 (MEST) Message-ID: <3CEA015E.65E15A1A@mips.com> Date: Tue, 21 May 2002 10:12:14 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ken Aaker CC: linux-mips@oss.sgi.com Subject: Re: Mangled struct hd_driveid with MIPSEB. References: <3CE2C834.2010302@silverbacksystems.com> <3CE3578C.CF29A2D6@mips.com> <3CE3CB16.1040503@silverbacksystems.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I just noticed that Ralf hadn't merged in the full IDE patch I send, so that's why it doesn't work for you. Ralf has just checked in the rest yesterday, so try check out the latest sources and see if that helps. /Carsten Ken Aaker wrote: > The problem with the difference isn't that it's byte swapped, its that > the byte swapping isn't respecting the data types inside the structure. > It fixes all of the "short" entities, but it re-orders the fields that > happen to be two chars next to each other, and the "shorts" that are > part of the two "ints" for lba capacity and capacity values are in the > wrong order, even though the bytes within the "shorts" are in the right > order. So, when the fixup code in ide.h is run, the values are still wrong. > > old ---- > 0070: 3f0010fc fb000001 80ac7e03 00000704 "?.........~....." > 0080: 03007800 78007800 78000000 00000000 "..x.x.x.x......." > new--- > 0070: 003ffc10 00fb0100 ac80037e 00000407 ".?.........~...." > 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" > > proper--- (after fix up). > 0070: 003f00fb fc100001 037eac80 00000407 ".?.......~......" > 0080: 00030078 00780078 00780000 00000000 "...x.x.x.x......" > > Ken -- _ _ ____ ___ 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 May 21 09:49:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LGnbnC003541 for ; Tue, 21 May 2002 09:49:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LGnbda003540 for linux-mips-outgoing; Tue, 21 May 2002 09:49:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LGnVnC003537 for ; Tue, 21 May 2002 09:49:32 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id B605684F; Tue, 21 May 2002 18:50:22 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 1975C3711D; Tue, 21 May 2002 18:47:30 +0200 (CEST) Date: Tue, 21 May 2002 18:47:30 +0200 From: Florian Lohoff To: Greg Lindahl Cc: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020521164730.GC11618@paradigm.rfc822.org> References: <20020519123059.E20670@dea.linux-mips.net> <20020520085743.A1748@wumpus.keyresearch.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20020520085743.A1748@wumpus.keyresearch.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 20, 2002 at 08:57:44AM -0700, Greg Lindahl wrote: > On Mon, May 20, 2002 at 12:06:45PM +0200, Maciej W. Rozycki wrote: >=20 > > Well, the surprise is going to happen in drivers, I'm afraid... >=20 > Linux drivers as a whole are 64-bit clean; alpha's been around for a > long time. MIPS-only devices might be dirtier. Not really true - I just stumbled over the cyclades multiport driver which says to work on alpha for a long time - But it doesnt on Sparc64 due to the porters misunderstanding on typedefs for the=20 driver internals. (Alpha and i386 are happy with char irqs e.g.). Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --qtZFehHsKgwS5rPz 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 iD8DBQE86nohUaz2rXW+gJcRAksIAKCXalmKjUo17wR6p1b5/SYTEU7TegCfcnvd R1u7ZoovIDJPi19Xro+SOl8= =yye5 -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-linux-mips@oss.sgi.com Tue May 21 09:59:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4LGxXnC003717 for ; Tue, 21 May 2002 09:59:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4LGxX5D003716 for linux-mips-outgoing; Tue, 21 May 2002 09:59:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nixon.xkey.com (nixon.xkey.com [209.245.148.124]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4LGxUnC003708 for ; Tue, 21 May 2002 09:59:30 -0700 Received: (qmail 19387 invoked from network); 21 May 2002 17:00:23 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 21 May 2002 17:00:23 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g4LH0eA02119 for linux-mips@oss.sgi.com; Tue, 21 May 2002 10:00:40 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 21 May 2002 10:00:40 -0700 From: Greg Lindahl To: Linux-MIPS Subject: Re: MIPS 64? Message-ID: <20020521100040.A2103@wumpus.internal.keyresearch.com> Mail-Followup-To: Linux-MIPS References: <20020519123059.E20670@dea.linux-mips.net> <20020520085743.A1748@wumpus.keyresearch.com> <20020521164730.GC11618@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: <20020521164730.GC11618@paradigm.rfc822.org>; from flo@rfc822.org on Tue, May 21, 2002 at 06:47:30PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Tue, May 21, 2002 at 06:47:30PM +0200, Florian Lohoff wrote: > On Mon, May 20, 2002 at 08:57:44AM -0700, Greg Lindahl wrote: > > On Mon, May 20, 2002 at 12:06:45PM +0200, Maciej W. Rozycki wrote: > > > > > Well, the surprise is going to happen in drivers, I'm afraid... > > > > Linux drivers as a whole are 64-bit clean; alpha's been around for a > > long time. MIPS-only devices might be dirtier. > > Not really true - I just stumbled over the cyclades multiport driver > which says to work on alpha for a long time - But it doesnt on > Sparc64 due to the porters misunderstanding on typedefs for the > driver internals. (Alpha and i386 are happy with char irqs e.g.). I must say I find this entire discussion bewildering: one example does not mean that Linux drivers are not "as a whole" 64-bit clean. Another poster thought that things like ISA and Turbochannel devices were a counter-example. Well, no. greg From owner-linux-mips@oss.sgi.com Wed May 22 00:48:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4M7mlnC027679 for ; Wed, 22 May 2002 00:48:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4M7mlc8027678 for linux-mips-outgoing; Wed, 22 May 2002 00:48:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4M7mhnC027675 for ; Wed, 22 May 2002 00:48:43 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id AAA14703 for ; Wed, 22 May 2002 00:49:29 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA13996 for ; Wed, 22 May 2002 00:49:30 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4M7nVb07726 for ; Wed, 22 May 2002 09:49:32 +0200 (MEST) Message-ID: <3CEB4D8C.8BE4CF3A@mips.com> Date: Wed, 22 May 2002 09:49:32 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Does anyone have a 64-bit kernel running ? Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk After fixing a lot of stuff, I finally got a 64-bit kernel up and run on the Malta board. But there are still a lot of things that doesn't work. E.g. the read_rtc routine fails, because a "long" is 64-bit in the kernel and 32-bit in the user application (I run on o32 compiled userland). If I replace all "longs" in the read_rtc routine with "integers" it works fine, but then I will probably break things, once we got a n64 compiled userland. NFS fails because of a checksum errors in some UDP packages. Does anyone have any experience in the 64-bit kernel ? /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 Thu May 23 14:29:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NLTUnC009033 for ; Thu, 23 May 2002 14:29:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NLTUmT009032 for linux-mips-outgoing; Thu, 23 May 2002 14:29:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NLTTnC009029 for ; Thu, 23 May 2002 14:29:29 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4NLUVl03254 for linux-mips@oss.sgi.com; Thu, 23 May 2002 14:30:31 -0700 Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4MN0BnC024315 for ; Wed, 22 May 2002 16:00:11 -0700 Received: from whrrusek (whnat1.weiderpub.com [65.115.104.67]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4MN19v04280 for ; Wed, 22 May 2002 16:01:09 -0700 From: "Robert Rusek" To: Subject: Executing IRIX binary ? Date: Wed, 22 May 2002 16:01:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C201A9.E36C94C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C201A9.E36C94C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there anyway to run/execute irix 5/6 binaries in linux mips on an Indy? Good old Microsoft does not provide the source for it's frontpage extensions, but they do provide a binary for IRIX. Thanks Rob. ------=_NextPart_000_0007_01C201A9.E36C94C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Is there anyway to run/execute irix 5/6 binaries in linux mips = on an=20 Indy?  Good old Microsoft does not provide the source for it's = frontpage=20 extensions, but they do provide a binary for IRIX.
 
Thanks
Rob.
------=_NextPart_000_0007_01C201A9.E36C94C0-- From owner-linux-mips@oss.sgi.com Thu May 23 16:59:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4NNxnnC014645 for ; Thu, 23 May 2002 16:59:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4NNxnSC014644 for linux-mips-outgoing; Thu, 23 May 2002 16:59:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4NNxknC014637 for ; Thu, 23 May 2002 16:59:46 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4NNxRf08207 for linux-mips@oss.sgi.com; Thu, 23 May 2002 16:59:27 -0700 Date: Thu, 23 May 2002 16:59:27 -0700 From: William Jhun To: linux-mips@oss.sgi.com Subject: Re: Please disregard; was: [PATCH] arch/mips/kernel/irq_cpu.c interrupt safety? Message-ID: <20020523165927.I7205@ayrnetworks.com> References: <20020520184151.C26598@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020520184151.C26598@ayrnetworks.com>; from wjhun@ayrnetworks.com on Mon, May 20, 2002 at 06:41:51PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Please disregard this, I jumped the gun on this one. These routines are only ever called from arch/mips/kernel/irq.c, which always safely calls these routines under the irq_desc's spinlock (or in the case of ack(), do_IRQ() is already invoked with interrupts turned off). I'll be sure to grep a little more carefully next time. ;o) Will On Mon, May 20, 2002 at 06:41:51PM -0700, William Jhun wrote: > The mips_cpu_irq_*() routines in arch/mips/kernel/irq_cpu.c seem to not be > safe; {clear,set}_cp0_*() don't provide interrupt safety while changing the cp0 > register. Is this not wrong? Is there a case where an interrupt handler may > change CP0 status? If so, the patch below (against linux_2_4) simply disables > interrupts during these operations. > > Thanks, > Will From owner-linux-mips@oss.sgi.com Fri May 24 05:03:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4OC37nC032333 for ; Fri, 24 May 2002 05:03:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4OC372G032332 for linux-mips-outgoing; Fri, 24 May 2002 05:03:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pat.uio.no (IDENT:7411@pat.uio.no [129.240.130.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4OC34nC032329 for ; Fri, 24 May 2002 05:03:05 -0700 Received: from vetikke.uio.no ([129.240.186.124]) by pat.uio.no with esmtp (Exim 2.12 #7) id 17BDne-0005tF-00; Fri, 24 May 2002 14:04:02 +0200 Received: from hakon by vetikke.uio.no with local (Exim 2.12 #1) id 17BDnd-0005Sm-00; Fri, 24 May 2002 14:04:01 +0200 To: "Robert Rusek" Cc: Subject: Re: Executing IRIX binary ? References: From: hakon@ping.uio.no (Håkon Eriksen) Date: 24 May 2002 14:04:01 +0200 In-Reply-To: "Robert Rusek"'s message of "Wed, 22 May 2002 16:01:07 -0700" Message-ID: <1zl8z6921n2.fsf@vetikke.uio.no> Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Robert Rusek" writes: > Is there anyway to run/execute irix 5/6 binaries in linux mips on an > Indy? Good old Microsoft does not provide the source for it's frontpage > extensions, but they do provide a binary for IRIX. If FrontPage extensions is what you want, there are several ways of getting this to run on linux. Microsoft may not supply the source, but they do show you how to install it on Apache. If this is not what you're looking for, try google. -- - håkon From owner-linux-mips@oss.sgi.com Fri May 24 07:27:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4OERknC006514 for ; Fri, 24 May 2002 07:27:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4OERkh6006513 for linux-mips-outgoing; Fri, 24 May 2002 07:27:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru ([193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4OERRnC006507 for ; Fri, 24 May 2002 07:27:36 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id SAA20739 for ; Fri, 24 May 2002 18:27:19 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id SAA09843 for linux-mips@oss.sgi.com; Fri, 24 May 2002 18:37:52 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id SAA27970 for ; Fri, 24 May 2002 18:10:23 +0400 (MSK) Message-ID: <3CEEBBA9.5070809@niisi.msk.ru> Date: Fri, 24 May 2002 18:16:09 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.17 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: 3 questions about linux-2.4.18 and R3000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, list. I have three little questions with linux-2.4.18 on my machine. My configuration is: MIPS R3000, linux-2.4.18 kernel from CVS, egcs-mips-linux-1.1.2-4 (egcs-2.91.66) and binutils-mips-linux-2.8.1-2 1. When i use MIPS specific arch_get_unmapped_area() function, my kernel hangs. It looks like this: ... Freeing unused kernel memory: 108k freed do_page_fault() #2: sending SIGSEGV to init for illegal read access from 0fb65330 (epc == 0fb65330, ra == 0fb851dc) ... and so on. Last message is printed infinitely. So, i have to give up HAVE_ARCH_UNMAPPED_AREA feature, and to use common arch_get_unmapped_area() routine. 2. There is a strange code in the local_flush_tlb_page() function (tlb-r3k.c and tlb-r4k.c): ... if (!vma || vma->vm_mm->context != 0) { unsigned long flags; int oldpid, newpid, idx; #ifdef DEBUG_TLB printk("[tlbpage<%lu,0x%08lx>]", vma->vm_mm->context, page); #endif newpid = (vma->vm_mm->context & 0xfc0); ^^^^^ Hmm... the kernel will crash if vma ==0. I guess that this code must look like this: if (vma && vma->vm_mm->context !=0) { Is any patches required? 3. I have some problems, when i try to compile latest kernels with my egcs and binutils, such as problems with "__INIT" and "__FINI" assembler macroses: # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c entry.S -o entry.o entry.S: Assembler messages: entry.S:179: Error: .previous without corresponding .section; ignored ... and ".macro" assembler command usage: # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c head.S -o head.o head.S: Assembler messages: head.S:224: Error: .size expression too complicated to fix up head.S:224: Error: .size expression too complicated to fix up head.S:224: Error: .size expression too complicated to fix up head.S:224: Error: .size expression too complicated to fix up make[1]: *** [head.o] Error 1 I know that my binutils are obsolete and so, I tried to use some newer binutils (2.9.5-1, 2.9.5-3), but my kernel crashed :(. Please, can you answer me, what egcs & binutils are suitable for linux-2.4.18 and MIPS R3000 compliant? Any help will be appriciated. From owner-linux-mips@oss.sgi.com Fri May 24 14:29:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4OLTBnC019668 for ; Fri, 24 May 2002 14:29:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4OLTBjG019667 for linux-mips-outgoing; Fri, 24 May 2002 14:29:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4OLSvnC019657 for ; Fri, 24 May 2002 14:28:58 -0700 Received: from av.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 OAA01234 for ; Fri, 24 May 2002 14:29:52 -0700 (PDT) mail_from (jsun@mvista.com) Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA06593; Fri, 24 May 2002 14:12:40 -0700 Message-ID: <3CEEAC5F.6010802@mvista.com> Date: Fri, 24 May 2002 14:10:55 -0700 From: Jun Sun 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: Alexandr Andreev CC: linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 References: <3CEEBBA9.5070809@niisi.msk.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alexandr Andreev wrote: > Hi, list. > I have three little questions with linux-2.4.18 on my machine. > > My configuration is: > MIPS R3000, linux-2.4.18 kernel from CVS, > egcs-mips-linux-1.1.2-4 (egcs-2.91.66) and binutils-mips-linux-2.8.1-2 > > 1. When i use MIPS specific arch_get_unmapped_area() function, my kernel > hangs. It looks like this: > ... > Freeing unused kernel memory: 108k freed > do_page_fault() #2: sending SIGSEGV to init for illegal read access > from 0fb65330 (epc == 0fb65330, ra == 0fb851dc) > ... and so on. Last message is printed infinitely. > > So, i have to give up HAVE_ARCH_UNMAPPED_AREA feature, and to use > common arch_get_unmapped_area() routine. > I took a look of the arch_get_unmapped_area(), and it looks fine to me. Can you try the following changes and let me know what happens? 1) change COLOUR_ALIGN #define COLOUR_ALIGN(addr,pgoff) addr 2) I don't understand why we need color alignment if file is not NULL. (Can someone explain?). So you can try to remove that condition: diff -Nru ./arch/mips/kernel/syscall.c.orig ./arch/mips/kernel/syscall.c --- ./arch/mips/kernel/syscall.c.orig Sat May 11 00:05:34 2002 +++ ./arch/mips/kernel/syscall.c Fri May 24 13:54:47 2002 @@ -77,7 +77,7 @@ if (len > TASK_SIZE) return -ENOMEM; do_color_align = 0; - if (filp || (flags & MAP_SHARED)) + if (flags & MAP_SHARED) do_color_align = 1; if (addr) { if (do_color_align) > 2. There is a strange code in the local_flush_tlb_page() function > (tlb-r3k.c and tlb-r4k.c): > ... > if (!vma || vma->vm_mm->context != 0) { > unsigned long flags; > int oldpid, newpid, idx; > #ifdef DEBUG_TLB > printk("[tlbpage<%lu,0x%08lx>]", vma->vm_mm->context, page); > #endif > newpid = (vma->vm_mm->context & 0xfc0); > ^^^^^ > Hmm... the kernel will crash if vma ==0. I guess that this code must look > like this: > > if (vma && vma->vm_mm->context !=0) { > > Is any patches required? > I think you just found a bug. The fix looks good to me. > 3. I have some problems, when i try to compile latest kernels with my egcs > and binutils, such as problems with "__INIT" and "__FINI" assembler > macroses: > > # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0 > -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c entry.S -o entry.o > entry.S: Assembler messages: > entry.S:179: Error: .previous without corresponding .section; ignored > > ... and ".macro" assembler command usage: > > # mips-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I include -G 0 > -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe -c head.S -o head.o > head.S: Assembler messages: > head.S:224: Error: .size expression too complicated to fix up > head.S:224: Error: .size expression too complicated to fix up > head.S:224: Error: .size expression too complicated to fix up > head.S:224: Error: .size expression too complicated to fix up > make[1]: *** [head.o] Error 1 > > I know that my binutils are obsolete and so, I tried to use some newer > binutils (2.9.5-1, 2.9.5-3), but my kernel crashed :(. Please, can you > answer > me, what egcs & binutils are suitable for linux-2.4.18 and MIPS R3000 > compliant? > We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for quite a while with no problems. It seems newer gcc and binutiles are fine too. Jun From owner-linux-mips@oss.sgi.com Fri May 24 17:05:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4P05tnC021039 for ; Fri, 24 May 2002 17:05:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4P05slD021038 for linux-mips-outgoing; Fri, 24 May 2002 17:05:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.laser5.co.jp (gw1.laser5.co.jp [202.221.8.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4P05jnC021035 for ; Fri, 24 May 2002 17:05:46 -0700 Received: from l5ac192.l5.laser5.co.jp (unknown [192.168.128.192]) by mail.laser5.co.jp (Postfix) with ESMTP id B84D4833A5 for ; Sat, 25 May 2002 09:06:51 +0900 (JST) Date: Sat, 25 May 2002 09:06:52 +0900 Message-ID: From: Kunihiko IMAI To: linux-mips Subject: fail to boot with MTD root fs User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-vine-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I'm using Pb1500 evaluation board and met somewhat serious problem. The problem is that failing to mount FlashROM filesystem as root fs and go into infinite loop without any message. Does anyone have a good (or better) solution? I'm using SGI kernel source tree, linux-2.4.18 of linux_2_4 branch. When booting with nfs root, and using MTD FlashROM fs, it works well. I traced code from init/main.c with printk. It reached at schedule() and go into infinite loop. I also used kernel gdb, but fail to trace. It may be sensible with timing or interrupt. So printk trace may be fake result, too. Some month ago, I ported 2.4.16 kernel to L-Card+, a small VR4181 board. At this time, it can boot with FlashROM root fs. It works well. I compared 2.4.16 and 2.4.18 code. And I found a difference at mount_root(). at 2.4.18: for (p = fs_names; *p; p += strlen(p)+1) { struct file_system_type * fs_type = get_fs_type(p); if (!fs_type) continue; atomic_inc(&bdev->bd_count); retval = blkdev_get(bdev, mode, 0, BDEV_FS); ///// <- /// go into infinite loop at this line if (retval) goto Eio; sb = read_super(ROOT_DEV, bdev, fs_type, root_mountflags, root_mount_data); put_filesystem(fs_type); if (sb) { blkdev_put(bdev, BDEV_FS); goto mount_it; } } panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); at 2.4.16: for (p = fs_names; *p; p += strlen(p)+1) { struct file_system_type * fs_type = get_fs_type(p); if (!fs_type) continue; sb = read_super(ROOT_DEV, bdev, fs_type, root_mountflags, root_mount_data); if (sb) goto mount_it; put_filesystem(fs_type); } panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV)); Reverting this part as 2.4.16, then it can boot. But I'm afraid that this reverting causes another problem... Thanks. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Fri May 24 19:02:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4P22QnC021773 for ; Fri, 24 May 2002 19:02:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4P22QOL021772 for linux-mips-outgoing; Fri, 24 May 2002 19:02:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4P22KnC021768 for ; Fri, 24 May 2002 19:02:20 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020525020323.UCNI11426.rwcrmhc51.attbi.com@ocean.lucon.org>; Sat, 25 May 2002 02:03:23 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 970A5125C2; Fri, 24 May 2002 19:03:22 -0700 (PDT) Date: Fri, 24 May 2002 19:03:22 -0700 From: "H . J . Lu" To: Eric Christopher Cc: cgd@broadcom.com, linux-mips@oss.sgi.com Subject: Re: linux.h patch for mips Message-ID: <20020524190322.C10735@lucon.org> References: <1022278283.25829.46.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1022278283.25829.46.camel@ghostwheel.cygnus.com>; from echristo@redhat.com on Fri, May 24, 2002 at 03:11:23PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I will leave it to the Linux mips people. Any comments? H.J. --- On Fri, May 24, 2002 at 03:11:23PM -0700, Eric Christopher wrote: > Hey, wanted to run this by you. > > I've noticed a tendency for the linux kernel people to test > _MIPS_ISA_MIPSXX when writing defines for 32 v. 64 bit code in the asm > headers (and other places). Personally I'd prefer they check something > else like -D__mips_fpr=32/64, but it's not something I have time to fix > in the kernel right now (and for gpr I'd have to define something new, > which wouldn't be hard). > > Thought I'd check with you and see if you had any other ideas how better > to do that kind of interface? > > -eric > > ps. I'm checking the following patch in momentarily to fix a problem I > noticed. > > -- > I will not carve gods > > Index: linux.h > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/config/mips/linux.h,v > retrieving revision 1.44 > diff -u -p -w -r1.44 linux.h > --- linux.h 20 May 2002 17:11:53 -0000 1.44 > +++ linux.h 24 May 2002 21:56:01 -0000 > @@ -155,6 +155,8 @@ void FN () \ > %{mips2: -D_MIPS_ISA=_MIPS_ISA_MIPS2} \ > %{mips3: -D_MIPS_ISA=_MIPS_ISA_MIPS3} \ > %{mips4: -D_MIPS_ISA=_MIPS_ISA_MIPS4} \ > +%{mips32: -D_MIPS_ISA=_MIPS_ISA_MIPS32} \ > +%{mips64: -D_MIPS_ISA=_MIPS_ISA_MIPS64} \ > %{!mips*: -D_MIPS_ISA=_MIPS_ISA_MIPS1} \ > %{mabi=32: -D_MIPS_SIM=_MIPS_SIM_ABI32} \ > %{mabi=n32: -D_ABIN32=2 -D_MIPS_SIM=_ABIN32} \ From owner-linux-mips@oss.sgi.com Sat May 25 00:26:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4P7QHnC029012 for ; Sat, 25 May 2002 00:26:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4P7QHKK029011 for linux-mips-outgoing; Sat, 25 May 2002 00:26:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4P7QFnC029008 for ; Sat, 25 May 2002 00:26:15 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4P7RNu27344; Sat, 25 May 2002 00:27:23 -0700 Date: Sat, 25 May 2002 00:27:23 -0700 From: Ralf Baechle To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? Message-ID: <20020525002723.A27302@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rrusek@teknuts.com on Wed, May 22, 2002 at 04:01:07PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 22, 2002 at 04:01:07PM -0700, Robert Rusek wrote: > Is there anyway to run/execute irix 5/6 binaries in linux mips on an > Indy? Good old Microsoft does not provide the source for it's frontpage > extensions, but they do provide a binary for IRIX. We have IRIX5 binary compatibility code in the kernel but I don't have any reports about it's status ever since I integrated those patch in about May '97. Ralf From owner-linux-mips@oss.sgi.com Sat May 25 06:57:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PDv6nC002104 for ; Sat, 25 May 2002 06:57:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PDv6kW002103 for linux-mips-outgoing; Sat, 25 May 2002 06:57:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PDuvnC002099 for ; Sat, 25 May 2002 06:56:59 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17Bc3U-0004dF-00 for ; Sat, 25 May 2002 08:58:00 -0500 Message-ID: <3CEF9850.3020300@realitydiluted.com> Date: Sat, 25 May 2002 08:57:36 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020520 Debian/1.0rc2-3 MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Removal of unneeded cache routines for NEC 5432... Content-Type: multipart/mixed; boundary="------------020609040304070502060603" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------020609040304070502060603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This patch removes to unused cache routines. Please apply. -Steve --------------020609040304070502060603 Content-Type: text/plain; name="mips-5432remove.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mips-5432remove.diff" diff -urN -X cvs-exc.txt mipslinux-2.4.18-xfs/arch/mips/mm/c-r5432.c settop/arch/mips/mm/c-r5432.c --- mipslinux-2.4.18-xfs/arch/mips/mm/c-r5432.c Fri Nov 30 07:28:06 2001 +++ settop/arch/mips/mm/c-r5432.c Wed Jan 30 11:09:47 2002 @@ -42,34 +42,6 @@ /* -------------------------------------------------------------------- */ /* #include */ -static inline void flush_icache_line_indexed(unsigned long addr) -{ - __asm__ __volatile__( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache %1, (%0)\n\t" - "cache %1, 1(%0)\n\t" - ".set mips0\n\t" - ".set reorder" - : - : "r" (addr), - "i" (Index_Invalidate_I)); -} - -static inline void flush_dcache_line_indexed(unsigned long addr) -{ - __asm__ __volatile__( - ".set noreorder\n\t" - ".set mips3\n\t" - "cache %1, (%0)\n\t" - "cache %1, 1(%0)\n\t" - ".set mips0\n\t" - ".set reorder" - : - : "r" (addr), - "i" (Index_Writeback_Inv_D)); -} - static inline void flush_icache_line(unsigned long addr) { __asm__ __volatile__( --------------020609040304070502060603-- From owner-linux-mips@oss.sgi.com Sat May 25 10:52:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PHqlnC003748 for ; Sat, 25 May 2002 10:52:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PHqlMl003747 for linux-mips-outgoing; Sat, 25 May 2002 10:52:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PHqcnC003736 for ; Sat, 25 May 2002 10:52:38 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17BfjS-0004pl-00; Sat, 25 May 2002 12:53:34 -0500 Message-ID: <3CEFCF86.5060401@realitydiluted.com> Date: Sat, 25 May 2002 12:53:10 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020520 Debian/1.0rc2-3 MIME-Version: 1.0 To: Kunihiko IMAI CC: linux-mips Subject: Re: fail to boot with MTD root fs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Kunihiko IMAI wrote: > Hi, > > I'm using Pb1500 evaluation board and met somewhat serious problem. > The problem is that failing to mount FlashROM filesystem as root fs > and go into infinite loop without any message. Does anyone have a > good (or better) solution? > > I'm using SGI kernel source tree, linux-2.4.18 of linux_2_4 branch. > > When booting with nfs root, and using MTD FlashROM fs, it works well. > There was a bug in 2.4.18 with respect to the MTD code and using flash as a root filesystem. It had to do with the MTD block devices. Make the changes below and things will work again. -Steve Index: mtdblock.c =================================================================== RCS file: /data/cvs/settop/drivers/mtd/mtdblock.c,v retrieving revision 1.6 diff -u -r1.6 mtdblock.c --- mtdblock.c 9 May 2002 13:35:40 -0000 1.6 +++ mtdblock.c 25 May 2002 16:52:14 -0000 @@ -371,8 +371,6 @@ if (inode == NULL) release_return(-ENODEV); - invalidate_device(inode->i_rdev, 1); - dev = MINOR(inode->i_rdev); mtdblk = mtdblks[dev]; Index: mtdblock_ro.c =================================================================== RCS file: /data/cvs/settop/drivers/mtd/mtdblock_ro.c,v retrieving revision 1.2 diff -u -r1.2 mtdblock_ro.c --- mtdblock_ro.c 3 Jan 2002 17:19:58 -0000 1.2 +++ mtdblock_ro.c 25 May 2002 16:53:01 -0000 @@ -79,8 +79,6 @@ if (inode == NULL) release_return(-ENODEV); - invalidate_device(inode->i_rdev, 1); - dev = MINOR(inode->i_rdev); mtd = __get_mtd_device(NULL, dev); From owner-linux-mips@oss.sgi.com Sat May 25 11:13:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PIDGnC003969 for ; Sat, 25 May 2002 11:13:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PIDGwU003968 for linux-mips-outgoing; Sat, 25 May 2002 11:13:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PID9nC003965 for ; Sat, 25 May 2002 11:13:10 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17Bg2a-0006Bq-00; Sat, 25 May 2002 20:13:20 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17Bg3I-0000AD-00; Sat, 25 May 2002 20:14:04 +0200 Date: Sat, 25 May 2002 20:14:04 +0200 To: "H . J . Lu" Cc: Eric Christopher , cgd@broadcom.com, linux-mips@oss.sgi.com Subject: Re: linux.h patch for mips Message-ID: <20020525181404.GI21557@rembrandt.csv.ica.uni-stuttgart.de> References: <1022278283.25829.46.camel@ghostwheel.cygnus.com> <20020524190322.C10735@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020524190322.C10735@lucon.org> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk H . J . Lu wrote: > I will leave it to the Linux mips people. Any comments? > > > H.J. > --- > On Fri, May 24, 2002 at 03:11:23PM -0700, Eric Christopher wrote: > > Hey, wanted to run this by you. > > > > I've noticed a tendency for the linux kernel people to test > > _MIPS_ISA_MIPSXX when writing defines for 32 v. 64 bit code in the asm > > headers (and other places). Personally I'd prefer they check something > > else like -D__mips_fpr=32/64, but it's not something I have time to fix > > in the kernel right now (and for gpr I'd have to define something new, > > which wouldn't be hard). > > > > Thought I'd check with you and see if you had any other ideas how better > > to do that kind of interface? > > > > -eric > > > > ps. I'm checking the following patch in momentarily to fix a problem I > > noticed. > > > > -- > > I will not carve gods > > > > Index: linux.h > > =================================================================== > > RCS file: /cvs/gcc/gcc/gcc/config/mips/linux.h,v > > retrieving revision 1.44 > > diff -u -p -w -r1.44 linux.h > > --- linux.h 20 May 2002 17:11:53 -0000 1.44 > > +++ linux.h 24 May 2002 21:56:01 -0000 > > @@ -155,6 +155,8 @@ void FN () \ > > %{mips2: -D_MIPS_ISA=_MIPS_ISA_MIPS2} \ > > %{mips3: -D_MIPS_ISA=_MIPS_ISA_MIPS3} \ > > %{mips4: -D_MIPS_ISA=_MIPS_ISA_MIPS4} \ At least for completeness there should be also _MIPS_ISA_MIPS5 (the -mips5 swich would cause _MIPS_ISA_MIPS1 otherwise). > > +%{mips32: -D_MIPS_ISA=_MIPS_ISA_MIPS32} \ > > +%{mips64: -D_MIPS_ISA=_MIPS_ISA_MIPS64} \ > > %{!mips*: -D_MIPS_ISA=_MIPS_ISA_MIPS1} \ > > %{mabi=32: -D_MIPS_SIM=_MIPS_SIM_ABI32} \ > > %{mabi=n32: -D_ABIN32=2 -D_MIPS_SIM=_ABIN32} \ From owner-linux-mips@oss.sgi.com Sat May 25 12:05:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PJ5HnC004287 for ; Sat, 25 May 2002 12:05:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PJ5Gqb004286 for linux-mips-outgoing; Sat, 25 May 2002 12:05:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PJ59nC004283; Sat, 25 May 2002 12:05:09 -0700 Received: from sohotower (adsl-66.218.38.74.dslextreme.com [66.218.38.74]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4PJ6Kv02117; Sat, 25 May 2002 12:06:20 -0700 From: "robru" To: "'Ralf Baechle'" Cc: Subject: RE: Executing IRIX binary ? Date: Sat, 25 May 2002 12:06:29 -0700 Message-ID: <000701c2041f$4d2ae7f0$0a01a8c0@sohotower> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20020525002723.A27302@dea.linux-mips.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf, How can I find out if I compiled my kernel with the compatibility code? Thanks, Robert. -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com] On Behalf Of Ralf Baechle Sent: Saturday, May 25, 2002 12:27 AM To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? On Wed, May 22, 2002 at 04:01:07PM -0700, Robert Rusek wrote: > Is there anyway to run/execute irix 5/6 binaries in linux mips on an > Indy? Good old Microsoft does not provide the source for it's > frontpage extensions, but they do provide a binary for IRIX. We have IRIX5 binary compatibility code in the kernel but I don't have any reports about it's status ever since I integrated those patch in about May '97. Ralf From owner-linux-mips@oss.sgi.com Sat May 25 12:12:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PJCrnC004392 for ; Sat, 25 May 2002 12:12:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PJCrkf004391 for linux-mips-outgoing; Sat, 25 May 2002 12:12:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PJConC004388 for ; Sat, 25 May 2002 12:12:51 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17Bgz6-0004w0-00; Sat, 25 May 2002 14:13:48 -0500 Message-ID: <3CEFE253.4090107@realitydiluted.com> Date: Sat, 25 May 2002 14:13:23 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020520 Debian/1.0rc2-3 MIME-Version: 1.0 To: robru CC: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? References: <000701c2041f$4d2ae7f0$0a01a8c0@sohotower> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk robru wrote: > > How can I find out if I compiled my kernel with the compatibility code? > I don't mean to be critical, but read the code. If you look in the 'arch/mips/config.in' file you will find: if [ "$CONFIG_CPU_LITTLE_ENDIAN" = "n" ]; then bool 'Include IRIX binary compatibility' CONFIG_BINFMT_IRIX bool 'Include forward keyboard' CONFIG_FORWARD_KEYBOARD fi at around line #522. You have to be a big endian machine since IRIX is itself a big endian operating system. This option is under the menu 'General setup'. -S From owner-linux-mips@oss.sgi.com Sat May 25 12:42:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PJghnC004576 for ; Sat, 25 May 2002 12:42:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PJgg9L004575 for linux-mips-outgoing; Sat, 25 May 2002 12:42:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PJgenC004572 for ; Sat, 25 May 2002 12:42:40 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17BhS0-0004wE-00; Sat, 25 May 2002 14:43:40 -0500 Message-ID: <3CEFE954.9090303@realitydiluted.com> Date: Sat, 25 May 2002 14:43:16 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020520 Debian/1.0rc2-3 MIME-Version: 1.0 To: Robert Rusek CC: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? References: <000701c20420$cc5ce5e0$0a01a8c0@sohotower> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Robert Rusek wrote: > > Thamk you for your reply, but I meant if I did not have the original > source. Is there anyway to tell from the binary? > If your kernel hasn't been stripped, you could use 'nm' or 'readelf' and look for 'irix' symbols. The second option is to try a SGI system call number and see if the kernel tells you if that is a valid system call or not. -S From owner-linux-mips@oss.sgi.com Sat May 25 13:18:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PKIqnC004833 for ; Sat, 25 May 2002 13:18:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PKIqLD004832 for linux-mips-outgoing; Sat, 25 May 2002 13:18:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PKIPnC004824; Sat, 25 May 2002 13:18:25 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4PKI6Y04077; Sat, 25 May 2002 13:18:06 -0700 Date: Sat, 25 May 2002 13:18:06 -0700 From: William Jhun To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com, davem@redhat.com Subject: [PATCH] include/asm-mips/pci.h: More optimal cache behavior, added "prep" routines Message-ID: <20020525131806.A4073@ayrnetworks.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 This patch (against latest linux_2_4 oss tree) makes several optimizations for pci_map_*() and pci_dma_sync_*() routines, as well as adds an extention to the interface that allows a driver to prepare a buffer for a DMA transfer after having intercepted it with pci_dma_sync_*(). These calls, pci_dma_prep_{sg,single}, are useful in cases where one wants to reuse a buffer for DMAing to a device without having to unmap/map it again. They essentially should do what pci_map_*() should do except for setting up the mapping itself. (On other architectures, this might involve something like copying to a bounce buffer or the like...) When preparing a buffer for a DMA transfer, we've found it's more optimal to only do a wback_inv if the direction is not known (PCIDMA_BIDIRECTIONAL), only a wback if transfer is to the device (PCIDMA_TO_DEVICE), and only an invalidate if from the device (PCIDMA_FROM_DEVICE). Such a modification has made a small (yet significant) improvement for one of our network drivers during a packet forwarding rate test. The other modification is to only invalidate on a pci_dma_sync_*() if the direction is from the device or bidirectional. Since this call is only supposed to insure that the CPU views exactly what has been DMAed in, there is no reason to write-back (or do anything if the direction is PCIDMA_TO_DEVICE). If I'm not mistaken, it seems that this call should actually do nothing to invalidate caches, but instead a pci_dma_prep_{sync,single} call with PCIDMA_FROM_DEVICE should do the invalidate. This would eliminate the extra invalidate that happens when a driver calls pci_dma_sync_*() after just having DMAed into a just mapped buffer. It would also clear up the abstraction of who "owns" the device; there would be an explicit call for each transition i.e. (FROM_DEVICE operation) pci_map_single() - device now owns the buffer [invalidate] [DMA] pci_dma_sync_single() - driver now owns it [no invalidate] [driver touches buffer] pci_dma_prep_single() - device owns it once again [invalidate] [DMA] ... rather than an implicit change from driver->device, i.e. pci_map_single() - device now owns the buffer [invalidate] [DMA] pci_dma_sync_single() - driver now owns it [unneeded invalidate] [driver touches buffer] [driver now gives bus address back to the device, and the device implicitly owns it once again] [DMA] ... However, such a change would require change lots of existing drivers and breaking others. So I'll veer away from that. :o) Thanks, William --- Index: include/asm-mips/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.1 diff -u -r1.24.2.1 pci.h --- include/asm-mips/pci.h 2002/02/26 06:00:25 1.24.2.1 +++ include/asm-mips/pci.h 2002/05/25 20:10:20 @@ -79,7 +79,40 @@ extern void pci_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle); +#ifdef CONFIG_NONCOHERENT_IO +/* + * Prepare buffer for DMA transfer + */ +static inline void prep_buffer(void *ptr, size_t size, int direction) +{ + switch(direction) { + case PCI_DMA_TODEVICE: + dma_cache_wback((unsigned long)ptr, size); + break; + case PCI_DMA_FROMDEVICE: + dma_cache_inv((unsigned long)ptr, size); + break; + case PCI_DMA_BIDIRECTIONAL: + dma_cache_wback_inv((unsigned long)ptr, size); + break; + } +} + /* + * Prepare buffer for CPU access after DMA transfer + */ +static inline void sync_buffer(void *ptr, size_t size, int direction) +{ + switch(direction) { + case PCI_DMA_FROMDEVICE: + case PCI_DMA_BIDIRECTIONAL: + dma_cache_inv((unsigned long)ptr, size); + break; + } +} +#endif + +/* * Map a single buffer of the indicated size for DMA in streaming mode. * The 32-bit bus address to use is returned. * @@ -93,7 +126,7 @@ BUG(); #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)ptr, size); + prep_buffer(ptr, size, direction); #endif return virt_to_bus(ptr); @@ -132,7 +165,7 @@ addr = (unsigned long) page_address(page); addr += offset; #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv(addr, size); + prep_buffer((void*)addr, size, direction); #endif return virt_to_bus((void *)addr); @@ -183,7 +216,7 @@ #ifdef CONFIG_NONCOHERENT_IO /* Make sure that gcc doesn't leave the empty loop body. */ for (i = 0; i < nents; i++, sg++) - dma_cache_wback_inv((unsigned long)sg->address, sg->length); + prep_buffer(sg->address, sg->length, direction); #endif return nents; @@ -221,7 +254,7 @@ BUG(); #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)bus_to_virt(dma_handle), size); + sync_buffer(bus_to_virt(dma_handle), size, direction); #endif } @@ -245,8 +278,52 @@ /* Make sure that gcc doesn't leave the empty loop body. */ #ifdef CONFIG_NONCOHERENT_IO + for (i = 0; i < nelems; i++, sg++) + sync_buffer(sg->address, sg->length, direction); +#endif + +} + +/* + * Prepare buffer for a DMA transfer after driver temporarily + * re-claimed it with pci_dma_sync_*(). + * + * In essence, this "returns" the buffer to the PCI device. + */ +static inline void pci_dma_prep_single(struct pci_dev *hwdev, + dma_addr_t dma_handle, + size_t size, int direction) +{ + if (direction == PCI_DMA_NONE) + BUG(); + +#ifdef CONFIG_NONCOHERENT_IO + prep_buffer(bus_to_virt(dma_handle), size, direction); +#endif +} + +/* + * Prepare buffer for a DMA transfer after driver temporarily + * re-claimed it with pci_dma_sync_*(). + * + * The same as pci_dma_prep_single but for a scatter-gather list, + * same rules and usage. + */ +static inline void pci_dma_prep_sg(struct pci_dev *hwdev, + struct scatterlist *sg, + int nelems, int direction) +{ +#ifdef CONFIG_NONCOHERENT_IO + int i; +#endif + + if (direction == PCI_DMA_NONE) + BUG(); + + /* Make sure that gcc doesn't leave the empty loop body. */ +#ifdef CONFIG_NONCOHERENT_IO for (i = 0; i < nelems; i++, sg++) - dma_cache_wback_inv((unsigned long)sg->address, sg->length); + prep_buffer(sg->address, sg->length, direction); #endif } From owner-linux-mips@oss.sgi.com Sat May 25 15:03:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PM3YnC005339 for ; Sat, 25 May 2002 15:03:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PM3YMW005338 for linux-mips-outgoing; Sat, 25 May 2002 15:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4PM3LnC005334; Sat, 25 May 2002 15:03:21 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4PM32h08267; Sat, 25 May 2002 15:03:02 -0700 Date: Sat, 25 May 2002 15:03:02 -0700 From: William Jhun To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH] include/asm-mips/pci.h: More optimal cache behavior, added "prep" routines Message-ID: <20020525150302.A8264@ayrnetworks.com> References: <20020525131806.A4073@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020525131806.A4073@ayrnetworks.com>; from wjhun@ayrnetworks.com on Sat, May 25, 2002 at 01:18:06PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, May 25, 2002 at 01:18:06PM -0700, William Jhun wrote: > When preparing a buffer for a DMA transfer, we've found it's more > optimal to only do a wback_inv if the direction is not known > (PCIDMA_BIDIRECTIONAL), only a wback if transfer is to the device > (PCIDMA_TO_DEVICE), and only an invalidate if from the device > (PCIDMA_FROM_DEVICE). Such a modification has made a small (yet > significant) improvement for one of our network drivers during a packet > forwarding rate test. *sigh*. On the platform we were testing on, we used our own cache code (rm7k with tertiary cache support) which has been well-tested for over a year now. In these routines, we implement dma_cache_wback and only do invalidates (no flush) for dma_cache_wback_inv. Now that I'm looking around in cache support for other MIPS CPUs, I see that all the _wback calls are not implemented and that many (or all?) of the _inv calls also flush the caches. The patch below leaves the existing funtions alone and just adds the two pci_dma_prep_{sg,single}() calls. My question is: why are these dma_cache_wback calls not implemented? And how come dma_cache_inv is treated the same as dma_cache_wback_inv? Are we doing something wrong by implementing these calls in our cache code as they are described? Thanks, Will --- Index: include/asm-mips/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.1 diff -u -r1.24.2.1 pci.h --- include/asm-mips/pci.h 2002/02/26 06:00:25 1.24.2.1 +++ include/asm-mips/pci.h 2002/05/25 22:01:53 @@ -250,6 +250,49 @@ #endif } +/* + * Prepare buffer for a DMA transfer after driver temporarily + * re-claimed it with pci_dma_sync_*(). + * + * In essence, this "returns" the buffer to the PCI device. + */ +static inline void pci_dma_prep_single(struct pci_dev *hwdev, + dma_addr_t dma_handle, + size_t size, int direction) +{ + if (direction == PCI_DMA_NONE) + BUG(); + +#ifdef CONFIG_NONCOHERENT_IO + dma_cache_wback_inv((unsigned long)bus_to_virt(dma_handle), size); +#endif +} + +/* + * Prepare buffer for a DMA transfer after driver temporarily + * re-claimed it with pci_dma_sync_*(). + * + * The same as pci_dma_prep_single but for a scatter-gather list, + * same rules and usage. + */ +static inline void pci_dma_prep_sg(struct pci_dev *hwdev, + struct scatterlist *sg, + int nelems, int direction) +{ +#ifdef CONFIG_NONCOHERENT_IO + int i; +#endif + + if (direction == PCI_DMA_NONE) + BUG(); + + /* Make sure that gcc doesn't leave the empty loop body. */ +#ifdef CONFIG_NONCOHERENT_IO + for (i = 0; i < nelems; i++, sg++) + dma_cache_wback_inv((unsigned long)sg->address, sg->length); +#endif +} + /* Return whether the given PCI device DMA address mask can * be supported properly. For example, if your device can * only drive the low 24-bits during PCI bus mastering, then From owner-linux-mips@oss.sgi.com Sat May 25 15:43:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PMhHnC005665 for ; Sat, 25 May 2002 15:43:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4PMhH91005664 for linux-mips-outgoing; Sat, 25 May 2002 15:43:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4PMhFnC005661 for ; Sat, 25 May 2002 15:43:15 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4PMiQO02501; Sat, 25 May 2002 15:44:26 -0700 Date: Sat, 25 May 2002 15:44:26 -0700 From: Ralf Baechle To: robru Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? Message-ID: <20020525154426.A2481@dea.linux-mips.net> References: <20020525002723.A27302@dea.linux-mips.net> <000701c2041f$4d2ae7f0$0a01a8c0@sohotower> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000701c2041f$4d2ae7f0$0a01a8c0@sohotower>; from robru@teknuts.com on Sat, May 25, 2002 at 12:06:29PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Sat, May 25, 2002 at 12:06:29PM -0700, robru wrote: > How can I find out if I compiled my kernel with the compatibility code? Make sure you have CONFIG_BINFMT_IRIX set in the kernel configuration. You'll also need to install IRIX libraries. Ralf From owner-linux-mips@oss.sgi.com Sun May 26 09:33:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4QGXUnC020966 for ; Sun, 26 May 2002 09:33:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4QGXUY1020965 for linux-mips-outgoing; Sun, 26 May 2002 09:33:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4QGXJnC020962; Sun, 26 May 2002 09:33:19 -0700 Received: from sohotower (adsl-66.218.38.74.dslextreme.com [66.218.38.74]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4QGYYu08567; Sun, 26 May 2002 09:34:34 -0700 From: "Robert Rusek" To: "'Ralf Baechle'" Cc: Subject: RE: Executing IRIX binary ? Date: Sun, 26 May 2002 09:34:50 -0700 Message-ID: <000701c204d3$47c94ae0$0a01a8c0@sohotower> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20020525154426.A2481@dea.linux-mips.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This may be a stupid question but which IRIX libraries? All of them? When I try to execute a IRIX biniary I get the following: bash: ./owsadm: No such file or directory Do I need to something special? Thanks, Robert. -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com] On Behalf Of Ralf Baechle Sent: Saturday, May 25, 2002 3:44 PM To: robru Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? On Sat, May 25, 2002 at 12:06:29PM -0700, robru wrote: > How can I find out if I compiled my kernel with the compatibility > code? Make sure you have CONFIG_BINFMT_IRIX set in the kernel configuration. You'll also need to install IRIX libraries. Ralf From owner-linux-mips@oss.sgi.com Sun May 26 11:01:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4QI1qnC021687 for ; Sun, 26 May 2002 11:01:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4QI1pe8021686 for linux-mips-outgoing; Sun, 26 May 2002 11:01:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4QI1mnC021683 for ; Sun, 26 May 2002 11:01:49 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g4QI12v06380; Sun, 26 May 2002 11:01:02 -0700 Subject: Re: linux.h patch for mips From: Eric Christopher To: Thiemo Seufer Cc: "H . J . Lu" , cgd@broadcom.com, linux-mips@oss.sgi.com In-Reply-To: <20020525181404.GI21557@rembrandt.csv.ica.uni-stuttgart.de> References: <1022278283.25829.46.camel@ghostwheel.cygnus.com> <20020524190322.C10735@lucon.org> <20020525181404.GI21557@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5.99 Date: 26 May 2002 11:00:54 -0700 Message-Id: <1022436056.29700.3.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > At least for completeness there should be also _MIPS_ISA_MIPS5 > (the -mips5 swich would cause _MIPS_ISA_MIPS1 otherwise). Rather irrelevent since mips5 really isn't supported in gcc, but ok. I was more concerned with the kernel issues and how checks for processor features was being done. Requiring -mipsX for anything isn't a good idea (what if you want to compile for something that is not a particular architecture, e.g. -march=r4600). -eric -- I will not carve gods From owner-linux-mips@oss.sgi.com Sun May 26 11:29:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4QIT5nC021905 for ; Sun, 26 May 2002 11:29:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4QIT5Pe021904 for linux-mips-outgoing; Sun, 26 May 2002 11:29:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4QIT0nC021901 for ; Sun, 26 May 2002 11:29:01 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17C2lV-0007ya-00; Sun, 26 May 2002 20:29:13 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17C2mF-00041o-00; Sun, 26 May 2002 20:29:59 +0200 Date: Sun, 26 May 2002 20:29:59 +0200 To: Eric Christopher Cc: "H . J . Lu" , cgd@broadcom.com, linux-mips@oss.sgi.com Subject: Re: linux.h patch for mips Message-ID: <20020526182959.GA15299@rembrandt.csv.ica.uni-stuttgart.de> References: <1022278283.25829.46.camel@ghostwheel.cygnus.com> <20020524190322.C10735@lucon.org> <20020525181404.GI21557@rembrandt.csv.ica.uni-stuttgart.de> <1022436056.29700.3.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022436056.29700.3.camel@ghostwheel.cygnus.com> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Eric Christopher wrote: > > > > > At least for completeness there should be also _MIPS_ISA_MIPS5 > > (the -mips5 swich would cause _MIPS_ISA_MIPS1 otherwise). > > Rather irrelevent since mips5 really isn't supported in gcc, but ok. I > was more concerned with the kernel issues and how checks for processor > features was being done. Requiring -mipsX for anything isn't a good idea > (what if you want to compile for something that is not a particular > architecture, e.g. -march=r4600). That's why my private patch for mips64-linux has: %{mips1:-D_MIPS_ISA=_MIPS_ISA_MIPS1} \ %{mips2:-D_MIPS_ISA=_MIPS_ISA_MIPS2} \ %{mips32:-D_MIPS_ISA=_MIPS_ISA_MIPS32} \ %{mips3:-D_MIPS_ISA=_MIPS_ISA_MIPS3} \ %{mips4:-D_MIPS_ISA=_MIPS_ISA_MIPS4} \ %{mips5:-D_MIPS_ISA=_MIPS_ISA_MIPS5} \ %{mips64:-D_MIPS_ISA=_MIPS_ISA_MIPS64} \ %{!mips*: \ %{mabi=32|mabi=o32|!mabi*:-D_MIPS_ISA=_MIPS_ISA_MIPS1} \ %{mabi=n32|mabi=64|mabi=n64:-D_MIPS_ISA=_MIPS_ISA_MIPS3}} \ Thiemo From owner-linux-mips@oss.sgi.com Sun May 26 21:58:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4R4w3nC025951 for ; Sun, 26 May 2002 21:58:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4R4w39a025950 for linux-mips-outgoing; Sun, 26 May 2002 21:58:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.laser5.co.jp (gw1.laser5.co.jp [202.221.8.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4R4w1nC025947 for ; Sun, 26 May 2002 21:58:01 -0700 Received: from l5ac192.l5.laser5.co.jp (unknown [192.168.128.192]) by mail.laser5.co.jp (Postfix) with ESMTP id 549FA833A5 for ; Mon, 27 May 2002 13:59:17 +0900 (JST) Date: Mon, 27 May 2002 13:59:18 +0900 Message-ID: From: Kunihiko IMAI To: linux-mips Subject: Re: fail to boot with MTD root fs In-Reply-To: <3CEFCF86.5060401@realitydiluted.com> References: <3CEFCF86.5060401@realitydiluted.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386-vine-linux-gnu) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Thank you for your advice. I followed your advice to fix the code. It goes well, boot with flash ROM root fs. Thank you. _._. __._ _ . ... _ .___ ._. _____ _... ._ _._ _.._. .____ _ . ... _ Kunihiko IMAI From owner-linux-mips@oss.sgi.com Sun May 26 23:56:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4R6uEnC026880 for ; Sun, 26 May 2002 23:56:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4R6uElV026879 for linux-mips-outgoing; Sun, 26 May 2002 23:56:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4R6uAnC026875 for ; Sun, 26 May 2002 23:56:10 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g4R6tQv08125; Sun, 26 May 2002 23:55:26 -0700 Subject: Re: linux.h patch for mips From: Eric Christopher To: Thiemo Seufer Cc: "H . J . Lu" , cgd@broadcom.com, linux-mips@oss.sgi.com In-Reply-To: <20020526182959.GA15299@rembrandt.csv.ica.uni-stuttgart.de> References: <1022278283.25829.46.camel@ghostwheel.cygnus.com> <20020524190322.C10735@lucon.org> <20020525181404.GI21557@rembrandt.csv.ica.uni-stuttgart.de> <1022436056.29700.3.camel@ghostwheel.cygnus.com> <20020526182959.GA15299@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5.99 Date: 26 May 2002 23:55:18 -0700 Message-Id: <1022482520.29700.8.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > That's why my private patch for mips64-linux has: > > %{mips1:-D_MIPS_ISA=_MIPS_ISA_MIPS1} \ > %{mips2:-D_MIPS_ISA=_MIPS_ISA_MIPS2} \ > %{mips32:-D_MIPS_ISA=_MIPS_ISA_MIPS32} \ > %{mips3:-D_MIPS_ISA=_MIPS_ISA_MIPS3} \ > %{mips4:-D_MIPS_ISA=_MIPS_ISA_MIPS4} \ > %{mips5:-D_MIPS_ISA=_MIPS_ISA_MIPS5} \ > %{mips64:-D_MIPS_ISA=_MIPS_ISA_MIPS64} \ > %{!mips*: \ > %{mabi=32|mabi=o32|!mabi*:-D_MIPS_ISA=_MIPS_ISA_MIPS1} \ > %{mabi=n32|mabi=64|mabi=n64:-D_MIPS_ISA=_MIPS_ISA_MIPS3}} \ Not a bad start. There's more that needs to be done, I may end up having to submit kernel patches to make everything agree. Do people use a cvs server or ... -eric -- I will not carve gods From owner-linux-mips@oss.sgi.com Mon May 27 02:42:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4R9glnC003116 for ; Mon, 27 May 2002 02:42:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4R9gkDI003115 for linux-mips-outgoing; Mon, 27 May 2002 02:42:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4R9ginC003109 for ; Mon, 27 May 2002 02:42:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id CAA03115 for ; Mon, 27 May 2002 02:43:55 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA16591 for ; Mon, 27 May 2002 02:43:55 -0700 (PDT) Message-ID: <019401c20563$e7f6af40$10eca8c0@grendel> From: "Kevin D. Kissell" To: Subject: PCI Graphics/Video Card for Malta Board? Date: Mon, 27 May 2002 11:49:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'd like to get a video-capable graphics card up and running on a MIPS Malta board (therefore PCI), ideally something mainstream like ATI. Does anyone on the list have any positive or negative recommendations in terms of cards and particularly in terms of the degree to which the drivers (and PCI set-up) have been ported to MIPS/Linux? I'll do what I must, but I hate re-inventing the wheel. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Mon May 27 06:12:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RDC1nC006072 for ; Mon, 27 May 2002 06:12:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RDC1Kp006071 for linux-mips-outgoing; Mon, 27 May 2002 06:12:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru ([193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RDBqnC006067 for ; Mon, 27 May 2002 06:11:53 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id RAA19392; Mon, 27 May 2002 17:12:21 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id RAA01134; Mon, 27 May 2002 17:03:30 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id RAA20083; Mon, 27 May 2002 17:07:17 +0400 (MSK) Message-ID: <3CF2A17D.6050207@niisi.msk.ru> Date: Mon, 27 May 2002 17:13:33 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.17 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 References: <3CEEBBA9.5070809@niisi.msk.ru> <3CEEAC5F.6010802@mvista.com> Content-Type: multipart/mixed; boundary="------------090100080205070303000804" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------090100080205070303000804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jun Sun wrote: > I took a look of the arch_get_unmapped_area(), and it looks fine to me. > > Can you try the following changes and let me know what happens? > > 1) change COLOUR_ALIGN > #define COLOUR_ALIGN(addr,pgoff) addr OK, It works for me. > > We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for > quite a while with no problems. It seems newer gcc and binutiles are > fine too. > I understand, but is there any __official__ recommended versions of these utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :( --------------090100080205070303000804 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -pru linux_2_4_18_orig/arch/mips/mm/tlb-r3k.c linux_2_4_18/arch/mips/mm/tlb-r3k.c --- linux_2_4_18_orig/arch/mips/mm/tlb-r3k.c Fri Apr 26 07:50:07 2002 +++ linux_2_4_18/arch/mips/mm/tlb-r3k.c Mon May 27 16:36:14 2002 @@ -118,7 +118,7 @@ void local_flush_tlb_range(struct mm_str void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page) { - if (!vma || vma->vm_mm->context != 0) { + if (vma && vma->vm_mm->context) { unsigned long flags; int oldpid, newpid, idx; diff -pru linux_2_4_18_orig/arch/mips/mm/tlb-r4k.c linux_2_4_18/arch/mips/mm/tlb-r4k.c --- linux_2_4_18_orig/arch/mips/mm/tlb-r4k.c Fri Apr 26 07:50:07 2002 +++ linux_2_4_18/arch/mips/mm/tlb-r4k.c Mon May 27 16:31:45 2002 @@ -140,7 +140,7 @@ void local_flush_tlb_range(struct mm_str void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page) { - if (!vma || vma->vm_mm->context != 0) { + if (vma && vma->vm_mm->context) { unsigned long flags; int oldpid, newpid, idx; --------------090100080205070303000804-- From owner-linux-mips@oss.sgi.com Mon May 27 06:25:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RDP4nC006218 for ; Mon, 27 May 2002 06:25:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RDP4LF006217 for linux-mips-outgoing; Mon, 27 May 2002 06:25:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RDP1nC006212 for ; Mon, 27 May 2002 06:25:01 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17CKVp-0008Dh-00; Mon, 27 May 2002 08:26:13 -0500 Message-ID: <3CF233DA.2040602@realitydiluted.com> Date: Mon, 27 May 2002 08:25:46 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020520 Debian/1.0rc2-3 MIME-Version: 1.0 To: "Kevin D. Kissell" CC: linux-mips@oss.sgi.com Subject: Re: PCI Graphics/Video Card for Malta Board? References: <019401c20563$e7f6af40$10eca8c0@grendel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Kevin D. Kissell wrote: > > I'd like to get a video-capable graphics card up > and running on a MIPS Malta board (therefore > PCI), ideally something mainstream like ATI. > Does anyone on the list have any positive or > negative recommendations in terms of cards > and particularly in terms of the degree to which > the drivers (and PCI set-up) have been ported > to MIPS/Linux? I'll do what I must, but I hate > re-inventing the wheel. > I can think of two things. First, a lot of graphics cards rely on BIOS calls to be set up before the operating system even boots. Second, I would stick to graphics cards that have framebuffer support in the kernel as you stand at least half a chance that those cards don't rely so heavily on a peecee bios. Just my $.02. -Steve From owner-linux-mips@oss.sgi.com Mon May 27 06:37:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RDbQnC006382 for ; Mon, 27 May 2002 06:37:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RDbQTM006381 for linux-mips-outgoing; Mon, 27 May 2002 06:37:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RDbHnC006378 for ; Mon, 27 May 2002 06:37:20 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA28194; Mon, 27 May 2002 15:37:28 +0200 (MET DST) Date: Mon, 27 May 2002 15:37:27 +0200 (MEST) From: Geert Uytterhoeven To: "Steven J. Hill" cc: "Kevin D. Kissell" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? In-Reply-To: <3CF233DA.2040602@realitydiluted.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, 27 May 2002, Steven J. Hill wrote: > Kevin D. Kissell wrote: > > I'd like to get a video-capable graphics card up > > and running on a MIPS Malta board (therefore > > PCI), ideally something mainstream like ATI. > > Does anyone on the list have any positive or > > negative recommendations in terms of cards > > and particularly in terms of the degree to which > > the drivers (and PCI set-up) have been ported > > to MIPS/Linux? I'll do what I must, but I hate > > re-inventing the wheel. > > > I can think of two things. First, a lot of graphics cards > rely on BIOS calls to be set up before the operating system > even boots. Second, I would stick to graphics cards that > have framebuffer support in the kernel as you stand at least > half a chance that those cards don't rely so heavily on a > peecee bios. Just my $.02. Even then, most frame buffer device drivers rely on the firmware (PC BIOS or SPARC/PPC Open Firmware) having set up the video card. One of the exceptions is matroxfb, which is able to initialize older Matrox cards. This should cover all their PCI cards (Matrox didn't release any new PCI cards during the last few years). 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 May 27 07:01:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RE1nnC006671 for ; Mon, 27 May 2002 07:01:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RE1nsa006670 for linux-mips-outgoing; Mon, 27 May 2002 07:01:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RE1lnC006667 for ; Mon, 27 May 2002 07:01:47 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id HAA03804; Mon, 27 May 2002 07:02:54 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA20057; Mon, 27 May 2002 07:02:54 -0700 (PDT) Message-ID: <029b01c20588$16335830$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Geert Uytterhoeven" , "Steven J. Hill" Cc: "Linux/MIPS Development" References: Subject: Re: PCI Graphics/Video Card for Malta Board? Date: Mon, 27 May 2002 16:09:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > One of the exceptions is matroxfb, which is able to initialize older Matrox > cards. This should cover all their PCI cards (Matrox didn't release any new PCI > cards during the last few years). They still sell/support the G450PCI, which has TV output support, and a flat-panel transmitter, and which might do the job for me. Can anyone confirm that the matroxfb support works for it? Kevin K. From owner-linux-mips@oss.sgi.com Mon May 27 07:13:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4REDmnC006848 for ; Mon, 27 May 2002 07:13:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4REDlxi006847 for linux-mips-outgoing; Mon, 27 May 2002 07:13:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4REDenC006844 for ; Mon, 27 May 2002 07:13:40 -0700 Message-Id: <200205271413.g4REDenC006844@oss.sgi.com> Received: (qmail 9771 invoked from network); 27 May 2002 14:06:35 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 27 May 2002 14:06:35 -0000 Date: Mon, 27 May 2002 22:13:37 +0800 From: "Zhang Fuxin" To: Geert Uytterhoeven CC: "linux-mips@oss.sgi.com" Subject: Re: Re: PCI Graphics/Video Card for Malta Board? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4REDfnC006845 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, ======= 2002-05-27 15:37:00 you wrote£º======= >On Mon, 27 May 2002, Steven J. Hill wrote: >> Kevin D. Kissell wrote: >> > I'd like to get a video-capable graphics card up >> I can think of two things. First, a lot of graphics cards >> rely on BIOS calls to be set up before the operating system >> even boots. Second, I would stick to graphics cards that >> have framebuffer support in the kernel as you stand at least >> half a chance that those cards don't rely so heavily on a >> peecee bios. Just my $.02. > >Even then, most frame buffer device drivers rely on the firmware (PC BIOS or >SPARC/PPC Open Firmware) having set up the video card. i have made vesa frame buffer & vga text console work for a pile of cards with x86emu code i posted days ago.but i think he want video-capable,that may leave few candidates > >One of the exceptions is matroxfb, which is able to initialize older Matrox >cards. This should cover all their PCI cards (Matrox didn't release any new PCI >cards during the last few years). It is expensive now:) I bought two G450pci last year,they are hard to find. > >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 = = = = = = = = = = = = = = = = = = = = Best Regards --------------------------------------- Zhang Fuxin System Architecture Lab Institute of Computing Technology Chinese Academy of Sciences,China http://www.ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-05-27 From owner-linux-mips@oss.sgi.com Mon May 27 07:14:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4REEFnC006877 for ; Mon, 27 May 2002 07:14:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4REEFY4006876 for linux-mips-outgoing; Mon, 27 May 2002 07:14:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4REE5nC006872 for ; Mon, 27 May 2002 07:14:08 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA01210; Mon, 27 May 2002 16:14:38 +0200 (MET DST) Date: Mon, 27 May 2002 16:14:38 +0200 (MEST) From: Geert Uytterhoeven To: "Kevin D. Kissell" cc: "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? In-Reply-To: <029b01c20588$16335830$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, 27 May 2002, Kevin D. Kissell wrote: > > One of the exceptions is matroxfb, which is able to initialize older Matrox > > cards. This should cover all their PCI cards (Matrox didn't release any new PCI > > cards during the last few years). > > They still sell/support the G450PCI, which has TV output support, > and a flat-panel transmitter, and which might do the job for me. Oh, I didn't know they made PCI cards after the G200 (which was hard to get in its PCI variant). In fact they responded negatively when we (the PPC guys, thinking about designing our own PPC motherboards) asked them if they intended to release other PCI chips after the G200, for platforms that lacked AGP support. BTW, the FAQ on Matrox' website says: | 1. What happens if I use the Millennium G450 PCI in a system with a | non-Intel chipset? | | 1. The G450 PCI does not support bus-mastering with non-Intel chipsets. | While this lowers performance on synthetic benchmarks, it does not hinder | the everyday usability of the card. Additionally, the Millennium G450 PCI | does not support OpenGL acceleration (primarily used for 3D gaming) or | DVDMax with non-Intel chipsets. > Can anyone confirm that the matroxfb support works for it? I'm not sure matroxfb support full initialization of the '450. You best ask Petr Vandrovec. 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 May 27 13:31:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RKVCnC015978 for ; Mon, 27 May 2002 13:31:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RKVCvg015977 for linux-mips-outgoing; Mon, 27 May 2002 13:31:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RKV7nC015974; Mon, 27 May 2002 13:31:07 -0700 Received: from sohotower (adsl-66.218.38.74.dslextreme.com [66.218.38.74]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4RKWRa02276; Mon, 27 May 2002 13:32:27 -0700 From: "Robert Rusek" To: "'Ralf Baechle'" Cc: Subject: RE: Executing IRIX binary ? Date: Mon, 27 May 2002 13:32:43 -0700 Message-ID: <000701c205bd$adaeff40$0a01a8c0@sohotower> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020525154426.A2481@dea.linux-mips.net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf, Looks like I have the kernal compiled with the IRIX binary support. How do I go about executing the binaries? When I try to execute it tells me that the file is not found. Thanks in advance, Robert. -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com] On Behalf Of Ralf Baechle Sent: Saturday, May 25, 2002 3:44 PM To: robru Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? On Sat, May 25, 2002 at 12:06:29PM -0700, robru wrote: > How can I find out if I compiled my kernel with the compatibility > code? Make sure you have CONFIG_BINFMT_IRIX set in the kernel configuration. You'll also need to install IRIX libraries. Ralf From owner-linux-mips@oss.sgi.com Mon May 27 14:16:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RLG4nC016624 for ; Mon, 27 May 2002 14:16:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RLG4jD016623 for linux-mips-outgoing; Mon, 27 May 2002 14:16:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RLFunC016620; Mon, 27 May 2002 14:15:57 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id A00D2852; Mon, 27 May 2002 23:17:15 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 6F50137102; Mon, 27 May 2002 23:15:13 +0200 (CEST) Date: Mon, 27 May 2002 23:15:13 +0200 From: Florian Lohoff To: Robert Rusek Cc: "'Ralf Baechle'" , linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? Message-ID: <20020527211513.GE32064@paradigm.rfc822.org> References: <20020525154426.A2481@dea.linux-mips.net> <000701c205bd$adaeff40$0a01a8c0@sohotower> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ULyIDA2m8JTe+TiX" Content-Disposition: inline In-Reply-To: <000701c205bd$adaeff40$0a01a8c0@sohotower> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --ULyIDA2m8JTe+TiX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 27, 2002 at 01:32:43PM -0700, Robert Rusek wrote: > Ralf, >=20 > Looks like I have the kernal compiled with the IRIX binary support. How > do I go about executing the binaries? When I try to execute it tells me > that the file is not found. Are you shure you have the dynamic loader + libc + other libs of IRIX installed in your system ? Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --ULyIDA2m8JTe+TiX 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 iD8DBQE88qHhUaz2rXW+gJcRArFjAJ9u0j878ANVfB096xYPOTkqO8gMewCgjiHS WUDlvsdAq/aTCA0fZrTRkWY= =0cxL -----END PGP SIGNATURE----- --ULyIDA2m8JTe+TiX-- From owner-linux-mips@oss.sgi.com Mon May 27 14:56:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4RLulnC017214 for ; Mon, 27 May 2002 14:56:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4RLulVK017213 for linux-mips-outgoing; Mon, 27 May 2002 14:56:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtla2.teknuts.com (adsl-66-125-62-110.dsl.lsan03.pacbell.net [66.125.62.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4RLudnC017209; Mon, 27 May 2002 14:56:42 -0700 Received: from sohotower (adsl-66.218.38.74.dslextreme.com [66.218.38.74]) (authenticated) by dtla2.teknuts.com (8.11.3/8.10.1) with ESMTP id g4RLvsa02522; Mon, 27 May 2002 14:57:54 -0700 From: "Robert Rusek" To: Cc: "'Ralf Baechle'" , Subject: RE: Executing IRIX binary ? Date: Mon, 27 May 2002 14:58:15 -0700 Message-ID: <001d01c205c9$9d8faf40$0a01a8c0@sohotower> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020527211513.GE32064@paradigm.rfc822.org> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I have IRIX binary support turned on in the kernel. I can copy over my IRIX libs from my old IRIX partition (I just do not know which ones). I don't think I have the dynamic loader? How would I check to see if I have it? If not where would I get it? Sorry about all these newbie questions it is just that I need to be able to run the IRIX version of fronpage server extensions since MS does not provide the open source. Thanks, Robert. -----Original Message----- From: flo@rfc822.org [mailto:flo@rfc822.org] Sent: Monday, May 27, 2002 2:15 PM To: Robert Rusek Cc: 'Ralf Baechle'; linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? On Mon, May 27, 2002 at 01:32:43PM -0700, Robert Rusek wrote: > Ralf, > > Looks like I have the kernal compiled with the IRIX binary support. > How do I go about executing the binaries? When I try to execute it > tells me that the file is not found. Are you shure you have the dynamic loader + libc + other libs of IRIX installed in your system ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. From owner-linux-mips@oss.sgi.com Mon May 27 23:45:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S6jCnC007763 for ; Mon, 27 May 2002 23:45:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4S6jC6p007762 for linux-mips-outgoing; Mon, 27 May 2002 23:45:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S6jAnC007755 for ; Mon, 27 May 2002 23:45:10 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4S6kOg09470; Mon, 27 May 2002 23:46:24 -0700 Date: Mon, 27 May 2002 23:46:24 -0700 From: Ralf Baechle To: Robert Rusek Cc: linux-mips@oss.sgi.com Subject: Re: Executing IRIX binary ? Message-ID: <20020527234624.A9392@dea.linux-mips.net> References: <20020525154426.A2481@dea.linux-mips.net> <000701c205bd$adaeff40$0a01a8c0@sohotower> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000701c205bd$adaeff40$0a01a8c0@sohotower>; from robru@teknuts.com on Mon, May 27, 2002 at 01:32:43PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, May 27, 2002 at 01:32:43PM -0700, Robert Rusek wrote: > Looks like I have the kernal compiled with the IRIX binary support. How > do I go about executing the binaries? When I try to execute it tells me > that the file is not found. The file it didn't find is the dynamic linker /usr/lib/libc.so.1. You have to install this file and others in special magic places. Also the kernel contains broken code to distinguish IRIX and Linux executables which you'd have to fix first before the code has any chance of working. Ralf From owner-linux-mips@oss.sgi.com Mon May 27 23:58:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S6wUnC008097 for ; Mon, 27 May 2002 23:58:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4S6wUHc008096 for linux-mips-outgoing; Mon, 27 May 2002 23:58:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4S6wRnC008092 for ; Mon, 27 May 2002 23:58:27 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id XAA05810 for ; Mon, 27 May 2002 23:59:38 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id XAA03706 for ; Mon, 27 May 2002 23:59:41 -0700 (PDT) Received: from copsun17.mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g4S6xfb26069 for ; Tue, 28 May 2002 08:59:41 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copsun17.mips.com (8.9.1/8.9.0) id IAA12543 for linux-mips@oss.sgi.com; Tue, 28 May 2002 08:59:41 +0200 (MET DST) Message-Id: <200205280659.IAA12543@copsun17.mips.com> Subject: Updated 7.1 installation images To: linux-mips@oss.sgi.com (user alias) Date: Tue, 28 May 2002 08:59:41 +0200 (MET DST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk We have just updated our MIPS RedHat 7.1 installation images for our development boards on ftp.mips.com. All the latest packages from H.J.'s 7.1 miniport are there, as well as new 2.4.18 kernels. /Hartvig >From ftp.mips.com: ftp> pwd 257 "/pub/linux/mips/installation/redhat7.1/02.00" is current directory. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 748399 -r--r--r-- 1 9618 40 13612 May 27 23:27 INSTALL -r--r--r-- 1 9618 40 383148032 May 27 23:32 MIPS_RedHat7.1_Release-02.00.iso -r--r--r-- 1 9618 40 382801920 May 27 23:29 MIPS_RedHat7.1_Release-02.00.tar -r--r--r-- 1 9618 40 585 May 27 23:27 README 226 Transfer complete. 321 bytes received in 0.026 seconds (12.11 Kbytes/s) From owner-linux-mips@oss.sgi.com Tue May 28 01:25:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4S8PhnC009100 for ; Tue, 28 May 2002 01:25:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4S8Ph7E009099 for linux-mips-outgoing; Tue, 28 May 2002 01:25:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4S8PDnC009095; Tue, 28 May 2002 01:25:14 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.SGI.COM [128.167.58.27]) with SMTP; 28 May 2002 08:26:36 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 98EACB476; Tue, 28 May 2002 17:26:17 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id RAA02699; Tue, 28 May 2002 17:26:17 +0900 (JST) Date: Tue, 28 May 2002 17:26:09 +0900 (JST) Message-Id: <20020528.172609.59648427.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Subject: Magic numbers about stack layout (again) From: Atsushi Nemoto In-Reply-To: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp> <200205280611.g4S6BuEj006804@oss.sgi.com> References: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp> 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.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_May_28_17:26:09_2002_727)--" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk ----Next_Part(Tue_May_28_17:26:09_2002_727)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Mon, 27 May 2002 23:11:56 -0700, Ralf Baechle said: ralf> Modified files: ralf> include/asm-mips: Tag: linux_2_4 processor.h ralf> Log message: ralf> Daily fix of get_wchan(), bloddy piece of shit ... I posted this message (and a patch) 9 month ago. How about this? >>>>> On Wed, 22 Aug 2001 14:45:47 +0900 (JST), Atsushi Nemoto said: nemoto> There are some magic constant numbers about stack layout in nemoto> thread_saved_pc() and get_wchan() function. nemoto> I made a patch to eliminate these magic numbers. This patch analyzes nemoto> some functions prologue codes in heuristic way at run-time. "ps -l" nemoto> (and "MAGIC SYSRQ" feature) works fine with this patch. Unfortunately, binutils 2.9.5 generates wrong codes with this patch. I think this is a bug of the binutils. Newer binutils (I tested 2.12 and 2.12.1) or binutils 2.8.1 seems fine. --- Atsushi Nemoto ----Next_Part(Tue_May_28_17:26:09_2002_727)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="get_wchan.patch" diff -ur linux.sgi/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c --- linux.sgi/arch/mips/kernel/process.c Sun Aug 5 23:39:09 2001 +++ linux/arch/mips/kernel/process.c Wed Aug 22 14:14:29 2001 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -31,6 +32,7 @@ #include #include #include +#include void cpu_idle(void) { @@ -196,6 +198,59 @@ #define first_sched ((unsigned long) scheduling_functions_start_here) #define last_sched ((unsigned long) scheduling_functions_end_here) +struct mips_frame_info schedule_frame; +static struct mips_frame_info schedule_timeout_frame; +static struct mips_frame_info sleep_on_frame; +static struct mips_frame_info sleep_on_timeout_frame; +static int mips_frame_info_initialized; +static int __init get_frame_info(struct mips_frame_info *info, void *func) +{ + int i; + union mips_instruction *ip = (union mips_instruction *)func; + info->pc_offset = -1; + info->frame_offset = -1; + for (i = 0; i < 128; i++, ip++) { + /* if jal, jalr, jr, stop. */ + if (ip->j_format.opcode == jal_op || + (ip->r_format.opcode == spec_op && + (ip->r_format.func == jalr_op || + ip->r_format.func == jr_op))) + break; + if (ip->i_format.opcode == sw_op && + ip->i_format.rs == 29) { + /* sw $ra, offset($sp) */ + if (ip->i_format.rt == 31) { + if (info->pc_offset != -1) + break; + info->pc_offset = + ip->i_format.simmediate / sizeof(long); + } + /* sw $s8, offset($sp) */ + if (ip->i_format.rt == 30) { + if (info->frame_offset != -1) + break; + info->frame_offset = + ip->i_format.simmediate / sizeof(long); + } + } + } + if (info->pc_offset == -1 || info->frame_offset == -1) { + printk("Can't analize prologue code at %p\n", func); + info->pc_offset = -1; + info->frame_offset = -1; + return -1; + } + return 0; +} +void __init frame_info_init(void) +{ + mips_frame_info_initialized = + !get_frame_info(&schedule_frame, schedule) && + !get_frame_info(&schedule_timeout_frame, schedule_timeout) && + !get_frame_info(&sleep_on_frame, sleep_on) && + !get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout); +} + /* get_wchan - a maintenance nightmare ... */ unsigned long get_wchan(struct task_struct *p) { @@ -204,6 +259,8 @@ if (!p || p == current || p->state == TASK_RUNNING) return 0; + if (!mips_frame_info_initialized) + return 0; pc = thread_saved_pc(&p->thread); if (pc < first_sched || pc >= last_sched) { return pc; @@ -220,23 +277,24 @@ goto schedule_timeout_caller; schedule_caller: - frame = ((unsigned long *)p->thread.reg30)[9]; - pc = ((unsigned long *)frame)[11]; + /* schedule_timeout called by interruptible_sleep_on or sleep_on */ + frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset]; + pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset]; return pc; schedule_timeout_caller: /* Must be schedule_timeout ... */ - pc = ((unsigned long *)p->thread.reg30)[10]; - frame = ((unsigned long *)p->thread.reg30)[9]; + pc = ((unsigned long *)p->thread.reg30)[schedule_frame.pc_offset]; + frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset]; /* The schedule_timeout frame ... */ - pc = ((unsigned long *)frame)[14]; - frame = ((unsigned long *)frame)[13]; + pc = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset]; + frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset]; if (pc >= first_sched && pc < last_sched) { /* schedule_timeout called by interruptible_sleep_on_timeout */ - pc = ((unsigned long *)frame)[11]; - frame = ((unsigned long *)frame)[10]; + pc = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset]; + frame = ((unsigned long *)frame)[sleep_on_timeout_frame.frame_offset]; } return pc; diff -ur linux.sgi/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c --- linux.sgi/arch/mips/kernel/setup.c Sun Aug 5 23:39:15 2001 +++ linux/arch/mips/kernel/setup.c Wed Aug 22 14:26:19 2001 @@ -518,12 +518,14 @@ void malta_setup(void); void momenco_ocelot_setup(void); void nino_setup(void); + void frame_info_init(void); unsigned long bootmap_size; unsigned long start_pfn, max_pfn, first_usable_pfn; int i; + frame_info_init(); #ifdef CONFIG_BLK_DEV_FD fd_ops = &no_fd_ops; #endif diff -ur linux.sgi/include/asm-mips/processor.h linux/include/asm-mips/processor.h --- linux.sgi/include/asm-mips/processor.h Sun Aug 5 23:41:29 2001 +++ linux/include/asm-mips/processor.h Wed Aug 22 14:14:59 2001 @@ -217,6 +217,11 @@ #define copy_segments(p, mm) do { } while(0) #define release_segments(mm) do { } while(0) +struct mips_frame_info { + int frame_offset; + int pc_offset; +}; +extern struct mips_frame_info schedule_frame; /* * Return saved PC of a blocked thread. */ @@ -228,7 +233,9 @@ if (t->reg31 == (unsigned long) ret_from_fork) return t->reg31; - return ((unsigned long *)t->reg29)[10]; + if (schedule_frame.pc_offset < 0) + return 0; + return ((unsigned long *)t->reg29)[schedule_frame.pc_offset]; } /* ----Next_Part(Tue_May_28_17:26:09_2002_727)---- From owner-linux-mips@oss.sgi.com Tue May 28 09:51:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SGpXnC026197 for ; Tue, 28 May 2002 09:51:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SGpXrd026196 for linux-mips-outgoing; Tue, 28 May 2002 09:51:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SGpOnC025527; Tue, 28 May 2002 09:51:25 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA29319; Tue, 28 May 2002 09:51:32 -0700 Message-ID: <3CF3B52B.508@mvista.com> Date: Tue, 28 May 2002 09:49:47 -0700 From: Jun Sun 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: William Jhun CC: linux-mips@oss.sgi.com, ralf@oss.sgi.com, davem@redhat.com Subject: Re: [PATCH] include/asm-mips/pci.h: More optimal cache behavior, added "prep" routines References: <20020525131806.A4073@ayrnetworks.com> <20020525150302.A8264@ayrnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk William Jhun wrote: > On Sat, May 25, 2002 at 01:18:06PM -0700, William Jhun wrote: > >>When preparing a buffer for a DMA transfer, we've found it's more >>optimal to only do a wback_inv if the direction is not known >>(PCIDMA_BIDIRECTIONAL), only a wback if transfer is to the device >>(PCIDMA_TO_DEVICE), and only an invalidate if from the device >>(PCIDMA_FROM_DEVICE). Such a modification has made a small (yet >>significant) improvement for one of our network drivers during a packet >>forwarding rate test. >> > > *sigh*. On the platform we were testing on, we used our own cache code > (rm7k with tertiary cache support) which has been well-tested for over a > year now. In these routines, we implement dma_cache_wback and only do > invalidates (no flush) for dma_cache_wback_inv. Now that I'm looking > around in cache support for other MIPS CPUs, I see that all the _wback > calls are not implemented and that many (or all?) of the _inv calls also > flush the caches. > > The patch below leaves the existing funtions alone and just adds the two > pci_dma_prep_{sg,single}() calls. > > My question is: why are these dma_cache_wback calls not implemented? And > how come dma_cache_inv is treated the same as dma_cache_wback_inv? Are > we doing something wrong by implementing these calls in our cache code > as they are described? > In theory cache_wback and cache_inv are doing different things. In practice, however, since the call must be made *before* dma transfer starts so the effects are same. Of course, _inv() version is more efficient if it is implemented. Jun From owner-linux-mips@oss.sgi.com Tue May 28 10:00:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SH02nC026382 for ; Tue, 28 May 2002 10:00:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SH02ri026381 for linux-mips-outgoing; Tue, 28 May 2002 10:00:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SGxunC026369 for ; Tue, 28 May 2002 09:59:56 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA29537; Tue, 28 May 2002 10:00:04 -0700 Message-ID: <3CF3B72B.4020600@mvista.com> Date: Tue, 28 May 2002 09:58:19 -0700 From: Jun Sun 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: Geert Uytterhoeven CC: "Steven J. Hill" , "Kevin D. Kissell" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Geert Uytterhoeven wrote: > On Mon, 27 May 2002, Steven J. Hill wrote: > >>Kevin D. Kissell wrote: >> >>>I'd like to get a video-capable graphics card up >>>and running on a MIPS Malta board (therefore >>>PCI), ideally something mainstream like ATI. >>>Does anyone on the list have any positive or >>>negative recommendations in terms of cards >>>and particularly in terms of the degree to which >>>the drivers (and PCI set-up) have been ported >>>to MIPS/Linux? I'll do what I must, but I hate >>>re-inventing the wheel. >>> >>> >>I can think of two things. First, a lot of graphics cards >>rely on BIOS calls to be set up before the operating system >>even boots. Second, I would stick to graphics cards that >>have framebuffer support in the kernel as you stand at least >>half a chance that those cards don't rely so heavily on a >>peecee bios. Just my $.02. >> > > Even then, most frame buffer device drivers rely on the firmware (PC BIOS or > SPARC/PPC Open Firmware) having set up the video card. > > One of the exceptions is matroxfb, Steve Longerbeam has a fb driver with BIOS init for ATI Xpert98 card, which you can still buy. Dan Malek also wrote a driver for MQ200. If you ask around, I am sure you can the patch somewhere. For a while, I also had 3dfx voodoo3 working. Not sure about its status now. You can find the patch at http://www.medex.hu/~danthe/tdfx/. Jun From owner-linux-mips@oss.sgi.com Tue May 28 10:18:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SHI5nC026623 for ; Tue, 28 May 2002 10:18:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SHI5LR026622 for linux-mips-outgoing; Tue, 28 May 2002 10:18:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SHHxnC026619 for ; Tue, 28 May 2002 10:17:59 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA30133; Tue, 28 May 2002 10:17:40 -0700 Message-ID: <3CF3BB4B.504@mvista.com> Date: Tue, 28 May 2002 10:15:55 -0700 From: Jun Sun 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: Alexandr Andreev CC: linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 References: <3CEEBBA9.5070809@niisi.msk.ru> <3CEEAC5F.6010802@mvista.com> <3CF2A17D.6050207@niisi.msk.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Alexandr Andreev wrote: > Jun Sun wrote: > >> I took a look of the arch_get_unmapped_area(), and it looks fine to me. >> >> Can you try the following changes and let me know what happens? >> >> 1) change COLOUR_ALIGN >> #define COLOUR_ALIGN(addr,pgoff) addr > > > OK, It works for me. > That indicate the logic of function works. So the problems might lie on something else: 1) some caller pass in non-zero addr but does not check the return addr and assume the addr remains the same. 2) given the reported toolchain, I will double-check to see if COLOUR_ALIGN() is compiled correctly. It is mildly complex. I would be also interested to know if removing filp condition would solve your problem. Nobody has explained why this condition is needed for doing COLOUR_ALIGN(). >> >> We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for >> quite a while with no problems. It seems newer gcc and binutiles are >> fine too. >> > I understand, but is there any __official__ recommended versions of these > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :( > Who are the "officiers" to decide on __official__ versions? :-) If you are really uncomfortable with non-official stuff, you might want to consider paying some vendor and I am sure you will be given an "official" version. Jun From owner-linux-mips@oss.sgi.com Tue May 28 10:36:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SHaRnC026892 for ; Tue, 28 May 2002 10:36:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SHaRgS026891 for linux-mips-outgoing; Tue, 28 May 2002 10:36:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SHaJnC026888 for ; Tue, 28 May 2002 10:36:19 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id KAA07893; Tue, 28 May 2002 10:37:33 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA16685; Tue, 28 May 2002 10:37:33 -0700 (PDT) Message-ID: <01da01c2066f$3ed63f40$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" , "Geert Uytterhoeven" Cc: "Steven J. Hill" , "Linux/MIPS Development" References: <3CF3B72B.4020600@mvista.com> Subject: Re: PCI Graphics/Video Card for Malta Board? Date: Tue, 28 May 2002 19:43:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: "Jun Sun" > Geert Uytterhoeven wrote: > > > On Mon, 27 May 2002, Steven J. Hill wrote: > > > >>Kevin D. Kissell wrote: > >> > >>>I'd like to get a video-capable graphics card up > >>>and running on a MIPS Malta board (therefore > >>>PCI), ideally something mainstream like ATI. > >>>Does anyone on the list have any positive or > >>>negative recommendations in terms of cards > >>>and particularly in terms of the degree to which > >>>the drivers (and PCI set-up) have been ported > >>>to MIPS/Linux? I'll do what I must, but I hate > >>>re-inventing the wheel. > >>> > >>> > >>I can think of two things. First, a lot of graphics cards > >>rely on BIOS calls to be set up before the operating system > >>even boots. Second, I would stick to graphics cards that > >>have framebuffer support in the kernel as you stand at least > >>half a chance that those cards don't rely so heavily on a > >>peecee bios. Just my $.02. > >> > > > > Even then, most frame buffer device drivers rely on the firmware (PC BIOS or > > SPARC/PPC Open Firmware) having set up the video card. > > > > One of the exceptions is matroxfb, > > > Steve Longerbeam has a fb driver with BIOS init for ATI Xpert98 card, which > you can still buy. Yeah, but it's a pretty wimpy card (8MB) and has no TV output. > Dan Malek also wrote a driver for MQ200. Which is essentially a handheld/webphone graphics chip, for which the documentation is only available under NDA. Not terribly useful for me, thanks. > If you ask around, I am sure you can the patch somewhere. I *am* asking around - that's why I started this thread. > > For a while, I also had 3dfx voodoo3 working. Not sure about its status now. > You can find the patch at http://www.medex.hu/~danthe/tdfx/. 3dfx, in case you hadn't heard, folded some time ago. So it sounds like the Matrox G450 PCI is really the only game in town... Kevin K. From owner-linux-mips@oss.sgi.com Tue May 28 15:19:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SMJAnC031000 for ; Tue, 28 May 2002 15:19:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SMJAhM030999 for linux-mips-outgoing; Tue, 28 May 2002 15:19:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from tibook.netx4.com (embeddededge.com [209.113.146.155]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SMJ5nC030996 for ; Tue, 28 May 2002 15:19:06 -0700 Received: from embeddededge.com (IDENT:dan@localhost.localdomain [127.0.0.1]) by tibook.netx4.com (8.11.1/8.11.1) with ESMTP id g4SMJW900688; Tue, 28 May 2002 18:19:32 -0400 Message-ID: <3CF40273.1000801@embeddededge.com> Date: Tue, 28 May 2002 18:19:31 -0400 From: Dan Malek Organization: Embedded Edge, LLC. User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.9) Gecko/20020411 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Jun Sun , Geert Uytterhoeven , "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? References: <3CF3B72B.4020600@mvista.com> <01da01c2066f$3ed63f40$10eca8c0@grendel> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Kevin D. Kissell wrote: >>Dan Malek also wrote a driver for MQ200. I can't really take credit for that :-). It was a bunch of code from various places I just turned into a driver. > I *am* asking around - that's why I started this thread. Look at some of the stuff from Epson. You may find something there. > So it sounds like the Matrox G450 PCI is really the only > game in town... It very well may be the only option. I've been working with "standard" graphic cards/chips for embedded devices for quite some time. The latest technology is always quite secret, seldom even available under NDA. Most of the cards I have used come from the $5 cardboard box in one of the electronic salvage yards in Silicon Valley. Something so old they will tell you about the registers on the board :-) -- Dan From owner-linux-mips@oss.sgi.com Tue May 28 15:51:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4SMpDnC031836 for ; Tue, 28 May 2002 15:51:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4SMpDLo031835 for linux-mips-outgoing; Tue, 28 May 2002 15:51:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from irongate.swansea.linux.org.uk (pc2-cwma1-5-cust12.swa.cable.ntl.com [80.5.121.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4SMpAnC031829 for ; Tue, 28 May 2002 15:51:11 -0700 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.2/8.11.6) with ESMTP id g4SNsiZ1010510; Wed, 29 May 2002 00:54:50 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g4SNsSfZ010508; Wed, 29 May 2002 00:54:28 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: PCI Graphics/Video Card for Malta Board? From: Alan Cox To: Dan Malek Cc: "Kevin D. Kissell" , Jun Sun , Geert Uytterhoeven , "Steven J. Hill" , Linux/MIPS Development In-Reply-To: <3CF40273.1000801@embeddededge.com> References: <3CF3B72B.4020600@mvista.com> <01da01c2066f$3ed63f40$10eca8c0@grendel> <3CF40273.1000801@embeddededge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 29 May 2002 00:54:27 +0100 Message-Id: <1022630067.9255.146.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Old S3 cards are very easy to configure. 3Dfx Voodoo 2 is great as we have full code to configure it -and- it can do 3D. Alas no utah-glx support so you can't do X with 3d on it right now. From owner-linux-mips@oss.sgi.com Wed May 29 01:18:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4T8IUnC022249 for ; Wed, 29 May 2002 01:18:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4T8IT9k022248 for linux-mips-outgoing; Wed, 29 May 2002 01:18:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4T8IPnC022244 for ; Wed, 29 May 2002 01:18:26 -0700 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA07277; Wed, 29 May 2002 10:17:49 +0200 (MET DST) Date: Wed, 29 May 2002 10:17:48 +0200 (MEST) From: Geert Uytterhoeven To: Alan Cox cc: Dan Malek , "Kevin D. Kissell" , Jun Sun , "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? In-Reply-To: <1022630067.9255.146.camel@irongate.swansea.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On 29 May 2002, Alan Cox wrote: > Old S3 cards are very easy to configure. 3Dfx Voodoo 2 is great as we I guess that's why we still don't have working frame buffer devices for them? There are at least 3 frame buffer devices for the Trio floating around the net, but none of them work on my cards. Of course I'm part of the problem myself, since I never got anything out of the Vision968 and Trio64V+ in my PPC box. Except by emulating the BIOS code and using vga16fb... 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 Wed May 29 03:16:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TAG0nC003076 for ; Wed, 29 May 2002 03:16:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TAG0vn003075 for linux-mips-outgoing; Wed, 29 May 2002 03:16:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TAFvnC003071 for ; Wed, 29 May 2002 03:15:58 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.2/8.12.2/Debian -5) with ESMTP id g4TAHHtS005719 for ; Wed, 29 May 2002 12:17:18 +0200 Message-ID: <3CF4AAAD.7070504@murphy.dk> Date: Wed, 29 May 2002 12:17:17 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: New platforms Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, I have a port of linux-mips to the Lasat (later Eicon) platform(s) - based on vr4300, vr5000 and vr4120 chips. I would very much like to have the code incorporated in the CVS at OSS. How do I go about this? /Brian From owner-linux-mips@oss.sgi.com Wed May 29 03:45:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TAjgnC003367 for ; Wed, 29 May 2002 03:45:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TAjg5O003366 for linux-mips-outgoing; Wed, 29 May 2002 03:45:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TAjanC003361 for ; Wed, 29 May 2002 03:45:36 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.2/8.12.2/Debian -5) with ESMTP id g4TAkvtS006767 for ; Wed, 29 May 2002 12:46:57 +0200 Message-ID: <3CF4B1A1.3000607@murphy.dk> Date: Wed, 29 May 2002 12:46:57 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: pcnet32.c bug? Content-Type: multipart/mixed; boundary="------------070203020806000606040209" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------070203020806000606040209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If I don't apply the following patch to pcnet32.c then the network connection on my vr5000 box is extremely jerky. It also seems quite sensible to have a dma sync operation here. any comments? /Brian --------------070203020806000606040209 Content-Type: text/plain; name="pcnet32.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pcnet32.diff" --- drivers/net/pcnet32.c 19 Mar 2002 16:40:55 -0000 1.1.1.1.2.1.2.6 +++ drivers/net/pcnet32.c 29 May 2002 09:57:33 -0000 1.13.4.2 @@ -1343,6 +1351,10 @@ if (!rx_in_place) { skb_reserve(skb,2); /* 16 byte align */ skb_put(skb,pkt_len); /* Make room */ + pci_dma_sync_single(lp->pci_dev, + lp->rx_skbuff[entry]->tail, + pkt_len, + PCI_DMA_FROMDEVICE); eth_copy_and_sum(skb, (unsigned char *)(lp->rx_skbuff[entry]->tail), pkt_len,0); --------------070203020806000606040209-- From owner-linux-mips@oss.sgi.com Wed May 29 04:45:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TBjwnC008489 for ; Wed, 29 May 2002 04:45:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TBjwVI008488 for linux-mips-outgoing; Wed, 29 May 2002 04:45:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from irongate.swansea.linux.org.uk (pc2-cwma1-5-cust12.swa.cable.ntl.com [80.5.121.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TBjsnC008484 for ; Wed, 29 May 2002 04:45:55 -0700 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.2/8.11.6) with ESMTP id g4TCo0Z1012278; Wed, 29 May 2002 13:50:01 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g4TCnw0Q012270; Wed, 29 May 2002 13:49:58 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: PCI Graphics/Video Card for Malta Board? From: Alan Cox To: Geert Uytterhoeven Cc: Dan Malek , "Kevin D. Kissell" , Jun Sun , "Steven J. Hill" , Linux/MIPS Development In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 29 May 2002 13:49:58 +0100 Message-Id: <1022676598.4124.165.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 2002-05-29 at 09:17, Geert Uytterhoeven wrote: > On 29 May 2002, Alan Cox wrote: > > Old S3 cards are very easy to configure. 3Dfx Voodoo 2 is great as we > Of course I'm part of the problem myself, since I never got anything out of the > Vision968 and Trio64V+ in my PPC box. Except by emulating the BIOS code and > using vga16fb... I've had no problem with Russell King's ARM code. And for the 3dfx voodoo2 (UKP 9 off ebay) none at all. The voodoo seems to have always been designed to be totally soft configured and as its not a primary video card the bios/firmware all leaves it alone From owner-linux-mips@oss.sgi.com Wed May 29 05:32:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TCW4nC010310 for ; Wed, 29 May 2002 05:32:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TCW4Co010309 for linux-mips-outgoing; Wed, 29 May 2002 05:32:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TCVsnC008829 for ; Wed, 29 May 2002 05:31:55 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.2/8.12.2/Debian -5) with ESMTP id g4TCXGtS010463 for ; Wed, 29 May 2002 14:33:16 +0200 Message-ID: <3CF4CA8C.9040802@murphy.dk> Date: Wed, 29 May 2002 14:33:16 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: ioremap? Content-Type: multipart/mixed; boundary="------------060405030301000005000902" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------060405030301000005000902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In three files/drivers I have had problems with physical addresses not being ioremapped. I include my patch to fix things up and request comments. How come others don't have similar problems? /Brian --------------060405030301000005000902 Content-Type: text/plain; name="ioremap.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ioremap.diff" --- drivers/ide/ide-dma.c 2001/10/19 01:24:24 1.9 +++ drivers/ide/ide-dma.c 2002/05/29 11:49:14 @@ -741,7 +741,8 @@ if (hwif->mate && hwif->mate->dma_base) { dma_base = hwif->mate->dma_base - (hwif->channel ? 0 : 8); } else { - dma_base = pci_resource_start(dev, 4); + dma_base = ioremap(pci_resource_start(dev, 4), + pci_resource_len(dev, 4)); if (!dma_base) { printk("%s: dma_base is invalid (0x%04lx)\n", name, dma_base); dma_base = 0; --- drivers/ide/ide-pci.c 2001/11/19 13:53:59 1.20 +++ drivers/ide/ide-pci.c 2002/05/29 11:49:15 @@ -716,8 +716,10 @@ if (IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT366) && (port) && (class_rev < 0x03)) return; if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE || (dev->class & (port ? 4 : 1)) != 0) { - ctl = dev->resource[(2*port)+1].start; - base = dev->resource[2*port].start; + ctl = ioremap(pci_resource_start(dev, (2*port)+1), + pci_resource_len(dev, (2*port)+1)); + base = ioremap(pci_resource_start(dev, 2*port), + pci_resource_len(dev, 2*port)); if (!(ctl & PCI_BASE_ADDRESS_IO_MASK) || !(base & PCI_BASE_ADDRESS_IO_MASK)) { printk("%s: IO baseregs (BIOS) are reported as MEM, report to .\n", d->name); --- drivers/net/pcnet32.c 2002/02/26 05:59:35 1.33.2.1 +++ drivers/net/pcnet32.c 2002/05/29 11:49:18 @@ -494,7 +494,8 @@ } pci_set_master(pdev); - ioaddr = pci_resource_start (pdev, 0); + ioaddr = ioremap(pci_resource_start (pdev, 0), + pci_resource_len (pdev, 0)); printk(KERN_INFO " ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr, pci_resource_flags (pdev, 0)); if (!ioaddr) { printk (KERN_ERR "no PCI IO resources, aborting\n"); --------------060405030301000005000902-- From owner-linux-mips@oss.sgi.com Wed May 29 07:42:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TEgvnC014819 for ; Wed, 29 May 2002 07:42:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TEgv1t014818 for linux-mips-outgoing; Wed, 29 May 2002 07:42:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TEgpnC014815 for ; Wed, 29 May 2002 07:42:52 -0700 Received: from [192.168.2.2] (IDENT:root@earth.ayrnetworks.com [10.1.1.24]) by ayrnetworks.com (8.11.6/8.11.2) with ESMTP id g4TEi3o12883; Wed, 29 May 2002 07:44:03 -0700 Mime-Version: 1.0 X-Sender: kph@192.168.2.1 Message-Id: In-Reply-To: <3CF4B1A1.3000607@murphy.dk> References: <3CF4B1A1.3000607@murphy.dk> Date: Wed, 29 May 2002 07:43:52 -0700 To: Brian Murphy , linux-mips From: Kevin Paul Herbert Subject: Re: pcnet32.c bug? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Yes, this fix is correct... I made the same patch locally... sorry we haven't submited it yet... turns out we've dropeed this one from our own latest sources; thanks for the reminder. :-) Note that there is another problem with cache line invalidation and the use of pci_dma_sync_single(), where one can get stale entries in the cache when the buffer is next re-used for DMA. My co-worker Will Jhun just sent e-mail on the subject of problems with the cache invalidation routines last Saturday, with Message-ID: <20020525131806.A4073@ayrnetworks.com> Kevin At 12:46 PM +0200 5/29/02, Brian Murphy wrote: >If I don't apply the following patch to pcnet32.c then the network connection >on my vr5000 box is extremely jerky. It also seems quite sensible to have a >dma sync operation here. > >any comments? > >/Brian > > >--- drivers/net/pcnet32.c 19 Mar 2002 16:40:55 -0000 1.1.1.1.2.1.2.6 >+++ drivers/net/pcnet32.c 29 May 2002 09:57:33 -0000 1.13.4.2 >@@ -1343,6 +1351,10 @@ > if (!rx_in_place) { > skb_reserve(skb,2); /* 16 byte align */ > skb_put(skb,pkt_len); /* Make room */ >+ pci_dma_sync_single(lp->pci_dev, >+ lp->rx_skbuff[entry]->tail, >+ pkt_len, >+ PCI_DMA_FROMDEVICE); > eth_copy_and_sum(skb, > (unsigned char >*)(lp->rx_skbuff[entry]->tail), > pkt_len,0); -- From owner-linux-mips@oss.sgi.com Wed May 29 09:08:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TG8YnC021838 for ; Wed, 29 May 2002 09:08:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TG8YBI021837 for linux-mips-outgoing; Wed, 29 May 2002 09:08:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TG8GnC021834 for ; Wed, 29 May 2002 09:08:20 -0700 Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17D5zG-000582-00; Wed, 29 May 2002 12:07:46 -0400 Message-ID: <009701c2072b$2b1e2820$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Brian Murphy" , "linux-mips" References: <3CF4CA8C.9040802@murphy.dk> Subject: Re: ioremap? Date: Wed, 29 May 2002 12:09:10 -0400 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 Looks like those are for io (inb, outb, etc.) not mem (readb, writeb, etc.). io addresses shouldn't be ioremapped. Regards, Brad ----- Original Message ----- From: "Brian Murphy" To: "linux-mips" Sent: Wednesday, May 29, 2002 8:33 AM Subject: ioremap? > In three files/drivers I have had problems with physical addresses not > being ioremapped. > I include my patch to fix things up and request comments. How come > others don't have similar > problems? > > /Brian > ---------------------------------------------------------------------------- ---- > --- drivers/ide/ide-dma.c 2001/10/19 01:24:24 1.9 > +++ drivers/ide/ide-dma.c 2002/05/29 11:49:14 > @@ -741,7 +741,8 @@ > if (hwif->mate && hwif->mate->dma_base) { > dma_base = hwif->mate->dma_base - (hwif->channel ? 0 : 8); > } else { > - dma_base = pci_resource_start(dev, 4); > + dma_base = ioremap(pci_resource_start(dev, 4), > + pci_resource_len(dev, 4)); > if (!dma_base) { > printk("%s: dma_base is invalid (0x%04lx)\n", name, dma_base); > dma_base = 0; > --- drivers/ide/ide-pci.c 2001/11/19 13:53:59 1.20 > +++ drivers/ide/ide-pci.c 2002/05/29 11:49:15 > @@ -716,8 +716,10 @@ > if (IDE_PCI_DEVID_EQ(d->devid, DEVID_HPT366) && (port) && (class_rev < 0x03)) > return; > if ((dev->class >> 8) != PCI_CLASS_STORAGE_IDE || (dev->class & (port ? 4 : 1)) != 0) { > - ctl = dev->resource[(2*port)+1].start; > - base = dev->resource[2*port].start; > + ctl = ioremap(pci_resource_start(dev, (2*port)+1), > + pci_resource_len(dev, (2*port)+1)); > + base = ioremap(pci_resource_start(dev, 2*port), > + pci_resource_len(dev, 2*port)); > if (!(ctl & PCI_BASE_ADDRESS_IO_MASK) || > !(base & PCI_BASE_ADDRESS_IO_MASK)) { > printk("%s: IO baseregs (BIOS) are reported as MEM, report to .\n", d->name); > --- drivers/net/pcnet32.c 2002/02/26 05:59:35 1.33.2.1 > +++ drivers/net/pcnet32.c 2002/05/29 11:49:18 > @@ -494,7 +494,8 @@ > } > pci_set_master(pdev); > > - ioaddr = pci_resource_start (pdev, 0); > + ioaddr = ioremap(pci_resource_start (pdev, 0), > + pci_resource_len (pdev, 0)); > printk(KERN_INFO " ioaddr=%#08lx resource_flags=%#08lx\n", ioaddr, pci_resource_flags (pdev, 0)); > if (!ioaddr) { > printk (KERN_ERR "no PCI IO resources, aborting\n"); > > From owner-linux-mips@oss.sgi.com Wed May 29 09:13:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TGDNnC021958 for ; Wed, 29 May 2002 09:13:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TGDNFb021957 for linux-mips-outgoing; Wed, 29 May 2002 09:13:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TGDJnC021954 for ; Wed, 29 May 2002 09:13:20 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id UAA24249 for ; Wed, 29 May 2002 20:14:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id UAA06469 for linux-mips@oss.sgi.com; Wed, 29 May 2002 20:06:43 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id UAA28375 for ; Wed, 29 May 2002 20:11:58 +0400 (MSK) Message-ID: <3CF56FDF.8090303@niisi.msk.ru> Date: Wed, 29 May 2002 20:18:39 -0400 From: Alexandr Andreev Organization: niisi User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.17 i686; en-US; rv:0.9) Gecko/20010507 X-Accept-Language: ru, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 References: <3CEEBBA9.5070809@niisi.msk.ru> <3CEEAC5F.6010802@mvista.com> <3CF2A17D.6050207@niisi.msk.ru> <3CF3BB4B.504@mvista.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > > I would be also interested to know if removing filp condition would > solve your problem. Nobody has explained why this condition is needed > for doing COLOUR_ALIGN(). > Removing of filp condition solves the problem too. So, as I understand, I need to remove filp condition instead of fix COLOUR_ALIGN(), isn't it? And what about that patch of local_flush_tlb_page(), will anybody apply it to CVS? From owner-linux-mips@oss.sgi.com Wed May 29 09:49:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TGnWnC023626 for ; Wed, 29 May 2002 09:49:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TGnWCf023625 for linux-mips-outgoing; Wed, 29 May 2002 09:49:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TGnQnC023622 for ; Wed, 29 May 2002 09:49:26 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 29 May 2002 09:50:26 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4TGor1S029298 for ; Wed, 29 May 2002 09:50:53 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4TGorn07849; Wed, 29 May 2002 09:50:53 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: __flush_cache_all() miscellany From: "Justin Carlson" To: linux-mips@oss.sgi.com X-Mailer: Ximian Evolution 1.0.5 Date: 29 May 2002 09:50:52 -0700 Message-ID: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10EBD958841367-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Looking at the cache routines, I've noticed that there's been a relatively recent introduction of a __flush_cache_all() routine. Looking at oss.sgi.com's cvs logs, I see this comment: >Introduce __flush_cache_all() which flushes the cache no matter if >this operation is necessary from the mm point of view or not. Some questions: Which caches does this apply to? It looks like the current implementations assume L1 only. Would anyone have a problem with renaming this function? To me, at least, it's rather confusing to have all of: flush_cache_all() _flush_cache_all() __flush_cache_all() ___flush_cache_all() defined, especially when the latter two mean something significantly different from the former two. I'd prefer calling the new one {_}force_flush_l1_caches() or somesuch. In a related note, one of the few places this routine is called is the kgdb stub routines (in arch/mips/kernel/gdb-stub.c): void set_async_breakpoint(unsigned int epc) { int cpu = smp_processor_id(); async_bp[cpu].addr = epc; async_bp[cpu].val = *(unsigned *)epc; *(unsigned *)epc = BP; __flush_cache_all(); } Shouldn't that be a flush_icache_range() call anyways? Thanks, Justin From owner-linux-mips@oss.sgi.com Wed May 29 10:04:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TH4BnC023930 for ; Wed, 29 May 2002 10:04:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TH4BND023929 for linux-mips-outgoing; Wed, 29 May 2002 10:04:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TH47nC023926 for ; Wed, 29 May 2002 10:04:08 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.2/8.12.2/Debian -5) with ESMTP id g4TH5UtS019566 for ; Wed, 29 May 2002 19:05:30 +0200 Message-ID: <3CF50A5A.9020807@murphy.dk> Date: Wed, 29 May 2002 19:05:30 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips Subject: Re: ioremap? References: <3CF4CA8C.9040802@murphy.dk> <009701c2072b$2b1e2820$4c00a8c0@prefect> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Bradley D. LaRonde wrote: >Looks like those are for io (inb, outb, etc.) not mem (readb, writeb, etc.). >io addresses shouldn't be ioremapped. > O.K. I have now used set_io_port_base to set the base address to KSEG1. What should be ioremapped then? /Brian From owner-linux-mips@oss.sgi.com Wed May 29 11:22:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TIMpnC025058 for ; Wed, 29 May 2002 11:22:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TIMppB025057 for linux-mips-outgoing; Wed, 29 May 2002 11:22:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TILjnC025039 for ; Wed, 29 May 2002 11:21:45 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020529182307.MPLG2751.rwcrmhc52.attbi.com@ocean.lucon.org>; Wed, 29 May 2002 18:23:07 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8B86D125C3; Wed, 29 May 2002 11:23:01 -0700 (PDT) Date: Wed, 29 May 2002 11:23:01 -0700 From: "H . J . Lu" To: Shiyi Ma Cc: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , debianbin@lucon.org, Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , GNU C Library , gcc@gcc.gnu.org Subject: The Linux binutils 2.12.90.0.9 is released. Message-ID: <20020529112301.A15144@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.12.90.0.9 for Linux, which is based on binutils 2002 0526 in CVS on sourecs.redhat.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.12.90.0.9 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.12.90.0.7: 1. Update from binutils 2002 0526. 2. Support "-z muldefs". Changes from binutils 2.12.90.0.4: 1. Update from binutils 2002 0423. 2. ELF EH frame bug fix. 3. MIPS ELF visibility bug fix. Changes from binutils 2.12.90.0.3: 1. Update from binutils 2002 0408. 2. Bug fixes for ELF/sparc. 3. Bug fixes for ELF/CRIS. Changes from binutils 2.12.90.0.1: 1. Update from binutils 2002 0323. 2. Fix linking a.out relocatable files with ELF. 3. Fix a PPC altivec assembler bug. Changes from binutils 2.11.93.0.2: 1. Update from binutils 2002 0307. 2. Add the .preinit_array/.init_array/.fini_array support. 3. Fix eh_frame. 4. Turn on combreloc by default. 5. Enable gprof for Linux/mips. Changes from binutils 2.11.92.0.12.3: 1. Update from binutils 2002 0207. 2. Fix a weak symbol alpha linker bug for glibc. 3. More support for gcc 3.1. Changes from binutils 2.11.92.0.12: 1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object files. Changes from binutils 2.11.92.0.10: 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. If you still see things like drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit' in the final kernel link, that means you have compiled a driver into the kernel which has a reference to the symbol in a discarded section. Kernel 2.4.17 or above should work fine. 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.12.90.0.9.tar.gz. Source code. 2. binutils-2.12.90.0.7-2.12.90.0.9.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.9-1.i386.rpm. IA-32 binary RPM for RedHat 7.3. There is no separate source rpm. You can do # rpm -ta binutils-2.12.90.0.9.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 04/29/2002 From owner-linux-mips@oss.sgi.com Wed May 29 11:41:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TIfnnC025466 for ; Wed, 29 May 2002 11:41:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TIfntC025465 for linux-mips-outgoing; Wed, 29 May 2002 11:41:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TIfjnC025462 for ; Wed, 29 May 2002 11:41:45 -0700 Received: from lahoo.mshome.net (vsat-148-63-243-254.c004.g4.mrt.starband.net [148.63.243.254]) 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 LAA02191 for ; Wed, 29 May 2002 11:42:57 -0700 (PDT) mail_from (brad@ltc.com) Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17D7BN-0005CP-00; Wed, 29 May 2002 13:24:21 -0400 Message-ID: <00fd01c20735$de410760$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Brian Murphy" Cc: "linux-mips" References: <3CF4CA8C.9040802@murphy.dk> <009701c2072b$2b1e2820$4c00a8c0@prefect> <3CF50A5A.9020807@murphy.dk> Subject: Re: ioremap? Date: Wed, 29 May 2002 13:25:45 -0400 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 ----- Original Message ----- From: "Brian Murphy" Cc: "linux-mips" Sent: Wednesday, May 29, 2002 1:05 PM Subject: Re: ioremap? > Bradley D. LaRonde wrote: > > >Looks like those are for io (inb, outb, etc.) not mem (readb, writeb, etc.). > >io addresses shouldn't be ioremapped. > > > O.K. I have now used set_io_port_base to set the base address to KSEG1. > What should be ioremapped then? Any address passed to readb, writeb, etc. For example, a PCI mem resource address. Regards, Brad From owner-linux-mips@oss.sgi.com Wed May 29 12:26:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TJQJnC026720 for ; Wed, 29 May 2002 12:26:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TJQJcj026719 for linux-mips-outgoing; Wed, 29 May 2002 12:26:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TJP1nC026696; Wed, 29 May 2002 12:25:02 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Wed, 29 May 2002 12:26:27 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4TJQT1S002193; Wed, 29 May 2002 12:26:29 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4TJQTN08360; Wed, 29 May 2002 12:26:29 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Re: __flush_cache_all() miscellany From: "Justin Carlson" To: linux-mips@oss.sgi.com cc: ralf@oss.sgi.com In-Reply-To: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> X-Mailer: Ximian Evolution 1.0.5 Date: 29 May 2002 12:26:29 -0700 Message-ID: <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10EBF4E8908394-01-01 Content-Type: multipart/mixed; boundary="=-Xa1GCNyIzk6j4NZOBlXP" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-Xa1GCNyIzk6j4NZOBlXP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a patch against cvs that does the rename. Unless anyone has objections, Ralf, could you apply this? While doing this, I've noticed that the whole mips tree is horribly inconsistent in terms of the cache flushing syscalls (sys_cacheflush and sys_sysmips->CACHE_FLUSH). Here's what the different ports appear to flush given one of these syscall: andes: l1 and l2 lexra: l1 icache mips32: l1 icache/dcache r3k: l1 icache r4k: l1 icache/dcache r5432: l1 icache/dcache r5900: l1 icache/dcache rm7k: l1 icache/dcache sb1: l1 icache/dcache sr7100: l1 and l2 tx39: l1 icache tx49: li icache/dcache Some of these are blatantly wrong with respect to the cacheflush syscall; it defines flags for flushing the icache, dcache, or both. In the latter two cases, the lexra, r3k, and tx39 are not doing what was requested. I doubt this matters for any significant userspace app, but it would be nice to at least be consistent. As for the sysmips system call, I've not been able to dig up the semantics. (Actually, I don't really see why we have both ways of flushing the cache at all...some historical cruft?). Anyone have a helpful pointer to docs on the subject? Thanks, Justin --=-Xa1GCNyIzk6j4NZOBlXP Content-Disposition: attachment; filename=rename___flush_cache_all.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; name=rename___flush_cache_all.patch ? rename___flush_cache_all.patch Index: arch/mips/kernel/gdb-stub.c =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: /cvsroot/linux-mips/linux/arch/mips/kernel/gdb-stub.c,v retrieving revision 1.7 diff -u -r1.7 gdb-stub.c --- arch/mips/kernel/gdb-stub.c 9 May 2002 17:22:34 -0000 1.7 +++ arch/mips/kernel/gdb-stub.c 29 May 2002 19:00:41 -0000 @@ -578,7 +578,7 @@ async_bp.addr =3D epc; async_bp.val =3D *(unsigned *)epc; *(unsigned *)epc =3D BP; - __flush_cache_all(); + force_flush_cache_all(); } =20 =20 @@ -805,7 +805,7 @@ * NB: We flush both caches, just to be sure... */ =20 - __flush_cache_all(); + force_flush_cache_all(); return; /* NOTREACHED */ break; @@ -834,7 +834,7 @@ * use breakpoints and continue, instead. */ single_step(regs); - __flush_cache_all(); + force_flush_cache_all(); return; /* NOTREACHED */ =20 Index: arch/mips/kernel/sysmips.c =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: /cvsroot/linux-mips/linux/arch/mips/kernel/sysmips.c,v retrieving revision 1.10 diff -u -r1.10 sysmips.c --- arch/mips/kernel/sysmips.c 26 Nov 2001 19:18:13 -0000 1.10 +++ arch/mips/kernel/sysmips.c 29 May 2002 19:00:41 -0000 @@ -84,7 +84,7 @@ goto out; =20 case FLUSH_CACHE: - __flush_cache_all(); + force_flush_cache_all(); retval =3D 0; goto out; =20 Index: arch/mips/mm/c-andes.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-andes.c,v retrieving revision 1.4 diff -u -r1.4 c-andes.c --- arch/mips/mm/c-andes.c 19 Feb 2002 17:43:02 -0000 1.4 +++ arch/mips/mm/c-andes.c 29 May 2002 19:00:41 -0000 @@ -70,7 +70,7 @@ } } =20 -static void andes___flush_cache_all(void) +static void andes_force_flush_cache_all(void) { andes_flush_cache_l1(); andes_flush_cache_l2(); @@ -105,7 +105,7 @@ _copy_page =3D andes_copy_page; =20 _flush_cache_all =3D andes_flush_cache_all; - ___flush_cache_all =3D andes___flush_cache_all; + _force_flush_cache_all =3D andes_force_flush_cache_all; _flush_cache_mm =3D andes_flush_cache_mm; _flush_cache_page =3D andes_flush_cache_page; _flush_page_to_ram =3D andes_flush_page_to_ram; Index: arch/mips/mm/c-lexra.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-lexra.c,v retrieving revision 1.1 diff -u -r1.1 c-lexra.c --- arch/mips/mm/c-lexra.c 9 May 2002 17:22:35 -0000 1.1 +++ arch/mips/mm/c-lexra.c 29 May 2002 19:00:42 -0000 @@ -282,7 +282,7 @@ dcache_size =3D 1024 * 2; =20 _flush_cache_all =3D lx_flush_cache_all; - ___flush_cache_all =3D lx_flush_cache_all;=20 + _force_flush_cache_all =3D lx_flush_cache_all;=20 _flush_cache_mm =3D lx_flush_cache_mm; _flush_cache_range =3D lx_flush_cache_range; _flush_cache_page =3D lx_flush_cache_page; Index: arch/mips/mm/c-mips32.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-mips32.c,v retrieving revision 1.4 diff -u -r1.4 c-mips32.c --- arch/mips/mm/c-mips32.c 28 Jan 2002 23:15:25 -0000 1.4 +++ arch/mips/mm/c-mips32.c 29 May 2002 19:00:42 -0000 @@ -590,7 +590,7 @@ _clear_page =3D (void *)mips32_clear_page_dc; _copy_page =3D (void *)mips32_copy_page_dc; _flush_cache_all =3D mips32_flush_cache_all_pc; - ___flush_cache_all =3D mips32_flush_cache_all_pc; + _force_flush_cache_all =3D mips32_flush_cache_all_pc; _flush_cache_mm =3D mips32_flush_cache_mm_pc; _flush_cache_range =3D mips32_flush_cache_range_pc; _flush_cache_page =3D mips32_flush_cache_page_pc; @@ -606,7 +606,7 @@ static void __init setup_scache_funcs(void) { _flush_cache_all =3D mips32_flush_cache_all_sc; - ___flush_cache_all =3D mips32_flush_cache_all_sc; + _force_flush_cache_all =3D mips32_flush_cache_all_sc; _flush_cache_mm =3D mips32_flush_cache_mm_sc; _flush_cache_range =3D mips32_flush_cache_range_sc; _flush_cache_page =3D mips32_flush_cache_page_sc; @@ -666,5 +666,5 @@ _flush_cache_sigtramp =3D mips32_flush_cache_sigtramp; _flush_icache_range =3D mips32_flush_icache_range; /* Ouch */ =20 - __flush_cache_all(); + force_flush_cache_all(); } Index: arch/mips/mm/c-r3k.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-r3k.c,v retrieving revision 1.6 diff -u -r1.6 c-r3k.c --- arch/mips/mm/c-r3k.c 19 Feb 2002 17:37:17 -0000 1.6 +++ arch/mips/mm/c-r3k.c 29 May 2002 19:00:42 -0000 @@ -240,7 +240,7 @@ { } =20 -static inline void r3k___flush_cache_all(void) +static inline void r3k_force_flush_cache_all(void) { r3k_flush_icache_range(KSEG0, KSEG0 + icache_size); } @@ -328,7 +328,7 @@ r3k_probe_cache(); =20 _flush_cache_all =3D r3k_flush_cache_all; - ___flush_cache_all =3D r3k___flush_cache_all; + _force_flush_cache_all =3D r3k_force_flush_cache_all; _flush_cache_mm =3D r3k_flush_cache_mm; _flush_cache_range =3D r3k_flush_cache_range; _flush_cache_page =3D r3k_flush_cache_page; Index: arch/mips/mm/c-r4k.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.9 diff -u -r1.9 c-r4k.c --- arch/mips/mm/c-r4k.c 28 May 2002 21:03:31 -0000 1.9 +++ arch/mips/mm/c-r4k.c 29 May 2002 19:00:42 -0000 @@ -1362,7 +1362,7 @@ _flush_cache_page =3D r4k_flush_cache_page_d32i32; break; } - ___flush_cache_all =3D _flush_cache_all; + _force_flush_cache_all =3D _flush_cache_all; =20 _flush_icache_page =3D r4k_flush_icache_page_p; #ifdef CONFIG_NONCOHERENT_IO @@ -1448,7 +1448,7 @@ _copy_page =3D r4k_copy_page_s128; break; } - ___flush_cache_all =3D _flush_cache_all; + _force_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; @@ -1504,5 +1504,5 @@ _flush_cache_sigtramp =3D r4600v20k_flush_cache_sigtramp; } =20 - __flush_cache_all(); + force_flush_cache_all(); } Index: arch/mips/mm/c-r5432.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-r5432.c,v retrieving revision 1.6 diff -u -r1.6 c-r5432.c --- arch/mips/mm/c-r5432.c 30 Nov 2001 18:34:09 -0000 1.6 +++ arch/mips/mm/c-r5432.c 29 May 2002 19:00:42 -0000 @@ -463,7 +463,7 @@ _clear_page =3D r5432_clear_page_d32; _copy_page =3D r5432_copy_page_d32; _flush_cache_all =3D r5432_flush_cache_all_d32i32; - ___flush_cache_all =3D r5432_flush_cache_all_d32i32; + _force_flush_cache_all =3D r5432_flush_cache_all_d32i32; _flush_page_to_ram =3D r5432_flush_page_to_ram_d32; _flush_cache_mm =3D r5432_flush_cache_mm_d32i32; _flush_cache_range =3D r5432_flush_cache_range_d32i32; @@ -476,5 +476,5 @@ _flush_cache_sigtramp =3D r5432_flush_cache_sigtramp; _flush_icache_range =3D r5432_flush_icache_range; /* Ouch */ =20 - __flush_cache_all(); + force_flush_cache_all(); } Index: arch/mips/mm/c-r5900.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-r5900.c,v retrieving revision 1.2 diff -u -r1.2 c-r5900.c --- arch/mips/mm/c-r5900.c 27 Nov 2001 17:53:47 -0000 1.2 +++ arch/mips/mm/c-r5900.c 29 May 2002 19:00:42 -0000 @@ -307,7 +307,7 @@ _flush_cache_range =3D r5900_flush_cache_range_d64i64; _flush_cache_page =3D r5900_flush_cache_page_d64i64; =20 - ___flush_cache_all =3D _flush_cache_all; + _force_flush_cache_all =3D _flush_cache_all; _flush_icache_range =3D r5900_flush_icache_range_i64; _flush_icache_page =3D r5900_flush_icache_page_i64; /* FIXME */ =20 Index: arch/mips/mm/c-rm7k.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-rm7k.c,v retrieving revision 1.5 diff -u -r1.5 c-rm7k.c --- arch/mips/mm/c-rm7k.c 21 Apr 2002 20:01:13 -0000 1.5 +++ arch/mips/mm/c-rm7k.c 29 May 2002 19:00:42 -0000 @@ -66,7 +66,7 @@ "i" (Page_Invalidate_T)); } =20 -static void __flush_cache_all_d32i32(void) +static void force_flush_cache_all_d32i32(void) { blast_dcache32(); blast_icache32(); @@ -105,7 +105,7 @@ /* * FIXME: This is overdoing things and harms performance. */ - __flush_cache_all_d32i32(); + force_flush_cache_all_d32i32(); } =20 static void rm7k_flush_icache_page(struct vm_area_struct *vma, @@ -116,7 +116,7 @@ * temporary mapping and use hit_invalidate operation to flush out * the line from the cache. */ - __flush_cache_all_d32i32(); + force_flush_cache_all_d32i32(); } =20 =20 @@ -331,7 +331,7 @@ _copy_page =3D rm7k_copy_page; =20 _flush_cache_all =3D rm7k_flush_cache_all_d32i32; - ___flush_cache_all =3D __flush_cache_all_d32i32; + _force_flush_cache_all =3D force_flush_cache_all_d32i32; _flush_cache_mm =3D rm7k_flush_cache_mm_d32i32; _flush_cache_range =3D rm7k_flush_cache_range_d32i32; _flush_cache_page =3D rm7k_flush_cache_page_d32i32; @@ -344,5 +344,5 @@ _dma_cache_wback =3D rm7k_dma_cache_wback; _dma_cache_inv =3D rm7k_dma_cache_inv; =20 - __flush_cache_all_d32i32(); + force_flush_cache_all_d32i32(); } Index: arch/mips/mm/c-sb1.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-sb1.c,v retrieving revision 1.14 diff -u -r1.14 c-sb1.c --- arch/mips/mm/c-sb1.c 21 Apr 2002 20:01:13 -0000 1.14 +++ arch/mips/mm/c-sb1.c 29 May 2002 19:00:42 -0000 @@ -74,7 +74,7 @@ { } =20 -static void local_sb1___flush_cache_all(void) +static void local_sb1_force_flush_cache_all(void) { /* * Haven't worried too much about speed here; given that we're flushing @@ -126,17 +126,17 @@ } =20 #ifdef CONFIG_SMP -extern void sb1___flush_cache_all_ipi(void *ignored); -asm("sb1___flush_cache_all_ipi =3D local_sb1___flush_cache_all"); +extern void sb1_force_flush_cache_all_ipi(void *ignored); +asm("sb1_force_flush_cache_all_ipi =3D local_sb1_force_flush_cache_all"); =20 -static void sb1___flush_cache_all(void) +static void sb1_force_flush_cache_all(void) { - smp_call_function(sb1___flush_cache_all_ipi, 0, 1, 1); - local_sb1___flush_cache_all(); + smp_call_function(sb1_force_flush_cache_all_ipi, 0, 1, 1); + local_sb1_force_flush_cache_all(); } #else -extern void sb1___flush_cache_all(void); -asm("sb1___flush_cache_all =3D local_sb1___flush_cache_all"); +extern void sb1_force_flush_cache_all(void); +asm("sb1_force_flush_cache_all =3D local_sb1_force_flush_cache_all"); #endif =20 =20 @@ -257,7 +257,7 @@ * conservatively flush the entire caches on all processors * (ouch). */ - sb1___flush_cache_all(); + sb1_force_flush_cache_all(); } =20 static inline void protected_flush_icache_line(unsigned long addr) @@ -506,7 +506,7 @@ _copy_page =3D sb1_copy_page; =20 _flush_cache_all =3D sb1_flush_cache_all; - ___flush_cache_all =3D sb1___flush_cache_all; + _force_flush_cache_all =3D sb1_force_flush_cache_all; _flush_cache_mm =3D (void (*)(struct mm_struct *))sb1_nop; _flush_cache_range =3D (void *) sb1_nop; _flush_page_to_ram =3D sb1_flush_page_to_ram; Index: arch/mips/mm/c-sr7100.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-sr7100.c,v retrieving revision 1.1 diff -u -r1.1 c-sr7100.c --- arch/mips/mm/c-sr7100.c 19 Jan 2002 21:17:35 -0000 1.1 +++ arch/mips/mm/c-sr7100.c 29 May 2002 19:00:42 -0000 @@ -419,7 +419,7 @@ static void __init setup_scache_funcs(void) { _flush_cache_all =3D sr7100_flush_cache_all_pc; - ___flush_cache_all =3D sr7100_nuke_caches; + _force_flush_cache_all =3D sr7100_nuke_caches; _flush_cache_mm =3D sr7100_flush_cache_mm_pc; _flush_cache_range =3D sr7100_flush_cache_range_pc; _flush_cache_page =3D sr7100_flush_cache_page_pc; Index: arch/mips/mm/c-tx39.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-tx39.c,v retrieving revision 1.5 diff -u -r1.5 c-tx39.c --- arch/mips/mm/c-tx39.c 30 Nov 2001 18:34:09 -0000 1.5 +++ arch/mips/mm/c-tx39.c 29 May 2002 19:00:43 -0000 @@ -286,7 +286,7 @@ case CPU_TX3912: /* TX39/H core (writethru direct-map cache) */ _flush_cache_all =3D tx39h_flush_icache_all; - ___flush_cache_all =3D tx39h_flush_icache_all; + _force_flush_cache_all =3D tx39h_flush_icache_all; _flush_cache_mm =3D (void *) tx39h_flush_icache_all; _flush_cache_range =3D (void *) tx39h_flush_icache_all; _flush_cache_page =3D (void *) tx39h_flush_icache_all; @@ -308,7 +308,7 @@ /* board-dependent init code may set WBON */ =20 _flush_cache_all =3D tx39_flush_cache_all; - ___flush_cache_all =3D tx39_flush_cache_all; + _force_flush_cache_all =3D tx39_flush_cache_all; _flush_cache_mm =3D tx39_flush_cache_mm; _flush_cache_range =3D tx39_flush_cache_range; _flush_cache_page =3D tx39_flush_cache_page; Index: arch/mips/mm/c-tx49.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/c-tx49.c,v retrieving revision 1.3 diff -u -r1.3 c-tx49.c --- arch/mips/mm/c-tx49.c 30 Nov 2001 18:34:09 -0000 1.3 +++ arch/mips/mm/c-tx49.c 29 May 2002 19:00:43 -0000 @@ -423,7 +423,7 @@ _flush_cache_page =3D r49_flush_cache_page_d32i32; break; } - ___flush_cache_all =3D _flush_cache_all; + _force_flush_cache_all =3D _flush_cache_all; =20 _flush_icache_page =3D r4k_flush_icache_page; =20 @@ -434,5 +434,5 @@ _flush_cache_sigtramp =3D r4k_flush_cache_sigtramp; _flush_icache_range =3D r4k_flush_icache_range; /* Ouch */ =20 - __flush_cache_all(); + force_flush_cache_all(); } Index: arch/mips/mm/init.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/init.c,v retrieving revision 1.6 diff -u -r1.6 init.c --- arch/mips/mm/init.c 18 Mar 2002 22:48:17 -0000 1.6 +++ arch/mips/mm/init.c 29 May 2002 19:00:43 -0000 @@ -49,7 +49,7 @@ asmlinkage int sys_cacheflush(void *addr, int bytes, int cache) { /* This should flush more selectivly ... */ - __flush_cache_all(); + force_flush_cache_all(); =20 return 0; } Index: arch/mips/mm/loadmmu.c =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: /cvsroot/linux-mips/linux/arch/mips/mm/loadmmu.c,v retrieving revision 1.13 diff -u -r1.13 loadmmu.c --- arch/mips/mm/loadmmu.c 9 May 2002 17:22:35 -0000 1.13 +++ arch/mips/mm/loadmmu.c 29 May 2002 19:00:43 -0000 @@ -24,7 +24,7 @@ =20 /* Cache operations. */ void (*_flush_cache_all)(void); -void (*___flush_cache_all)(void); +void (*_force_flush_cache_all)(void); void (*_flush_cache_mm)(struct mm_struct *mm); void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start, unsigned long end); Index: arch/mips64/mm/c-sb1.c =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: /cvsroot/linux-mips/linux/arch/mips64/mm/c-sb1.c,v retrieving revision 1.6 diff -u -r1.6 c-sb1.c --- arch/mips64/mm/c-sb1.c 24 Apr 2002 17:30:19 -0000 1.6 +++ arch/mips64/mm/c-sb1.c 29 May 2002 19:00:43 -0000 @@ -111,24 +111,24 @@ "r" (KSEG0), "i" (Index_Invalidate_I)); } =20 -static void local_sb1___flush_cache_all(void) +static void local_sb1_force_flush_cache_all(void) { local_sb1___flush_dcache_all(); local_sb1___flush_icache_all(); } =20 #ifdef CONFIG_SMP -extern void sb1___flush_cache_all_ipi(void *ignored); -asm("sb1___flush_cache_all_ipi =3D local_sb1___flush_cache_all"); +extern void sb1_force_flush_cache_all_ipi(void *ignored); +asm("sb1_force_flush_cache_all_ipi =3D local_sb1_force_flush_cache_all"); =20 -static void sb1___flush_cache_all(void) +static void sb1_force_flush_cache_all(void) { - smp_call_function(sb1___flush_cache_all_ipi, 0, 1, 1); - local_sb1___flush_cache_all(); + smp_call_function(sb1_force_flush_cache_all_ipi, 0, 1, 1); + local_sb1_force_flush_cache_all(); } #else -extern void sb1___flush_cache_all(void); -asm("sb1___flush_cache_all =3D local_sb1___flush_cache_all"); +extern void sb1_force_flush_cache_all(void); +asm("sb1_force_flush_cache_all =3D local_sb1_force_flush_cache_all"); #endif =20 =20 @@ -256,7 +256,7 @@ * * Bumping the ASID may well be cheaper, need to experiment ... */ - sb1___flush_cache_all(); + sb1_force_flush_cache_all(); } =20 static inline void protected_flush_icache_line(unsigned long addr) @@ -505,7 +505,7 @@ _copy_page =3D sb1_copy_page; =20 _flush_cache_all =3D sb1_flush_cache_all; - ___flush_cache_all =3D sb1___flush_cache_all; + _force_flush_cache_all =3D sb1_force_flush_cache_all; _flush_cache_mm =3D (void (*)(struct mm_struct *))sb1_nop; _flush_cache_range =3D (void *) sb1_nop; _flush_page_to_ram =3D sb1_flush_page_to_ram; Index: arch/mips64/mm/loadmmu.c =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: /cvsroot/linux-mips/linux/arch/mips64/mm/loadmmu.c,v retrieving revision 1.6 diff -u -r1.6 loadmmu.c --- arch/mips64/mm/loadmmu.c 19 Feb 2002 17:43:02 -0000 1.6 +++ arch/mips64/mm/loadmmu.c 29 May 2002 19:00:43 -0000 @@ -25,7 +25,7 @@ =20 /* Cache operations. */ void (*_flush_cache_all)(void); -void (*___flush_cache_all)(void); +void (*_force_flush_cache_all)(void); void (*_flush_cache_mm)(struct mm_struct *mm); void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start, unsigned long end); Index: include/asm-mips/pgtable.h =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: /cvsroot/linux-mips/linux/include/asm-mips/pgtable.h,v retrieving revision 1.17 diff -u -r1.17 pgtable.h --- include/asm-mips/pgtable.h 21 Apr 2002 20:34:31 -0000 1.17 +++ include/asm-mips/pgtable.h 29 May 2002 19:00:44 -0000 @@ -33,7 +33,7 @@ * - flush_icache_all() flush the entire instruction cache */ extern void (*_flush_cache_all)(void); -extern void (*___flush_cache_all)(void); +extern void (*_force_flush_cache_all)(void); extern void (*_flush_cache_mm)(struct mm_struct *mm); extern void (*_flush_cache_range)(struct mm_struct *mm, unsigned long star= t, unsigned long end); @@ -49,7 +49,7 @@ #define flush_dcache_page(page) do { } while (0) =20 #define flush_cache_all() _flush_cache_all() -#define __flush_cache_all() ___flush_cache_all() +#define force_flush_cache_all() _force_flush_cache_all() #define flush_cache_mm(mm) _flush_cache_mm(mm) #define flush_cache_range(mm,start,end) _flush_cache_range(mm,start,end) #define flush_cache_page(vma,page) _flush_cache_page(vma, page) Index: include/asm-mips64/pgtable.h =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: /cvsroot/linux-mips/linux/include/asm-mips64/pgtable.h,v retrieving revision 1.14 diff -u -r1.14 pgtable.h --- include/asm-mips64/pgtable.h 28 May 2002 20:25:38 -0000 1.14 +++ include/asm-mips64/pgtable.h 29 May 2002 19:00:44 -0000 @@ -28,7 +28,7 @@ * - flush_page_to_ram(page) write back kernel page to ram */ extern void (*_flush_cache_all)(void); -extern void (*___flush_cache_all)(void); +extern void (*_force_flush_cache_all)(void); extern void (*_flush_cache_mm)(struct mm_struct *mm); extern void (*_flush_cache_range)(struct mm_struct *mm, unsigned long star= t, unsigned long end); @@ -47,7 +47,7 @@ =20 =20 #define flush_cache_all() _flush_cache_all() -#define __flush_cache_all() ___flush_cache_all() +#define force_flush_cache_all() _force_flush_cache_all() #define flush_dcache_page(page) do { } while (0) =20 #ifdef CONFIG_CPU_R10000 --=-Xa1GCNyIzk6j4NZOBlXP-- From owner-linux-mips@oss.sgi.com Wed May 29 12:48:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TJmTnC027439 for ; Wed, 29 May 2002 12:48:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TJmToQ027438 for linux-mips-outgoing; Wed, 29 May 2002 12:48:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TJmInC027435; Wed, 29 May 2002 12:48:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA26634; Wed, 29 May 2002 21:50:11 +0200 (MET DST) Date: Wed, 29 May 2002 21:50:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: Justin Carlson cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: __flush_cache_all() miscellany In-Reply-To: <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.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 29 May 2002, Justin Carlson wrote: > Here's a patch against cvs that does the rename. Unless anyone has > objections, Ralf, could you apply this? That looks fine to me. I'd keep the leading double underscore, though -- it acts as a warning sign the function is internal and low-level and thus it should not be used without an appropriate justification. > While doing this, I've noticed that the whole mips tree is horribly > inconsistent in terms of the cache flushing syscalls (sys_cacheflush and > sys_sysmips->CACHE_FLUSH). Ugh, it's not the only place of inconsistency... > Here's what the different ports appear to flush given one of these > syscall: > > andes: l1 and l2 > lexra: l1 icache > mips32: l1 icache/dcache > r3k: l1 icache > r4k: l1 icache/dcache > r5432: l1 icache/dcache > r5900: l1 icache/dcache > rm7k: l1 icache/dcache > sb1: l1 icache/dcache > sr7100: l1 and l2 > tx39: l1 icache > tx49: li icache/dcache > > Some of these are blatantly wrong with respect to the cacheflush > syscall; it defines flags for flushing the icache, dcache, or both. In > the latter two cases, the lexra, r3k, and tx39 are not doing what was > requested. I doubt this matters for any significant userspace app, but > it would be nice to at least be consistent. Well, at least r3k uses WT for dcache, so it really doesn't matter unless what you want to achieve is to hit performance. I suspect this is also the case for the others that ignore dcache flushes. The L1 vs L2 issue should be investigated where applicable. This reminds me to check ld.so (and libdl) for missing sys_cacheflush() invocations as well... > As for the sysmips system call, I've not been able to dig up the > semantics. (Actually, I don't really see why we have both ways of > flushing the cache at all...some historical cruft?). Anyone have a > helpful pointer to docs on the subject? It's compatibility crap, like the whole sysmips() stuff, I am afraid. Use sys_cacheflush() normally. 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 Wed May 29 12:52:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TJqknC027692 for ; Wed, 29 May 2002 12:52:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TJqkaZ027691 for linux-mips-outgoing; Wed, 29 May 2002 12:52:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TJqgnC027680 for ; Wed, 29 May 2002 12:52:42 -0700 Received: from excalibur.cologne.de (pD9E40755.dip.t-dialin.net [217.228.7.85]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA03106; Wed, 29 May 2002 21:53:52 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17D9PP-0000Bg-00; Wed, 29 May 2002 21:46:59 +0200 Date: Wed, 29 May 2002 21:46:59 +0200 From: Karsten Merker To: Brian Murphy Cc: linux-mips Subject: Re: New platforms Message-ID: <20020529214659.A256@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , Brian Murphy , linux-mips References: <3CF4AAAD.7070504@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CF4AAAD.7070504@murphy.dk>; from brian@murphy.dk on Wed, May 29, 2002 at 12:17:17PM +0200 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 12:17:17PM +0200, Brian Murphy wrote: > I have a port of linux-mips to the Lasat (later Eicon) platform(s) - > based on vr4300, vr5000 and vr4120 chips. I would very much like > to have the code incorporated in the CVS at OSS. How do I go > about this? Usually by splitting your patches into small chunks (one patch for one feature) and submitting them to Ralf Baechle (ralf@gnu.org) and/or to this list. Regards, 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 May 29 13:09:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TK9hnC027949 for ; Wed, 29 May 2002 13:09:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TK9haL027948 for linux-mips-outgoing; Wed, 29 May 2002 13:09:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp3.poczta.onet.pl (smtp3.poczta.onet.pl [213.180.130.29]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TK9bnC027945 for ; Wed, 29 May 2002 13:09:40 -0700 Received: from B3ee4.pppool.de ([213.7.62.228]:34821 "HELO poczta.onet.pl") by ps3.test.onet.pl with SMTP id ; Wed, 29 May 2002 22:10:04 +0200 From: "MAREK KAREWSKY" To: Subject: Searching for used formwork Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 29 May 2002 22:12:51 +0200 Message-Id: <20020529201004Z843505-14210+1307@ps3.test.onet.pl> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4TK9fnC027946 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dear Sir, we are searching for used formwork 1 000 sqm modular, typ PERI TRIO or DOKA FRAMAX Please send usoffer with list price pictures and location. BestRegards. MAREK KAREWSKY From owner-linux-mips@oss.sgi.com Wed May 29 13:15:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TKFgnC028075 for ; Wed, 29 May 2002 13:15:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TKFgDo028074 for linux-mips-outgoing; Wed, 29 May 2002 13:15:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TKFenC028071 for ; Wed, 29 May 2002 13:15:40 -0700 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 g4TKGr6F025234; Wed, 29 May 2002 13:16:53 -0700 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 g4TKGrOo025230; Wed, 29 May 2002 13:16:53 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 29 May 2002 13:16:53 -0700 (PDT) From: James Simmons To: Brian Murphy cc: linux-mips Subject: Re: New platforms In-Reply-To: <3CF4AAAD.7070504@murphy.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Hi, > I have a port of linux-mips to the Lasat (later Eicon) platform(s) - > based on vr4300, vr5000 and vr4120 chips. I would very much like > to have the code incorporated in the CVS at OSS. How do I go > about this? Please at a look at the Linux MIPS project at sourceforge. We already have several VR chipsets supported. http://linux-mips.sf.net From owner-linux-mips@oss.sgi.com Wed May 29 13:19:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TKJQnC028162 for ; Wed, 29 May 2002 13:19:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TKJQYu028161 for linux-mips-outgoing; Wed, 29 May 2002 13:19:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TKJJnC028158; Wed, 29 May 2002 13:19:19 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 29 May 2002 13:20:19 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4TKKl1S002805; Wed, 29 May 2002 13:20:47 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4TKKlM08677; Wed, 29 May 2002 13:20:47 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Re: __flush_cache_all() miscellany From: "Justin Carlson" To: "Maciej W. Rozycki" cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com In-Reply-To: References: X-Mailer: Ximian Evolution 1.0.5 Date: 29 May 2002 13:20:46 -0700 Message-ID: <1022703646.7643.175.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10EBE7896168-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 2002-05-29 at 12:50, Maciej W. Rozycki wrote: > On 29 May 2002, Justin Carlson wrote: > > > Here's a patch against cvs that does the rename. Unless anyone has > > objections, Ralf, could you apply this? > > That looks fine to me. I'd keep the leading double underscore, though -- > it acts as a warning sign the function is internal and low-level and thus > it should not be used without an appropriate justification. > Yes, you're right, it's not a standard function to have. But I'm already wondering if this is not the right thing to do. See below. > Well, at least r3k uses WT for dcache, so it really doesn't matter unless > what you want to achieve is to hit performance. I suspect this is also > the case for the others that ignore dcache flushes. The L1 vs L2 issue > should be investigated where applicable. Are the general semantics of the thing just broken, then? We already ignore the arguments to sys_cacheflush; would redefining the syscall to mean "flush the caches in such a way that I won't get stale instructions from this address range" actually break any current programs? (Evidently not, if several ports are already doing it that way)... More to the point, does __flush_cache_all() serve any useful purpose at all, or can it just be replaced with appropriate invocations of flush_icache_range()? Other than internal use for the individual port cache routines, it's *only* used in the syscalls and the gdb stub. I'd like to hear the rationale for __flush_cache_all() from the original author; it appears to have shown up in CVS a little more than a year ago, but I don't know who sent the patch to Ralf. Ralf, do you remember? Thanks, Justin From owner-linux-mips@oss.sgi.com Wed May 29 13:56:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TKu1nC028954 for ; Wed, 29 May 2002 13:56:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TKu1Ro028953 for linux-mips-outgoing; Wed, 29 May 2002 13:56:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TKtonC028948; Wed, 29 May 2002 13:55:50 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id NAA13994; Wed, 29 May 2002 13:57:10 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA07058; Wed, 29 May 2002 13:57:09 -0700 (PDT) Message-ID: <01cb01c20754$4c14e400$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Justin Carlson" , Cc: References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com> Subject: Re: __flush_cache_all() miscellany Date: Wed, 29 May 2002 23:03:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > While doing this, I've noticed that the whole mips tree is horribly > inconsistent in terms of the cache flushing syscalls (sys_cacheflush and > sys_sysmips->CACHE_FLUSH). > > Here's what the different ports appear to flush given one of these > syscall: > > andes: l1 and l2 > lexra: l1 icache > mips32: l1 icache/dcache > r3k: l1 icache > r4k: l1 icache/dcache > r5432: l1 icache/dcache > r5900: l1 icache/dcache > rm7k: l1 icache/dcache > sb1: l1 icache/dcache > sr7100: l1 and l2 > tx39: l1 icache > tx49: li icache/dcache > > Some of these are blatantly wrong with respect to the cacheflush > syscall; it defines flags for flushing the icache, dcache, or both. In > the latter two cases, the lexra, r3k, and tx39 are not doing what was > requested. I doubt this matters for any significant userspace app, but > it would be nice to at least be consistent. > > As for the sysmips system call, I've not been able to dig up the > semantics. (Actually, I don't really see why we have both ways of > flushing the cache at all...some historical cruft?). Anyone have a > helpful pointer to docs on the subject? I agree that things need to be straightened out a bit here, or at least better documented, but things may not be as bad as you think, depending on the actual use of the system calls. Specifically, if what one is worried about is ensuring that a modification to memory gets picked up by the instruction stream, as in setting/clearing a breakpoint or executing a JIT, one does not need to flush the dcache *if* the dcache is write-through in the first place - as it is for most if not all of the processors you list above as flushing the icache only. (As a parenthetical note, future MIPS processors won't need a system call to deal with instruction stream modifications, but we need to deal with the here-and-now). While trampolines, breakpointing and JITing are the main uses of user-mode cache manipulation (drivers are a whole 'nother story), we really should have distinct capabilities for I-stream modification and for explicit synchronizations of the data storage hierarchy, for non-coherent multiprocessors and user-manipulated DMA buffers. As to whether those capabilities should be distinguished by system call (sysmips vs. cacheflush) or by parameter to the same system call, I don't have enough data to form an opinion at this point. Kevin K. From owner-linux-mips@oss.sgi.com Wed May 29 13:58:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TKwdnC029062 for ; Wed, 29 May 2002 13:58:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TKwdkp029061 for linux-mips-outgoing; Wed, 29 May 2002 13:58:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TKwTnC029041; Wed, 29 May 2002 13:58:29 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA28092; Wed, 29 May 2002 23:00:21 +0200 (MET DST) Date: Wed, 29 May 2002 23:00:21 +0200 (MET DST) From: "Maciej W. Rozycki" To: Justin Carlson cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: __flush_cache_all() miscellany In-Reply-To: <1022703646.7643.175.camel@ldt-sj3-022.sj.broadcom.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 29 May 2002, Justin Carlson wrote: > Are the general semantics of the thing just broken, then? We already > ignore the arguments to sys_cacheflush; would redefining the syscall to > mean "flush the caches in such a way that I won't get stale instructions > from this address range" actually break any current programs? > (Evidently not, if several ports are already doing it that way)... You mean removing the DCACHE operation? The overlying _flush_cache() library function is specified by the MIPS ABI supplement, so we shouldn't really redefine it. Also a reasonable use for it may exist -- a userland program touching hardware directly (say X11) may want to use cached accesses for performance reasons (e.g. because cache can do prefetches on reads). I guess the intent for the ICACHE operation is to assure ICACHE vs DCACHE coherency and the intent for the DCACHE operation is to assure DCACHE vs RAM coherency. If the operations do not work in this way for a given backend, then there is a bug in it. > More to the point, does __flush_cache_all() serve any useful purpose at > all, or can it just be replaced with appropriate invocations of > flush_icache_range()? Other than internal use for the individual port > cache routines, it's *only* used in the syscalls and the gdb stub. It does serve a useful purpose. Or at least it should. This reminds me of adding flushing of WB caches at a system shutdown. The function should remain at least for this purpose. If there are places you are absolutely sure flush_icache_range() would suffice, feel free to replace the call. There are not many __flush_cache_all() invocations. > I'd like to hear the rationale for __flush_cache_all() from the original > author; it appears to have shown up in CVS a little more than a year > ago, but I don't know who sent the patch to Ralf. Ralf, do you > remember? I converted a few flush_cache_all() invocations to __flush_cache_all() where appropriate late last year, but the function is a bit older. I think you might dig the linux-kernel list archives for a discussion on the semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and friends. The short description in Documentation/cachetlb.txt is a bit insufficient, I'm afraid. 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 Wed May 29 14:06:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TL6pnC029218 for ; Wed, 29 May 2002 14:06:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TL6p6f029217 for linux-mips-outgoing; Wed, 29 May 2002 14:06:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TL6inC029214 for ; Wed, 29 May 2002 14:06:44 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4TL7xP01136; Wed, 29 May 2002 14:07:59 -0700 Date: Wed, 29 May 2002 14:07:59 -0700 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020529140759.A888@dea.linux-mips.net> References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com>; from justinca@cs.cmu.edu on Wed, May 29, 2002 at 09:50:52AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 09:50:52AM -0700, Justin Carlson wrote: > Looking at the cache routines, I've noticed that there's been a > relatively recent introduction of a __flush_cache_all() routine. > Looking at oss.sgi.com's cvs logs, I see this comment: > > >Introduce __flush_cache_all() which flushes the cache no matter if > >this operation is necessary from the mm point of view or not. > > Some questions: > > Which caches does this apply to? It looks like the current > implementations assume L1 only. The operation got introduced for the R10000 where we only need to flush the caches during initialization or the (unlikely on Origin) case of > Would anyone have a problem with renaming this function? To me, at > least, it's rather confusing to have all of: No. You may have noticed that I already introduced a bunch of local_*() functions for the TLB stuff for the same reason - the old functions had poor names. The common Linux conventions to use extra underscores for a more basic version of a function (like get_user vs __get_user etc.) is frequently not expressive enough. > flush_cache_all() > _flush_cache_all() > __flush_cache_all() > ___flush_cache_all() Odd number of underscores means it's a pointer ;) > defined, especially when the latter two mean something significantly > different from the former two. I'd prefer calling the new one > {_}force_flush_l1_caches() or somesuch. Ok. > In a related note, one of the few places this routine is called is the > kgdb stub routines (in arch/mips/kernel/gdb-stub.c): > > void set_async_breakpoint(unsigned int epc) > { > int cpu = smp_processor_id(); > > async_bp[cpu].addr = epc; > async_bp[cpu].val = *(unsigned *)epc; > *(unsigned *)epc = BP; > __flush_cache_all(); > } > > Shouldn't that be a flush_icache_range() call anyways? Yes. Ralf From owner-linux-mips@oss.sgi.com Wed May 29 14:08:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TL8lnC029307 for ; Wed, 29 May 2002 14:08:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TL8lcl029306 for linux-mips-outgoing; Wed, 29 May 2002 14:08:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TL8inC029303 for ; Wed, 29 May 2002 14:08:45 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4TL9xX01145; Wed, 29 May 2002 14:09:59 -0700 Date: Wed, 29 May 2002 14:09:59 -0700 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020529140959.B888@dea.linux-mips.net> References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com>; from justinca@cs.cmu.edu on Wed, May 29, 2002 at 12:26:29PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 12:26:29PM -0700, Justin Carlson wrote: > Here's a patch against cvs that does the rename. Unless anyone has > objections, Ralf, could you apply this? > > While doing this, I've noticed that the whole mips tree is horribly > inconsistent in terms of the cache flushing syscalls (sys_cacheflush and > sys_sysmips->CACHE_FLUSH). These are compacrapability syscalls inherited from Risc/OS and IRIX. Even gcc generated trampoline code expects to have these available. Ralf From owner-linux-mips@oss.sgi.com Wed May 29 14:27:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TLRinC031150 for ; Wed, 29 May 2002 14:27:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TLRi2Q031149 for linux-mips-outgoing; Wed, 29 May 2002 14:27:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TLRfnC031146 for ; Wed, 29 May 2002 14:27:41 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4TLStu01350; Wed, 29 May 2002 14:28:55 -0700 Date: Wed, 29 May 2002 14:28:55 -0700 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020529142855.C888@dea.linux-mips.net> References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> <1022700389.7644.155.camel@ldt-sj3-022.sj.broadcom.com> <01cb01c20754$4c14e400$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <01cb01c20754$4c14e400$10eca8c0@grendel>; from kevink@mips.com on Wed, May 29, 2002 at 11:03:20PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 11:03:20PM +0200, Kevin D. Kissell wrote: > While trampolines, breakpointing and JITing are the main > uses of user-mode cache manipulation (drivers are a whole > 'nother story), we really should have distinct capabilities for > I-stream modification and for explicit synchronizations of > the data storage hierarchy, for non-coherent multiprocessors > and user-manipulated DMA buffers. As to whether > those capabilities should be distinguished by system > call (sysmips vs. cacheflush) or by parameter to the > same system call, I don't have enough data to form > an opinion at this point. It should clearly be cacheflush(2); sysmips(2) is too coarse, too ugly interface. Another thing we'll still have to implement is the cachectl(2) syscall; for certain systems and applications fine control of the caching mode use for a memory mapping may result in major performance improvments. Ralf From owner-linux-mips@oss.sgi.com Wed May 29 14:31:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TLVxnC000914 for ; Wed, 29 May 2002 14:31:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TLVxqS000913 for linux-mips-outgoing; Wed, 29 May 2002 14:31:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TLVunC000910 for ; Wed, 29 May 2002 14:31:56 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4TLX5W01448; Wed, 29 May 2002 14:33:05 -0700 Date: Wed, 29 May 2002 14:33:05 -0700 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020529143305.D888@dea.linux-mips.net> References: <1022703646.7643.175.camel@ldt-sj3-022.sj.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, May 29, 2002 at 11:00:21PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 11:00:21PM +0200, Maciej W. Rozycki wrote: > I converted a few flush_cache_all() invocations to __flush_cache_all() > where appropriate late last year, but the function is a bit older. I > think you might dig the linux-kernel list archives for a discussion on the > semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and > friends. The short description in Documentation/cachetlb.txt is a bit > insufficient, I'm afraid. I don't like that function very much; it's sort of a shotgun approach to flushing caches in a part of the kernel that's not too performance relevant. The whole interface sucks, should be replaced by something more finegrained. Ralf From owner-linux-mips@oss.sgi.com Wed May 29 14:45:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TLjBnC002644 for ; Wed, 29 May 2002 14:45:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TLjAnL002643 for linux-mips-outgoing; Wed, 29 May 2002 14:45:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TLj3nC002638; Wed, 29 May 2002 14:45:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA29138; Wed, 29 May 2002 23:46:59 +0200 (MET DST) Date: Wed, 29 May 2002 23:46:58 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany In-Reply-To: <20020529143305.D888@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, 29 May 2002, Ralf Baechle wrote: > > I converted a few flush_cache_all() invocations to __flush_cache_all() > > where appropriate late last year, but the function is a bit older. I > > think you might dig the linux-kernel list archives for a discussion on the > > semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and > > friends. The short description in Documentation/cachetlb.txt is a bit > > insufficient, I'm afraid. > > I don't like that function very much; it's sort of a shotgun approach > to flushing caches in a part of the kernel that's not too performance > relevant. The whole interface sucks, should be replaced by something > more finegrained. Well, I suspect the API might be somewhat influenced by SPARC's oddities. ;-) -- + 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 Wed May 29 15:45:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TMjNnC003691 for ; Wed, 29 May 2002 15:45:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TMjNwS003690 for linux-mips-outgoing; Wed, 29 May 2002 15:45:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TMjDnC003687 for ; Wed, 29 May 2002 15:45:19 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4TMkOH02431; Wed, 29 May 2002 15:46:24 -0700 Date: Wed, 29 May 2002 15:46:24 -0700 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020529154624.A2409@dea.linux-mips.net> References: <20020529143305.D888@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, May 29, 2002 at 11:46:58PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 11:46:58PM +0200, Maciej W. Rozycki wrote: > > > I converted a few flush_cache_all() invocations to __flush_cache_all() > > > where appropriate late last year, but the function is a bit older. I > > > think you might dig the linux-kernel list archives for a discussion on the > > > semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and > > > friends. The short description in Documentation/cachetlb.txt is a bit > > > insufficient, I'm afraid. > > > > I don't like that function very much; it's sort of a shotgun approach > > to flushing caches in a part of the kernel that's not too performance > > relevant. The whole interface sucks, should be replaced by something > > more finegrained. > > Well, I suspect the API might be somewhat influenced by SPARC's oddities. > ;-) Historically that's certainly true. As a general complaint about the style of interfaces of the cache stuff - they're too low level. Frequently we just don't know enough about the situation to optimize the flush operation. Ralf From owner-linux-mips@oss.sgi.com Wed May 29 15:57:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TMvknC003848 for ; Wed, 29 May 2002 15:57:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TMvkX4003847 for linux-mips-outgoing; Wed, 29 May 2002 15:57:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TMvbnC003844; Wed, 29 May 2002 15:57:37 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Wed, 29 May 2002 15:58:38 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4TMx51S005882; Wed, 29 May 2002 15:59:05 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4TMx5g09598; Wed, 29 May 2002 15:59:05 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Re: __flush_cache_all() miscellany From: "Justin Carlson" To: "Maciej W. Rozycki" cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com In-Reply-To: References: X-Mailer: Ximian Evolution 1.0.5 Date: 29 May 2002 15:59:05 -0700 Message-ID: <1022713145.7644.363.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10EB829436381-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 2002-05-29 at 14:00, Maciej W. Rozycki wrote: > On 29 May 2002, Justin Carlson wrote: > > > Are the general semantics of the thing just broken, then? We already > > ignore the arguments to sys_cacheflush; would redefining the syscall to > > mean "flush the caches in such a way that I won't get stale instructions > > from this address range" actually break any current programs? > > (Evidently not, if several ports are already doing it that way)... > > You mean removing the DCACHE operation? The overlying _flush_cache() > library function is specified by the MIPS ABI supplement, so we shouldn't > really redefine it. Also a reasonable use for it may exist -- a userland > program touching hardware directly (say X11) may want to use cached > accesses for performance reasons (e.g. because cache can do prefetches on > reads). This is true; I hadn't thought about the cases of userland touching hardware directly. Of course, I think these cases should be hunted down and eliminated (go framebuffer device!), but alas, if that ever really happens, it's not going to be soon. > > I guess the intent for the ICACHE operation is to assure ICACHE vs DCACHE > coherency and the intent for the DCACHE operation is to assure DCACHE vs > RAM coherency. If the operations do not work in this way for a given > backend, then there is a bug in it. We may theoretically need these capabilities, but, given that several of the ports already get this wrong and no loud screaming has been heard, I wonder about the real need. Assuming we do need these capabilities in the syscall (and, really, it's pretty easy to make them right), I'm actually more wondering about the need for the __flush_cache_all() in the first place. The gdb stubs can use the defined interface without a problem (and, indeed, more efficiently. What they're doing now is overkill). That leaves the syscalls, which, if implemented properly, should also use the normal interface. I'm still looking for a reason for the existence of __flush_cache_all(). > I converted a few flush_cache_all() invocations to __flush_cache_all() > where appropriate late last year, but the function is a bit older. I > think you might dig the linux-kernel list archives for a discussion on the > semantics of flush_cache_all() (it's a nop for many MIPS CPUs) and > friends. The short description in Documentation/cachetlb.txt is a bit > insufficient, I'm afraid. Woefully insufficient. :) I'm going to have a stab at editing that file when I feel like I have a complete understanding. Don't hold your breath. :) -Justin From owner-linux-mips@oss.sgi.com Wed May 29 16:26:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4TNQinC004368 for ; Wed, 29 May 2002 16:26:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4TNQiAL004367 for linux-mips-outgoing; Wed, 29 May 2002 16:26:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4TNQbnC004364; Wed, 29 May 2002 16:26:38 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id QAA10269; Wed, 29 May 2002 16:26:23 -0700 Message-ID: <3CF56335.3010404@mvista.com> Date: Wed, 29 May 2002 16:24:37 -0700 From: Jun Sun 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: Justin Carlson CC: "Maciej W. Rozycki" , linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: __flush_cache_all() miscellany References: <1022713145.7644.363.camel@ldt-sj3-022.sj.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Justin Carlson wrote: > I'm still looking for a reason for the existence of __flush_cache_all(). > It is needed by kgdb where gdb client may modify several instructions before a 'c' command is issued. In that case, you cannot use flush_icache_range because you don't know the range. It is probably not safe either as the data cache may not be written back yet Does flush_icache_range() mandates write-back of dcache in the same range? If it does, you might be able to get away with flush_icache_range(ICACHE_BEGIN, ICACHE_END). Like someone else has pointed out, __flush_cache_all() is introduced to ensure i-cache/d-cache consistency. I remember it was shortly introduced after we had the first cache-coherent system where flush_cache_all() is a null function. Jun From owner-linux-mips@oss.sgi.com Thu May 30 02:47:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4U9lGnC032215 for ; Thu, 30 May 2002 02:47:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4U9lG5m032214 for linux-mips-outgoing; Thu, 30 May 2002 02:47:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4U9l9nC032211 for ; Thu, 30 May 2002 02:47:10 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id BB684846; Thu, 30 May 2002 11:48:38 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 0D54137102; Thu, 30 May 2002 11:42:56 +0200 (CEST) Date: Thu, 30 May 2002 11:42:56 +0200 From: Florian Lohoff To: James Simmons Cc: Brian Murphy , linux-mips Subject: Re: New platforms Message-ID: <20020530094255.GA18436@paradigm.rfc822.org> References: <3CF4AAAD.7070504@murphy.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2002 at 01:16:53PM -0700, James Simmons wrote: > > Hi, > > I have a port of linux-mips to the Lasat (later Eicon) platform(s) - > > based on vr4300, vr5000 and vr4120 chips. I would very much like > > to have the code incorporated in the CVS at OSS. How do I go > > about this? >=20 > Please at a look at the Linux MIPS project at sourceforge. We already have > several VR chipsets supported.=20 The Eicons are not anything really embedded rather than Cobalt RaQ like. Flo PS: I dont like this split up tree - Currently Ralf is the one=20 feeding mainstream so please stop this diversification of the trees as the normal user gets completely confused which makes linux mips a VERY BAD target and does not help any popularity for the mips targets. We had the linux-vr desaster before which helped nothing but in the end bound developer efforts which were useless in the end. --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --SUOF0GtieIMvvwua 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 iD8DBQE89fQfUaz2rXW+gJcRAvt7AJ4xrCC0ZtBUZ3XUIi7LD34jIsZLKQCfR1/q ehhbFC/ntyk3n+l52ncRxXg= =fWn3 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-linux-mips@oss.sgi.com Thu May 30 04:00:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UB0NnC000606 for ; Thu, 30 May 2002 04:00:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UB0NWs000605 for linux-mips-outgoing; Thu, 30 May 2002 04:00:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UB0KnC000602 for ; Thu, 30 May 2002 04:00:20 -0700 Received: from aihana (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id EAA20747 for ; Thu, 30 May 2002 04:00:33 -0700 Subject: returns corrupt value from shmctl(); From: Takeshi Aihana To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution/1.0.5-build 20020511 Date: 30 May 2002 20:00:31 +0900 Message-Id: <1022756432.1045.37.camel@aihana> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello all, I have a problem now about return the segment size of shared memory from shmctl() func. First of step was to start apache_1.3.24 on kernel-2.4.17/pb1000. However it could not be started because it might be currput segment size from shmctl() called in apache. So that I tried to test with shmctl() on (A)kernel-2.4.17/pb1000 and (B)kernel-2.4.9/x86 as the follows. (B) was just returned correct segment size, but (A)'s segment size was 0 (of cause memory on pb1000 was left). This code is -----------------------------------8<--------------------------------------- -----------------------------------8<--------------------------------------- HOST: kernel-2.4.9/RH-7.2 on x86. From owner-linux-mips@oss.sgi.com Thu May 30 04:10:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UBADnC001135 for ; Thu, 30 May 2002 04:10:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UBADHm001134 for linux-mips-outgoing; Thu, 30 May 2002 04:10:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UBA4nC001126 for ; Thu, 30 May 2002 04:10:05 -0700 Received: from aihana (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id EAA21036 for ; Thu, 30 May 2002 04:10:18 -0700 Subject: (Re-Send) shmctl() returns corrupt value on pb1000. From: Takeshi Aihana To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution/1.0.5-build 20020511 Date: 30 May 2002 20:10:16 +0900 Message-Id: <1022757017.1045.47.camel@aihana> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk # Sorry, please ignore previous mail I send. Hello all, I have a problem now about return the segment size of shared memory from shmctl() func. First of step was to start apache_1.3.24 on kernel-2.4.17/pb1000. However it could not be started because it might be currput segment size from shmctl() called in apache. So that I tried to test with shmctl() on (A)kernel-2.4.17/pb1000/gcc-2.95.3 and (B)kernel-2.4.9/x86/gcc-2.95.3 as the follows. (B) was just returned correct segment size, but (A)'s segment size was 0 (of cause memory on pb1000 was left). This simple code is follows, and `gcc -o test test.c`. -----------------------------------8<--------------------------------------- #include #include #include int main (void) { int shm_id; struct shmid_ds ds; shm_id = shmget(IPC_PRIVATE, 123, IPC_CREAT|0666); if (shm_id < 0) { perror ("shmget"); return 1; } if (shmctl(shm_id, IPC_STAT, &ds)) { perror ("shmctl"); exit (1); } printf( "shm_segsz = %d\n", ds.shm_segsz); } -----------------------------------8<--------------------------------------- Then each results are, x86(kernel-2.4.9/RH-7.2/gcc-2.95.3) : shm_segsz = 123 pb1000(kernel-2.4.17/gcc-2.95.3) : shm_segsz = 0 This value of pb1000 could not be expected for me. So if you have any adivices that should be add option to compile on pb1000, or if you have been faced similar to this, please let me knows. Thank you for your helps. Regards. --- (TAKESHI - MontaVista Software Japan) From owner-linux-mips@oss.sgi.com Thu May 30 05:17:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UCHlnC002047 for ; Thu, 30 May 2002 05:17:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UCHkkV002046 for linux-mips-outgoing; Thu, 30 May 2002 05:17:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UCHhnC002040 for ; Thu, 30 May 2002 05:17:43 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.SGI.COM [128.167.58.27]) with SMTP; 30 May 2002 12:19:15 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 26BDFB46B; Thu, 30 May 2002 21:19:13 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id VAA09184; Thu, 30 May 2002 21:19:12 +0900 (JST) Date: Thu, 30 May 2002 21:19:02 +0900 (JST) Message-Id: <20020530.211902.102583216.nemoto@toshiba-tops.co.jp> To: takeshi_aihana@montavista.co.jp Cc: linux-mips@oss.sgi.com Subject: Re: (Re-Send) shmctl() returns corrupt value on pb1000. From: Atsushi Nemoto In-Reply-To: <1022757017.1045.47.camel@aihana> References: <1022757017.1045.47.camel@aihana> 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.2 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 30 May 2002 20:10:16 +0900, Takeshi Aihana said: takeshi_aihana> I have a problem now about return the segment size of takeshi_aihana> shared memory from shmctl() func. What version of libc are you using? It seems your kernel headers and libc headers are inconsistent. Please look structures in libc's /usr/include/bits/{ipc,sem,shm,msg}.h and kernel's include/asm-mips/{ipc,sem,shm,msg}buf.h carefully. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu May 30 06:02:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UD2onC002865 for ; Thu, 30 May 2002 06:02:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UD2oUb002864 for linux-mips-outgoing; Thu, 30 May 2002 06:02:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UD2jnC002840 for ; Thu, 30 May 2002 06:02:45 -0700 Received: from aihana (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id GAA22734 for ; Thu, 30 May 2002 06:02:59 -0700 Subject: Re: (Re-Send) shmctl() returns corrupt value on pb1000. From: Takeshi Aihana To: linux-mips@oss.sgi.com In-Reply-To: <20020530.211902.102583216.nemoto@toshiba-tops.co.jp> References: <1022757017.1045.47.camel@aihana> <20020530.211902.102583216.nemoto@toshiba-tops.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution/1.0.5-build 20020511 Date: 30 May 2002 22:02:57 +0900 Message-Id: <1022763778.1046.71.camel@aihana> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, > >>>>> On 30 May 2002 20:10:16 +0900, Takeshi Aihana said: > takeshi_aihana> I have a problem now about return the segment size of > takeshi_aihana> shared memory from shmctl() func. > > What version of libc are you using? It seems your kernel headers and > libc headers are inconsistent. (A) The version of glibc on x86 is 2.2.4/kernel-2.4.9. (B) The version of glibc on pb1000 is 2.2.3/kernel-2.4.17. Is there any inconsistents on those conditions? Should be update to 2.2.4 on pb1000? > Please look structures in libc's /usr/include/bits/{ipc,sem,shm,msg}.h > and kernel's include/asm-mips/{ipc,sem,shm,msg}buf.h carefully. OK. I will do carefully. It looks like to not any diffs I should observe on both files, now. Thank you for your help. --- (TAKESHI - MontaVista Software Japan) From owner-linux-mips@oss.sgi.com Thu May 30 08:46:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UFknnC015088 for ; Thu, 30 May 2002 08:46:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UFkn9l015087 for linux-mips-outgoing; Thu, 30 May 2002 08:46:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UFkbnC015084 for ; Thu, 30 May 2002 08:46:38 -0700 Message-Id: <200205301546.g4UFkbnC015084@oss.sgi.com> Received: (qmail 21731 invoked from network); 30 May 2002 15:39:02 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 30 May 2002 15:39:02 -0000 Date: Thu, 30 May 2002 23:47:26 +0800 From: "Zhang Fuxin" To: Kevin Paul Herbert CC: "linux-mips@oss.sgi.com" Subject: Re: Re: pcnet32.c bug? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4UFkcnC015085 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, >>--- drivers/net/pcnet32.c 19 Mar 2002 16:40:55 -0000 1.1.1.1.2.1.2.6 >>+++ drivers/net/pcnet32.c 29 May 2002 09:57:33 -0000 1.13.4.2 >>@@ -1343,6 +1351,10 @@ >> if (!rx_in_place) { >> skb_reserve(skb,2); /* 16 byte align */ >> skb_put(skb,pkt_len); /* Make room */ >>+ pci_dma_sync_single(lp->pci_dev, >>+ lp->rx_skbuff[entry]->tail, >>+ pkt_len, >>+ PCI_DMA_FROMDEVICE); >> eth_copy_and_sum(skb, >> (unsigned char >>*)(lp->rx_skbuff[entry]->tail), >> pkt_len,0); Because many mips ports do wback_inv for pci_dma_sync_single,how can this help? I think it just mean to invalidate cache contents the cpu has for this buffer,and thus cpu can be sure to read data dmaed to memory by the device And now we are doing write back,won't that be overwriting the buffer with stale data in cache? so,the problem is,can we use wback_inv instead of inv in pci_dma_sync_single when the direction is FROMDEVICE? I don't think so,but that would mean many current drivers are broken... i guess the fact that current driver are working is because no mips machine has big enough cache to survive the data to the point of the buffer's reuse. Correct solution should be something like Will Jhun's proposal? that is: each transition i.e. (FROM_DEVICE operation) pci_map_single() - device now owns the buffer [invalidate] [DMA] pci_dma_sync_single() - driver now owns it [no invalidate] [driver touches buffer] pci_dma_prep_single() - device owns it once again [invalidate] [DMA] ... I hope i am totally wrong:) BTW: i am struggling with eepro100 driver these days,and now i have got an NAPI version of it running. The rx ring often got messed up with the old pci_dma_sync_xx logic,before i change it. > >Note that there is another problem with cache line invalidation and >the use of pci_dma_sync_single(), where one can get stale entries in >the cache when the buffer is next re-used for DMA. > >My co-worker Will Jhun just sent >e-mail on the subject of problems with the cache invalidation >routines last Saturday, with Message-ID: ><20020525131806.A4073@ayrnetworks.com> > >Kevin > > >-- = = = = = = = = = = = = = = = = = = = = Best Regards --------------------------------------- Zhang Fuxin System Architecture Lab Institute of Computing Technology Chinese Academy of Sciences,China http://www.ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-05-30 From owner-linux-mips@oss.sgi.com Thu May 30 09:45:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UGjgnC019637 for ; Thu, 30 May 2002 09:45:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UGjgd0019636 for linux-mips-outgoing; Thu, 30 May 2002 09:45:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UGjenC019631 for ; Thu, 30 May 2002 09:45:40 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4UGj5U22541; Thu, 30 May 2002 09:45:05 -0700 Date: Thu, 30 May 2002 09:45:05 -0700 From: William Jhun To: Brian Murphy Cc: linux-mips Subject: Re: pcnet32.c bug? Message-ID: <20020530094505.B22531@ayrnetworks.com> References: <3CF4B1A1.3000607@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CF4B1A1.3000607@murphy.dk>; from brian@murphy.dk on Wed, May 29, 2002 at 12:46:57PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 12:46:57PM +0200, Brian Murphy wrote: > If I don't apply the following patch to pcnet32.c then the network > connection > on my vr5000 box is extremely jerky. It also seems quite sensible to have a > dma sync operation here. Yes, that should be there by all means. We had to add that exact same line to get our pcnet32 working on MIPS. Thanks, William From owner-linux-mips@oss.sgi.com Thu May 30 10:37:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UHbxnC025303 for ; Thu, 30 May 2002 10:37:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UHbxGZ025302 for linux-mips-outgoing; Thu, 30 May 2002 10:37:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ayrnetworks.com (64-166-72-142.ayrnetworks.com [64.166.72.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UHbsnC025299 for ; Thu, 30 May 2002 10:37:54 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g4UHbX722590; Thu, 30 May 2002 10:37:33 -0700 Date: Thu, 30 May 2002 10:37:33 -0700 From: William Jhun To: Zhang Fuxin Cc: Kevin Paul Herbert , "linux-mips@oss.sgi.com" Subject: Re: Re: pcnet32.c bug? Message-ID: <20020530103732.C22531@ayrnetworks.com> References: <200205301546.g4UFkbnC015084@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205301546.g4UFkbnC015084@oss.sgi.com>; from fxzhang@ict.ac.cn on Thu, May 30, 2002 at 11:47:26PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 30, 2002 at 11:47:26PM +0800, Zhang Fuxin wrote: > I think it just mean to invalidate cache contents the cpu has for this > buffer,and thus cpu can be sure to read data dmaed to memory by the device > And now we are doing write back,won't that be overwriting the buffer with > stale data in cache? > > so,the problem is,can we use wback_inv instead of inv in pci_dma_sync_single > when the direction is FROMDEVICE? I don't think so,but that would mean many > current drivers are broken... If I understand this correctly, a writeback means only modified cachelines (i.e. data cache lines with a dirty bit, like 'W', set) will be written back to main memory. Since the driver never actually writes to any of these buffers (and their contents are invalidated on the pci_map_single()), nothing should ever be written back to main memory. If this were not the case, you would surely see packet corruption as the stale cachelines from a re-used buffer would be written back. I tend not to think that it's just coincidence and that MIPS caches tend to be small... So, writeback-invalidate is not incorrect, but it's not efficient for all platforms. Ralf explained to me that some CPUs cannot do indexed invalidates separately from writebacks. I think all three (dma_cache_wback, dma_cache_wback_inv, dma_cache_inv) of these calls should be implemented for all CPUs and default to dma_cache_wback_inv() if not available. I can come up with a patch if people agree (that wback_inv is a suitable replacement for either _inv or _wback; MIPS-specific code than can be written to use whatever is most optimal if present on that architecture... Thanks, Will From owner-linux-mips@oss.sgi.com Thu May 30 10:47:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UHlWnC025661 for ; Thu, 30 May 2002 10:47:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UHlW5D025660 for linux-mips-outgoing; Thu, 30 May 2002 10:47:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from server3.toshibatv.com (mail.toshibatv.com [67.32.37.75]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UHlTnC025656 for ; Thu, 30 May 2002 10:47:29 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id <26NPQT26>; Thu, 30 May 2002 11:02:38 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: system() function Date: Thu, 30 May 2002 11:01:30 -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 I was planning to use system() to invoke a shell and launch a script. However it appears that this causes the parent process to terminate. A note in Linux Programming Bible (Goerzen, 2000) says to never invoke a shell or use the system() function. Having looked at fork() and exec(), these will require obscene amounts of memory and overhead (for an embedded box). I've also looked at vfork() and execve(), which looks like it will do what I want. So do I do the vfork()/execve() pair, or is there a better way? And would sigaction() handling be the way to pass progress information from the child back to the parent process? 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 May 30 10:53:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UHrVnC025954 for ; Thu, 30 May 2002 10:53:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UHrVxh025953 for linux-mips-outgoing; Thu, 30 May 2002 10:53:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pop3.inreach.com (pop3.inreach.com [209.142.2.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UHrOnC025949 for ; Thu, 30 May 2002 10:53:25 -0700 Received: (qmail 26522 invoked from network); 30 May 2002 17:54:53 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by pop3.inreach.com with SMTP; 30 May 2002 17:54:53 -0000 Message-ID: <001601c20803$339e4650$0b01a8c0@w2k30g> From: "David Christensen" To: Subject: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host Date: Thu, 30 May 2002 10:54:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: I have downloaded ftp://ftp.mips.com/pub/linux/mips/installation/redhat7 .1/01.00/MIPS_RedHat7.1_Release-01.00.iso, burned a CD, and followed the instructions provided on the CD (/linux/installation/README) to install Linux (little-endian) on a MIPS Atlas/4Kc board with a SCSI disk. I would now like to recompile the kernel to experiment with sound. I have posted to this mailing list before and was informed that I need a cross- compiler, available on oss.sgi.com. My host is Red Hat Linux-i386 7.3. Following the instructions provided in Chapter 10 of the Linux/MIPS HOWTO (http://oss.sgi.com/mips/mips-howto.html), I have located these files: ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/ binutils-mipsel-linux-2.8.1-2.i386.rpm ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/ egcs-mipsel-linux-1.1.2-4.i386.rpm ftp://oss.sgi.com/pub/linux/mips/glibc/mipsel-linux/ glibc-2.0.6-5lm.mipsel.rpm I am unable to find: glibc-crypt-2.0.6.tar.gz glibc-localedata-2.0.6.tar.gz glibc-linuxthreads-2.0.6.tar.gz Does anybody have any comments or suggestions? TIA, David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Thu May 30 11:40:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UIeYnC026499 for ; Thu, 30 May 2002 11:40:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UIeYU3026498 for linux-mips-outgoing; Thu, 30 May 2002 11:40:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UIeTnC026494 for ; Thu, 30 May 2002 11:40:29 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Thu, 30 May 2002 11:41:34 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4UIg11S015644; Thu, 30 May 2002 11:42:01 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4UIg1F12762; Thu, 30 May 2002 11:42:01 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Re: system() function From: "Justin Carlson" To: "Siders, Keith" cc: "Linux-Mips (E-mail)" In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX> References: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX> X-Mailer: Ximian Evolution 1.0.5 Date: 30 May 2002 11:42:01 -0700 Message-ID: <1022784121.7643.457.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10E8ADD448107-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-05-30 at 09:01, Siders, Keith wrote: > I was planning to use system() to invoke a shell and launch a script. > However it appears that this causes the parent process to terminate. A note > in Linux Programming Bible (Goerzen, 2000) says to never invoke a shell or > use the system() function. Having looked at fork() and exec(), these will > require obscene amounts of memory and overhead (for an embedded box). I'm not sure that fork() qualifies as an "obscene amount of overhead". That may have been true before copy-on-write, but the only thing vfork() saves you with respect to fork() is page table construction, which is not particularly memory or processor intensive. > I've > also looked at vfork() and execve(), which looks like it will do what I > want. So do I do the vfork()/execve() pair, or is there a better way? And > would sigaction() handling be the way to pass progress information from the > child back to the parent process? As a personal preference, I dislike vfork() since it's pretty nonstandard in its behaviour on linux. Generally, though, it sounds like maybe you'd benefit from a copy of Kernighan & Pike's _The Unix Programming Environment_. There are more ways to do interprocess communication than you can shake a stick at, and which one is "right" for you depends largely on your specific application. Signals is a reasonable way (though if you vfork() you won't be able to handle signals in your parent concurrent with the child running...). There are also named pipes, shared memory, SysV messaging... -Justin From owner-linux-mips@oss.sgi.com Thu May 30 12:27:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJRcnC000463 for ; Thu, 30 May 2002 12:27:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJRbI2000462 for linux-mips-outgoing; Thu, 30 May 2002 12:27:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJQWnC000431 for ; Thu, 30 May 2002 12:26:32 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Thu, 30 May 2002 12:28:01 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4UJS31S016298 for ; Thu, 30 May 2002 12:28:03 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4UJS3R17799; Thu, 30 May 2002 12:28:03 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Cache flushing, take 2 From: "Justin Carlson" To: linux-mips@oss.sgi.com X-Mailer: Ximian Evolution 1.0.5 Date: 30 May 2002 12:28:03 -0700 Message-ID: <1022786883.7643.466.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10E8A2CB62503-01-01 Content-Type: multipart/mixed; boundary="=-OIpXZaCsihiMHNAFriFG" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --=-OIpXZaCsihiMHNAFriFG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've taken a second look at the cache flushing, and think maybe this is a better way to fix what I see as the major problems. Attached is a patch which does the following: * Removes __flush_cache_all() * Adds writeback_inv_dcache_all() and writeback_inv_dcache_range(). these functions force the flushing of the dcache, as opposed to the flush_cache_* functions, which only flush if needed for coherence. * Adds better documentation to the function declarations in pgtable.h * Fixes up gdb-stub.c to use this interface * Actually implements the more agressive semantics for the cacheflush system call * Fixes up the old sysmips system call to use this interface I've only implemented the actual new routines for the sb1; I'd like to solicit some feedback as to what other people think of this approach before taking the plunge to other implementations. Note this patch is not tested beyond compilability; if people like this approach I'll flesh it out and resubmit something tested. Comments? -Justin --=-OIpXZaCsihiMHNAFriFG Content-Disposition: attachment; filename=cacheflush.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1; name=cacheflush.patch ? cacheflush.patch Index: arch/mips/kernel/gdb-stub.c =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/kernel/gdb-stub.c,v retrieving revision 1.16 diff -u -r1.16 gdb-stub.c --- arch/mips/kernel/gdb-stub.c 2002/05/29 22:40:04 1.16 +++ arch/mips/kernel/gdb-stub.c 2002/05/30 19:13:10 @@ -575,7 +575,7 @@ async_bp.addr =3D epc; async_bp.val =3D *(unsigned *)epc; *(unsigned *)epc =3D BP; - __flush_cache_all(); + flush_icache_range(epc, epc + 4); } =20 =20 @@ -799,10 +799,8 @@ * has no way of knowing that a data ref to some location * may have changed something that is in the instruction * cache. - * NB: We flush both caches, just to be sure... */ - - __flush_cache_all(); + flush_icache_all(); return; /* NOTREACHED */ break; @@ -831,7 +829,7 @@ * use breakpoints and continue, instead. */ single_step(regs); - __flush_cache_all(); + flush_icache_all(); return; /* NOTREACHED */ =20 Index: arch/mips/kernel/sysmips.c =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/kernel/sysmips.c,v retrieving revision 1.21 diff -u -r1.21 sysmips.c --- arch/mips/kernel/sysmips.c 2002/05/29 18:36:28 1.21 +++ arch/mips/kernel/sysmips.c 2002/05/30 19:13:10 @@ -83,7 +83,8 @@ goto out; =20 case FLUSH_CACHE: - __flush_cache_all(); + flush_icache_all(); + writeback_inv_dcache_all(); retval =3D 0; goto out; =20 Index: arch/mips/mm/c-sb1.c =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/mm/c-sb1.c,v retrieving revision 1.19 diff -u -r1.19 c-sb1.c --- arch/mips/mm/c-sb1.c 2002/05/29 22:40:05 1.19 +++ arch/mips/mm/c-sb1.c 2002/05/30 19:13:10 @@ -74,72 +74,6 @@ { } =20 -static void local_sb1___flush_cache_all(void) -{ - /* - * Haven't worried too much about speed here; given that we're flushing - * the icache, the time to invalidate is dwarfed by the time it's going - * to take to refill it. Register usage: - *=20 - * $1 - moving cache index - * $2 - set count - */ - __asm__ __volatile__ ( - ".set push \n" - ".set noreorder \n" - ".set noat \n" - ".set mips4 \n" - " move $1, %2 \n" /* Start at index 0 */ - "1: cache %3, 0($1) \n" /* WB/Invalidate this index */ - " addiu %1, %1, -1 \n" /* Decrement loop count */ - " bnez %1, 1b \n" /* loop test */ - " addu $1, $1, %0 \n" /* Next address */ - ".set pop \n" - : - : "r" (dcache_line_size), "r" (dcache_sets * dcache_assoc), - "r" (KSEG0), "i" (Index_Writeback_Inv_D)); - - __asm__ __volatile__ ( - ".set push \n" - ".set noreorder \n" - ".set mips2 \n" - "sync \n" -#ifdef CONFIG_SB1_PASS_1_WORKAROUNDS /* Bug 1384 */ =09 - "sync \n" -#endif - ".set pop \n"); - - __asm__ __volatile__ ( - ".set push \n" - ".set noreorder \n" - ".set noat \n" - ".set mips4 \n" - " move $1, %2 \n" /* Start at index 0 */ - "1: cache %3, 0($1) \n" /* Invalidate this index */ - " addiu %1, %1, -1 \n" /* Decrement loop count */ - " bnez %1, 1b \n" /* loop test */ - " addu $1, $1, %0 \n" /* Next address */ - ".set pop \n" - : - : "r" (icache_line_size), "r" (icache_sets * icache_assoc), - "r" (KSEG0), "i" (Index_Invalidate_I)); -} - -#ifdef CONFIG_SMP -extern void sb1___flush_cache_all_ipi(void *ignored); -asm("sb1___flush_cache_all_ipi =3D local_sb1___flush_cache_all"); - -static void sb1___flush_cache_all(void) -{ - smp_call_function(sb1___flush_cache_all_ipi, 0, 1, 1); - local_sb1___flush_cache_all(); -} -#else -extern void sb1___flush_cache_all(void); -asm("sb1___flush_cache_all =3D local_sb1___flush_cache_all"); -#endif - - /* * When flushing a range in the icache, we have to first writeback * the dcache for the same range, so new ifetches will see any @@ -216,33 +150,129 @@ } =20 #ifdef CONFIG_SMP -struct flush_icache_range_args { + +struct flush_cache_range_args { unsigned long start; unsigned long end; }; =20 static void sb1_flush_icache_range_ipi(void *info) { - struct flush_icache_range_args *args =3D info; + struct flush_cache_range_args *args =3D info; =20 local_sb1_flush_icache_range(args->start, args->end); } =20 -void sb1_flush_icache_range(unsigned long start, unsigned long end) +void smp_sb1_flush_icache_range(unsigned long start, unsigned long end) { - struct flush_icache_range_args args; + struct flush_cache_range_args args; =20 args.start =3D start; args.end =3D end; smp_call_function(sb1_flush_icache_range_ipi, &args, 1, 1); local_sb1_flush_icache_range(start, end); } -#else -void sb1_flush_icache_range(unsigned long start, unsigned long end); -asm("sb1_flush_icache_range =3D local_sb1_flush_icache_range"); #endif =20 /* + * Writeback and invalidate a range of addresses. + */ +static void local_sb1_writeback_inv_dcache_range(unsigned long start, unsi= gned long end) +{ +#ifdef CONFIG_SB1_PASS_1_WORKAROUNDS + unsigned long flags; + local_irq_save(flags); +#endif + + __asm__ __volatile__ ( + ".set push \n" + ".set noreorder \n" + ".set noat \n" + ".set mips4 \n" + " move $1, %0 \n"=20 + "1: \n" +#ifdef CONFIG_SB1_PASS_1_WORKAROUNDS + ".align 3 \n" + " lw $0, 0($1) \n" /* Bug 1370, 1368 */ + " sync \n" +#endif + " cache %3, 0($1) \n" /* Hit-WB{,-inval} this address */ + " bne $1, %1, 1b \n" /* loop test */ + " addu $1, $1, %2 \n" /* next line */ + " sync \n" + ".set pop \n" + : + : "r" (start & ~(dcache_line_size - 1)), + "r" ((end - 1) & ~(dcache_line_size - 1)), + "r" (dcache_line_size), + "i" (Hit_Writeback_Inv_D) + ); +#ifdef CONFIG_SB1_PASS_1_WORKAROUNDS + local_irq_restore(flags); +#endif +} + + +#ifdef CONFIG_SMP + +static void sb1_writeback_inv_dcache_range_ipi(void *info) +{ + struct flush_cache_range_args *args =3D info; + + local_sb1_writeback_inv_dcache_range(args->start, args->end); +} + +void smp_sb1_writeback_inv_dcache_range(unsigned long start, unsigned long= end) +{ + struct flush_cache_range_args args; + + args.start =3D start; + args.end =3D end; + smp_call_function(sb1_writeback_inv_dcache_range_ipi, &args, 1, 1); + local_sb1_flush_icache_range(start, end); +} + +#endif + +/* + * Writeback and invalidate the entire dcache + */ +static void local_sb1_writeback_inv_dcache_all(void) +{ + /* + * Register usage: + *=20 + * $1 - moving cache index + * $2 - set count + */ + __asm__ __volatile__ ( + ".set push \n" + ".set noreorder \n" + ".set noat \n" + ".set mips4 \n" + " move $1, %2 \n" /* Start at index 0 */ + "1: cache %3, 0($1) \n" /* Invalidate this index */ + " addiu %1, %1, -1 \n" /* Decrement loop count */ + " bnez %1, 1b \n" /* loop test */ + " addu $1, $1, %0 \n" /* Next address */ + ".set pop \n" + : + : "r" (dcache_line_size), "r" (dcache_sets * dcache_assoc), + "r" (KSEG0), "i" (Index_Writeback_Inv_D)); +} + + +#ifdef CONFIG_SMP + +void smp_sb1_writeback_inv_dcache_all(void) +{ + smp_call_function((void (*)(void *))local_sb1_writeback_inv_dcache_all, 0= , 1, 1); + local_sb1_writeback_inv_dcache_all(); +} + +#endif + +/* * If there's no context yet, or the page isn't executable, no icache flus= h * is needed */ @@ -257,7 +287,7 @@ * conservatively flush the entire caches on all processors * (ouch). */ - sb1___flush_cache_all(); + flush_icache_all(); } =20 static inline void protected_flush_icache_line(unsigned long addr) @@ -345,7 +375,7 @@ protected_flush_icache_line(iaddr); } =20 -static void sb1_flush_cache_sigtramp(unsigned long addr) +static void smp_sb1_flush_cache_sigtramp(unsigned long addr) { unsigned long tmp; =20 @@ -359,10 +389,6 @@ =20 smp_call_function(sb1_flush_cache_sigtramp_ipi, (void *) addr, 1, 1); } - -#else -void sb1_flush_cache_sigtramp(unsigned long addr); -asm("sb1_flush_cache_sigtramp =3D local_sb1_flush_cache_sigtramp"); #endif =20 static void sb1_flush_icache_all(void) @@ -506,17 +532,26 @@ _copy_page =3D sb1_copy_page; =20 _flush_cache_all =3D sb1_flush_cache_all; - ___flush_cache_all =3D sb1___flush_cache_all; _flush_cache_mm =3D (void (*)(struct mm_struct *))sb1_nop; _flush_cache_range =3D (void *) sb1_nop; _flush_page_to_ram =3D sb1_flush_page_to_ram; _flush_icache_page =3D sb1_flush_icache_page; - _flush_icache_range =3D sb1_flush_icache_range; + +#ifdef CONFIG_SMP + _writeback_inv_dcache_range =3D smp_sb1_writeback_inv_dcache_range; + _writeback_inv_dcache_all =3D smp_sb1_writeback_inv_dcache_all; + _flush_icache_range =3D smp_sb1_flush_icache_range; + _flush_cache_sigtramp =3D smp_sb1_flush_cache_sigtramp; +#else + _writeback_inv_dcache_range =3D local_sb1_writeback_inv_dcache_range; + _writeback_inv_dcache_all =3D local_sb1_writeback_inv_dcache_all; + _flush_icache_range =3D local_sb1_flush_icache_range; + _flush_cache_sigtramp =3D local_sb1_flush_cache_sigtramp;=09 +#endif =20 /* None of these are needed for the sb1 */ _flush_cache_page =3D (void *) sb1_nop; =20 - _flush_cache_sigtramp =3D sb1_flush_cache_sigtramp; _flush_icache_all =3D sb1_flush_icache_all; =20 change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_COW); Index: arch/mips/mm/init.c =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/mm/init.c,v retrieving revision 1.43 diff -u -r1.43 init.c --- arch/mips/mm/init.c 2002/03/15 03:14:31 1.43 +++ arch/mips/mm/init.c 2002/05/30 19:13:10 @@ -37,6 +37,7 @@ #include #include #include +#include =20 mmu_gather_t mmu_gathers[NR_CPUS]; unsigned long highstart_pfn, highend_pfn; @@ -48,8 +49,21 @@ =20 asmlinkage int sys_cacheflush(void *addr, int bytes, int cache) { - /* This should flush more selectivly ... */ - __flush_cache_all(); + if (cache & ~(ICACHE | DCACHE)) { + return -EINVAL; + } +=09 + if (verify_area(VERIFY_READ, addr, bytes)) { + return -EFAULT; + } + + if (cache & DCACHE) { + writeback_inv_dcache_range((unsigned long)addr, (unsigned long)addr + by= tes); + }=20 + + if (cache & ICACHE) { + flush_icache_range((unsigned long)addr, ((unsigned long)addr) + bytes); + } =20 return 0; } Index: arch/mips/mm/loadmmu.c =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/mm/loadmmu.c,v retrieving revision 1.45 diff -u -r1.45 loadmmu.c --- arch/mips/mm/loadmmu.c 2001/11/29 04:47:24 1.45 +++ arch/mips/mm/loadmmu.c 2002/05/30 19:13:10 @@ -24,7 +24,6 @@ =20 /* Cache operations. */ void (*_flush_cache_all)(void); -void (*___flush_cache_all)(void); void (*_flush_cache_mm)(struct mm_struct *mm); void (*_flush_cache_range)(struct mm_struct *mm, unsigned long start, unsigned long end); @@ -35,6 +34,8 @@ =20 void (*_flush_page_to_ram)(struct page * page); void (*_flush_icache_all)(void); +void (*_writeback_inv_dcache_range)(unsigned long start, unsigned long end= ); +void (*_writeback_inv_dcache_all) (void); =20 #ifdef CONFIG_NONCOHERENT_IO =20 Index: include/asm-mips/pgtable.h =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/include/asm-mips/pgtable.h,v retrieving revision 1.74 diff -u -r1.74 pgtable.h --- include/asm-mips/pgtable.h 2002/05/28 09:58:58 1.74 +++ include/asm-mips/pgtable.h 2002/05/30 19:13:22 @@ -17,49 +17,70 @@ #include #include =20 -/* Cache flushing: +/* Generic cache flushing. See Documentation/cachetlb for more specific d= etails * - * - flush_cache_all() flushes entire cache - * - flush_cache_mm(mm) flushes the specified mm context's cache lines - * - flush_cache_page(mm, vmaddr) flushes a single page - * - flush_cache_range(mm, start, end) flushes a range of pages - * - flush_page_to_ram(page) write back kernel page to ram - * - flush_icache_range(start, end) flush a range of instructions + * Note that none of these routines check access permissions. Any needed + * checking should be done by the caller. * - * - flush_cache_sigtramp() flush signal trampoline - * - flush_icache_all() flush the entire instruction cache + * - flush_cache_all Writeback & inval all virtually mapped cached d= ata + * & ensure all writes are visible to the system= . + * - flush_cache_mm Same as above, but only for a specific mm conte= xt + * - flush_cache_page Same as above, but for a single page + * - flush_cache_range Same as above, for a range of addresses + * - flush_page_to_ram Clear all virtual mappings of this physical pag= e + * - flush_icache_range An istream modification may have occurred; ensu= re=20 + * that all data stores before this point are vi= sible=20 + * for new instruction fetches for the given ran= ge. + * - flush_icache_page Same as above, but for a specific page */ -extern void (*_flush_cache_all)(void); -extern void (*___flush_cache_all)(void); -extern void (*_flush_cache_mm)(struct mm_struct *mm); -extern void (*_flush_cache_range)(struct mm_struct *mm, unsigned long star= t, - unsigned long end); -extern void (*_flush_cache_page)(struct vm_area_struct *vma, unsigned long= page); -extern void (*_flush_page_to_ram)(struct page * page); + +/* + * Mips-specific cache flushing. =20 + * - flush_icache_all Same as flush_icache_range, for all memor= y=20 + * - writeback_inv_dcache_all Force writeback and invalidation of the f= irst + * level dcache. + * - writeback_inv_dcache_range Same as above, but for a specific virtual= range + * - flush_cache_sigtramp Flush signal trampoline + */ + +extern void (*_flush_cache_all) (void); +extern void (*_flush_cache_mm) (struct mm_struct *mm); +extern void (*_flush_cache_page) (struct vm_area_struct *vma,=20 + unsigned long page); +extern void (*_flush_cache_range) (struct mm_struct *mm, unsigned long sta= rt, + unsigned long end); +extern void (*_flush_page_to_ram) (struct page * page); extern void (*_flush_icache_range)(unsigned long start, unsigned long end)= ; -extern void (*_flush_icache_page)(struct vm_area_struct *vma, - struct page *page); -extern void (*_flush_cache_sigtramp)(unsigned long addr); -extern void (*_flush_icache_all)(void); +extern void (*_flush_icache_page) (struct vm_area_struct *vma, + struct page *page); + +extern void (*_flush_icache_all) (void); +extern void (*_writeback_inv_dcache_all) (void); +extern void (*_writeback_inv_dcache_range)(unsigned long start,=20 + unsigned long end); +extern void (*_flush_cache_sigtramp) (unsigned long addr); + =20 #define flush_dcache_page(page) do { } while (0) =20 #define flush_cache_all() _flush_cache_all() -#define __flush_cache_all() ___flush_cache_all() #define flush_cache_mm(mm) _flush_cache_mm(mm) -#define flush_cache_range(mm,start,end) _flush_cache_range(mm,start,end) #define flush_cache_page(vma,page) _flush_cache_page(vma, page) +#define flush_cache_range(mm,start,end) _flush_cache_range(mm,start,end) #define flush_page_to_ram(page) _flush_page_to_ram(page) - #define flush_icache_range(start, end) _flush_icache_range(start,end) #define flush_icache_page(vma, page) _flush_icache_page(vma, page) + + =20 -#define flush_cache_sigtramp(addr) _flush_cache_sigtramp(addr) #ifdef CONFIG_VTAG_ICACHE -#define flush_icache_all() _flush_icache_all() +#define flush_icache_all() _flush_icache_all() #else -#define flush_icache_all() do { } while(0) +#define flush_icache_all() do { } while(0) #endif +#define writeback_inv_dcache_all() _writeback_inv_dcache_all() +#define writeback_inv_dcache_range(start, end) _writeback_inv_dcache_range= (start, end) +#define flush_cache_sigtramp(addr) _flush_cache_sigtramp(addr) =20 /* * - add_wired_entry() add a fixed TLB entry, and move wired register --=-OIpXZaCsihiMHNAFriFG-- From owner-linux-mips@oss.sgi.com Thu May 30 12:30:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJUhnC000628 for ; Thu, 30 May 2002 12:30:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJUhZX000627 for linux-mips-outgoing; Thu, 30 May 2002 12:30:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pop3.inreach.com (pop3.inreach.com [209.142.2.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJUZnC000623 for ; Thu, 30 May 2002 12:30:35 -0700 Received: (qmail 3439 invoked from network); 30 May 2002 19:32:04 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by pop3.inreach.com with SMTP; 30 May 2002 19:32:04 -0000 Message-ID: <002401c20810$c73edd40$0b01a8c0@w2k30g> From: "David Christensen" To: References: <001601c20803$339e4650$0b01a8c0@w2k30g> Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host Date: Thu, 30 May 2002 12:32:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com: I tried installing the three packages anyway. binutils and egcs installed fine. They contain files and directories with "mips-linux", etc., in their names, so they don't conflict with my native i386 installation: root@r7320g:~# rpm -ihv binutils-mipsel-linux-2.8.1-2.i386.rpm Preparing... ######################################## ### [100%] 1:binutils-mipsel-linux ######################################## ### [100%] root@r7320g:~# rpm -ihv egcs-mipsel-linux-1.1.2-4.i386.rpm Preparing... ######################################## ### [100%] 1:egcs-mipsel-linux ######################################## ### [100%] But glibc has problems: root@r7320g:~# rpm -ihv glibc-2.0.6-5lm.mipsel.rpm error: failed dependencies: glibc < 2.2.5 conflicts with glibc-common-2.2.5-34 glibc < 2.1.90 conflicts with db1-1.85-8 glibc < 2.1.90 conflicts with db2-2.4.14-10 glibc < 2.1.90 conflicts with gnome-libs-1.4.1.2.90-14 Looking at the contents: root@r7320g:~# rpm -q -l -p glibc-2.0.6-5lm.mipsel.rpm | head /etc/nsswitch.conf /etc/rpc /lib/ld-2.0.6.so /lib/ld.so.1 /lib/libBrokenLocale-2.0.6.so /lib/libBrokenLocale.so.1 /lib/libc-2.0.6.so /lib/libc.so.6 /lib/libcrypt-2.0.6.so /lib/libcrypt.so.1 It contains files that would break my native i386 installation: root@r7320g:~# ls -1 /etc/nsswitch.conf /etc/rpc /lib/ld* /etc/nsswitch.conf /etc/rpc /lib/ld-2.2.5.so /lib/ld-linux.so.2 Any comments or suggestions? TIA, David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Thu May 30 12:31:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJVInC000664 for ; Thu, 30 May 2002 12:31:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJVInG000663 for linux-mips-outgoing; Thu, 30 May 2002 12:31:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJVFnC000660 for ; Thu, 30 May 2002 12:31:15 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Thu, 30 May 2002 12:32:45 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4UJWl1S016348 for ; Thu, 30 May 2002 12:32:47 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4UJWlv17833; Thu, 30 May 2002 12:32:47 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Function pointers and #defines From: "Justin Carlson" To: linux-mips@oss.sgi.com X-Mailer: Ximian Evolution 1.0.5 Date: 30 May 2002 12:32:47 -0700 Message-ID: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10E8A1D763377-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk A fair number of places in the headers, we have stuff like this: void (*_some_fn)(int arg1, int arg2); #define some_fn(arg1, arg2) _some_fn(arg1, arg2) Why do we do this, as opposed to: void (*some_fn)(int arg1, int arg2); Both syntaxes result in being able to say some_fn(1, 2); but the latter is both clearer and shorter. Is there some deep, mystical C reason that we use the former, or did someone do it that way a long time ago and no one has changed it? -Justin From owner-linux-mips@oss.sgi.com Thu May 30 12:34:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJYwnC000812 for ; Thu, 30 May 2002 12:34:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJYww3000811 for linux-mips-outgoing; Thu, 30 May 2002 12:34:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJYrnC000807 for ; Thu, 30 May 2002 12:34:54 -0700 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g4UJaBG04915; Thu, 30 May 2002 21:36:11 +0200 From: Hartvig Ekner Message-Id: <200205301936.g4UJaBG04915@coplin09.mips.com> Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host To: dpchrist@holgerdanske.com (David Christensen) Date: Thu, 30 May 2002 21:36:10 +0200 (CEST) Cc: linux-mips@oss.sgi.com In-Reply-To: from "David Christensen" at May 30, 2002 10:54:55 AM 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 Hi David, David Christensen writes: > > linux-mips@oss.sgi.com: > > I have downloaded ftp://ftp.mips.com/pub/linux/mips/installation/redhat7 > .1/01.00/MIPS_RedHat7.1_Release-01.00.iso, burned a CD, and followed the > instructions provided on the CD (/linux/installation/README) to install > Linux (little-endian) on a MIPS Atlas/4Kc board with a SCSI disk. Note that you can install the Release-02.00 (with all the latest RPMs from H.J.) as well on an Atlas, you'll just have to use the 2.4.3 install kernel from the 01.00 CD image you downloaded, and everything else from the new release. > would now like to recompile the kernel to experiment with sound. I have > posted to this mailing list before and was informed that I need a cross- > compiler, available on oss.sgi.com. My host is Red Hat Linux-i386 7.3. For kernel cross compilation we use the following binary RPM's (LE shown only): binutils-mipsel-linux-2.9.5-3 egcs-mipsel-linux-1.1.2-4 They can be found on: ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mipsel-linux/ /Hartvig From owner-linux-mips@oss.sgi.com Thu May 30 12:57:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJvGnC001173 for ; Thu, 30 May 2002 12:57:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJvGaU001172 for linux-mips-outgoing; Thu, 30 May 2002 12:57:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mms2.broadcom.com (mms2.broadcom.com [63.70.210.59]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJvDnC001169 for ; Thu, 30 May 2002 12:57:14 -0700 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7)); Thu, 30 May 2002 12:57:00 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from ldt-sj3-022.sj.broadcom.com (ldt-sj3-022 [10.21.64.22]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g4UJwj1S016616; Thu, 30 May 2002 12:58:45 -0700 (PDT) Received: (from carlson@localhost) by ldt-sj3-022.sj.broadcom.com ( 8.11.6/8.9.3) id g4UJwj619434; Thu, 30 May 2002 12:58:45 -0700 X-Authentication-Warning: ldt-sj3-022.sj.broadcom.com: carlson set sender to justinca@cs.cmu.edu using -f Subject: Re: Function pointers and #defines From: "Justin Carlson" To: "Daniel Jacobowitz" cc: linux-mips@oss.sgi.com In-Reply-To: <20020530195052.GA10587@branoic.them.org> References: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> <20020530195052.GA10587@branoic.them.org> X-Mailer: Ximian Evolution 1.0.5 Date: 30 May 2002 12:58:44 -0700 Message-ID: <1022788724.7890.475.camel@ldt-sj3-022.sj.broadcom.com> MIME-Version: 1.0 X-WSS-ID: 10E85B8659714-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-05-30 at 12:50, Daniel Jacobowitz wrote: > > but the latter is both clearer and shorter. Is there some deep, > > mystical C reason that we use the former, or did someone do it that way > > a long time ago and no one has changed it? > > At a guess, this prevents taking the address of the function > unintentionally... But if you're writing code in such a way that the compiler type checking doesn't flag this, you deserve what you get. (IMHO, of course. :) -Justin From owner-linux-mips@oss.sgi.com Thu May 30 12:59:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UJxcnC001281 for ; Thu, 30 May 2002 12:59:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UJxcC7001280 for linux-mips-outgoing; Thu, 30 May 2002 12:59:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UJxZnC001277 for ; Thu, 30 May 2002 12:59:35 -0700 Received: from branoic (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 NAA06433 for ; Thu, 30 May 2002 13:01:05 -0700 (PDT) mail_from (drow@branoic.them.org) Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17DVwj-0002l3-00; Thu, 30 May 2002 15:50:53 -0400 Date: Thu, 30 May 2002 15:50:52 -0400 From: Daniel Jacobowitz To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: Function pointers and #defines Message-ID: <20020530195052.GA10587@branoic.them.org> References: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, May 30, 2002 at 12:32:47PM -0700, Justin Carlson wrote: > A fair number of places in the headers, we have stuff like this: > > void (*_some_fn)(int arg1, int arg2); > #define some_fn(arg1, arg2) _some_fn(arg1, arg2) > > Why do we do this, as opposed to: > > void (*some_fn)(int arg1, int arg2); > > Both syntaxes result in being able to say > > some_fn(1, 2); > > but the latter is both clearer and shorter. Is there some deep, > mystical C reason that we use the former, or did someone do it that way > a long time ago and no one has changed it? At a guess, this prevents taking the address of the function unintentionally... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu May 30 13:21:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UKLwnC001830 for ; Thu, 30 May 2002 13:21:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UKLwIg001829 for linux-mips-outgoing; Thu, 30 May 2002 13:21:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pop3.inreach.com (pop3.inreach.com [209.142.2.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UKLsnC001826 for ; Thu, 30 May 2002 13:21:54 -0700 Received: (qmail 28417 invoked from network); 30 May 2002 20:23:22 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by pop3.inreach.com with SMTP; 30 May 2002 20:23:22 -0000 Message-ID: <007401c20817$f2277f60$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Hartvig Ekner" References: <200205301936.g4UJaBG04915@coplin09.mips.com> Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host Date: Thu, 30 May 2002 13:06:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com & Hartvig: Hartvig Ekner wrote: > Note that you can install the Release-02.00 (with all the latest RPMs > from H.J.) as well on an Atlas, you'll just have to use the 2.4.3 > install kernel from the 01.00 CD image you downloaded, and everything > else from the new release. I'll keep that in mind for my next install. > For kernel cross compilation we use the following binary RPM's (LE > shown only): > > binutils-mipsel-linux-2.9.5-3 > egcs-mipsel-linux-1.1.2-4 I'll try what I've already installed and see what happens. If it fails, I'll upgrade binutils and try again. Thank you for your help. :-) David From owner-linux-mips@oss.sgi.com Thu May 30 14:07:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UL7cnC002754 for ; Thu, 30 May 2002 14:07:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UL7cxX002753 for linux-mips-outgoing; Thu, 30 May 2002 14:07:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pop3.inreach.com (pop3.inreach.com [209.142.2.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UL7anC002750 for ; Thu, 30 May 2002 14:07:36 -0700 Received: (qmail 11721 invoked from network); 30 May 2002 21:09:05 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by pop3.inreach.com with SMTP; 30 May 2002 21:09:05 -0000 Message-ID: <00b001c2081e$55245240$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Hartvig Ekner" Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host Date: Thu, 30 May 2002 14:09:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com & Hartvig: >> binutils-mipsel-linux-2.9.5-3 >> egcs-mipsel-linux-1.1.2-4 > I'll try what I've already installed and see what happens. It works! :-) David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Thu May 30 14:11:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ULB0nC002847 for ; Thu, 30 May 2002 14:11:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ULAx1L002846 for linux-mips-outgoing; Thu, 30 May 2002 14:10:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ULAtnC002843 for ; Thu, 30 May 2002 14:10:55 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id OAA19029; Thu, 30 May 2002 14:12:21 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA11959; Thu, 30 May 2002 14:12:19 -0700 (PDT) Message-ID: <023001c2081f$95a397d0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Daniel Jacobowitz" , "Justin Carlson" Cc: References: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> <20020530195052.GA10587@branoic.them.org> Subject: Re: Function pointers and #defines Date: Thu, 30 May 2002 23:18:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk From: "Daniel Jacobowitz" > On Thu, May 30, 2002 at 12:32:47PM -0700, Justin Carlson wrote: > > A fair number of places in the headers, we have stuff like this: > > > > void (*_some_fn)(int arg1, int arg2); > > #define some_fn(arg1, arg2) _some_fn(arg1, arg2) > > > > Why do we do this, as opposed to: > > > > void (*some_fn)(int arg1, int arg2); > > > > Both syntaxes result in being able to say > > > > some_fn(1, 2); > > > > but the latter is both clearer and shorter. Is there some deep, > > mystical C reason that we use the former, or did someone do it that way > > a long time ago and no one has changed it? > > At a guess, this prevents taking the address of the function > unintentionally... More likely, some ancient early version of the code was written with a single global function, some_fn(), and it was easier to override it with a pointer indirection in the header than to hunt down and change all invocations. Sometimes that's good software engineering. Sometimes it's just laziness... Kevin K. From owner-linux-mips@oss.sgi.com Thu May 30 14:12:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ULC6nC002950 for ; Thu, 30 May 2002 14:12:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ULC65x002949 for linux-mips-outgoing; Thu, 30 May 2002 14:12:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ULBwnC002898 for ; Thu, 30 May 2002 14:11:58 -0700 Received: from Muruga.localdomain (adsl-63-199-30-114.dsl.snfc21.pacbell.net [63.199.30.114]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with ESMTP id g4ULDN2115254; Thu, 30 May 2002 17:13:23 -0400 Received: from localhost (muthu@localhost) by Muruga.localdomain (8.11.2/8.11.2) with ESMTP id g4UL5HX04791; Thu, 30 May 2002 14:05:17 -0700 X-Authentication-Warning: Muruga.localdomain: muthu owned process doing -bs Date: Thu, 30 May 2002 14:05:17 -0700 (PDT) From: Muthukumar Ratty X-X-Sender: To: David Christensen cc: , Hartvig Ekner Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host In-Reply-To: <007401c20817$f2277f60$0b01a8c0@w2k30g> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 30 May 2002, David Christensen wrote: > linux-mips@oss.sgi.com & Hartvig: > > Hartvig Ekner wrote: > > from H.J.) as well on an Atlas, you'll just have to use the 2.4.3 > > install kernel from the 01.00 CD image you downloaded, and everything > > else from the new release. Is there any latest kernel (2.5.xx) available for MIPS/Atlas? > > > > > binutils-mipsel-linux-2.9.5-3 > > egcs-mipsel-linux-1.1.2-4 > I played around with some cross-compilers and what I understood is 1. Algorithmics sde4 is not matured enough to compile 2.4.xx kernels (As Dominic Sweetman mentioned in his reply to my help mail). He said sde5 will do but I dint get a chance to try this. Any update from anyone used it? 2. I followed BradLaRondes write up - Building a Modern Mips Tool chain (I dont have the link irght now, but you can google it). It compiles the kernel and Applications. But it requires kernel header lying around from previous builds. So if you are just starting, then you may wanna grab the header from somewhere. But the problem with this toolchain is: I was not able to build Yamon SREC using this. 3. I also tried Steve Hills toolchain located at ftp://ftp.cotw.com/Linux/MIPS/toolchain/experimental It is complete and I can build kernel and applications with it. Again I couldnt build Yamon SREC with it. BTW you may need to do slight changes, like changing target from little-mips to tradlittle-mips etc. Its simple but if you get stuck, post it here and someone will help you. All the best, Muthu > I'll try what I've already installed and see what happens. If it fails, > I'll upgrade binutils and try again. > > > Thank you for your help. :-) > > > David > > > > > From owner-linux-mips@oss.sgi.com Thu May 30 14:24:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ULOxnC003255 for ; Thu, 30 May 2002 14:24:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ULOxW8003254 for linux-mips-outgoing; Thu, 30 May 2002 14:24:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from coplin09.mips.com ([80.63.7.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ULOrnC003251 for ; Thu, 30 May 2002 14:24:53 -0700 Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g4ULPgq05186; Thu, 30 May 2002 23:25:42 +0200 From: Hartvig Ekner Message-Id: <200205302125.g4ULPgq05186@coplin09.mips.com> Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc To: muthu5@sbcglobal.net (Muthukumar Ratty) Date: Thu, 30 May 2002 23:25:42 +0200 (CEST) Cc: dpchrist@holgerdanske.com (David Christensen), linux-mips@oss.sgi.com, hartvige@mips.com (Hartvig Ekner) In-Reply-To: from "Muthukumar Ratty" at May 30, 2002 02:05:17 PM 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 Hi, Muthukumar Ratty writes: > > On Thu, 30 May 2002, David Christensen wrote: > > > linux-mips@oss.sgi.com & Hartvig: > > > > Hartvig Ekner wrote: > > > from H.J.) as well on an Atlas, you'll just have to use the 2.4.3 > > > install kernel from the 01.00 CD image you downloaded, and everything > > > else from the new release. > > Is there any latest kernel (2.5.xx) available for MIPS/Atlas? No. Not from us anyway. Internally, we use the Linux systems heavily for processor testing, so we tend to stay away from the bleeding edge (== too many problems and SW bugs). That is also why we haven't switched to 2.4.18 until now. That being said, there are probably many others who compile & use 2.5 kernels for MIPS. > I played around with some cross-compilers and what I understood is > > 1. Algorithmics sde4 is not matured enough to compile 2.4.xx kernels (As > Dominic Sweetman mentioned in his reply to my help mail). He said sde5 > will do but I dint get a chance to try this. Any update from anyone used it? We're using a beta of it - and there are known issues being worked on, both compiling userland natively and kernel cross compiles. You'll have to ask Dom when he expects final 5.0 to go out the door. /Hartvig From owner-linux-mips@oss.sgi.com Thu May 30 14:57:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4ULvLnC003618 for ; Thu, 30 May 2002 14:57:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4ULvL1m003617 for linux-mips-outgoing; Thu, 30 May 2002 14:57:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from irongate.swansea.linux.org.uk (pc2-cwma1-5-cust12.swa.cable.ntl.com [80.5.121.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4ULvFnC003614 for ; Thu, 30 May 2002 14:57:16 -0700 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.2/8.11.6) with ESMTP id g4UN2lZ1017552; Fri, 31 May 2002 00:02:48 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g4UN2jmc017550; Fri, 31 May 2002 00:02:45 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: system() function From: Alan Cox To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX> References: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 31 May 2002 00:02:45 +0100 Message-Id: <1022799765.9255.400.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 2002-05-30 at 17:01, Siders, Keith wrote: > I was planning to use system() to invoke a shell and launch a script. You can do that yes > However it appears that this causes the parent process to terminate. A note No it doesn't > in Linux Programming Bible (Goerzen, 2000) says to never invoke a shell or > use the system() function. Having looked at fork() and exec(), these will > require obscene amounts of memory and overhead (for an embedded box). I've Nope. > also looked at vfork() and execve(), which looks like it will do what I > want. So do I do the vfork()/execve() pair, or is there a better way? And > would sigaction() handling be the way to pass progress information from the > child back to the parent process? system is actually implemented using either vfork/execve or fork/execve to run your command through the shell. It works great but you do need to remember its going via the shell so things like "*" will be expanded. fork creates a copy on write clone of the process (ie the program data is not actually copied unless either task writes to it), so it generally uses very little ram indeed, especially when one of them exec's something From owner-linux-mips@oss.sgi.com Thu May 30 15:14:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UMEwnC003848 for ; Thu, 30 May 2002 15:14:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UMEwa7003847 for linux-mips-outgoing; Thu, 30 May 2002 15:14:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UMEtnC003839 for ; Thu, 30 May 2002 15:14:55 -0700 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 g4UMGB6F021416; Thu, 30 May 2002 15:16:11 -0700 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 g4UMGAma021412; Thu, 30 May 2002 15:16:10 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 30 May 2002 15:16:10 -0700 (PDT) From: James Simmons To: Florian Lohoff cc: Brian Murphy , linux-mips Subject: Re: New platforms In-Reply-To: <20020530094255.GA18436@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 > PS: I dont like this split up tree - Currently Ralf is the one > feeding mainstream so please stop this diversification of the trees > as the normal user gets completely confused which makes linux mips > a VERY BAD target and does not help any popularity for the mips targets. > We had the linux-vr desaster before which helped nothing but in > the end bound developer efforts which were useless in the end. True. The problem is the slow migration to Linus tree and the slow migration into the OSS tree. Here is a suggestion, how about using the BK tree at bkbits.net. There is a mips tree there but it has never been used. The question is who is the admin of that tree so we can have access ? From owner-linux-mips@oss.sgi.com Thu May 30 15:33:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UMX5nC004086 for ; Thu, 30 May 2002 15:33:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UMX5tw004085 for linux-mips-outgoing; Thu, 30 May 2002 15:33:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from gateway.total-knowledge.com (12-236-42-25.client.attbi.com [12.236.42.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UMWxnC004082 for ; Thu, 30 May 2002 15:33:00 -0700 Received: (qmail 12286 invoked by uid 502); 30 May 2002 22:34:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 May 2002 22:34:32 -0000 Date: Thu, 30 May 2002 15:34:26 -0700 (PDT) From: Ilya X-X-Sender: ilya@ns2.total-knowledge.com To: James Simmons cc: Florian Lohoff , Brian Murphy , linux-mips Subject: Re: New platforms 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 30 May 2002, James Simmons wrote: > > > PS: I dont like this split up tree - Currently Ralf is the one > > feeding mainstream so please stop this diversification of the trees > > as the normal user gets completely confused which makes linux mips > > a VERY BAD target and does not help any popularity for the mips targets. > > We had the linux-vr desaster before which helped nothing but in > > the end bound developer efforts which were useless in the end. > > True. The problem is the slow migration to Linus tree and the slow > migration into the OSS tree. You can always pos your patches to the list, and whatever didn't make it into the tree, can be picked up from there by interested parties. > Here is a suggestion, how about using the BK > tree at bkbits.net. There is a mips tree there but it has never been used. > The question is who is the admin of that tree so we can have access ? Are you saing "let's make yet another tree"? Ugh... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE89qj484S94bALfyURAufLAJ9s0E5CSZllyEq4wFcTgogaBra38QCgpntH CjYS1mv/lzI9xnTS3NspGoM= =UBYu -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Thu May 30 16:34:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4UNYPnC004532 for ; Thu, 30 May 2002 16:34:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4UNYPeV004531 for linux-mips-outgoing; Thu, 30 May 2002 16:34:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hotmail.com (CacheFlowServer@[62.3.37.134]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UNYBnC004527; Thu, 30 May 2002 16:34:16 -0700 Reply-To: Message-ID: <020d02c54a3b$1178e6c6$0ce08ae7@wafgxy> From: To: stephane@oss.sgi.com Subject: re Date: Thu, 30 May 0102 22:35:21 +0100 MiME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk salut! hi! Gutentag! LA liste des meilleurs sites x gratuits: THE list of the best free x web sites: DIE X Internet-Adresse (kostenlose sex): en francais: http://www.best-annuaire.com in english: http://uk.best-annuaire.com 6583vnvk6-546ql13 From owner-linux-mips@oss.sgi.com Thu May 30 17:21:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V0LRnC005395 for ; Thu, 30 May 2002 17:21:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V0LRRB005394 for linux-mips-outgoing; Thu, 30 May 2002 17:21:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pop3.inreach.com (pop3.inreach.com [209.142.2.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V0LOnC005391 for ; Thu, 30 May 2002 17:21:25 -0700 Received: (qmail 22753 invoked from network); 31 May 2002 00:22:53 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by pop3.inreach.com with SMTP; 31 May 2002 00:22:53 -0000 Message-ID: <014201c20839$6804ac50$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Muthukumar Ratty" References: Subject: Re: cross-compiler for MIPS_RedHat7.1_Release-01.00 on Atlas/4Kc using RH7.3-i386 host Date: Thu, 30 May 2002 17:23:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk linux-mips@oss.sgi.com & Muthukumar: Muthukumar Ratty wrote: > BTW you may need to do slight changes, like changing target from > little-mips to tradlittle-mips etc. Its simple but if you get stuck, > post it here and someone will help you. So far, no problems. :-) Thank you for your reply. David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Thu May 30 17:56:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V0u3nC010514 for ; Thu, 30 May 2002 17:56:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V0u3ql010513 for linux-mips-outgoing; Thu, 30 May 2002 17:56:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V0tunC010509 for ; Thu, 30 May 2002 17:55:57 -0700 Message-Id: <200205310055.g4V0tunC010509@oss.sgi.com> Received: (qmail 10240 invoked from network); 31 May 2002 00:48:18 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 31 May 2002 00:48:18 -0000 Date: Fri, 31 May 2002 8:56:47 +0800 From: "Zhang Fuxin" To: William Jhun CC: "linux-mips@oss.sgi.com" Subject: Re: Re: Re: pcnet32.c bug? X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g4V0tvnC010510 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk hi, >> >> so,the problem is,can we use wback_inv instead of inv in pci_dma_sync_single >> when the direction is FROMDEVICE? I don't think so,but that would mean many >> current drivers are broken... > >If I understand this correctly, a writeback means only modified >cachelines (i.e. data cache lines with a dirty bit, like 'W', set) will >be written back to main memory. Since the driver never actually writes >to any of these buffers (and their contents are invalidated on the >pci_map_single()), nothing should ever be written back to main memory. >If this were not the case, you would surely see packet corruption as the >stale cachelines from a re-used buffer would be written back. I tend not >to think that it's just coincidence and that MIPS caches tend to be >small... Oh,yes,thank you. > >So, writeback-invalidate is not incorrect, but it's not efficient for >all platforms. Ralf explained to me that some CPUs cannot do indexed >invalidates separately from writebacks. > >I think all three (dma_cache_wback, dma_cache_wback_inv, >dma_cache_inv) of these calls should be implemented for all CPUs and >default to dma_cache_wback_inv() if not available. I can come up with a >patch if people agree (that wback_inv is a suitable replacement for >either _inv or _wback; MIPS-specific code than can be written to use >whatever is most optimal if present on that architecture... Why not? We have many different c-xxx.c for caches anyway. > >Thanks, >Will = = = = = = = = = = = = = = = = = = = = Best Regards --------------------------------------- Zhang Fuxin System Architecture Lab Institute of Computing Technology Chinese Academy of Sciences,China http://www.ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-05-31 From owner-linux-mips@oss.sgi.com Thu May 30 17:57:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V0vWnC010590 for ; Thu, 30 May 2002 17:57:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V0vWNS010589 for linux-mips-outgoing; Thu, 30 May 2002 17:57:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V0vVnC010586 for ; Thu, 30 May 2002 17:57:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g4V0wl002329 for linux-mips@oss.sgi.com; Thu, 30 May 2002 17:58:47 -0700 Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4UDhNnC003555 for ; Thu, 30 May 2002 06:43:23 -0700 Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) 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 GAA00228 for ; Thu, 30 May 2002 06:44:53 -0700 (PDT) mail_from (florian@void.s.bawue.de) Received: from fwd00.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17DQ4m-0000O4-08; Thu, 30 May 2002 15:34:48 +0200 Received: from void.s.bawue.de (520095841842-0001@[62.155.180.20]) by fmrl00.sul.t-online.com with esmtp id 17DQ4c-1yhO1QC; Thu, 30 May 2002 15:34:38 +0200 Received: from florian by void.s.bawue.de with local (Exim 3.33 #1 (Debian)) id 17DP5M-0002Bk-00; Thu, 30 May 2002 14:31:20 +0200 Date: Thu, 30 May 2002 14:31:20 +0200 To: linux-mips@oss.sgi.com Subject: Re: __flush_cache_all() miscellany Message-ID: <20020530123120.GB1203@void.s.bawue.de> Mail-Followup-To: Florian Laws , linux-mips@oss.sgi.com References: <1022691053.7644.16.camel@ldt-sj3-022.sj.broadcom.com> <20020529140759.A888@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020529140759.A888@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: Florian Laws X-Sender: 520095841842-0001@t-dialin.net Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 02:07:59PM -0700, Ralf Baechle wrote: > > > > Which caches does this apply to? It looks like the current > > implementations assume L1 only. > > The operation got introduced for the R10000 where we only need to flush > the caches during initialization or the (unlikely on Origin) case of Which case? Thanks, Florian From owner-linux-mips@oss.sgi.com Thu May 30 19:27:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V2RSnC014339 for ; Thu, 30 May 2002 19:27:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V2RStg014338 for linux-mips-outgoing; Thu, 30 May 2002 19:27:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V2ROnC014334 for ; Thu, 30 May 2002 19:27:25 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [128.167.58.27]) with SMTP; 31 May 2002 02:28:59 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 86EC0B46B; Fri, 31 May 2002 11:28:57 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA10842; Fri, 31 May 2002 11:28:57 +0900 (JST) Date: Fri, 31 May 2002 11:28:47 +0900 (JST) Message-Id: <20020531.112847.74756483.nemoto@toshiba-tops.co.jp> To: takeshi_aihana@montavista.co.jp Cc: linux-mips@oss.sgi.com Subject: Re: (Re-Send) shmctl() returns corrupt value on pb1000. From: Atsushi Nemoto In-Reply-To: <1022763778.1046.71.camel@aihana> References: <1022757017.1045.47.camel@aihana> <20020530.211902.102583216.nemoto@toshiba-tops.co.jp> <1022763778.1046.71.camel@aihana> 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.2 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 30 May 2002 22:02:57 +0900, Takeshi Aihana said: takeshi_aihana> (B) The version of glibc on pb1000 is 2.2.3/kernel-2.4.17. takeshi_aihana> Is there any inconsistents on those conditions? AFAIK, Yes. For example, look struct ipc_perm in bits/ipc.h and struct ipc64_perm in asm-mips/ipcbuf.h (not struct ipc_perm in linux/ipc.h which is obsolete). takeshi_aihana> Should be update to 2.2.4 on pb1000? If you can. Please do not forget rebuilding all applications which including these headers. If you want to stay in 2.2.3, you will have to modify your kernel headers according to the libc headers. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Thu May 30 20:22:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V3MinC016323 for ; Thu, 30 May 2002 20:22:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V3MiL7016322 for linux-mips-outgoing; Thu, 30 May 2002 20:22:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V3MbnC016319 for ; Thu, 30 May 2002 20:22:37 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020531032406.FQXQ29266.sccrmhc01.attbi.com@ocean.lucon.org> for ; Fri, 31 May 2002 03:24:06 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id AEE2B125C3; Thu, 30 May 2002 20:24:04 -0700 (PDT) Date: Thu, 30 May 2002 20:24:04 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Announce RedHat 7.3 for mips/mipsel Message-ID: <20020530202404.A13170@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 My mini-port of RedHat 7.3 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.3/ It has both mips (big endian) and mipsel (little endian) binary rpms. You should be able to put a small RedHat 7.3 on the mips/mipsel box and compile the rest of RedHat 7.3 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.3/x86 is provided as the toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. This toolchain is a combination of gcc, binutils, gdb and glibc. It is packaged for the cross compiling. It allows you to cross compile to RedHat 7.3/mips/mipsel from a RedHat 7.3/x86 host. 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. baseline.tar.bz2 contains the cross build tree. You may need to install i386 rpm binary included here to rebuild mips/mipsel rpms on an x86 host. The "installer" directory has a simple installer, which can be used to prepare NFS root and install RedHat 7.3/mips/mipsel on a hard drive. 4. 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. 5. You should build/install perl rpm natively on your newly installed mips/mipsel box. Thanks. H.J. From owner-linux-mips@oss.sgi.com Fri May 31 02:13:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V9D9nC024229 for ; Fri, 31 May 2002 02:13:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V9D9Gw024228 for linux-mips-outgoing; Fri, 31 May 2002 02:13:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V9CxnC024225 for ; Fri, 31 May 2002 02:13:03 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA12950; Fri, 31 May 2002 13:14:26 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA16977; Fri, 31 May 2002 13:07:27 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA11423; Fri, 31 May 2002 13:11:22 +0400 (MSK) Message-ID: <3CF73F2A.BA1C747E@niisi.msk.ru> Date: Fri, 31 May 2002 13:15:22 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Daniel Jacobowitz , Justin Carlson , linux-mips@oss.sgi.com Subject: Re: Function pointers and #defines References: <1022787167.14210.472.camel@ldt-sj3-022.sj.broadcom.com> <20020530195052.GA10587@branoic.them.org> <023001c2081f$95a397d0$10eca8c0@grendel> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Kevin D. Kissell" wrote: > > From: "Daniel Jacobowitz" > > On Thu, May 30, 2002 at 12:32:47PM -0700, Justin Carlson wrote: > > > A fair number of places in the headers, we have stuff like this: > > > > > > void (*_some_fn)(int arg1, int arg2); > > > #define some_fn(arg1, arg2) _some_fn(arg1, arg2) > > > > > > Why do we do this, as opposed to: > > > > > > void (*some_fn)(int arg1, int arg2); > > > > > > Both syntaxes result in being able to say > > > > > > some_fn(1, 2); > > > > > > but the latter is both clearer and shorter. Is there some deep, > > > mystical C reason that we use the former, or did someone do it that way > > > a long time ago and no one has changed it? > > > > At a guess, this prevents taking the address of the function > > unintentionally... > > More likely, some ancient early version of the code was > written with a single global function, some_fn(), and it > was easier to override it with a pointer indirection in > the header than to hunt down and change all invocations. > Sometimes that's good software engineering. Sometimes > it's just laziness... > > Kevin K. Just remove the declaration, compile, and look at the code generated. So, #define is just a safety belt. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri May 31 02:19:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V9J5nC024330 for ; Fri, 31 May 2002 02:19:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V9J5sG024329 for linux-mips-outgoing; Fri, 31 May 2002 02:19:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V9IwnC024326 for ; Fri, 31 May 2002 02:18:59 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 6A9DF856; Fri, 31 May 2002 11:20:32 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id CA04737100; Fri, 31 May 2002 11:16:06 +0200 (CEST) Date: Fri, 31 May 2002 11:16:06 +0200 From: Florian Lohoff To: James Simmons Cc: Brian Murphy , linux-mips Subject: Re: New platforms Message-ID: <20020531091606.GA29190@paradigm.rfc822.org> References: <20020530094255.GA18436@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 30, 2002 at 03:16:10PM -0700, James Simmons wrote: > > PS: I dont like this split up tree - Currently Ralf is the one=20 > > feeding mainstream so please stop this diversification of the trees > > as the normal user gets completely confused which makes linux mips > > a VERY BAD target and does not help any popularity for the mips targets. > > We had the linux-vr desaster before which helped nothing but in > > the end bound developer efforts which were useless in the end. >=20 > True. The problem is the slow migration to Linus tree and the slow > migration into the OSS tree. Here is a suggestion, how about using the BK > tree at bkbits.net. There is a mips tree there but it has never been used= ..=20 > The question is who is the admin of that tree so we can have access ?=20 Bitkeeper is evil non free software i will hopfully never be required to use. If the migration is to slow help Ralf - Ralf is handing out CVS access to those he trusts developing in the correct direction. I also think that there are ways to split up feeding back the stuff. Generating one another tree wont help a lot. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --XsQoSWH+UP9D9v3l 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 iD8DBQE89z9WUaz2rXW+gJcRApj+AJ9a8qj8QCWjGwPTlx7PNxQ4DFJcjwCg1u6Q aWFE7HdXckyIk2BGr3PqaaM= =x5vU -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- From owner-linux-mips@oss.sgi.com Fri May 31 02:42:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4V9gsnC024716 for ; Fri, 31 May 2002 02:42:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4V9gsKM024715 for linux-mips-outgoing; Fri, 31 May 2002 02:42:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from t111.niisi.ras.ru (t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4V9genC024712; Fri, 31 May 2002 02:42:41 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA13476; Fri, 31 May 2002 13:44:22 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA17165; Fri, 31 May 2002 13:36:31 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA12452; Fri, 31 May 2002 13:39:29 +0400 (MSK) Message-ID: <3CF745B7.16CD0387@niisi.msk.ru> Date: Fri, 31 May 2002 13:43:19 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Jun Sun CC: Alexandr Andreev , linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: 3 questions about linux-2.4.18 and R3000 References: <3CEEBBA9.5070809@niisi.msk.ru> <3CEEAC5F.6010802@mvista.com> <3CF2A17D.6050207@niisi.msk.ru> <3CF3BB4B.504@mvista.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Jun Sun wrote: > >> > >> We have been using gcc 2.9.5 and binutils 2.10.x for R3000 CPUs for > >> quite a while with no problems. It seems newer gcc and binutiles are > >> fine too. > >> > > I understand, but is there any __official__ recommended versions of these > > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :( > > > > Who are the "officiers" to decide on __official__ versions? :-) If you are > really uncomfortable with non-official stuff, you might want to consider > paying some vendor and I am sure you will be given an "official" version. "Official" means "if I report a bug w/o a patch in this list, I don't get a message which requests to change the tools". I think, Ralf is the "officier" who decides what the right toolchain is. Now, last toolchain Ralf announced was - binutils Date: Fri, 1 Dec 2000 03:06:19 +0100 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Binutils were buggy handling a cases involving empty object files. I've uploaded fixed binutils 2.8.1 cross-linker packages to oss.sgi.com; I'll upload fixed binutils 2.9.5 binaries (mips64 only) later. The worarounds for this bug have been removed from the CVS archive that is updating is required for building a current 2.4 kernel. Ralf - compiler Subject: New crosscompilers Date: Wed, 18 Apr 2001 18:42:07 -0300 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr I've uploaded new egcs 1.1.2 based crosscompiler to oss.sgi.com into /pub/linux/mips/crossdev/. The only change for version 1.1.2-4 affects mips64-linux and mips64el-linux targets where asking for alignments larger than 8 bytes was ignored with a warning message. This did possibly result in some performance penalty for mips64 kernels. Ralf The faq does mention this toolchain still. Ralf, are you going to announce new toolchain given the lastest kernel can't be compiled with old one? Or shall we change back the sources? Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri May 31 11:39:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VId0nC011272 for ; Fri, 31 May 2002 11:39:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VId0C3011271 for linux-mips-outgoing; Fri, 31 May 2002 11:39:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VIcwnC011268 for ; Fri, 31 May 2002 11:38:58 -0700 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 g4VIeT6F003045; Fri, 31 May 2002 11:40:29 -0700 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 g4VIeT7C003041; Fri, 31 May 2002 11:40:29 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 11:40:29 -0700 (PDT) From: James Simmons To: linux-mips-kernel@lists.sourceforge.net cc: linux-mips Subject: TX 3912 framebuffer device In-Reply-To: <3CF6A583.2040309@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Can the video mode of this device be switched at run time or is it a static mode. I'm porting it to the new fbdev api and I want to get it right. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ From owner-linux-mips@oss.sgi.com Fri May 31 11:41:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VIf8nC011414 for ; Fri, 31 May 2002 11:41:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VIf8oq011413 for linux-mips-outgoing; Fri, 31 May 2002 11:41:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from potter.sfbay.redhat.com (IDENT:root@potter.sfbay.redhat.com [205.180.83.107]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VIevnC011376 for ; Fri, 31 May 2002 11:40:57 -0700 Received: from localhost.localdomain (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g4VIeHv03645; Fri, 31 May 2002 11:40:19 -0700 Subject: Re: [Fwd: Current state of MIPS16 support?] From: Eric Christopher To: Dominic Sweetman Cc: Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk In-Reply-To: <15566.28397.770794.272735@gladsmuir.algor.co.uk> References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5.99 Date: 31 May 2002 11:40:29 -0700 Message-Id: <1022870431.3668.19.camel@ghostwheel.cygnus.com> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Dominic, > > I have not looked at the Algorithmics code because I don't have > > copyright on it... > > We do publish our sources on our web server. Not only are they GPL > but we have a copyright assignment to the FSF in place (which I know > was sent to Jim Wilson of Cygnus, albeit in 1993...) > It's great that your changes do get out in one form or another. I'm personally uncertain as to the nature of copyright and how it would affect if I looked at your code and put it into the mainline sources - so I haven't :) > We're operating from a baseline which was a Cygnus/RedHat "2.96" > release made to MIPS Technologies in late 2000. A snapshot from a > contract which had run into some kind of dissension, it had some new > MIPS16 support but it was very buggy (the regular 32-bit MIPS code > generator, too). It has some nice features, though, like the "Haifa" > scheduler and the DFA extensions to machine descriptions for > superscalar CPUs. > I don't remember any new mips16 support, however, I do remember that the work was quite old (more than 2 years now). MIPS32 support is quite a bit better now, and with the acceptance of Vlad's DFA scheduler into mainline the scheduling descriptions will be following shortly. > It's true we have not contributed patches lately. We don't really > have the resouces; our success rate used to be very low, and since > we're not working around the developing 3.x sources the prospects seem > even dimmer. > The backend has changed a bit in the time, however, it hasn't changed so much that the patches would be that difficult for you to bring forward. I encourage you to reconsider contributing them. > We're working (with funding from MIPS Technologies) on building a > toolchain which: > > o Can build Linux kernel, libraries and applications alike; > > o Is substantially more efficient than other GCC versions when > producing MIPS application ("MIPS/ABI", PIC) code; > > o Will produce ugly-but-correct PIC code for MIPS16 functions, so > MIPS16 can be tested in a standard Linux environment; > > o Operates to a known and documented ABI (even the forgotten details, > like gprof...) > > (The modesty of those ambitions should be measured against the reality > of today's Linux/MIPS...) I'm not certain what you are actually fixing here as I've not seen any descriptions of problems here. I'd love to fix any problems that you've had reported in the mainline sources so that everyone can get the benefit of the work you are doing. > It would be even more valuable if we could ensure that MIPS becomes a > "first-class" architecture for the evolving GCC - but the latter > surely is a big commitment for the core GCC group. > I'm putting in a lot of effort to cleaning up the MIPS port and am committed to the architecture. > It's a pity that the different priorities of various funders and > developers mean that there is no baseline toolkit for Linux/MIPS, so > that such resources as are available are frequently used to re-invent > the wheel. > > Anyone got any ideas how to make it better? > The problem as I see it is that no one wants/cares to contribute their changes back that they make, or at least file bug reports against the problems that they have. Almost 90% of the bug reports I see are against IRIX. People have to "re-invent the wheel" because the changes never make it back into the official sources - everyone has their own one offs. If we fix this then the work that all of the disparate groups are doing will at least go toward a common goal. -eric -- A fire drill does not demand a fire. From owner-linux-mips@oss.sgi.com Fri May 31 12:16:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VJGWnC011976 for ; Fri, 31 May 2002 12:16:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VJGWHV011975 for linux-mips-outgoing; Fri, 31 May 2002 12:16:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VJGTnC011972 for ; Fri, 31 May 2002 12:16:30 -0700 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 g4VJHg6F005169; Fri, 31 May 2002 12:17:42 -0700 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 g4VJHfmd005165; Fri, 31 May 2002 12:17:41 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 12:17:41 -0700 (PDT) From: James Simmons To: Ilya cc: Florian Lohoff , Brian Murphy , linux-mips Subject: Re: New platforms 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 > > True. The problem is the slow migration to Linus tree and the slow > > migration into the OSS tree. > You can always pos your patches to the list, and whatever didn't make it > into the tree, can be picked up from there by interested parties. Now that I have time I plan to do that. > > Here is a suggestion, how about using the BK > > tree at bkbits.net. There is a mips tree there but it has never been used. > > The question is who is the admin of that tree so we can have access ? > Are you saing "let's make yet another tree"? Ugh... No. I'm talking about having a BK tree to use to sync up to Linus with. This way the OSS and SF tree and push into the BK tree and have no issues. From owner-linux-mips@oss.sgi.com Fri May 31 12:41:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VJfLnC012173 for ; Fri, 31 May 2002 12:41:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VJfLH6012172 for linux-mips-outgoing; Fri, 31 May 2002 12:41:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VJfFnC012168 for ; Fri, 31 May 2002 12:41:15 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA02446; Fri, 31 May 2002 12:41:28 -0700 Message-ID: <3CF7D235.5@mvista.com> Date: Fri, 31 May 2002 12:42:45 -0700 From: Steve Longerbeam Organization: MontaVista Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: James Simmons CC: linux-mips-kernel@lists.sourceforge.net, linux-mips Subject: Re: [Linux-mips-kernel]TX 3912 framebuffer device References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi James, There's also a few fb drivers that Pete and I wrote that exist in the linux-mips tree, and need porting to the new fbdev api. Are you planning to do these also? These are au1100fb.c, epson1356fb.c, and it8181fb.c. Steve James Simmons wrote: >Can the video mode of this device be switched at run time or is it a >static mode. I'm porting it to the new fbdev api and I want to get it >right. > > . --- > |o_o | > |:_/ | Give Micro$oft the Bird!!!! > // \ \ Use Linux!!!! > (| | ) > /'\_ _/`\ > \___)=(___/ > > > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Linux-mips-kernel mailing list >Linux-mips-kernel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/linux-mips-kernel > -- Steve Longerbeam MontaVista Software, Inc. office:408-328-9008, fax:408-328-9204 http://www.mvista.com From owner-linux-mips@oss.sgi.com Fri May 31 12:56:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VJuVnC012557 for ; Fri, 31 May 2002 12:56:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VJuVMx012556 for linux-mips-outgoing; Fri, 31 May 2002 12:56:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VJuTnC012553 for ; Fri, 31 May 2002 12:56:29 -0700 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 g4VJvv6F007430; Fri, 31 May 2002 12:57:57 -0700 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 g4VJvupW007425; Fri, 31 May 2002 12:57:56 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 12:57:56 -0700 (PDT) From: James Simmons To: Steve Longerbeam cc: linux-mips-kernel@lists.sourceforge.net, linux-mips Subject: Re: [Linux-mips-kernel]TX 3912 framebuffer device In-Reply-To: <3CF7D235.5@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > Hi James, > > There's also a few fb drivers that Pete and I wrote that exist in > the linux-mips tree, and need porting to the new fbdev api. Are you > planning to do these also? These are au1100fb.c, epson1356fb.c, and > it8181fb.c. Yes!!! With some help of course. From owner-linux-mips@oss.sgi.com Fri May 31 13:18:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VKITnC013125 for ; Fri, 31 May 2002 13:18:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VKITZ7013124 for linux-mips-outgoing; Fri, 31 May 2002 13:18:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VKIPnC013120 for ; Fri, 31 May 2002 13:18:25 -0700 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 g4VKJf6F008603; Fri, 31 May 2002 13:19:41 -0700 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 g4VKJddY008599; Fri, 31 May 2002 13:19:39 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 13:19:39 -0700 (PDT) From: James Simmons To: "Kevin D. Kissell" cc: Jun Sun , Geert Uytterhoeven , "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? In-Reply-To: <01da01c2066f$3ed63f40$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > Dan Malek also wrote a driver for MQ200. > > Which is essentially a handheld/webphone graphics chip, > for which the documentation is only available under NDA. > Not terribly useful for me, thanks. I have docs on this chipset. I forgot where I got them. I plan to work on a driver for that chipset since I have a board with it on it. From owner-linux-mips@oss.sgi.com Fri May 31 13:23:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VKNLnC013411 for ; Fri, 31 May 2002 13:23:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VKNL0V013410 for linux-mips-outgoing; Fri, 31 May 2002 13:23:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VKNJnC013407 for ; Fri, 31 May 2002 13:23:19 -0700 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 g4VKOD6F008837; Fri, 31 May 2002 13:24:13 -0700 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 g4VKO9FO008833; Fri, 31 May 2002 13:24:09 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 13:24:08 -0700 (PDT) From: James Simmons To: Geert Uytterhoeven cc: Alan Cox , Dan Malek , "Kevin D. Kissell" , Jun Sun , "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? 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 guess that's why we still don't have working frame buffer devices for them? > There are at least 3 frame buffer devices for the Trio floating around the net, > but none of them work on my cards. > I have started a operation to find all the MIA framebuffer drivers that have been posted. I really like to track those S3 drivers down. From owner-linux-mips@oss.sgi.com Fri May 31 13:24:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VKOfnC013492 for ; Fri, 31 May 2002 13:24:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VKOfgq013491 for linux-mips-outgoing; Fri, 31 May 2002 13:24:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VKOdnC013488 for ; Fri, 31 May 2002 13:24:39 -0700 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 g4VKPu6F009001; Fri, 31 May 2002 13:25:56 -0700 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 g4VKPtlQ008997; Fri, 31 May 2002 13:25:55 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 31 May 2002 13:25:55 -0700 (PDT) From: James Simmons To: Alan Cox cc: Geert Uytterhoeven , Dan Malek , "Kevin D. Kissell" , Jun Sun , "Steven J. Hill" , Linux/MIPS Development Subject: Re: PCI Graphics/Video Card for Malta Board? In-Reply-To: <1022676598.4124.165.camel@irongate.swansea.linux.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > I've had no problem with Russell King's ARM code. The problem with older S3 cards is that they have so many different RAMDACS and often 3rd party PLLs. > And for the 3dfx > voodoo2 (UKP 9 off ebay) none at all. The voodoo seems to have always > been designed to be totally soft configured and as its not a primary > video card the bios/firmware all leaves it alone Yeap!! I was reading in the docs how to get voodoo cards to be multihead freindly :-) From owner-linux-mips@oss.sgi.com Fri May 31 14:42:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VLgdnC014642 for ; Fri, 31 May 2002 14:42:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VLgdS1014640 for linux-mips-outgoing; Fri, 31 May 2002 14:42:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from kiruna.synopsys.com (kiruna.synopsys.com [204.176.20.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VLganC014615 for ; Fri, 31 May 2002 14:42:36 -0700 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by kiruna.synopsys.com (Postfix) with ESMTP id 5301AF6A3; Fri, 31 May 2002 14:44:08 -0700 (PDT) Received: from atrus.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id OAA24854; Fri, 31 May 2002 14:44:27 -0700 (PDT) From: Joe Buck Received: (from jbuck@localhost) by atrus.synopsys.com (8.9.3+Sun/8.9.1) id OAA15256; Fri, 31 May 2002 14:44:04 -0700 (PDT) Message-Id: <200205312144.OAA15256@atrus.synopsys.com> Subject: Re: [Fwd: Current state of MIPS16 support?] To: echristo@redhat.com (Eric Christopher) Date: Fri, 31 May 2002 14:44:04 -0700 (PDT) Cc: dom@algor.co.uk (Dominic Sweetman), js@convergence.de (Johannes Stezenbach), gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk In-Reply-To: <1022870431.3668.19.camel@ghostwheel.cygnus.com> from "Eric Christopher" at May 31, 2002 11:40:29 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk > > > I have not looked at the Algorithmics code because I don't have > > > copyright on it... Dominic wrote: > > We do publish our sources on our web server. Not only are they GPL > > but we have a copyright assignment to the FSF in place (which I know > > was sent to Jim Wilson of Cygnus, albeit in 1993...) Eric Christopher wrote: > It's great that your changes do get out in one form or another. I'm > personally uncertain as to the nature of copyright and how it would > affect if I looked at your code and put it into the mainline sources - > so I haven't :) Whose name and what company name would be on the copyright assignment? We can check with the FSF list to see if it's on file. Meanwhile it should not go in. From owner-linux-mips@oss.sgi.com Fri May 31 15:21:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VMLsnC025909 for ; Fri, 31 May 2002 15:21:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VMLsuk025908 for linux-mips-outgoing; Fri, 31 May 2002 15:21:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from broadon.com (gw2.routefree.net [209.21.47.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VMLnnC025881 for ; Fri, 31 May 2002 15:21:49 -0700 Received: from osprey.routefree.com ([10.0.0.30] helo=broadon.com) by broadon.com with esmtp (BroadOn) id 17DunC-0002Nf-00; Fri, 31 May 2002 22:22:42 +0000 Message-ID: <3CF7F7B1.50300@broadon.com> Date: Fri, 31 May 2002 15:22:41 -0700 From: Raymond Lo Organization: BroadOn Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: virtual coherency issues with 4Kc ? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I'm evaluting the MIPS 4Kc core. One thing I'm trying to find out is how does linux deal with virtual aliasing in the cache for 4Kc. The cache of 4Kc is virtually-indexed and it has no hardware support to suppress virtual aliasing. The cachetlb.txt under linux/Documentation indicates that two things need to be done in software to handle virtual aliasing in D-cache. The first is to handle virtual aliasing in user address spaces. Shared pages are mmaped at virtual addresses that are multiples of the cache size. That has already been taked care of in include/asm-mips/shmparam.h. The second is to handle virtual aliasing between kernel virtual address space and user virtual address space by providing a number of functions to flush the cache at various points in the kernel. The old interface is flush_page_to_ram. The new ones are copy_user_page, clear_user_page, flush_dcache_page. I'm surprised to find out that flush_dcache_page is a macro defined to be do {} while (0) in linux/asm-mips/pgtable.h. The source code I looked is the web CVS on oss.sgi.com and 2.4.18. Apparently the necessary flushing hasn't been done from the mm and fs code for any MIPS port. I know this is not necessary for R4000 with virtual coherency execptions. I don't understand why it can be skipped for 4Kc. Can anybody shine some light on the subject? -Raymond P.S. The link http://oss.sgi.com/mips/archive/ is stale. From owner-linux-mips@oss.sgi.com Fri May 31 16:59:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g4VNxpnC003799 for ; Fri, 31 May 2002 16:59:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g4VNxpQC003798 for linux-mips-outgoing; Fri, 31 May 2002 16:59:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx2.mips.com (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g4VNxhnC003793 for ; Fri, 31 May 2002 16:59:44 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.9.3/8.9.0) with ESMTP id RAA24616; Fri, 31 May 2002 17:01:12 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id RAA20950; Fri, 31 May 2002 17:01:13 -0700 (PDT) Message-ID: <004101c20900$5a1f35c0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Raymond Lo" , References: <3CF7F7B1.50300@broadon.com> Subject: Re: virtual coherency issues with 4Kc ? Date: Sat, 1 Jun 2002 02:07:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Note that the cache organization of the 4Kc is configurable. Virtual aliasing problems should only be possible if the cache "way" size exceeds the page size used (4KB for Linux). A maxed-out 4Kc can create a virtual coherency problem, but a 4Kc with e.g. 4-way set associative 16KB caches should be exempt. Since the cache configuration of a 4Kc can be determined at boot time by the kernel, by reading the config registers, those annoying cache flushes should only really happen if the cache configuration is "at risk". Kevin K. ----- Original Message ----- From: "Raymond Lo" To: Sent: Saturday, June 01, 2002 12:22 AM Subject: virtual coherency issues with 4Kc ? > I'm evaluting the MIPS 4Kc core. One thing I'm trying to find out is > how does linux deal with virtual aliasing in the cache for 4Kc. > > The cache of 4Kc is virtually-indexed and it has no hardware support to > suppress virtual aliasing. The cachetlb.txt under linux/Documentation > indicates that two things need to be done in software to handle virtual > aliasing in D-cache. > > The first is to handle virtual aliasing in user address spaces. Shared > pages are mmaped at virtual addresses that are multiples of the cache > size. That has already been taked care of in include/asm-mips/shmparam.h. > > The second is to handle virtual aliasing between kernel virtual address > space and user virtual address space by providing a number of functions > to flush the cache at various points in the kernel. The old interface > is flush_page_to_ram. The new ones are > copy_user_page, > clear_user_page, > flush_dcache_page. > > I'm surprised to find out that flush_dcache_page is a macro defined to > be do {} while (0) in linux/asm-mips/pgtable.h. The source code I > looked is the web CVS on oss.sgi.com and 2.4.18. > > Apparently the necessary flushing hasn't been done from the mm and fs > code for any MIPS port. I know this is not necessary for R4000 with > virtual coherency execptions. I don't understand why it can be > skipped for 4Kc. Can anybody shine some light on the subject? > > -Raymond > > > P.S. The link http://oss.sgi.com/mips/archive/ is stale. > > > >