From ralf@linux-mips.net Thu Nov 1 02:10:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id CAA00699; Thu, 1 Nov 2001 02:10:38 +0100 (MET) Received-Date: Thu, 1 Nov 2001 02:10:38 +0100 (MET) Received: from a1as05-p109.stg.tli.de(195.252.187.109), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd000697; Thu Nov 1 02:10:33 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fA116WH05633; Thu, 1 Nov 2001 02:06:32 +0100 Date: Thu, 1 Nov 2001 02:06:32 +0100 From: Ralf Baechle To: Green Cc: LinuxEmbeddedMailList , LinuxKernelMailList , MipsMailList , linux-mips@oss.sgi.com Subject: Re: Discontinuous memory!! Message-ID: <20011101020632.A5076@dea.linux-mips.net> References: <00c701c1612b$4c133620$4c0c5c8c@trd.iii.org.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c701c1612b$4c133620$4c0c5c8c@trd.iii.org.tw>; from greeen@iii.org.tw on Tue, Oct 30, 2001 at 06:11:43PM +0800 X-Accept-Language: de,en,fr Content-Length: 1180 Lines: 34 On Tue, Oct 30, 2001 at 06:11:43PM +0800, Green wrote: > I am porting Linux to R3912. > > There are two memory block on my target board. > > One is 16MB from 0x8000 0000 to 0x8100 0000. > > The other one is 16MB from 0x8200 0000 to 0x8300 0000. > > But I found kernel just managed the first memory block. > > How could I modify the kernel to support 32MB discontinuous memory? > > Now I am trying to add entries to page table. > It will halt at decompressing ramdisk. > > Has anyone resolve this kind of problem before? The kernel support this type of memory architecture if you enable CONFIG_DISCONTIGMEM. One machine which uses this feature is the Origin, grep in arch/mips64 for CONFIG_DISCONTIGMEM. There are also several ARM system using it. As support for CONFIG_DISCONTIGMEM is less than perfect you should check if your system allows for reconfiguration of memory as a single physically contiguous chunk. Don't use add_memory_region() in this case; that code only works well for small holes in memory address space. Your holes are fairly large so memory management would waste about 2mb if you would not use CONFIG_DISCONTIGMEM. Ralf From greeen@iii.org.tw Mon Nov 5 04:46:15 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id EAA08233; Mon, 5 Nov 2001 04:46:15 +0100 (MET) Received-Date: Mon, 5 Nov 2001 04:46:15 +0100 (MET) Received: from h116-210-243-147.iii.org.tw(210.243.147.116), claiming to be "mta1.iii.org.tw" via SMTP by guadalquivir.fnet.fr, id smtpd008231; Mon Nov 5 04:46:06 2001 Received: from [140.92.12.76] (helo=Green) by mta1.iii.org.tw with smtp (Exim 3.33 #1) id 160acr-0002Zy-00; Mon, 05 Nov 2001 11:40:42 +0800 Message-ID: <008701c165ac$1a49a9a0$4c0c5c8c@trd.iii.org.tw> From: "Green" To: "Linux-mips" , "MipsMailList" Subject: do_ri( ) Date: Mon, 5 Nov 2001 11:43:54 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01C165EF.25598F20" 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 Content-Length: 2492 Lines: 69 This is a multi-part message in MIME format. ------=_NextPart_000_0084_01C165EF.25598F20 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear all, I often get into trouble executing multithread application. Sometimes it will appear the message " Illegal instruction =3D = 0xXXXX " in=20 do_ri() function in /arch/mips/kernel/traps.c. It happened randomly. =20 Up to now, I still didn't know how to fix bug. If any one know how to fix it, please reply me. Appreciate in sincerely. P.S My mips bos is R3912. =20 ~~ Green ------=_NextPart_000_0084_01C165EF.25598F20 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Dear all,
 
    I often get = into trouble executing=20 multithread application.
    Sometimes it = will appear the message=20 " Illegal instruction =3D 0xXXXX " in
    do_ri() = function in=20 /arch/mips/kernel/traps.c.
    It happened = randomly.
    =
    Up to now, I = still didn't know how to=20 fix bug.
    If any one = know how to fix it, please=20 reply me.
    Appreciate = in sincerely.
 
    P.S  My = mips bos is=20 R3912.   
 
~~
Green  <greeen@iii.org.tw>
<= /BODY> ------=_NextPart_000_0084_01C165EF.25598F20-- From brad@ltc.com Mon Nov 5 05:33:05 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA10717; Mon, 5 Nov 2001 05:33:05 +0100 (MET) Received-Date: Mon, 5 Nov 2001 05:33:05 +0100 (MET) Received: from ns1.ltc.com(38.149.17.165) via SMTP by guadalquivir.fnet.fr, id smtpd010715; Mon Nov 5 05:32:57 2001 Received: from prefect (gw1.ltc.com [38.149.17.163]) by ns1.ltc.com (Postfix) with SMTP id F30EF590A9; Sun, 4 Nov 2001 19:28:45 -0500 (EST) Message-ID: <07b401c165b2$f981ec30$3501010a@ltc.com> From: "Bradley D. LaRonde" To: "Green" , "Linux-mips" , "MipsMailList" References: <008701c165ac$1a49a9a0$4c0c5c8c@trd.iii.org.tw> Subject: Re: do_ri( ) Date: Sun, 4 Nov 2001 23:33:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Length: 697 Lines: 27 I've seen the same thing but on a different processor (VR5432). gcc 3.0.1, glibc 2.2.3. I suspect stack/register corruption. Regards, Brad ----- Original Message ----- From: Green To: Linux-mips ; MipsMailList Sent: Sunday, November 04, 2001 10:43 PM Subject: do_ri( ) Dear all, I often get into trouble executing multithread application. Sometimes it will appear the message " Illegal instruction = 0xXXXX " in do_ri() function in /arch/mips/kernel/traps.c. It happened randomly. Up to now, I still didn't know how to fix bug. If any one know how to fix it, please reply me. Appreciate in sincerely. P.S My mips bos is R3912. ~~ Green greeen@iii.org.tw From airlied@csn.ul.ie Tue Nov 6 23:49:01 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id XAA28367; Tue, 6 Nov 2001 23:49:01 +0100 (MET) Received-Date: Tue, 6 Nov 2001 23:49:01 +0100 (MET) Received: from holly.csn.ul.ie(136.201.105.4) via SMTP by guadalquivir.fnet.fr, id smtpd028365; Tue Nov 6 23:48:58 2001 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 51B482B331; Tue, 6 Nov 2001 22:48:55 +0000 (GMT) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 695B8C8CA; Tue, 6 Nov 2001 22:48:54 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 57150E8C3; Tue, 6 Nov 2001 22:48:54 +0000 (GMT) Date: Tue, 6 Nov 2001 22:48:54 +0000 (GMT) From: Dave Airlie X-X-Sender: To: Cc: , Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 558 Lines: 21 > Since I'll be away till Tuesday, expect an update in the middle of the > next week. I'm assuming ELF loading works, right? > not sure the VAX is handling this too well.. if I boot the vmlinux ELF file our build system produces it won't boot it but I think this is due to our vmlinux file being linked for running with VM switched on, and the mop loads it into memory that doesn't exist.. Dave. > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From warren@palmchip.com Thu Nov 8 00:50:22 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id AAA06666; Thu, 8 Nov 2001 00:50:22 +0100 (MET) Received-Date: Thu, 8 Nov 2001 00:50:22 +0100 (MET) Received: from UNKNOWN(63.203.52.2), claiming to be "mail.palmchip.com" via SMTP by guadalquivir.fnet.fr, id smtpd006644; Thu Nov 8 00:50:12 2001 Received: from palmchip.com (scarlett.palmchip.com [10.1.10.90]) by mail.palmchip.com (8.11.6/8.11.0) with ESMTP id fA7Mo5r13483; Wed, 7 Nov 2001 14:50:05 -0800 Message-ID: <3BE9D6E6.2010706@palmchip.com> Date: Wed, 07 Nov 2001 16:50:46 -0800 From: Waren Hardy Reply-To: warren.hardy@palmchip.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Linux-mips , MipsMailList Subject: memory mapping for MIPS 4Kc References: <008701c165ac$1a49a9a0$4c0c5c8c@trd.iii.org.tw> <07b401c165b2$f981ec30$3501010a@ltc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 789 Lines: 26 I have a small prototype board with a mips 4kc on it and I have linux running. I have to megs of sram mapped how do i map in sdram ? the memory map looks like 0000.0000 - 0001f.ffff 2M SRAM 0020.0000 - 0020.1fff 8K Embedded SRAM CPU 0020.2000 - 002f.fffff reserved 0030.0000 - 0030.ffff 64K Chip registers 0031.0000 - 00ff.ffff reserved 0100.0000 - 01ff.ffff 16M SDRAM 0200.0000 - 1fb0.ffff SDRAM 1fc0.0000 - 1fdf.ffff 2M ROM / FLASH 0060.0000 - ffff.ffff SDRAM how do I get linux to read this 16M SDRAM @ 0100.000 - 01ff.ffff ? Then how do I get linux to read RAM @ 0200.000 - 1fb0.ffff and 0060.000 - ffff.ffff ? We have our own load which is loading linux from ROM, and we can pass arg to linux, can the memory be set as an argument passed ? Thanks for you help Warren Hardy From macro@ds2.pg.gda.pl Thu Nov 8 13:50:07 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA13890; Thu, 8 Nov 2001 13:50:07 +0100 (MET) Received-Date: Thu, 8 Nov 2001 13:50:07 +0100 (MET) Received: from delta.ds.pg.gda.pl(213.192.72.1), claiming to be "delta.ds2.pg.gda.pl" via SMTP by guadalquivir.fnet.fr, id smtpd013868; Thu Nov 8 13:49:52 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA07628; Thu, 8 Nov 2001 13:48:01 +0100 (MET) Date: Thu, 8 Nov 2001 13:48:00 +0100 (MET) From: "Maciej W. Rozycki" To: Dave Airlie cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, linux-vax@mithra.physics.montana.edu Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 705 Lines: 21 On Tue, 30 Oct 2001, Dave Airlie wrote: > Okay it didn't go so well.. my VAX couldn't boot the file I normally use > with this mopd (I had to rebuild it for a static libelf)... > > I've put a tgz up at > > http://www.skynet.ie/~airlied/vax/mopd_on_the_vax.tgz > > it contains the file I was trying to boot and the tcpdumps of this mopd > and the one I normally use ... I've uploaded updated files -- you should be able to boot your image with this version of mopd. Please report results. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Nov 8 14:10:37 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA15887; Thu, 8 Nov 2001 14:10:37 +0100 (MET) Received-Date: Thu, 8 Nov 2001 14:10:37 +0100 (MET) Received: from delta.ds.pg.gda.pl(213.192.72.1), claiming to be "delta.ds2.pg.gda.pl" via SMTP by guadalquivir.fnet.fr, id smtpd015864; Thu Nov 8 14:10:18 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA08062; Thu, 8 Nov 2001 14:06:06 +0100 (MET) Date: Thu, 8 Nov 2001 14:06:05 +0100 (MET) From: "Maciej W. Rozycki" To: Dave Airlie cc: linux-vax@mithra.physics.montana.edu, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [LV] FYI: Mopd ELF support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1157 Lines: 25 On Tue, 6 Nov 2001, Dave Airlie wrote: > > Since I'll be away till Tuesday, expect an update in the middle of the > > next week. I'm assuming ELF loading works, right? > > > not sure the VAX is handling this too well.. > > if I boot the vmlinux ELF file our build system produces it won't boot it > but I think this is due to our vmlinux file being linked for running with > VM switched on, and the mop loads it into memory that doesn't exist.. Do you set segments' p_paddr (physical address) correctly? The current version of ELF support uses p_vaddr (virtual address) for simplicity, as the ELF specification mandates loadable program's segments to be ordered by an ascending value of their p_vaddr. I'll fix the program to use p_paddr instead. The difference is insignificant for the DECstation since its firmware uses virtual addresses -- MIPS never exposes physical addresses to a program (well, almost, but that's irrelevant here). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From khs@digital-digital.com Mon Nov 12 09:11:57 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id JAA21479; Mon, 12 Nov 2001 09:11:57 +0100 (MET) Received-Date: Mon, 12 Nov 2001 09:11:57 +0100 (MET) Received: from UNKNOWN(210.122.73.240), claiming to be "wine.digital-digital.com" via SMTP by guadalquivir.fnet.fr, id smtpd021477; Mon Nov 12 09:11:53 2001 Received: from khs ([210.122.73.37]) by wine.digital-digital.com (8.11.0/8.11.0) with SMTP id fAC8BhQ29820; Mon, 12 Nov 2001 17:11:45 +0900 Reply-To: From: "Han-Seong Kim" To: , Subject: Power MGMT on mips Date: Mon, 12 Nov 2001 17:13:40 +0900 Message-ID: <000001c16b51$f05f6070$cbadfea9@khs> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 280 Lines: 4 SGksIA0KDQpJIHdhbnQgdG8gYXNrIGFib3V0IFBvd2VyLU1uYWdlbWVudCBvbiBtaXBzLg0KMS4g SXMgaXQgcG9zc2libGUgdG8gdXNlIHBvd2VyIG1nbnQgKGV4LiBhcG0sYWNwaSkgZmVhdHVyZXMg b2YgbGludXgga2VybmVsPw0KMi5JZiBubywgaG93IGNhbiBtYW5hZ2UgQ1BVIGFuZCBCaWRnZSBj aGlwcyBmb3IgcG93ZXIgbWdudCA/DQoNCkhhbi1TZW9uZw== From ralf@linux-mips.net Mon Nov 12 13:31:45 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA23671; Mon, 12 Nov 2001 13:31:45 +0100 (MET) Received-Date: Mon, 12 Nov 2001 13:31:45 +0100 (MET) Received: from oss.sgi.com(216.32.174.27) via SMTP by guadalquivir.fnet.fr, id smtpd023669; Mon Nov 12 13:31:44 2001 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fACCVd018798 for ; Mon, 12 Nov 2001 04:31:39 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fACCUV409976; Mon, 12 Nov 2001 23:30:31 +1100 Date: Mon, 12 Nov 2001 23:30:31 +1100 From: Ralf Baechle To: Han-Seong Kim Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Power MGMT on mips Message-ID: <20011112233031.A6493@dea.linux-mips.net> References: <000001c16b51$f05f6070$cbadfea9@khs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c16b51$f05f6070$cbadfea9@khs>; from khs@digital-digital.com on Mon, Nov 12, 2001 at 05:13:40PM +0900 X-Accept-Language: de,en,fr Content-Length: 402 Lines: 13 On Mon, Nov 12, 2001 at 05:13:40PM +0900, Han-Seong Kim wrote: > I want to ask about Power-Mnagement on mips. > 1. Is it possible to use power mgnt (ex. apm,acpi) features of linux kernel? Both are PC stuff, so no. > 2.If no, how can manage CPU and Bidge chips for power mgnt ? Right now Linux/MIPS will only use the CPU's power managment features, that is the wait instruction or similar. Ralf From ralf@linux-mips.net Mon Nov 19 10:06:05 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA05139; Mon, 19 Nov 2001 10:06:05 +0100 (MET) Received-Date: Mon, 19 Nov 2001 10:06:05 +0100 (MET) Received: from oss.sgi.com(216.32.174.27) via SMTP by guadalquivir.fnet.fr, id smtpd005136; Mon Nov 19 10:05:53 2001 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAJA5kW14179 for ; Mon, 19 Nov 2001 02:05:47 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAJ95Ff27568; Mon, 19 Nov 2001 20:05:15 +1100 Date: Mon, 19 Nov 2001 20:05:15 +1100 From: Ralf Baechle To: renc stone Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ld error " linking PIC files with non-PIC files " Message-ID: <20011119200514.A26473@dea.linux-mips.net> References: <20011026161259.54925.qmail@web11908.mail.yahoo.com> <20011113200948.75977.qmail@web11908.mail.yahoo.com> <20011114111834.B10410@dea.linux-mips.net> <000a01c170d0$e8662000$101d690a@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000a01c170d0$e8662000$101d690a@huawei.com>; from renwei@huawei.com on Mon, Nov 19, 2001 at 04:05:09PM +0800 X-Accept-Language: de,en,fr Content-Length: 691 Lines: 19 On Mon, Nov 19, 2001 at 04:05:09PM +0800, renc stone wrote: > That's the same problem as mine. > I try to use 64bit long long div& mod in one module, > and find I miss some _divdi3 and something like that. > > when I try to link my module with libgcc.a, in my mipsel-glibc 2.95.3, > the ld report the same thing. > > Does it mean I can't use 64bit div in module? How to get rid of this error? Again, it's a grave mistake to mix pic and non-pic libraries. To solve this you must either supply your own non-pic versions of the routines in question or - and better - try to avoid them. In your case take a look at which supplies a 64-bit by 32-bit division routine. Ralf From khs@digital-digital.com Mon Nov 19 13:31:24 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA07171; Mon, 19 Nov 2001 13:31:24 +0100 (MET) Received-Date: Mon, 19 Nov 2001 13:31:24 +0100 (MET) Received: from UNKNOWN(210.122.73.240), claiming to be "wine.digital-digital.com" via SMTP by guadalquivir.fnet.fr, id smtpd007169; Mon Nov 19 13:31:18 2001 Received: from khs ([210.122.73.37]) by wine.digital-digital.com (8.11.0/8.11.0) with SMTP id fAJCB9Q16460; Mon, 19 Nov 2001 21:11:09 +0900 Reply-To: From: "Han-Seong Kim" To: "'Ralf Baechle'" Cc: , Subject: RE: Power MGMT on mips Date: Mon, 19 Nov 2001 21:13:08 +0900 Message-ID: <000001c170f3$8d784d80$cbadfea9@khs> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20011112233031.A6493@dea.linux-mips.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 1151 Lines: 15 SGkgUmFsZiwNCg0KSSByZXZpZXdlZCB0aGUgZGF0YSBzaGVldCBvZiBNaXBzIENQVSAtIFFFRCBS TTUyMzEuDQpUaGVyZSBpcyBhIHdhaXQgaW5zdHJ1Y3Rpb24uDQpCdXQgd2hlbiB0aGUgU3lzQUQg YnVzIGdvZXMgdG8gaWRsZSwgdGhlIHdhaXQgaW5zdHJ1Y3Rpb24gaXMgdmFsaWQuDQpIb3cgY2Fu IEkgU3lzQUQgYnVzIG1ha2UgaWRsZSBzdGF0ZT8NCg0KSGFuLVNlb25nDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWxmIEJhZWNobGUgW21haWx0bzpyYWxmQG9zcy5zZ2ku Y29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMiwgMjAwMSA5OjMxIFBNDQpUbzogSGFuLVNl b25nIEtpbQ0KQ2M6IGxpbnV4LW1pcHNAZm5ldC5mcjsgbGludXgtbWlwc0Bvc3Muc2dpLmNvbQ0K U3ViamVjdDogUmU6IFBvd2VyIE1HTVQgb24gbWlwcw0KDQoNCk9uIE1vbiwgTm92IDEyLCAyMDAx IGF0IDA1OjEzOjQwUE0gKzA5MDAsIEhhbi1TZW9uZyBLaW0gd3JvdGU6DQoNCj4gSSB3YW50IHRv IGFzayBhYm91dCBQb3dlci1NbmFnZW1lbnQgb24gbWlwcy4NCj4gMS4gSXMgaXQgcG9zc2libGUg dG8gdXNlIHBvd2VyIG1nbnQgKGV4LiBhcG0sYWNwaSkgZmVhdHVyZXMgb2YgbGludXgga2VybmVs Pw0KDQpCb3RoIGFyZSBQQyBzdHVmZiwgc28gbm8uDQoNCj4gMi5JZiBubywgaG93IGNhbiBtYW5h Z2UgQ1BVIGFuZCBCaWRnZSBjaGlwcyBmb3IgcG93ZXIgbWdudCA/DQoNClJpZ2h0IG5vdyBMaW51 eC9NSVBTIHdpbGwgb25seSB1c2UgdGhlIENQVSdzIHBvd2VyIG1hbmFnbWVudCBmZWF0dXJlcywg dGhhdA0KaXMgdGhlIHdhaXQgaW5zdHJ1Y3Rpb24gb3Igc2ltaWxhci4NCg0KICBSYWxmDQo= From macro@ds2.pg.gda.pl Fri Nov 23 19:56:02 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA25251; Fri, 23 Nov 2001 19:56:02 +0100 (MET) Received-Date: Fri, 23 Nov 2001 19:56:02 +0100 (MET) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd025189; Fri Nov 23 19:55:01 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA17000; Fri, 23 Nov 2001 19:46:44 +0100 (MET) Date: Fri, 23 Nov 2001 19:46:42 +0100 (MET) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: R3k DECstation FPU support Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 17638 Lines: 589 Hello, Here is an implementation of an FPU interrupt handler for R3k DECstations (R4k ones are fine with the dedicated exception). At first I thought only interrupt to do_fpe() glue is missing but to my surprise I discovered no R3k-class CPU is currently assumed to feature an FPU. As making use of an FPU is usually advantageous if one exists, I implemented an FPU detection function following guidelines given by my MIPS manual (I can't test an FPU-less system). I believe the code is stable as is. It does not provide any additional functionality beyond what is currently available to systems using the dedicated FPU exception. To verify an FPU is detected properly (the kernel does not report it in any way now) and FPU exceptions are delivered successfully the following program can be used. fdiv.c: #include #include #include int main(void) { double x, y, z; int r; fpu_control_t fpcw; unsigned int fpir; setvbuf(stdout, NULL, _IONBF, 0); _FPU_GETCW(fpcw); fpcw &= _FPU_RESERVED; fpcw |= _FPU_IEEE; _FPU_SETCW(fpcw); __asm__("cfc1 %0, $0" : "=r" (fpir) : : "memory"); _FPU_GETCW(fpcw); printf("FPCW: %08x\n", fpcw); printf("FPIR: %08x\n", fpir); __asm__(".set push\n\t" ".set reorder\n\t" "mtc1 %z4, %1\n\t" "mtc1 %z5, %2\n\t" "cvt.d.w %1, %1\n\t" "cvt.d.w %2, %2\n\t" ".set noreorder\n\t" "b 0f\n\t" " div.d %3, %1, %2\n\t" ".set reorder\n\t" "nop\n" "0:\n\t" "cvt.w.d %3, %3\n\t" "mfc1 %0, %3\n\t" ".set pop" : "=r" (r), "=f" (x), "=f" (y), "=f" (z) : "Jr" (0), "Jr" (0)); return r; } You should receive an output similar to one of the following ones: FPCW: 00000f80 FPIR: 00000340 Floating point exception for an R3k-class FPU, FPCW: 00000f80 FPIR: 00000500 Floating point exception for an R4k-class FPU, FPCW: 00000f80 FPIR: 00000000 Floating point exception for the FPU emulation (the Implementation and Revision register is zero). If you don't get an exception then there is a problem with FPU interrupt delivery -- please report it to me, especially if it happens for a DECstation. The patch includes a few minor clean-ups of nearby code as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-dec-fpu-9 diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/dec/int-handler.S linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/int-handler.S --- linux-mips-2.4.14-20011123-dist/arch/mips/dec/int-handler.S Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/int-handler.S Fri Nov 23 16:35:53 2001 @@ -2,7 +2,7 @@ * arch/mips/dec/int-handler.S * * Copyright (C) 1995, 1996, 1997 Paul M. Antoine and Harald Koerfgen - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki * * Written by Ralf Baechle and Andreas Busse, modified for DECStation * support by Paul Antoine and Harald Koerfgen. @@ -145,6 +145,9 @@ beqz t0,spurious + andi t2,t0,DEC_IE_FPU + bnez t2,fpu # handle FPU immediately + /* * Find irq with highest priority */ @@ -169,7 +172,7 @@ * Handle "IRQ Controller" Interrupts * Masked Interrupts are still visible and have to be masked "by hand". */ - EXPORT(kn02_io_int) + FEXPORT(kn02_io_int) kn02_io_int: # 3max lui t0,KN02_CSR_ADDR>>16 # get interrupt status and mask lw t0,(t0) @@ -179,7 +182,7 @@ kn02_io_int: # 3max b find_int and t0,t3 # mask out allowed ones - EXPORT(kn03_io_int) + FEXPORT(kn03_io_int) kn03_io_int: # 3max+ lui t2,KN03_IOASIC_BASE>>16 # upper part of IOASIC Address lw t0,SIR(t2) # get status: IOASIC isr @@ -188,7 +191,7 @@ kn03_io_int: # 3max+ b find_int and t0,t3 # mask out allowed ones - EXPORT(kn02xa_io_int) + FEXPORT(kn02xa_io_int) kn02xa_io_int: # 3min/maxine lui t2,KN02XA_IOASIC_BASE>>16 # upper part of IOASIC Address @@ -219,28 +222,27 @@ handle_it: jal do_IRQ j ret_from_irq nop +fpu: + j handle_fpe_int + nop + spurious: j spurious_interrupt nop END(decstation_handle_int) -/* - * Interrupt routines common to all DECStations first. - */ - EXPORT(dec_intr_fpu) -dec_intr_fpu: PANIC("Unimplemented FPU interrupt handler") /* * Generic unimplemented interrupt routines - ivec_tbl is initialised to * point all interrupts here. The table is then filled in by machine-specific * initialisation in dec_setup(). */ - EXPORT(dec_intr_unimplemented) + FEXPORT(dec_intr_unimplemented) dec_intr_unimplemented: mfc0 a1,CP0_CAUSE # cheats way of printing an arg! nop # to be sure... PANIC("Unimplemented cpu interrupt! CP0_CAUSE: 0x%x"); - EXPORT(asic_intr_unimplemented) + FEXPORT(asic_intr_unimplemented) asic_intr_unimplemented: move a1,t0 # cheats way of printing an arg! PANIC("Unimplemented asic interrupt! ASIC ISR: 0x%x"); diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/dec/setup.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/setup.c --- linux-mips-2.4.14-20011123-dist/arch/mips/dec/setup.c Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/dec/setup.c Thu Nov 22 00:20:46 2001 @@ -6,7 +6,7 @@ * for more details. * * Copyright (C) 1998 Harald Koerfgen - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki */ #include #include @@ -55,7 +55,7 @@ extern int setup_dec_irq(int, struct irq void (*board_time_init) (struct irqaction * irq); -static struct irqaction irq10 = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; +static struct irqaction haltirq = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; /* * enable the periodic interrupts @@ -139,10 +139,10 @@ void __init dec_init_kn01(void) cpu_mask_tbl[4] = IE_IRQ4; cpu_irq_nr[4] = MEMORY; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU. + */ + set_cp0_status(DEC_IE_FPU); } /* dec_init_kn01 */ /* @@ -165,10 +165,10 @@ void __init dec_init_kn230(void) cpu_mask_tbl[0] = IE_IRQ2; cpu_irq_nr[0] = CLOCK; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU. + */ + set_cp0_status(DEC_IE_FPU); } /* dec_init_kn230 */ /* @@ -176,6 +176,8 @@ void __init dec_init_kn230(void) */ void __init dec_init_kn02(void) { + int dec_ie_io; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -184,10 +186,11 @@ void __init dec_init_kn02(void) imr = (void *) KN02_CSR_ADDR; /* - * Setup IOASIC interrupt + * Setup I/O interrupt */ + dec_ie_io = IE_IRQ0; cpu_ivec_tbl[1] = kn02_io_int; - cpu_mask_tbl[1] = IE_IRQ0; + cpu_mask_tbl[1] = dec_ie_io; cpu_irq_nr[1] = -1; *imr = *imr & 0xff00ff00; @@ -234,11 +237,10 @@ void __init dec_init_kn02(void) cpu_mask_tbl[2] = IE_IRQ3; cpu_irq_nr[2] = MEMORY; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[3] = IE_IRQ5; - cpu_irq_nr[3] = FPU; - + /* + * Enable board interrupts: FPU, I/O. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_io); } /* dec_init_kn02 */ /* @@ -246,6 +248,8 @@ void __init dec_init_kn02(void) */ void __init dec_init_kn02ba(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. */ @@ -257,9 +261,10 @@ void __init dec_init_kn02ba(void) /* * Setup IOASIC interrupt */ - cpu_mask_tbl[0] = IE_IRQ3; - cpu_irq_nr[0] = -1; + dec_ie_ioasic = IE_IRQ3; cpu_ivec_tbl[0] = kn02xa_io_int; + cpu_mask_tbl[0] = dec_ie_ioasic; + cpu_irq_nr[0] = -1; *imr = 0; /* @@ -315,12 +320,12 @@ void __init dec_init_kn02ba(void) cpu_mask_tbl[4] = IE_IRQ4; cpu_irq_nr[4] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[5] = IE_IRQ5; - cpu_irq_nr[5] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn02ba */ /* @@ -328,6 +333,8 @@ void __init dec_init_kn02ba(void) */ void __init dec_init_kn02ca(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -339,9 +346,10 @@ void __init dec_init_kn02ca(void) /* * Setup IOASIC interrupt */ + dec_ie_ioasic = IE_IRQ3; cpu_ivec_tbl[1] = kn02xa_io_int; + cpu_mask_tbl[1] = dec_ie_ioasic; cpu_irq_nr[1] = -1; - cpu_mask_tbl[1] = IE_IRQ3; *imr = 0; /* @@ -392,12 +400,12 @@ void __init dec_init_kn02ca(void) cpu_mask_tbl[3] = IE_IRQ4; cpu_irq_nr[3] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[4] = IE_IRQ5; - cpu_irq_nr[4] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn02ca */ /* @@ -405,6 +413,8 @@ void __init dec_init_kn02ca(void) */ void __init dec_init_kn03(void) { + int dec_ie_ioasic; + /* * Setup some memory addresses. FIXME: probably incomplete! */ @@ -416,8 +426,9 @@ void __init dec_init_kn03(void) /* * Setup IOASIC interrupt */ + dec_ie_ioasic = IE_IRQ0; cpu_ivec_tbl[1] = kn03_io_int; - cpu_mask_tbl[1] = IE_IRQ0; + cpu_mask_tbl[1] = dec_ie_ioasic; cpu_irq_nr[1] = -1; *imr = 0; @@ -474,10 +485,10 @@ void __init dec_init_kn03(void) cpu_mask_tbl[3] = IE_IRQ4; cpu_irq_nr[3] = HALT; - dec_interrupt[FPU].cpu_mask = IE_IRQ5; - dec_interrupt[FPU].iemask = 0; - cpu_mask_tbl[4] = IE_IRQ5; - cpu_irq_nr[4] = FPU; + /* + * Enable board interrupts: FPU, I/O ASIC. + */ + set_cp0_status(DEC_IE_FPU | dec_ie_ioasic); - dec_halt_init(&irq10); + dec_halt_init(&haltirq); } /* dec_init_kn03 */ diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/entry.S linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/entry.S --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/entry.S Tue Nov 20 05:26:20 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/entry.S Fri Nov 23 14:50:11 2001 @@ -106,16 +106,16 @@ LEAF(spurious_interrupt) __INIT - /* - * General exception vector. Used for all CPUs except R4000 - * and R4400 SC and MC versions. - */ .set reorder NESTED(except_vec1_generic, 0, sp) PANIC("Exception vector 1 called") END(except_vec1_generic) + /* + * General exception vector. Used for all CPUs except R4000 + * and R4400 SC and MC versions. + */ NESTED(except_vec3_generic, 0, sp) mfc0 k1, CP0_CAUSE la k0, exception_handlers @@ -225,6 +225,7 @@ EXPORT(exception_count_##exception); NESTED(handle_##exception, PT_SIZE, sp); \ .set noat; \ SAVE_ALL; \ + FEXPORT(handle_##exception##_int); \ __BUILD_clear_##clear(exception); \ .set at; \ __BUILD_##verbose(exception); \ diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/setup.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/setup.c --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/setup.c Tue Nov 20 05:26:20 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/setup.c Fri Nov 23 14:50:11 2001 @@ -7,7 +7,7 @@ * Copyright (C) 1995 Waldorf Electronics * Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001 Ralf Baechle * Copyright (C) 1996 Stoned Elipot - * Copyright (C) 2000 Maciej W. Rozycki + * Copyright (C) 2000, 2001 Maciej W. Rozycki */ #include #include @@ -182,6 +182,28 @@ static inline int cpu_has_confreg(void) #endif } +/* + * Get the FPU Implementation/Revision. + */ +static inline unsigned long cpu_get_fpu_id(void) +{ + unsigned long tmp, fpu_id; + + tmp = read_32bit_cp0_register(CP0_STATUS); + write_32bit_cp0_register(CP0_STATUS, tmp | ST0_CU1); + fpu_id = read_32bit_cp1_register(CP1_REVISION); + write_32bit_cp0_register(CP0_STATUS, tmp); + return fpu_id; +} + +/* + * Check the CPU has an FPU the official way. + */ +static inline int cpu_has_fpu(void) +{ + return ((cpu_get_fpu_id() & 0xff00) != FPIR_IMP_NONE); +} + /* declaration of the global struct */ struct mips_cpu mips_cpu = {PRID_IMP_UNKNOWN, CPU_UNKNOWN, 0, 0, 0, {0,0,0,0}, {0,0,0,0}, {0,0,0,0}, {0,0,0,0}}; @@ -206,6 +228,8 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R2000; mips_cpu.isa_level = MIPS_CPU_ISA_I; mips_cpu.options = MIPS_CPU_TLB; + if (cpu_has_fpu()) + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; break; case PRID_IMP_R3000: @@ -218,6 +242,8 @@ static inline void cpu_probe(void) mips_cpu.cputype = CPU_R3000; mips_cpu.isa_level = MIPS_CPU_ISA_I; mips_cpu.options = MIPS_CPU_TLB; + if (cpu_has_fpu()) + mips_cpu.options |= MIPS_CPU_FPU; mips_cpu.tlbsize = 64; break; case PRID_IMP_R4000: diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/arch/mips/kernel/traps.c linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/traps.c --- linux-mips-2.4.14-20011123-dist/arch/mips/kernel/traps.c Wed Nov 21 05:26:46 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/arch/mips/kernel/traps.c Fri Nov 23 14:50:11 2001 @@ -501,7 +501,6 @@ asmlinkage void do_fpe(struct pt_regs *r return; force_sig(SIGFPE, current); - printk(KERN_DEBUG "Sent send SIGFPE to %s\n", current->comm); } static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode) diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/cpu.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/cpu.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/cpu.h Fri Nov 23 14:46:34 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/cpu.h Fri Nov 23 15:08:18 2001 @@ -90,6 +90,17 @@ #define PRID_REV_TX3927C 0x0042 #define PRID_REV_TX39H3TEG 0x0050 +/* + * FPU implementation/revision register (CP1 control register 0). + * + * +---------------------------------+----------------+----------------+ + * | 0 | Implementation | Revision | + * +---------------------------------+----------------+----------------+ + * 31 16 15 8 7 0 + */ + +#define FPIR_IMP_NONE 0x0000 + #ifndef _LANGUAGE_ASSEMBLY /* * Capability and feature descriptor structure for MIPS CPU diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/dec/interrupts.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/dec/interrupts.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/dec/interrupts.h Tue Jul 3 04:27:22 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/dec/interrupts.h Wed Nov 21 23:57:52 2001 @@ -13,6 +13,8 @@ #ifndef __ASM_DEC_INTERRUPTS_H #define __ASM_DEC_INTERRUPTS_H +#include + /* * DECstation Interrupts */ @@ -22,7 +24,7 @@ * Exception: on kmins we have to handle Memory Error * Interrupts before the TC Interrupts. */ -#define CLOCK 0 +#define CLOCK 0 #define SCSI_DMA_INT 1 #define SCSI_INT 2 #define ETHER 3 @@ -31,10 +33,17 @@ #define TC1 6 #define TC2 7 #define MEMORY 8 -#define FPU 9 -#define HALT 10 +#define HALT 9 + +#define NR_INTS 10 -#define NR_INTS 11 +/* + * The FPU is special. It must always be handled first. + * Since it bypasses the regular IRQ handler we define + * the line it uses here. All DECstations use the same + * one. + */ +#define DEC_IE_FPU IE_IRQ5 #ifndef __ASSEMBLY__ /* @@ -70,8 +79,6 @@ extern long asic_mask_tbl[32]; * Common interrupt routine prototypes for all DECStations */ extern void dec_intr_unimplemented(void); -extern void dec_intr_fpu(void); -extern void dec_intr_rtc(void); extern void kn02_io_int(void); extern void kn02xa_io_int(void); diff -up --recursive --new-file linux-mips-2.4.14-20011123-dist/include/asm-mips/mipsregs.h linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/mipsregs.h --- linux-mips-2.4.14-20011123-dist/include/asm-mips/mipsregs.h Tue Nov 20 05:27:07 2001 +++ linux-mips-2.4.14-20011123-dec-fpu/include/asm-mips/mipsregs.h Fri Nov 23 14:55:27 2001 @@ -508,6 +508,19 @@ :"=r" (__res)); \ __res;}) +/* + * Macros to access the floating point coprocessor control registers + */ +#define read_32bit_cp1_register(source) \ +({ int __res; \ + __asm__ __volatile__( \ + ".set\tpush\n\t" \ + ".set\treorder\n\t" \ + "cfc1\t%0,"STR(source)"\n\t" \ + ".set\tpop" \ + : "=r" (__res)); \ + __res;}) + /* TLB operations. */ static inline void tlb_probe(void) { From macro@ds2.pg.gda.pl Mon Nov 26 15:37:34 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA26017; Mon, 26 Nov 2001 15:37:34 +0100 (MET) Received-Date: Mon, 26 Nov 2001 15:37:34 +0100 (MET) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd026015; Mon Nov 26 15:37:17 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA00100; Mon, 26 Nov 2001 15:35:18 +0100 (MET) Date: Mon, 26 Nov 2001 15:35:17 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: A critical DECstation interrupt handler fix Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1614 Lines: 43 Hello, The DECstation's interrupt handler can crash under certain circumstances. Due to a missing masking of the CP0 Cause register, if a spurious interrupt is delivered (its deasserted before reading the register), the handler may jump to an arbitrary memory location as determined by data fetched from an incorrect location. Due to this problem my new /260 system used to crash frequently, because Cause.CE is often set to 3 (CE is unspecified for all but coprocessor unusable exceptions). The following patch masks Cause appropriately. A small reorganization of code was also possible due to changes in the scheduling of delay slots. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-dec-cause-0 diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S --- linux-mips-2.4.14-20011123.macro/arch/mips/dec/int-handler.S Tue Jul 3 04:27:16 2001 +++ linux-mips-2.4.14-20011123/arch/mips/dec/int-handler.S Sun Nov 25 00:40:11 2001 @@ -140,7 +140,7 @@ */ mfc0 t0,CP0_CAUSE # get pending interrupts mfc0 t2,CP0_STATUS - la t1,cpu_mask_tbl + andi t0,ST0_IM # CAUSE.CE may be non-zero! and t0,t2 # isolate allowed ones beqz t0,spurious @@ -148,7 +148,8 @@ /* * Find irq with highest priority */ -1: lw t2,(t1) + la t1,cpu_mask_tbl +1: lw t2,(t1) move t3,t0 and t3,t2 beq t3,zero,1b From macro@ds2.pg.gda.pl Mon Nov 26 16:30:14 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA27049; Mon, 26 Nov 2001 16:30:14 +0100 (MET) Received-Date: Mon, 26 Nov 2001 16:30:14 +0100 (MET) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd027027; Mon Nov 26 16:30:05 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA01718; Mon, 26 Nov 2001 16:28:36 +0100 (MET) Date: Mon, 26 Nov 2001 16:28:34 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: Report the faulting FPU instruction Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2011 Lines: 49 Hello, I believe it's desireable to point to the faulting instruction upon an FPU trap and not the following one. Why? First, the FPU restores the state from before attempting to exectute the instruction. Second, with the current approach state is lost -- consider instructions in branch/jump delay slots. Third, erroneous execution is possible if SIG_FPE's handler is set to "ignore" by mistake. The following patch implements the described approach. It should not affect standard handlers which use setjmp()/longjmp(), but it should enable a smarter interpreting handler or just better diagnostics. Both the hardware and the emulator are handled. Tested successfully with gdb on an R3k, an R4k and the emulator. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.14-20011123-fpu-epc-0 diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c --- linux-mips-2.4.14-20011123.macro/arch/mips/kernel/traps.c Wed Nov 21 05:26:46 2001 +++ linux-mips-2.4.14-20011123/arch/mips/kernel/traps.c Sun Nov 25 13:25:06 2001 @@ -497,9 +497,6 @@ asmlinkage void do_fpe(struct pt_regs *r return; } - if (compute_return_epc(regs)) - return; - force_sig(SIGFPE, current); printk(KERN_DEBUG "Sent send SIGFPE to %s\n", current->comm); } diff -up --recursive --new-file linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c --- linux-mips-2.4.14-20011123.macro/arch/mips/math-emu/cp1emu.c Sun Oct 14 04:26:36 2001 +++ linux-mips-2.4.14-20011123/arch/mips/math-emu/cp1emu.c Sun Nov 25 13:29:30 2001 @@ -1721,6 +1721,9 @@ int fpu_emulator_cop1Handler(struct pt_r /* but if epc has advanced, then ignore it */ sig = 0; + if (sig) + xcp->cp0_epc = prevepc; + return sig; } From ralf@linux-mips.net Tue Nov 27 04:12:13 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id EAA06449; Tue, 27 Nov 2001 04:12:13 +0100 (MET) Received-Date: Tue, 27 Nov 2001 04:12:13 +0100 (MET) Received: from oss.sgi.com(216.32.174.27) via SMTP by guadalquivir.fnet.fr, id smtpd006447; Tue Nov 27 04:12:03 2001 Received: from dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.11.2/8.11.3) with ESMTP id fAR4Bko05312 for ; Mon, 26 Nov 2001 20:11:46 -0800 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id fAR1DbJ26525; Tue, 27 Nov 2001 12:13:37 +1100 Date: Tue, 27 Nov 2001 12:13:37 +1100 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: Report the faulting FPU instruction Message-ID: <20011127121337.E2525@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Nov 26, 2001 at 04:28:34PM +0100 X-Accept-Language: de,en,fr Content-Length: 1140 Lines: 22 On Mon, Nov 26, 2001 at 04:28:34PM +0100, Maciej W. Rozycki wrote: > I believe it's desireable to point to the faulting instruction upon an > FPU trap and not the following one. Why? First, the FPU restores the > state from before attempting to exectute the instruction. Second, with > the current approach state is lost -- consider instructions in branch/jump > delay slots. Third, erroneous execution is possible if SIG_FPE's handler > is set to "ignore" by mistake. > > The following patch implements the described approach. It should not > affect standard handlers which use setjmp()/longjmp(), but it should > enable a smarter interpreting handler or just better diagnostics. Both > the hardware and the emulator are handled. Tested successfully with gdb > on an R3k, an R4k and the emulator. The problem you found in the FPU emulator is a fairly generic one. We got other exception handlers which in error case will still skip over the instruction. What also isn't handled properly is the case of sending a signal to the application. In such a case sigreturn() should do the the compute_return_epc() thing ... Ralf From macro@ds2.pg.gda.pl Tue Nov 27 14:22:51 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA13806; Tue, 27 Nov 2001 14:22:51 +0100 (MET) Received-Date: Tue, 27 Nov 2001 14:22:51 +0100 (MET) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd013804; Tue Nov 27 14:21:39 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA03242; Tue, 27 Nov 2001 14:20:06 +0100 (MET) Date: Tue, 27 Nov 2001 14:20:05 +0100 (MET) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: Report the faulting FPU instruction In-Reply-To: <20011127121337.E2525@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 753 Lines: 16 On Tue, 27 Nov 2001, Ralf Baechle wrote: > The problem you found in the FPU emulator is a fairly generic one. We > got other exception handlers which in error case will still skip over > the instruction. What also isn't handled properly is the case of sending > a signal to the application. In such a case sigreturn() should do the > the compute_return_epc() thing ... Well, with break/trap 6/7 I have already noticed exception handlers tend to call compute_return_epc() unnecessarily. I shall be cleaning the code gradually as time passes by... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +