From owner-linux-mips@oss.sgi.com Sat Jun 1 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 g51IfnnC023537 for ; Sat, 1 Jun 2002 11:41:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51IfnjL023536 for linux-mips-outgoing; Sat, 1 Jun 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 dea.linux-mips.net (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g51IflnC023532 for ; Sat, 1 Jun 2002 11:41:47 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g51Igsl08252 for linux-mips@oss.sgi.com; Sat, 1 Jun 2002 11:42:54 -0700 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 g4VLKinC014263 for ; Fri, 31 May 2002 14:20:45 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id BDD0B8F6; Fri, 31 May 2002 23:22:20 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D477D37100; Fri, 31 May 2002 23:20:21 +0200 (CEST) Date: Fri, 31 May 2002 23:20:21 +0200 From: Florian Lohoff To: James Simmons Cc: linux-mips Subject: Re: New platforms Message-ID: <20020531212021.GA19878@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" 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 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 31, 2002 at 12:17:41PM -0700, James Simmons wrote: >=20 > 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. >=20 I dont know how others feel which would need to work more with this but i don't like BK's license (and its advocat Larry 'need to earn money' McVoy= ). Forcing people into creating seperate trees due to licensing issues of the SCCS is not really something we need now. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --M9NhX3UHpAaciwkO 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 iD8DBQE89+kVUaz2rXW+gJcRAlgAAKCRwSnO/PSV34KAkbL4Jpjje8XmCACfWKol 9V1/ImO/8MgNyYdP5SAkca8= =OvEU -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-linux-mips@oss.sgi.com Sat Jun 1 11:41: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 g51IfdnC023528 for ; Sat, 1 Jun 2002 11:41:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51IfdYv023527 for linux-mips-outgoing; Sat, 1 Jun 2002 11:41:39 -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 g51IfWnC023524 for ; Sat, 1 Jun 2002 11:41:32 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g51Igf008248 for linux-mips@oss.sgi.com; Sat, 1 Jun 2002 11:42:41 -0700 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 g4VJ4rnC011892 for ; Fri, 31 May 2002 12:04:54 -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 g4VJ6OtS023396 for ; Fri, 31 May 2002 21:06:24 +0200 Message-ID: <3CF7C9B0.20808@murphy.dk> Date: Fri, 31 May 2002 21:06:24 +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: Patch for support of Lasat 100 and 200 machines (~60k) Content-Type: multipart/mixed; boundary="------------040102050900040803070107" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------040102050900040803070107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, this is the reference source for the lasat platforms. I have cleaned up the original code to give a patch which applies against todays tree and produces a running kernel on both platforms. The patch adds (v)r5000 cache support, the general stuff required to add a new platform and some small patches in various places to fix bugs and add, for example, mtd support for the flash in these machines. The files not patched (not existing in the oss CVS) are in lasat.tar.gz. This includes arch/mips/lasat and include/asm-mips/lasat - one file to support r5000 cache support and one for the memory mapped flash modules to give mtd support. In addition there are two drivers for the rtc and display in the two machines which have interface include files in include/linux. I know I was encouraged to split up this stuff but I could spend weeks or months doing that and not have something which would satisfy the authorities - This is my first attempt. Perhaps, Florian, you can look at it and give me some advice as to how I should structure any splitting-up to get this accepted. If anyone has a masquerade (or safepipe) box then you will also need the information on http://debian.murphy.dk to get this stuff uploaded on your box. Any problems, send me a mail. regards /Brian --------------040102050900040803070107 Content-Type: text/plain; name="sgi.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sgi.diff" ? arch/mips/defconfig-lasat100 ? arch/mips/defconfig-lasat200 ? arch/mips/lasat ? arch/mips/patch ? arch/mips/mm/c-r5000.c ? drivers/mtd/maps/lasat.c ? include/asm-mips/lasat ? include/linux/ds1603.h ? include/linux/picvue.h Index: arch/mips/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/Makefile,v retrieving revision 1.78.2.2 diff -u -r1.78.2.2 Makefile --- arch/mips/Makefile 2002/02/15 21:05:47 1.78.2.2 +++ arch/mips/Makefile 2002/05/30 10:33:14 @@ -77,6 +77,9 @@ ifdef CONFIG_CPU_R5000 GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap endif +ifdef CONFIG_CPU_VR5000 +GCCFLAGS += -mcpu=vr5000 -mips2 -Wa,--trap +endif ifdef CONFIG_CPU_R5432 GCCFLAGS += -mcpu=r5000 -mips2 -Wa,--trap endif @@ -288,7 +291,14 @@ LOADADDR += 0x80100000 endif +ifdef CONFIG_LASAT +LIBS += arch/mips/lasat/lasatkern.o +SUBDIRS += arch/mips/lasat +LOADADDR += 0x80000000 +endif + # +# # Au1000 eval board # ifdef CONFIG_MIPS_PB1000 @@ -379,6 +389,11 @@ endif MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot + +ifdef CONFIG_LASAT +rom.bin: vmlinux + $(MAKE) -C arch/$(ARCH)/lasat/image $@ +endif vmlinux.ecoff: vmlinux @$(MAKEBOOT) $@ Index: arch/mips/config.in =================================================================== RCS file: /cvs/linux/arch/mips/config.in,v retrieving revision 1.154.2.19 diff -u -r1.154.2.19 config.in --- arch/mips/config.in 2002/05/29 14:30:49 1.154.2.19 +++ arch/mips/config.in 2002/05/30 10:33:14 @@ -43,6 +43,22 @@ fi dep_bool 'Support for Galileo EV96100 Evaluation board (EXPERIMENTAL)' CONFIG_MIPS_EV96100 $CONFIG_EXPERIMENTAL bool 'Support for Globespan IVR board' CONFIG_MIPS_IVR +bool 'Support for LASAT Networks platforms' CONFIG_LASAT +if [ "$CONFIG_LASAT" = "y" ]; then + bool ' Support for LASAT Networks 100 series' CONFIG_LASAT_100 + bool ' Support for LASAT Networks 200 series' CONFIG_LASAT_200 + tristate ' DS1603 rtc support' CONFIG_DS1603 + tristate ' PICVUE LCD display driver' CONFIG_PICVUE + dep_tristate ' PICVUE LCD display driver /proc interface' CONFIG_PICVUE_PROC $CONFIG_PICVUE + if [ "$CONFIG_LASAT_100" = "y" ]; then + define_bool CONFIG_PCI y + define_bool CONFIG_NONCOHERENT_IO y + fi + if [ "$CONFIG_LASAT_200" = "y" ]; then + define_bool CONFIG_PCI y + define_bool CONFIG_NONCOHERENT_IO y + fi +fi bool 'Support for Hewlett Packard LaserJet board' CONFIG_HP_LASERJET bool 'Support for ITE 8172G board' CONFIG_MIPS_ITE8172 if [ "$CONFIG_MIPS_ITE8172" = "y" ]; then @@ -324,6 +340,7 @@ R4x00 CONFIG_CPU_R4X00 \ R49XX CONFIG_CPU_TX49XX \ R5000 CONFIG_CPU_R5000 \ + VR5000 CONFIG_CPU_VR5000 \ R5432 CONFIG_CPU_R5432 \ RM7000 CONFIG_CPU_RM7000 \ R52xx CONFIG_CPU_NEVADA \ @@ -355,6 +372,7 @@ if [ "$CONFIG_CPU_R4X00" = "y" -o \ "$CONFIG_CPU_R5000" = "y" -o \ + "$CONFIG_CPU_VR5000" = "y" -o \ "$CONFIG_CPU_RM7000" = "y" -o \ "$CONFIG_CPU_R10000" = "y" -o \ "$CONFIG_CPU_SB1" = "y" -o \ Index: arch/mips/kernel/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/kernel/Makefile,v retrieving revision 1.51.2.1 diff -u -r1.51.2.1 Makefile --- arch/mips/kernel/Makefile 2002/01/24 23:14:24 1.51.2.1 +++ arch/mips/kernel/Makefile 2002/05/30 10:33:15 @@ -32,6 +32,7 @@ obj-$(CONFIG_CPU_R4300) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R4X00) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R5000) += r4k_fpu.o r4k_switch.o +obj-$(CONFIG_CPU_VR5000) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_R5432) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_RM7000) += r4k_fpu.o r4k_switch.o obj-$(CONFIG_CPU_NEVADA) += r4k_fpu.o r4k_switch.o Index: arch/mips/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/setup.c,v retrieving revision 1.96.2.17 diff -u -r1.96.2.17 setup.c --- arch/mips/kernel/setup.c 2002/05/28 05:38:37 1.96.2.17 +++ arch/mips/kernel/setup.c 2002/05/30 10:33:16 @@ -137,7 +137,7 @@ printk(" available.\n"); break; case CPU_R4200: -/* case CPU_R4300: */ + case CPU_R4300: case CPU_R4600: case CPU_R4640: case CPU_R4650: @@ -762,6 +762,11 @@ case MACH_GROUP_PHILIPS: nino_setup(); break; +#endif +#ifdef CONFIG_LASAT + case MACH_GROUP_LASAT: + platform_setup(); + break; #endif #ifdef CONFIG_MIPS_PB1000 case MACH_GROUP_ALCHEMY: Index: arch/mips/mm/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/mm/Makefile,v retrieving revision 1.27 diff -u -r1.27 Makefile --- arch/mips/mm/Makefile 2001/11/26 13:38:14 1.27 +++ arch/mips/mm/Makefile 2002/05/30 10:33:16 @@ -24,6 +24,7 @@ obj-$(CONFIG_CPU_R4X00) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_VR41XX) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R5000) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o +obj-$(CONFIG_CPU_VR5000) += pg-r4k.o c-r5000.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_NEVADA) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R5432) += pg-r5432.o c-r5432.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_RM7000) += pg-rm7k.o c-rm7k.o tlb-r4k.o tlbex-r4k.o Index: arch/mips/mm/loadmmu.c =================================================================== 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 10:33:17 @@ -52,6 +52,7 @@ extern void ld_mmu_r23000(void); extern void ld_mmu_r4xx0(void); +extern void ld_mmu_r5000(void); extern void ld_mmu_tx39(void); extern void ld_mmu_tx49(void); extern void ld_mmu_r5432(void); @@ -72,6 +73,10 @@ defined(CONFIG_CPU_R4300) || defined(CONFIG_CPU_R5000) || \ defined(CONFIG_CPU_NEVADA) ld_mmu_r4xx0(); + r4k_tlb_init(); +#endif +#if defined(CONFIG_CPU_VR5000) + ld_mmu_r5000(); r4k_tlb_init(); #endif #if defined(CONFIG_CPU_RM7000) Index: drivers/mtd/maps/Config.in =================================================================== RCS file: /cvs/linux/drivers/mtd/maps/Config.in,v retrieving revision 1.3.2.2 diff -u -r1.3.2.2 Config.in --- drivers/mtd/maps/Config.in 2002/02/15 21:05:48 1.3.2.2 +++ drivers/mtd/maps/Config.in 2002/05/30 10:33:21 @@ -50,6 +50,7 @@ int ' Bus width in octets' CONFIG_MTD_CSTM_MIPS_IXX_BUSWIDTH 2 fi dep_tristate ' Momenco Ocelot boot flash device' CONFIG_MTD_OCELOT $CONFIG_MOMENCO_OCELOT + dep_tristate ' LASAT flash device' CONFIG_MTD_LASAT $CONFIG_MTD_CFI $CONFIG_LASAT fi if [ "$CONFIG_SH" = "y" ]; then Index: drivers/mtd/maps/Makefile =================================================================== RCS file: /cvs/linux/drivers/mtd/maps/Makefile,v retrieving revision 1.2.2.2 diff -u -r1.2.2.2 Makefile --- drivers/mtd/maps/Makefile 2002/02/15 21:05:48 1.2.2.2 +++ drivers/mtd/maps/Makefile 2002/05/30 10:33:21 @@ -31,5 +31,6 @@ obj-$(CONFIG_MTD_SOLUTIONENGINE)+= solutionengine.o obj-$(CONFIG_MTD_PB1000) += pb1xxx-flash.o obj-$(CONFIG_MTD_PB1500) += pb1xxx-flash.o +obj-$(CONFIG_MTD_LASAT) += lasat.o include $(TOPDIR)/Rules.make Index: drivers/net/pcnet32.c =================================================================== RCS file: /cvs/linux/drivers/net/pcnet32.c,v retrieving revision 1.33.2.1 diff -u -r1.33.2.1 pcnet32.c --- drivers/net/pcnet32.c 2002/02/26 05:59:35 1.33.2.1 +++ drivers/net/pcnet32.c 2002/05/30 10:33:23 @@ -656,7 +656,7 @@ #if defined(__i386__) printk(KERN_WARNING "%s: Probably a Compaq, using the PROM address of", dev->name); memcpy(dev->dev_addr, promaddr, 6); -#elif defined(__powerpc__) +#else if (!is_valid_ether_addr(dev->dev_addr) && is_valid_ether_addr(promaddr)) { printk("\n" KERN_WARNING "%s: using PROM address:", @@ -765,8 +765,12 @@ if (irq_line) { dev->irq = irq_line; } - + +#ifdef CONFIG_LASAT + if (dev->irq >= 0) +#else if (dev->irq >= 2) +#endif printk(" assigned IRQ %d.\n", dev->irq); else { unsigned long irq_mask = probe_irq_on(); @@ -821,7 +825,10 @@ u16 val; int i; - if (dev->irq == 0 || + if ( +#ifndef CONFIG_LASAT + dev->irq == 0 || +#endif request_irq(dev->irq, &pcnet32_interrupt, lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) { return -EAGAIN; @@ -1343,6 +1350,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); @@ -1664,7 +1675,7 @@ } return -EOPNOTSUPP; } - + static struct pci_driver pcnet32_driver = { name: DRV_NAME, probe: pcnet32_probe_pci, Index: drivers/pci/pci.c =================================================================== RCS file: /cvs/linux/drivers/pci/pci.c,v retrieving revision 1.48 diff -u -r1.48 pci.c --- drivers/pci/pci.c 2001/12/02 11:34:45 1.48 +++ drivers/pci/pci.c 2002/05/30 10:33:25 @@ -38,6 +38,8 @@ LIST_HEAD(pci_root_buses); LIST_HEAD(pci_devices); +static int pci_reverse = 0; + /** * pci_find_slot - locate PCI device from a given PCI slot * @bus: number of PCI bus on which desired PCI device resides @@ -1327,8 +1329,13 @@ * Link the device to both the global PCI device chain and * the per-bus list of devices. */ - list_add_tail(&dev->global_list, &pci_devices); - list_add_tail(&dev->bus_list, &bus->devices); + if (!pci_reverse) { + list_add_tail(&dev->global_list, &pci_devices); + list_add_tail(&dev->bus_list, &bus->devices); + } else { + list_add(&dev->global_list, &pci_devices); + list_add(&dev->bus_list, &bus->devices); + } /* Fix up broken headers */ pci_fixup_device(PCI_FIXUP_HEADER, dev); @@ -1952,7 +1959,10 @@ *k++ = 0; if (*str && (str = pcibios_setup(str)) && *str) { /* PCI layer options should be handled here */ - printk(KERN_ERR "PCI: Unknown option `%s'\n", str); + if (!strcmp(str, "reverse")) + pci_reverse = 1; + else + printk(KERN_ERR "PCI: Unknown option `%s'\n", str); } str = k; } Index: include/asm-mips/bootinfo.h =================================================================== RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v retrieving revision 1.43.2.8 diff -u -r1.43.2.8 bootinfo.h --- include/asm-mips/bootinfo.h 2002/02/15 21:05:49 1.43.2.8 +++ include/asm-mips/bootinfo.h 2002/05/30 10:33:31 @@ -35,6 +35,7 @@ #define MACH_GROUP_ALCHEMY 18 /* Alchemy Semi Eval Boards*/ #define MACH_GROUP_NEC_VR41XX 19 /* NEC Vr41xx based boards/gadgets */ #define MACH_GROUP_HP_LJ 20 /* Hewlett Packard LaserJet */ +#define MACH_GROUP_LASAT 21 /* * Valid machtype values for group unknown (low order halfword of mips_machtype) @@ -151,6 +152,12 @@ #define MACH_TOPAS 1 #define MACH_JMR 2 #define MACH_TOSHIBA_JMR3927 3 /* JMR-TX3927 CPU/IO board */ + +/* + * Valid machtype for group LASAT + */ +#define MACH_LASAT_100 0 /* Masquerade II/SP100/SP50/SP25 */ +#define MACH_LASAT_200 1 /* Masquerade PRO/SP200 */ /* * Valid machtype for group Alchemy Index: include/asm-mips/cacheops.h =================================================================== RCS file: /cvs/linux/include/asm-mips/cacheops.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 cacheops.h --- include/asm-mips/cacheops.h 1997/06/01 03:17:12 1.1.1.1 +++ include/asm-mips/cacheops.h 2002/05/30 10:33:31 @@ -35,6 +35,7 @@ #define Hit_Writeback_Inv_D 0x15 /* 0x16 is unused */ #define Hit_Writeback_Inv_SD 0x17 +#define Page_Invalidate 0x17 #define Hit_Writeback_I 0x18 #define Hit_Writeback_D 0x19 /* 0x1a is unused */ Index: include/asm-mips/cpu.h =================================================================== RCS file: /cvs/linux/include/asm-mips/cpu.h,v retrieving revision 1.24.2.6 diff -u -r1.24.2.6 cpu.h --- include/asm-mips/cpu.h 2002/05/13 18:54:25 1.24.2.6 +++ include/asm-mips/cpu.h 2002/05/30 10:33:32 @@ -53,6 +53,7 @@ #define PRID_IMP_R4640 0x2200 #define PRID_IMP_R4650 0x2200 /* Same as R4640 */ #define PRID_IMP_R5000 0x2300 +#define PRID_IMP_VR5000 0x2300 #define PRID_IMP_TX49 0x2d00 #define PRID_IMP_SONIC 0x2400 #define PRID_IMP_MAGIC 0x2500 @@ -127,7 +128,7 @@ CPU_R5000A, CPU_R4640, CPU_NEVADA, CPU_RM7000, CPU_R5432, CPU_4KC, CPU_5KC, CPU_R4310, CPU_SB1, CPU_TX3912, CPU_TX3922, CPU_TX3927, CPU_AU1000, CPU_4KEC, CPU_4KSC, CPU_VR41XX, CPU_R5500, CPU_TX49XX, - CPU_TX39XX, CPU_AU1500, CPU_20KC, CPU_LAST + CPU_TX39XX, CPU_AU1500, CPU_20KC, CPU_VR5000, CPU_LAST }; #endif Index: include/asm-mips/r4kcache.h =================================================================== RCS file: /cvs/linux/include/asm-mips/r4kcache.h,v retrieving revision 1.8 diff -u -r1.8 r4kcache.h --- include/asm-mips/r4kcache.h 2001/10/31 02:31:23 1.8 +++ include/asm-mips/r4kcache.h 2002/05/30 10:33:35 @@ -76,6 +76,19 @@ "i" (Hit_Writeback_Inv_D)); } +extern inline void flush_dcache_line_wb(unsigned long addr) +{ + __asm__ __volatile__( + ".set noreorder\n\t" + ".set mips3\n\t" + "cache %1, (%0)\n\t" + ".set mips0\n\t" + ".set reorder" + : + : "r" (addr), + "i" (Hit_Writeback_D)); +} + static inline void invalidate_dcache_line(unsigned long addr) { __asm__ __volatile__( @@ -606,6 +619,40 @@ static inline void blast_scache128_page_indexed(unsigned long page) { cache128_unroll32(page,Index_Writeback_Inv_SD); +} + + +#define cache_unroll(base,op) \ + __asm__ __volatile__(" \ + .set noreorder; \ + .set mips3; \ + cache %1, (%0); \ + .set mips0; \ + .set reorder" \ + : \ + : "r" (base), \ + "i" (op)); + +extern inline void blast_r5000_scache(void) +{ + unsigned long start = KSEG0; + unsigned long end = KSEG0 + scache_size; + + while(start < end) { + cache_unroll(start,Page_Invalidate); + start += 128*sc_lsize; + } +} + +extern inline void blast_r5000_scache_page_indexed(unsigned long page) +{ + unsigned long start = page; + unsigned long end = page + PAGE_SIZE; + + while(start < end) { + cache_unroll(start,Page_Invalidate); + start += 128*sc_lsize; + } } #endif /* !(_MIPS_R4KCACHE_H) */ Index: include/asm-mips/serial.h =================================================================== RCS file: /cvs/linux/include/asm-mips/serial.h,v retrieving revision 1.23.2.2 diff -u -r1.23.2.2 serial.h --- include/asm-mips/serial.h 2002/01/07 03:33:54 1.23.2.2 +++ include/asm-mips/serial.h 2002/05/30 10:33:35 @@ -144,6 +144,18 @@ #define IVR_SERIAL_PORT_DEFNS #endif +#ifdef CONFIG_LASAT +#include +#define LASAT_SERIAL_PORT_DEFNS \ + { baud_base: LASAT_BASE_BAUD, irq: LASATINT_UART, \ + flags: STD_COM_FLAGS, \ + port: LASAT_UART_REGS_BASE, /* Only for display */ \ + iomem_base: (u8 *)KSEG1ADDR(LASAT_UART_REGS_BASE), \ + iomem_reg_shift: LASAT_UART_REGS_SHIFT, io_type: SERIAL_IO_MEM } +#else +#define LASAT_SERIAL_PORT_DEFNS +#endif + #ifdef CONFIG_AU1000_UART #include #define AU1000_SERIAL_PORT_DEFNS \ @@ -286,6 +298,7 @@ COBALT_SERIAL_PORT_DEFNS \ EV96100_SERIAL_PORT_DEFNS \ JAZZ_SERIAL_PORT_DEFNS \ + LASAT_SERIAL_PORT_DEFNS \ STD_SERIAL_PORT_DEFNS \ EXTRA_SERIAL_PORT_DEFNS \ HUB6_SERIAL_PORT_DFNS \ --------------040102050900040803070107 Content-Type: application/gzip; name="lasat.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="lasat.tar.gz" H4sIABHG9zwAA+xce3Pbtpbvv/GnwKTTrp2bxHrbbpvsQCAlweYrJCXL2bvDoSXa5kaWfCkq jaf37mffA1CU+ACo3N222+5Sk9gWfwfP8wQIHD+aPZw+hk/r03lwN1st78L7Nwt/7cfNRuOb X+nTgLp6nc43jUajedZtZH/Dp91pn8HfZ52zbqvZPWu0gb7TbjS/Qb9aB6o+m3XsRwh9cxs9 VtIdwv+kn2+PvkV4E68e/Tic+YvFM7oPlkHkx8Ec3T6jR/9TgB6D5SYRjR/QfLX8lxgF8zA+ +vaImMaADj2dWs675+y3dgu+H7G6yWoOFfjxJgrjZ7QIPgcLtHqKw9Vyva9AnVqqTXXVcLGW FtRW/ty/XUDh1XwDv9abp6dVlG3VVMaayhqGVnaPJqrtUNNwULhGy1WM1kGcFrgCOK1d92cP 4RJqDRbBjPUm6WxCiIlqexYl2Os1s/Xs24EhelYfxLpRiXclONaGJrTQabRbQryPh6rLa5FX T8w+1lwhrqjEcbEL0yAvrk56nWarovvq5KLXrBofndiCSdawg929MPCvHtSTZVPysJWvPO27 0+w12vsKgA2TsVr87lm2STIPCd1/MUyDmCPVBmnyqJltd2SxplX7UhXPWzIsVz1vnon5wgmw C5XIYR0PjbHudSplQwfWYTFsghoQ0zOJqpkS9ir9LphLKdY561VgZ0LMUIlnOpat3ghhU6MT 1XWpp59JhmVQwxQCzpB61GqJJ9Sh/RtX9Zx+s9UV1+sY1LN1kBXGZCGFazoj2sfepW63L1ri 4Y3ocKSrukDe7GtH1b2haoABIp5jUUMzyVVWahKKKRkNsaIkqkvdkV4hIOOiYUiMizUWmxsA PLstkxeGutP2xXQqhe1eVeGJ3WnmC2eLgqfN6WbycFrZmU5lZ7rVnamE7W5HYhI5yqRPXthQ J1gRaxUvzbgiLw0yKMUSl1YJ98T6yGCsTLBBVEXCghF2PE1zMuZs/1RxiFLkDkOu+yXxGnK3 vWAPNk97L8lKaNR1NdVTDYViI2MoVTdbN+iXZ2BdFds26ohnVpUBLhFrCBGTO/2xuOGR6Vra eCjELKITKq5vW6xoNdLWbpwJtUh2+H1H4V5FdUCDCXHFpYir7Sfwipg2TKs2yNaTPMTmWGy8 +9QY6G4Jz6OFKrdPdeqI59TSS9KgB4+r6Bm5wexhuVqs7p+REnwOZ8EaHeuucpI1P/C9VNzy QZQWEKqxkCsTeu2bxLZl2m654GJzj/zlHP7wn1ESNG4gmiyYPMuwZFJWgHip/mI1+4TmyQiy 9fS1K4h2Jt5AEU/2Fp6KYRgEVVRpSWJ98CT2JIUJBWmpoGGNK5hc9MR2JyXRTFM8HymB0a8e oI3F/ijFqUFdu8xmfbOIwzfJvKZcRsc2pgrnoTbR85JS3QkJrCtggAwV2zKUtSeJlRJQEoQn YFcG6mPNpRZ2R9VTPykrjxHEP6+iT+HyPrNUyUgNuZIEkGBRYai8Yhk+oJqriqeiDG2BsUGn e6tDC3abWslQCXbEvQKC1AV5NtgdSfNAJlNLaBFgWgUObbEigZ0QiwUbhqcS8RLFuTFggWNe UZk3sibiGPdq5LqSBrEr1pGJhg3vvNFqfpA0JY51MKxVr2TLL0MiIH0wOEPxRE1bYknWsNUX A5rYG7B5VSBct8VdUOG3pHfXMBEVAsIqHoCQcRIpxejaG2jmNTwBQq2kWx9WDrMtp6sI3flh hP62CTYBaFpWw1g1DhmpZYPlQvz89LBaPiNH4JNGMDKxoWeIR6eX1aggnuD1A6tPwVGc6gP9 1Na08lYEgOnGAvz5mhXgBhR+W7TkvYq2mRcuGaaR4lU5p4REFELsq1Wok1vJbB8l5oJtllRX n5JPIHA0xSJRJB2ML6nrjL+KlvYP+Ky0t3jqfmXzH8bYcMdfV62j4iGWyHGR9rra8RFT12H5 iLVKKpdOxCvkTGtEbO6yFNVdAQqQuYOjAg21LPFSP0PlEEe85N4NXFd6nerQJiGBtceotAYq N1mK/sqBzsfi2rrc7WQ3KCv1bGnjjDDE5dT+cEBndJzfTkoxDIhIT83BoG9iW+LkdhV6eOya B5suauu27LXE9W5JDPXaU2ww+RBoOS41htVShFXSa0lW8FvMcyHmMMSLrl01Gm12p22xJ1FI Jb6rQ1fOOrKuJJhngisrxukiIZuKuENuzlukd1HdC+J0u+1qMR5Zbrsj7mcCcf4CMw7W0hMH LrtI3zk/6zTFocBO5CyX9lriqDilsRTSasi4nIJef2xLgsYdycC0SbU9cSbXV9US51CY4WY1 ExyNXDTUA7Pj2nrroppTE4qB5VPJyEGOPDKilqO6ksgyUamithZxOhEHZVwdTUO865DRde59 HZHEQszAF2CVapPQMCZ9FR3IXSmo4cZdsLIvGv0kqmmZKL9MzBZhqHCuWqZ015ZhfbbVKkUh LJdiUs/Em7RNUhrBdk1XHsU+5oQZo4QzJYn6bLIMYtGuAyCyEFoZ67rEr5qGIjOpKgQuGv0o ibvBFotLuSMI8nF5u0SNH4KI9f242UAQaIPL1G/D+CQ32qR4YS3pjA2N+WmxocMQM+iqJMyB on0di+URsA/iOgEZquKAjfUxCT29NkRYksWRrLOZ0o4uXyhtSWxMJMMaWbKXYHzdm9/8zCC5 GMJi8sLfie5lSMGWqxLPARUdUNni2bIpkbwFIs75xRdxz9yxJgkYXNLunku8i6J2phJkaIuN paJfNBvifXFVBTWUTZ1mqG2JGR+AfBli221g11F1sd4bautKamugtVZT3JzqSKHzZvuCiKeR Qa4pNnpbzLNoNQ5arXruNQRsErVPCc+brQspAY/97Klnq47EIoHvvZCwQbUokbEIFFORKpcr s83gfD17RCXL8B3q6bpkdq6pwQyldy5ZVrC9GgfjizNJvMZVzyxu0JWsIgw6tYh7ZSOqQcWW QtFaYj+l39hU/uoCYrn2ueQd+wiDsRyJ5fVG1TTzekAle2NXF+eaBBsoirhKCHksMWLJbIVl iZ87hQJ8Dq/DKFgE6zViknG8XC3fPPiPkT8PVyfFnR0bK3nmJzs7q0/BEtlsz1Xgcd2KHSkx y2wiswawELTyKpeMwF+icBkH0Z1faPw6L+xJcPDox8EmQjYboigmAv6KB0ojBaPjcHkX+VEw PxHGU7ZS3oSijmIA8e36eR0HjzlyhhTJyYMf+TMYjmg6J8K3W3wLY++0ku8efHNMLbdFtUXU qQveU7Km39JALAweDkyJLdqrYhvbF+ee5d5kzg/tH0LbY8N91+r20iiUiMPPcrinw5BzL4rG jm6OHbFdKiG85OUKZjqcfcrNHDWssesNsa4WX3/tSD5Q0mh5xV2YrYzFs4f56h4RP5oXZMwl I8UUh4fUcFXNsyXBozGRvf2xJe9gFVeyc223LyTvsSH002ghCuP9H8T+U/AagW1Fd4vV09Mz Yg/SMHsehZ+DKDvQgXR7Cg/F9kaxBa832Yurx2Ae+kLxhgWWWXwJk/Q2ZCfJuAblSnwYm5Lz OGwhOHC8gdjCJ2hHBtsqBT2QF9/hZKRKVkI7EraqAUkYiP0mVio6mWCefS2GB/KiIznUL0Fp VDF124DsFfqynzvDAF+BN33JK/0BdmUt6o5iSrszrkQnFdWq8jFeVkwNw1oykIBKSiBXt2TS IC1DHfOi12tIu2JqVBL9fYSisumkYGilEzaVj9xwD2ASQRtZMpHhsj3IbYeA9spbSUCdeYcK vCRke9RynUJ7H4xpR97gFpUMzDb1CmVoFVpiZ0+kUqwMqiBJ+2N5xxPIu7apW3ZH6Z4It4pO 2SoSU8GyiplPsnX140dTPHBjUJxh9mQi3gO0TdNluFikBo44xGBAocb94sW2Mgeq2D5TzgY5 el8qwcSqgJgh5u//YV01lG6RJ4TUJK7G266mY29UKwnYzBlVXTLBElUSODrWNLCPVY1oVSjI sS059ZqYGNmcfdQom2rmuTQskEHLj+KQnbFA7vNTUDhoYbuUnWKuOkGXmP0daZHJ0lHlnyc7 oqvNcp7bCgUDU34HPXb6oiiUPRZqoNP3xiPJWiQFPdlRbkZgVpXGY0WylGZoXxurLiiX+AwM o3Bc08aSIwkZvMJj56iwiwdYPhEp3cBWVdmeXpYOljYtyQZFrlmLHK5rZMFavBEcpHMUxW6I d1yyZJdj3XJGks05zpmKPlk2t59SXCGyVzcM1RVyXjUrBBtGReU6JbbpquJ4kxGMLPgp3WLn /VeH2JHsejD8Cl+rFUJHsGRlwkGF8K1pucI4fdn2ewI7Z/lNl53aOkEU+gtEVktYlbC1sViP t4tX+QQna9vtofFDZH1Vu5Js12SorkfgoUcqlo9rS6jQIWUHVFVNvgTNkKs68OoQ0cBVKDg0 uR3Z0k3A1Mv5siWiFhafpMrSHKxFVYZfNb4r9caxsOFZklOYZdKvrXHs4Nb5P0Us11gh9dd2 eEteYVVL5M0K+1Um/qc63ryQBKFC6s5hap243rglOV6frVWrMEhbGktrtRviGDNDRW76qn2J JSvuDOGU2pVeKqEydYNWGSSbml3BfRC6fNrEaLaKxO9U2UaTJPJmW1Awx33ZMdOEgu9qVZNc mjfVBOpEtItyxfbRF+jBn31KTu7tVr2m48CEWTS/X2irOvibihBiqPTTfUbJek5WUsdDdm3n xrHFNodfyBkbBBePE/5v37v8o3x82f3f1u92//es22vt7v/22i1+/7dZ3//9XT71/d/6/q+E 4H90/3dHu7sBLCNmF4H30lPf/63v/+Yo6vu/v/r933xhdgO4Av01rwLnesXA0s3j/2v3f3ud PnU9a3QDYqEo4lVvfUe4qEX1HeE/xh3hlB9uTsDgq/TdGsN2m/FOsZStKn32qodRiCI0RkNG 2C6WKx0ULmKenXP0A1e8eWcUAD4NNtZPbVM/HcCy5wFBWPi0Pbawzs2ARwa02K9LWF8TEIi+ 6HICIwC/4nG8WBIqYzrPj/Kbklc3KR0//qFORbKwq0pXnDKTZOdCOCbZ12AY7jsQPElhs88W 6u72IL28Ft4nKczu44gPfOxmtiyx/tMTPyGW8AfdraKEYf4MxDb38ogLIphdHcsbqYrgE1gW wPN5d1x9GzJKfCCfrFIclwHTYDl5/RQs7t7AMiv2YWEyR+xafu4UTXl4Oul2JQsUgHWn0TLE mzt8/rUq8YD/VXBfu9IreKuYpHJmAW8dxuVDA7ykdckbbWwoKFHkxJYhRTx3nLBYus568Ftm PSgQsJwH7x6LT42+Ag9LtdX5Dcpgnd9gT1DnN6jzG6SLDVLnN5CgdX4DUQ11foM6v4Fs4HV+ A2F+g4y+ZbIblOuskxqUulInNZDQ1EkNKkj+e0kN8gq1VdGintWZDOpMBkL+15kMxFidyaDO ZLBnW53JoM5kII4W60wGdSaDOpNBncmgzmSQbbTOZFBgb53JoNCROpNBnclAAP3ZMhns1iKT 0k34On1BHvojpy/IfJ+0c8eCf6ecBdmv3qRTZzH4c2QxSO1BKYdBbuuEmLaxpxE2bTqDAxRY p0N8iMbFsL6rpoFlnJgi57WEqRbYwVj2JlHDfVW8+5TYaGfcr+4DBOjQUcebnvcO9JYF19fY Vg+0qyl65aDY9QThkMaaa0OPD3R3fIh9dRKKOglFnYRCULxOQlEnoaiTUByqsU5CUSehqJNQ /DGTUOzC5l0KitwFnD9H5ol9/gee9eH0t2ij0ei0zrpdSf4H/knyP5x1Wr0zoGu2Wq3eN6j7 W3Sm+Pl/nv+hyP+nWQgB6tvZr9lGdf6PZqvXayf8b7Y73TN43my3u2d1/o/f43P66gi9Qhrj PWKrnPVTMAvvwhliLx23LuEtkJwefRsuZ4vNPEA/LcLl5stpcs3p7cP7EvKJm2YREi7DWPQc pI49zjz3149bieQ/84X24OdoxnIhJIVh5RzcIW6n2QkKeALfWZYPzTyOgvsTxH6iU9Q52SEj mkfQX1Dz5Ojo82rhx2xbcbNch/fsOt5itbyHiYJBr2MErXrQZSizRu/Q8edVOEevTiZJX7w+ dtQfj/at8/OxhF8atlWsINQQQckeZxPKgUDGwIBwGSM+SNbUbbhae8mMe8llx+Nd12YPIMDJ Qy9+fgpeH72AD0o+6zjazGIEVXjz4DN6BT9yeL4WGFEehYjo1dyP/ZOjX45e5GlvN2zwUN+b 9/Dnm/fLzeNtEP1YJAMC726ZUsKPuyWjgYr9efQaPfrrT69REEHBoxfhHTo+5vW+Q40T9P33 6JgfbdZM9zip5wS9R+cnJ9DH01fIfQigknkEA2dv29ezh+AxgFZX62CJFoH/OVijaLV65PdE /wMUHYoBD8/TN21otUxe94URMJW1e3wbrMM5IOwxEyFegF3KjFaLBazVwngdLO5OmD68eBEF 8SZaojdNSd/Tob/jfGa7+sZx43Xj5OQE/ZKMAHOuZRsADoTrmF1unYN8zeLFc9IWqz7D47TS rPAktb7ICOe/HTe+gFL/hYv4+/eo9e/AB85PYMGLf6BgsQ6SQvwhgJWFeaGjVDbQdvgNePwP prp3INhsUEdsztwHCHngn4+W/jp+5nHaW9QPZv4G2mTTu1rMUWIpeAFgJIgMA1LuhEtogl3e BNpoHoCw6P76b5sg8sEG+Ms5L7b274KnkL+nfQqW8x1LfRD6+AGMWhA/8LD3JTvP0XyZtAWE 8Ly5e956+RY5K/RzgJ7YDU4f3fsgSas7nv/ozW2wCKEjb1nZ04TTe0b/smVOSVAZ/KXR2XJl pwYZUfjS6L7m3wcQJ6blTjKsqai3W1lvR1YvY9W3ME/h3RHnlRs8goX3o3DBcj09cat/HS7n q59RE8Wr7V1W8Ar+LOCDZ/pakBOwrlCMXcFsnjAZkWKI9zxx+j76ezKL/4q4mKEfYDJ/TDpF QHcj3hU1ilZ7nXibSJW/WEPHGE2ipwkR23jnzL0FHWWywyCSKNauBj6Ecv9U2056V+g9eIc8 yrvnsOwZqeEpS8ReQcDAQbErRx02WfKP4+TWg6GY180TcDTHx030008CDoMP6oKN+HsCZZnI 6M85wvzV9+g/25yvTFi+stntrEM9zR7/thWgcsU/cp3Oe9QXTxG4pU/HLxlztrLx3foH3uR3 X16+RgdMFHD75c9RGAcvgd8vo8CfszLzCBrbSeXXWrp0uK+OuZc6SYadWre9cdvRbU1chn5n uSSjRJ/9xQZ6AGP76xJ6mrjCH3MaRB6C2SfuYUA1mIjBXxBR3gcx8m/ZfWMmIODfeKBQki3i 2hoIF5hXUOjvQRXOtkJmB+uYrcpzCimW3r12MeVMfRE0CaK49TOJiqxms00ERpYHc8Uxp9OU jv2vMBZW6LsvCKxowmA+CfD4tUD/uZbs5ybnHdksv9i7C/h2lMSd1+CufZZQLtWmc26bmz2m xf/F3pX3tnEs+b/lT9GAg32SQ8ndPT09M9ImG1qWYyHyAVFew9h9K/QpcU2RWnJoxcHLfvat 6prhLflMgoe1ABvkTHcdv6qurj7JbiDsz/vBPcaOIfkCn8E4fQm9OwQoJIJu9DB5FQTuTLY1 EyVE5OHVCCR6T30L+gBUh+5hmm67uzHDJr+9Ne1C+m3uZd/XYXtTTpXqYfrEpiV7AH6DGVOL KToccv6Bd1gcmIsJGmkCGpyDjOdu0N9OT3da292V9q1kkx2WuCfO/5LckzqGMfnPeSI8I79u FRQVXTMBA2643QSALMUaCC/JK2M8SBbcSLMhCYI9On7RO++9StI9eXVClv4oXNFgH8IVvOKj gEUESQmxM9e4Fe9RF++h+TntVj5//urZo6PTfz5rfIE9Psoc/mPsgVH00+yR/ZPag/qUr94A Usz6tMjyIbxnQ6nN+LX1qD/6IiAPZsTmvc3WxQhyxtG0Rgma7pZ8GTKKbXTclPCsOjXkHVB3 G7He9BqJfZLAKUfYJDFItn+bFRd7zSU/oOTqc1vVko0/Mso1Rt663bqfEeIaY/1FntE8+KB/ 3O4hbEbk/4GjfGz83RAObnOUL4+9XwgtynrwR4E6A2p0PZmLmL79gBH/7oyuc1cBNMWdBfzG EmvB/e4SH6aR2Nz7/eDrLiCtzv+7scvk153+/9D8Py+4ns//6yLN/3P+bf7/z/iDwWFjcra7 C0P6q+tpTfNzh6eHuxBPRhFGVSlGQysL5gpHXIej6/fj/sVlzbYPd5ioqnwX/ivZMzN+y7p+ EMZY6gnezjeC0WC6YgoJ+T7Q6Ntp2imJw7PpJHTYJMAocEZxOKrxvEV/yH4b9O3eJUuDMxgv sp+27++w7479fitx5x0TexKXLcRDLh+KnIlsX2b7ecHe3ozY0a/X7LtUuV0ZePO8++z48Bw0 Oz/rPjo5ms/RD0YO70VNwTkx++Er/SEQZ+kec9CfIP1bwgJGnwynrQdhF6MDTTVM2PYVzm42 N6+fg6LnNdbeSSjQ6sPymsSsyH/IXP89RTs2m2bj/KSDkwoFLzJe6fQlBB60kC59qSpe5cKa 9IUX2jslqpNOIgHN0kRVRqpV6czkWU61glZVbjKqFbwty0wSp8o7WxrVkAjc56ESgWoVXvqq LKlWZbVy0lKtYEXhrCdOhS2l50VDouI2Cl+J9E54WwiIJemLNpZLHolxzGxVCEXES2WDEj40 JITxxquCyGvvfVCBGEfllc1zIl5mPitzVxCnTLuqzHVDQittTekIzui1jFVBoJVG564KBKdQ XOROEWQ641o738IZDY+Z1wRa6XnJfSQ4M6uD5I5kV05XgucEmc81VyK0cBqpi0IUpHHmeBaU J9mV5aCKItm95L7MI+lrcm5srm1DIsttbspIsitpZVVqkt1ba13lyUmMsy5WivTNpIdCIWtI qBwEdwXJ7p3X3DvS2FgvMp9X6YvUvsq4IeI5WIPzzDQkXOkh2pdE3kbPtRDEWAqrItiEammb OSUJMhetqfKqhdOW1oNuxFiWXNqyItDyyPOy5ASn0xxMYAkyK7gNlWzhlFHHwpUEWl7qUjlB cDoBAnlDTmK11tJnBGfTRHhDgjceSQ5eeim5JY1D9LngkoAuhBVlXhIwXFttcxFbB482BmVI 41Da0quMNC5KXrjKkOw8ch6rjFy/0rwyZdk6eBA8VKUgjYuoDQdjUq1Sg+SSZK8EuLGrSN+g dZY7LloHJ5mIvHDaaaGJMTSCPAOHIteXGsKtIqC147rKg2+bmeXC5AUxLiUvI+BJtcBOTuXE WOeW+8oRZELaIlR5C2dpbbBlINCisxAtCoITLOCF92RukXsjvSI4S+ezwsXWO6OFduA0wam8 lVrkJHtmsKk7kt1k1nFIOsiJlbUZD7J1cOOjyRXJnnlfVrkn2Q20N6c0wQnA6qgi6asyXUGM bB08Uzr4KpLsxuuiLBVp7I3mYGNyfaW4kr4gc0PSk0EzydvGbrhRLieNvee+cI40zjnPC5ER cVlwqYQhyGzg4OOihdNV3IEdiHFe6NLmkoCRXMcyt8TYVlp7xYm4g84hqKr1TjBviBUn0GQF hoOOnmpxz6tSkpO4whemtARnXtks86KN4DJYBf5DcNrC+txlBJrj1mhnmrhP3QgBUxkbLcTF tpk1IZIcXFnhZUUaQx6eqyIj2SvvZVEYgow3xm97s8xDqy5J45BBcLaCZK+UVpktSXbutdcm I30Lo01uTNk2M8WDi5xkh9hWxViR7NxwboIkJymg86qgRyMnplbbhpyy4KWBBkluHLiABkVw 6oprJyMxjoWWeZET8ZJryIpdG8FFpV2mCyKvg7ZcB2Icg1fCFmTusvKZBH8gTtybAlRpG3vh vYIxG9WqbOUhElKtYEMAtahWAdYKiiADr+Vl8C2cDUwkuxFeVFlBsmelL510BKeKPkaZk75e WKuL2IYco60DpyTZs2hzDn0z1SqtzLQioD10lBJiPXGK3EAP4dpmpnmmTCSNleAKLEYag0Y8 REeymxI0jnnT2wodSlCybexaVzYUjfNbLWxWEjDWafAXQYwhuYpeGiKeg9ECSNg2M8ddUVRE 3lpuVcGJMXQHUmjbNNucQ0VJQLvcQgiybQS3oCG3kuCU1qrcVARa7mwGAZ3gdBAsYjQEmc09 h7jXwimhn6ug/6Ba1gcTRBP3KdUi2YPTWZSSICtybUxWtXDyps+mWo6DSxqSPViObYZkLyRk ikVJ+vImGrW9WW6jMiXJHqBTLowg2QsLDc4achLeIE2cpJdlqFoHD7nPwXGb/tZ5F6Iljbn1 1kfZpGvUsxFxSBFVkKqN4Lr03maRyIvoTZlpYlwKGwRkZVQLTCOhPyIHj5YXRWjhFKWFIWlB jDGdyE0g0GLk0MUWBKfWXENXQpAJjL02b+Eso84raE1Uq9QSKBCc0LnaGD05iYAs0UVFcDaB pA05vuAQ0wLJrgJXZZaTxlkFQTFzBLQBe0itCRjIpriAzKZ18EpXqlCkcRYgWBSeNDbBC20U ye4h9cuNJ9eHeA1xTrcOnhW+zGwkjU0F6oacZPfBWkh+m962sNLFgvSF+JrHGGbpGlmOyDtj jZMlMc5BjQr6PnJ9ZZXJDAFtjefQwtuQ4zygoStinCvoKQvZpJqZr3RhiTE0F10YSZBBZy2U sS2cudfgAJxAk0ZHaSuCE7ooaI0ZmdtlkI0HQ3DmhkPCK1rvhKGJDLH0JzgV8xUHij+kZdlm OPr4hdi207iDozsY0s3HeNvb/WG9g0//i20/gCLffz9bFPo7PsNXP+IeqYMFYpKIzcgezD8t lFKzUnJWSq6VKmel1KxU8+mrDpwTHmtD3Uxurz3rsJVxcdp39oCBTJ35wzTjGobtdClt2YjN Jp52bfqE5q5nqAOiNCuNf83Lm0vcGLgNtNiPPwDQ6WE7B9vi086BY6ldKEXff5+xRkmYHy3U Ewv1fm+Z7O5iQXrYyLhBqt+/YEpwdf6PJiBDuB6PrvZ6X2eO6QPzfzlkwSvzfzkU+Db/92f8 QYtNU2rLdv+YmbV7LG3hWK7YPDy7HF2ZCXs6Gk9qaAH/Wl9e/kT7eN3o6sf1KcT0axDp1zDa U/0T1n3Y22vI3f9Kfw052kYGAl+MzRXuAYzjENhkFOsbMw4H7P1oittS5tOVgfXr9lbvZjNJ v06UcGJxnKZL6zC+ShN7+OXn569mP7b0cmoHfcdO+i4MJ9Cm/z2MJzj/KXeYmSQi11hickm/ uIjVn6A8vUYe9gSPBKcfk9i7TYG5pL7d+nY5uk5i3/QHA2YDTrXG6aADUbFmr4/Pnr54dZZI dZ+/Ya+7p6fd52dvDqB0fTmCEuFdIDL9q+tBH6iCJGMzrN+jhs+OTg+fQvnuo+OT47M3bJSm e9mT47PnR70ee/LilHVZOhZ9+Oqke8pevjp9+aJ3tMdYL4QP4JMopd1UuPvJh9r0B5OZ3m/A MhMQcOBpA9A4uNB/B+KZNIP8EfAb7DUSLVQVSs+BPMDIPBzVHUabierRncbosOOh2+skWnmV dlJCyH45wJ2Su6w3RRKQ1nTYo9GkBns/6zIYDAixKzJedNirXvcPcu9ufRUGrHtWZYdKswkd N023GD5jcTpMvz83g/S7k9HFhtaPrZudhnf95KoYCzYGA4wGWPJZGF+AFfCwAHbMuKdfSjap pzFixwtAjqfDt2w7An1Wm4vdybXYaUVYYAOM9sScFVdMKGQlEiss/BIvnlrgQUGDOOHe3xEb mxt6uyv31B7fwEUuceDVPuf7QrUcumkjcs/E8BL3FSfSHyFqxqTYz8p9LltCDx48YOAU+LOn owt2FSYTcxHw6ToxnQjxh1w/lAXqnMl9AQ/ry7lEuDaDe+Tg45OXP3ehZQK5ZMemwOHi786w 17gFrv0VgTWGectQNQyF2FcAAYCLJY+w+acWeNE0I/KN5hqsDXCoOUFRMl7uK76gQdMY+781 W7yXqK0Ty1aJyWo/mxF7ges1ZlJT2gdBCRO+IfofWP/KuPHoNpMTxQL9N5dg9Zbik/6v02v6 OalhuGF2NKoHI+M3iSYWCGUomiiSdxKhZ7h4c4LOx9LVNEhxvmmdqD1cPeYC/9aPt4zDBaTc tx17mZ2JSdvu6WdU6ZZ2yGch27p3n7UJ+9FJ9w2eSGHi3v0wWC8tN5fOsDSE4/uMtoFSO7Mj M/b/Ntv/en+x2nAbQmJ9db3DDth/3tsa9LfgS4cNAZY5WXwl8v0tOwy/0XuRW6qAVwI2j1Yo 53w70W3YSGKzXAaUXiqkNhZaoaQ3FZIrlIqNhVYoVbfItFwqa6W6R9vI2fQ6uQjkGrSDYnEM 2Ds6e/XysIcEOq5uUb0hiIAuDFtw+3GPXUIa1WG9Xzq0TDsY3QAZKg45C5X/X7I69QLnz7q9 X6jAaEzvl14f9tK7yRKv9AgY1ofQxac4DqyhwdHhGZd+A6Rl21oNxE6qPh6BPqm/XVfz8Yvn R6taNnrhCRE+I7pB9Q47PAG18cKPT1P7VtWWVZALOrw2kEyhsdLZlevQhNl0RgJ7/jqsavW6 e3yW9MIL/iCpWtMP7HaLdnfZ5lYNFkWmhsb3Z3SXiOC+LfxhB3CxefUZaMtFE7ipwEKbFbFp s8PR9eLLRlEIQQuNerrwnOQS+w0EaDRzYSBlvQOHW6y5EQkyVUrfcB94k8I13Q3YB89cTSbT qzA/EtJuPce8mTdlHgfIp0fvJ9SicKcCsFg4m7Vg6denj8DMWK6z6sPp1Wdo9nqOOVB5Oa3n W9dbYpPBIG2gW7FWqnnee3r85GzO4bZyy16W/ks87mghh6mZX4zChLzXRESwfnzcQ5vz4WS5 /WBQngGy2Z1P7myRxA86+fcNw9QAe7887TBw9FV2i76/Im1yNDAjkcJvSGmZxm1+doeIG9me XZr6bxM6fdZsXTnFUwvokJQA/8Euefp4ySXZonDp3UzlDSb95IB0twUfo7S4W+596ywvH/Nk PfYh8/0cNjj+p8Uzcv07o9pkvLElna62pHV/+oyQdTdWT7HDazz8hDC6E6BVR5vHvuH3gs7B QQAkT4NEjA7GTdJYuUmcV+NYb3sBMdfGBdlUXvAkyO7oNVFte5ur0buwtRpJAOCVolsUNFPf iORnZOdhTSx0K8RpqU9pn91bdvovlZ9azkfIBU1hxuljJd3am4R6awijqnSctflu6ntbzYkv iBFgNtwMZuYnogzHDbST6aDGcPAuhYOTo+6T7cUxe9qPuoPbR7dqvtY4fgbes2xSgMz5DuXn Ii2q4V/G+UwGyGeuML7gaTNs8lgD/plU4hme/wRBFo8/Nq6TCmJynsE/yHSrhlNjmXec6LRF iuZ1mwC2gv331thQZnHv6PnjTWpS55ocfTNezdZyQyfmkl7NjuIGQ0jc0rCmw0Z4l/5NfxLY LcimuaAvgVaWfC7v18a2eW1WXt+GLQYNysUScRRUpjU96aSl4pS1ik4ih3Uos4NvIoJZoAoa kqfK+GlX3IN07i6jtQgm9kdDXMd66PuTtCmSZtqgWB1c3VrL8H0w7A/LL4Hn7FFIRG6x1/Wd xkraoI+02ixaivM142mO6s1MLJdxv80sn+LTKPBSf0cjqvpmtPxLws1xyDSd9pY/fCs2638R ahcvgGeKxegYyDp9eQtq/xbGo/araL4m7k/oEoT3NI5BGBAlBbKbwdZaI2yUwY6ucYhfY0wu jUzecaIph36NYv5pFDHy4rdyjXg2XieuP4+40GvUFQxWV6kXn0ddqkXqWytodxJK6cDqAqvy 03EXd+NefRHu4m7cBf8y4MXdwAvxZci35JPbj6HXNkhwPGuUW+utsm1Gf/X63B/9t7r+i0P1 r3z840Prv1rnitZ/ZaYKvAtKZFkmvq3//hl/dA6frN7Mdh8aWrU9McOLC2PGHvJmejT4CT0F 13A3ngKpGF56x86CuxyOBqOLfpjQIhlj3cGApbITTGbD+F3w7SLCt7Xib2vF39aK/6K14l6o a7w7a3qd5Kdp/OYOJboULi35bL4B7rbb3OhWp3M8TbXpNd7T5Tdc94axBS8UWV/0uq7HgNSG 5+MRLieMxivUiI+fCM2zTRJguPt18/10eOvJ9Lr+vNvo0v9AI9VuTvqmXWq4XHk+rt359Boc ItBlQosFEvCT8+swPofG56jA8k63qz6u/Z5fBjOuz20w9aS5kwh3tgV/adx5f/w/58mC9KJh sExmrN6ej2KchPoAF1G6V+CkaaIc9BmHq4DLqaOra/RfPDgcjLtM3cPCFSnrBN10fIB71HCc i7NRDoni1dbU/mwaoQ/Dr3UiNWYgKC2ENpM33ZOT4+dnPbZ9nH7CmrN/ACn6LOAzfZKzT9ns k2L/ePCw+QwDrYXz1QOkm27mM+7tOQiZOK/sHhyGm/awPZ21TdfHnLvr/2vv3/sTx5HFcfj3 L3kVmuxMD6RzsQ25dDLpWQKkmzO5HSDdO9s7Dx8HTMI2YBZDLrvT39f+1EWyZVsGksn07J4N O9sBu0oqlUqlklSqstpqZzVfubAwAzroqNq6QtBj2FSoiaA9oZUBqkBv8mMyoAxwm7p/ONQD 9zEJ/h1SRjSwxLYBOq8eHyQC52zJOdOD/sE+wvO+KeoyWCt2vLGManM1oSR0tzx94FRDszwM apqhZScoYQf9OMJLm5j3yiV14E5QdW2uqEBueH4Hf2AheoN52Pq9HtQ/mvIMgcW6g2sfGHiD Mwxiwci8hTX6A6vmiX8FZhYrEeoSNrWJjHZIRnjffdqmyIpr+C/xBVmIInModg/4V2c8g1/B cNwOdUC7383zTXIYBR4WmgeodUSUF8zzkeyLb8LgbeSFmcvlPpO+AujgE+D98gm+/fL69QEF WfOZ1jxRhIVRVKX3fbzK3sebo7ivA3Vudfyutw+LilxuTWDSMho5ePPVfRCB4NEPEjkGqu83 ceacPMDqRkiMISihqRfA5KcC5QHqjX9HLOb4igE7FuC8K5Hu4JWnnB8+Q1dcBf4AigHmBzNg Przv+jx5cf0KD7oL5v9tywJb5MrrYUdhPWs8UEEL+XxgMsGdU4k0vZlx0LWePxj4dygr2ORN iiFI/4jaPcohzcua0wDQTTIL4yQkpMsIYPwFPl4IBgGDMYK9AyDA1QEaiVQvRkDkCIvIUJpZ gI5Xotkqty/Pmj+fVTgunliRsStfvRL3ZNROb9uoT9+mVPBrsbNjhicF/AP5UaCp+VrkMXke elXbMnwM0xIb1HptBRUIDj9p1a+DknipIAckVNBXaEDSoSj8BzTyRuDissCS2LGsA2rTF/xH ambx+lDX+vgmphIlmAw8KD2P83E1VaCAB5na8fKsRc3dULNBQfyAlzekj3IhCsgWq9mKxut9 f6oP1yia5BHoprt+F+yvQX/YJ+2kQu4lJr23ckTTNNTwNuQuIYUIrL4vVwTMEYQrEtPlxsYB PsQiv4m/KcioI1wUPs6TTMNk1a40fqZ2hRHPSCbA9kNkjEUJpGKTKFopaBD5Kl+QejwMkYkE XnkBmN/uwzp2/tBzceTym8rFJQblhcGCLu0uun9J+wy6hHIHsvGwKS5HMOams5FLY38qS4dC EbOPzmMd3OdW1p0+NgOY/JlTKF3Y16CzZ8BssrG5FFAwvghg0K+LGw/B+3j4hFNBF9WRMhGx 34x2Agxo7HmQQgqYG4tbEgOkYWF+RXaFFq1GRRs9xl1Sj7QiNaIEGpKknfM5ugYjh8xdNnSo iPDwFRVXZPXg0N/kSi5l4FLS6z62pzMb4DDkqmR4UEUaW3FyRkeOQscLKZrAXlavAR8IQ4mb ZA9p7Qr9TaQihhqDm34v8kFRSApHDlyqN1GxFpNSHMgdyCYqduKUNNaosEVmEAz0dQ7U+TXb uc768MnNpRYClYuVmNYwaXblGXlLvP8rjVx2i1tWwmWcRZWb4OKy/aFRsh0rtOrkruO1hyTN 2jf/zBegrj1VH9c2H9iJgEkRRRFe5XDEo2vONhOId9BosFlwx8LldavqIdYB9ptda8Oy4T9h Wfv0H7uYkosCHj9gwgiYmEb+ZAiGD5XSw+8w1vqb3iaUsGdt2M5G0RboJPwG/sMCDt+KB1i6 HOLrdTALR4e2gyd1D4dFGzSKP5scOsV1NIEOt99gUJAO/FWr3k/HUhj+ZzZA2oHT0ER3IvIg BjBU78B2mAW8odGYBUHfVRaN/cbepXX3EQg2zqmvQN6ht/peaPTYu9tAiTt6YAuFpin1anvP IWw8swM1GExxhwRKQdvsCgwsf8hnejNYCkORBQ47rRQRYm5gq7fAlnhNX0pgUdD2zzqV6Xa7 YGds/hLuhVF8W2VLY7P4NCi27fMOTMMA1kqo40efQz/qj+UG5vLbZ9WvPL15U8eH3u+h0wJu JtnWzoblbFi7wtrZd/bQT9cfYQlDUHug80HdIyNIpqGkorMBI+YbkX/v36HFuo6WGtlhZKjx CFgHHCyCanMH7PGBQVDB0oWpE0xMWAHSYSuGWJbBtx2ruIfCZr8RVnHfLu1be4X40olWcYl1 MBkP+djFLmRt4q4XSNi6FoscH3Vxfo09QbFLQoEEJqDQpKNlCEzwFl76okt4Ig9V4OUuB61C VKn25qbtiA2wE+11EG78abHthpBghdnOgfToCsSxd8VezDzu+rgKC1B8xrRYIDRsFtbA4QhD LZDPs4JLmGh5FjAwA5XIge0aCt1rUdzZXQNCtoDG11hHQbxWihKh1oo724C7a78pvXnDLwpr DkbERy6hqoY1KW+l4YNAmlIAtIOlA9tiMHItI6EkEE7tCAWLflqnKt0DQJHWohViu427Syxm +C3bZqDtD7CLexPvH3r0eRIWdgHhI2+0NVV021MysWj58tAZeMEWU7K5uSlWac0drRQPdb2O 71QZ31l7g/v8d90ChcWNMNalfERPOHyapBEKdNaid2vv/3qQ096CmMCSzFLbKbQQ5xjCCgIE Qn3/jtYoGk1oLeKLGVhoD+K77uZ3ltMVp+//yaF7JdoWL22sdS2oXrxIyyqswRcFSA1Qy4lD DCm3aCKFzk60f7kNFm0xwl79BMsLvnyzZbXrp+tqu0jFCydDg6y10L2uC+IFwwnU2TiImQ3S UGCDnvcL4gs/jgIuRUb9Go5TNg40iC0QEVv7JeFoLYj4BRknXpb8+jWsVxR3cel0BfCfD1jJ LFskLUZV14fqn93UuuimhjmH3PEY1QjM9FdgGc9GI5B6cinyyCJGD4BvQDpo+adtQFn0YB4d MkaqcowLxBiU+7DfmfjSlEOpTW9sakNrC5oqeRAZWFFoaNIjLo/QcEsxvXwBY4FC98vNRpya YboKZ1TMHtC/RoWj9sN46x/3s3iNQ/PsP2bSP2c88O55Y4s0M01qnvg8ktswHBJcHh4oolxe T5A+p80CUF3YARjamjZnaPsNe2BTiI3pzc1K5nYqrBR7uMy/xp15EBXiVKj9EupNLeml++Ad zOCjB6nS5MQiacINP1rLsJkf6rYlbGKYFNQegdhIjmo1J4mwS5M9LjdLSatD48J2wQykdvzw AQb1XJveGho5P2J2DpDURggO1duNt2oogyo1czM7DqVOabAEpUgJlkbVY3D56a3UHqSz8FGr flrDSJvq+dC95ys1h+K0/JeL95Qthl95wdTwCoxO3jT4Pc5/zfe/h34XzODNm+epY8H5f2nX LqXuf5eKL+f/X+PDyvYU+1t0vaAz6Y/5XgvOjwFfV8M0DLiKVfvzE78Lf8Es6/mwBMBRQPEX KOwCftbG/fbIpeFoeIOlgTQnijnIrIYDI3JFoWIAXT+ZCjG+bd+OR+2ru4PMd1OY8UCWswFg CHujaQaAclbQCVYEpUm+BQsWDyIyGXObYEyClfhef4S1xso8CE+djlyY5niY6nOJVqFKVjW9 n7Zx31AO6k8qRuTq6f8KB4xC/Hsx8fFb80I42/LLtiW/wOANH4Vfd6Ovtvx6OcI5crSKcVHU ud4ZJcNqn55XaydNkQ/6/wR1mk9QVNiSz5HstcIGJuCSrbxgZoAFPnav+gNaY+vNTclI/IFs a05mtII58swfbeAa12Wb8F/ULWAHy3+EJb6s41wKX5A9uQVQtmDmhXC25ZTW8Q/9E8I5glgL YEiEENtbAu+RhkRs2w550SHadoRWFMR1heZYW1yqRHOsEu6lOBbjhmglwd0yn/p7sS1kpy4C 3BGyyxcB7uYWQewthHiTW8BNWFRj+2zbivFzITttG/GKFgDqHNUYmoXoMGLRysDTO8KJOsKW /ecoPEeuqBbhlRivmIVHiMi17XWWI4m3zYxxon7KANxhwGIIaBAlrNjeRcAdmMBRe80H3SNQ exnQNwTq6KDY1Zbqa6aUW86y7CwBajNoaQlQh0G3lwAtMuiOBI0pt4tGvRqptbjuCbVaUkcV IvVW64OKDr3YMvQ4aktv1B7+g7TZanSdfPUgGzoYM3RTpkdbjdxBjDNP7KeHZIXzxL8iCkDL 1+urwAjmjQgFUofAuSSEsBMQwRggYI6JynBMEDD5RBBFEwTOSiFEyVwGgkiIbRPErg6xY4Io 6nTsGmuxtTL2jLXoEG+MbYFBoyDsJE8lHU4EYeQpaqcQIoOnWhlGnm7rZRh5irolhDDyFJVK CGHkKWqT1Ui/mCB0fhh5irpjNdImRvmIKHWMPEVNsRrpDiPEdgRh5CnqhdVIUxj1Q7tWr5yf pbRENNJSmoLHpK4nRv2pN1Aue5ia0A0SymNdeOx3wfaiqFf5QFYV8TPu4VbwvHP0MEfRPHRC RUMY0gDLVDUAr1RNAn55dUMhRvqdhMIhSkAVn12enJgVjhHCTkBgN8UhnIUQxYUQpYUQ2wsh dhZC7C6E2FsI8WYRhJ3kaRpiIU/thTy1F/LUXshTeyFP7YU8tRfy1F7IU3shT52FPHUW8tRZ yNNMhfOudlZr1CtmlSNH22KlczRwO5/FkX8/R11cXYXq4mPtaOOi3GyW39UytQWAK23xYaNF C/NHaYqrK/8+oSaIgrl2iYLItkuIrLl2iYLItksURLZdEpWRZZcoiGy7REFk2yVhLZl2SVhL pl0StiXTLonoyLJLIogsuyTiR5ZdEkFk2SURpVl2SQSRZZcoiGy7JITItEtCiEy7JJKPLLsk gsiySyKILLskgljCLjk6Ov+LWUfgOJujIFg/XI76zZvZ6HiOepgFvVA/ZCoFBAqXK//z0bI3 PlycbR0/SjFAGQm9wFXPVQwhSLZmYNrmqoYQJFs3hCDZykErJUs7hCDZ6iEEydYPUUWZCiKq KFNDRC3KVBEaLVk6QgPJUhIaX7K0hAaSpSY0crP0hAaSpShCkGxNEYFkqooIJFNXaPKSpSw0 kCxtoYFkqQsNZAl9cdk8NqsLKGaxOYEHsXJtQmcLutqI75vzcI89o9jX0QBfja99Vtdz6VUV yb+EpuUTQM0H05dIySKl1RTChsZREhBVp9AKVVoyVTswTUjAGK8/1M6q541oVynFh5DVsTfI 6aec/yTP/07dz0DJwHvOM6b5538WDLhiMv/bzvbL/d+v8vnTyp+E6vPQ5VYGVR17nX4PhJ7v 8/F9oR5eWZR+E4G80koBLzdX/rTi3WO00Q3/6u9BmCmS7w/6Kyubzc1gfyX3bb5ycVEQ8Of4 pPyuCd9+EBu++HZtM0AQn0EqOsRGJwKCgs7brXLjXa0l9mUdSB+8gGo3HnL4lJxbNtG1dTob w19yYvEFRbf1dbra6LvpAzJG68nFCJZJ5qA+LBeIYRfeahM9YApC+7xWfjGShhD2ol75cFlL wo77nduZZ4YFTXteKSRh6Y5TihIObgJDq4CQ0c1F2cB643/DtsrAvr6pAOdRBaz0e94/RD4i u1IvrD9gDPw5tI07feR+pw8PoAwjrJOEdQhWugSqu5bf5lvnF9V6o7DVmA28YBMvPP2fD9Hw u36S+l9K8rNGgFig/6G+bRX/YdvCXAB20dl9yf/5VT5g8KF1VmV/yaY3RKMIrRR/EggUBbru woGahdyBPqL7A6ezyfjmQfxwhb82h/Trz2RTUeAGoaIdyysQ7TaYa0fNarutXZ2WDufGq9rB Q7A1mg0G8adxjDaHSeYr4xyv2HgXfWEc5eXvjne9gfvA9cWDIFMQQnL2qpxWKdOQHso39sYK 37Qa9dPTWqONEPyykn75oXwCUwNFr8X0WmlkilJYpEtl7z9G83Z0pUlFfddtbn8AfwdJ7/o1 vgB2jV6+iTcFnvvaIBAYTCtan5PDnMTjaF8JVLwyLdBdTisdnukJsRN3ymVh5GhKvo8i7RfI XrmqyOiiNDyfXzKGh4uXbiw8dPxdy6eZhV7na4W8xhIKGAl8KWRSEvJpNAmmbYy2GdUeZ1+s /Zj8XGd9s1XILnXg3y1Z6Cvx/5YplZxJ2+TUmehVypVO19Yx3N6vhzqRlZOfDpL1y9zquREN obyzbfFFT0rNm+Ljh1qjWavKwl8dxohFkPBulKF29Z7vZZpKWI4+8VqV+v7yXa1NQTjNXGLn dizhqj+N302BBwb5kiEK432yBDswiOyh+Ab+HMQunlItuWxmqDvG2excwI5MbuSSUiIRDSOQ ctfLC6Yhs9IDkO/qTF2kSfIpnxq3KMAGPpWrBbypbXrBetJAcLwTtPHLRGR2N4YpS/T1w9SL IhYg/bikyvfpHoHo/3C4C/++fs2O+2m5obhnr4R9Qr739OvtW3X9J5MMjB2XGJr4aC4dRXsu IRSOLiSEfpkIMSlt6FkiKOxWSUIuTaG8XZG4/UuXPzmAyVyqqYRfD9MCVRA//MDFIPH0heI4 RDeoENXYr3jTqO2P4xo00taF9CiZq1RByxBKOITMygOGsblSVObaELT5Jg7fHo9W42vJPGn6 LY2M6Y05kNPbrIayJtsxk4auvHCvxXtaIcpmaOMn5DO71EeXSxJzrYp/soAc3YyKvyY6wngp MVrStbenk/4wFgsGRRQfqlgwC+jI5yUwClrMCEMBSFttdL/nV5FPGHuFhcTKKKlRJxoaoQqt 1puY0h7lLl2QvO60VDm14/LlSet3u3Dw8vm3+pjvf8Q2x37zXsD89X9xp1S0o/iPlgPwOw78 eVn/f4XPlpbEj3c+OysvcRlf4jK+xGX8Q+MyNtQJS7iZI1uih+2Jb68dnZ+3Ts7LVZjDtS22 1SEYMoP+VWfzZjW1RbbERphp/0yGcZzi/XnTmw5ei5q75dYeTrv6HhrYs2feHd9nSl9D42aq BsVvKK6iOU2Xr/g5nobGTnj4HtWKdw+De5QM2JJOKLyeTCO8jtYhWvHI6RGymg8szmqV9uXH eqOW21r7FxCINiRHmsfr6HHbcuwHqXI5fYSWlTi5VjukNQ+85DUP2JCE8/p1eLSmBcLOQxUA pN3IpXCBEVEf49tyT6AqEbSeL4hnkZpOAMAUrgvZCEROlmin6Gf5AA5/IVfmeDSd8JBJ9sAW pgYcPOBNk+8Diq0HooTR6ZSvUBhCD4ju+neja7xFoTJjrnGmnnNQS48WQ8eSghgGfASN3e2Q DTUc5/VLeWN3ioK4HrupN8SklnyfWAeFjpbg8ZuUa0N4QzgcJWECj8frnZthKDwHB7RGxkB+ 7fE+9AcA4EbmmAMa4oYRPTkU3//N+r4gOPgAxZ+rX48oZCMGJANVTNVwAD4dawOQrn3QSVwF hTVpfu6P8U3AAfvozZArR4LXhnrlw6jyiUrOwcFRuMUUusC7v3HBPvO6Wv1DQ/1DQ/0Jgn8E BGAhKNWZR9AfZQ/pwFN/Nh5j3MibcQEjREa/hwWdTg58EAoqVT4LM9t9iUkCJ9CEpSMnc2j3 +t6gm4/pLDkC5LM1TNnaDjdXt2RUoDCeD/JnOObcPr3+qCsDESQzRVDIsjBe3MUGhRs629h6 t6GGAYfi4nCaoeR0cCxjae3u1afOL5ud3jU+UJsuHJ3im6R4K+hxe+Svh/RvvKXYFO2xO5mO fMxT/2qFwy3OKeI6VYTfjUqQ8Rej10DfJws9g5I0p8HsNJhNYJHGocCJ0T4RdnW8N0O1oToN p5eMLczOQfLBpEPX+bO6vj2eeLvCH3SxN4beEHdKXsHPdbwiKZ1+FmAXVEwUmVJMKjeJBWIU S4mCm8r18zOUg1xyztwc9FX5szE3WYXPoI1ALfLKTVgPzb5YGssSb9x1fliSdk3O8nnWdAVi QKEA/SUOV3K5dAqIfEcPRHLjdT5z2MRGhQgBnmOv00Rv3QMf84kZT9awLiVzSVLBOizJqLIw ILASUBdQzibVJMU0rjCikJb1HoKG0UiyegWaMcJwoKgJOxy/TXXkmoyASVWG3XJoLoeJQZV3 8yBgrVEXHImV7WyNCsx9S5o2RjgHRPtXeNqAktkZP+Sx6ps7zFUEXJ0jPfSTAdfFDkfP1YrQ VcTicuLQOwU1oSRL+rTzi5onUGoy6nu987gaX4PNX8xoAefZXrY8BW2XDMWFCm+Z0jTgJDvC V/O4EQItx4wIPIMXALA8KzRgEyfcILjrtm/c4GaJwnRgW8oZDw9yOj1cWAIC9nFXnNCmAaiX 3hJoDKihoXrxe4C6BKaEVdhkKatolYvQMTIFrIgxdE3Y2P4Yx9kSyAyo6h150yEmH1uMJyGp wi2V2HvqxXTuo5QuzNKPUrlMMKvZQ55SmZQmbib0R0ImURxyUsRcTl//mEjhGVYFgl5+mt3a 0iwFDs4eX65oZoOaQXWjYWkTcP6q5xH2BI4rbq0q/nFmRXDXh8UAxlxVZpWcPGiG6WBEEntf fnHUl+I+d0/rxgtkSC/sIR724YqMcljeebhl9304222mZiNZZikssy/jflL8Jtpz8q+CDsYC Hs8msOL0AllIbKIU22FR27Koj9HIAyWARHj3/WCqYcfGpn2QKnMnLHMnajIuo6+nN2pTC1Vn 2GbihUxdL+tBMeZ9nvg0EVPz3rQjQyz6tzpmeRDAWxWnrAuKECd1qjJdPcYoRJNnDVNyw3LB xVhhtJ2GXvDjm/7AD3z076KeSdIuMSeeDCuHi9N+F6yKrlidwELDH9LZ+WpBrjGUNRvJHUaE cPZYSxusebLFDea74bnzizotVjIevVdmR8xWidsg5sUKo5isDTM8zbA4wR4sKhnnTZMdUpxL lRKEtL2RmDeNCyeFl7IVjNCL2hIzAQxGRHZLtOk+ZSxkt0Of2FNmgZrpdZ2E07g4FNHkH29q OLNH03wKIJzDRXxSjwNqM7CEjJREgqpwYo5m6XhZ0RSsTchqbvsIg30WTGlwX3vTjCW/VAVo AGbsOqhZBaPzy6W0butT2oCY6CEf8/nUAH37FuZi8QqzZPYSghQpxF3cNGWNuCs14uUYFQbF jNZVO41emOPc2WCq9PENBpR2cceWwkqpdcqPhhVKIko2PozNxF9WaCNUbRD3dfsm7qcSW7Kr LeL0s941qBG5fWC4rcSRzm77WWG+8O04/TYMYgVvMYog7by2R3qoLOBqLKRWYl9QbiquAVoi xhYgJp5oFTDxXLi8fgRvTZey1vrt1H0k9OVMPtMKRyHioukWmb61kbQ19X2O5Luvt7GhJ+ic ZO1vaDv9RptygRlN9uYy1mbY7KftbCwgY/ldj/iGh9zvWLRWINpMWyFcyuL1GPfKN+Z9DVjK qh1JS7w1mtivFtVRUAldVBDdSyoF40JrPY5rCSSEogsrqr6jVAXar57bH3jdbyjQslpNCD1I N54jLdnmda0AY9sPjKqbS2dPJZ0PBTWPnP+0rotzNHpwjylzBD1uCFkqe8vWlmnl0qw1PtQr Nc3qptxZeJ1Sq8vYBiiQ96DUVhTv+tFO9wVap7jFrRYWvszHoQwKUxukMRQGwX7UbovtRGdY pmI/2WSZ4hmHtv4ywUsT6HFkJJHIfjKSw5Cf7JJOjmRbvZewI8hQoHUDXqLDFF8zSnuCaerZ lsfZb4mNArYUDgjeXhLe/iXcUmVh+Wi1q81K6+eLWh6rpUMZ26RRpJEkI0bDTNrvJhpGtKsV bFh6s9oonx6Vz35q/pVriJay1n6G5OP0BfoSRf3e2rNkBPYwgHe4Dl6ILENfp5CdZZCdDOTi MsilDOTSMsh7aWTNdluALfX/nI4w9sPjmLt2KBwzeca6jy6bzYtarZqq+T5TBq5mQfvmn7jq tzJYCd27GHknEzlTBjRk+uwakDNlIETeyyY7UwYi5CJ/DMjbC5Gl0MerNnZL5eKycvLTIzqF c+Lo50QmGh7TU8uViHk0cjmjapcAlDsO0zws3c2PqflRbc2UjeepcVlePELunpOw5VhlEEe7 TTnkUBrt5aSRMsmpLSsjABiaQgEsK5FLl2o/RqmoUu2nlJopUapU51GlfllRe6cwxbGnm3AH d+5DQBlyauVqPTz/1HWFZiUchlZCZq3qMovZZLrp99CUDfv+ff34jLs+w8bqB90YQr1ZXYDQ 9UQMoVqbC3/THXRiFFVPKnMRZkFkkodYl01p1ytUXusOcK+YZ84tg+Qfw7f3zfpfaynpz+r5 HpbYTtgqyxtJCfTSI82kBHqGiZYptgn0LCstU18ZG5+a7kK+454M5gEDezvgfEm4fGLmH52X G1USZ8sydzNXRmUcip+atXd2uVpt5IFsL0zdM49K3sE0F1B6RAEJds3F4dRx5jq3l6hT4qer zNpV0Hrkbdgj2QqCwUHWzSTuhCQuwE4TOAehF5hr212mtl4QVbatKqN90bQoOY8XJSsSpSVY /EM0aBbxeJ74aZU+Sf6e0LWW87t07Rx5t+xlaswU+KUkPlKh3B3mDYa5UmgVIzIXoEsi5cbi Ato20HwIG/NF8zZ6stSUvr7ULCWoMalxfqPULCWn2VLz+P7fXqZCXQu5MS2Etw44s9EJYkur Th7thLcAzNb5kA6hosX6aV0u1LN23/jUavEmGvn6ZA0gLgVbggmsxa+/GgsMoQoZjJlDDDYs ownhEeaiRiiXJZkpW6WEEcF0BkQrKzmTrW+T50tZzZCdkIA+IOeTrF3NqyG8XE8fRX3KquAX ZY9+YI+txY2QfHp7qB9jZbUhZCrlS7zFJcArw3GWkTzG/WV+gxGImgyFb7yVqX5Um1Qmm3pV dD3MDo45qPnEj09zMnpbE9OOaigdqbEun0MO1k7kqMw8nOWJE/3NwcPLO3G8FjxZzRz7mEPp 89U4mLco1RIxLQKT6ZjUXmE0H8SZSK0TeXcQ+JKheGjjj6L49wU+TxiPqadVn+hHsZ86vyzg RchDKGXj7TjsUp541UPkGDlWLsPVGBKWJANz5AI6g0qffMb75Lvu6rptrXX4SGc8vqXGxbMe cbMW9BWgAh1a/qwlOk7HifJqLdGVOmKUbytr9d31rmbXLt+nWKwDNejk9SG+Az/IOFHKCI0g XQqznBv/kGPXeSdwfHoS94cMj9YMZ9cZ7oTKMx2dwGH89Ed8iIK+evGDFHJLD6SzJUIzqehz N09XZ5wX/vorn2CZL1YUCuFZ30I3zgUsUkfuy525/9fEPjDe/8fQj83nq2NB/L/dXSuZ/7EE C46X+/9f4wOD/tt6dz8K+dlcvxX2ZhG3Cewta3vLLgl7Z79o75dK4vOdL2r3Y/GtvKUcIckH FZeDBZy4o+tr18XcvB1+NPgzChmGDkhHDrDfvHkjTusXTdHyOjcjf+Bf972A72YLUR4MBMEG QmVj3Hz+EAXiJUzBS5iClzAFjxTvugoaLLNPobCBgIzx0rDAq9eq3m9P/OuEkvmW4hx4t30S UVQ5Rp2DSgchMYIAqhA2RjbJt92/CvyBB41Hxx+VbzvwvKF0S8erAYoCrSZH1eRs2dvCLu47 xf3t3bCmU29yDf2MoazRJsSQBo4jV6NgoUNXTWajzyLPyebd641gbBcM1UBFm3ZUlQWNKmFV NlVF6U2RT1odMu421YSWli8m7h2/3XA2S5vW/MZADdabfcvat0uqhnK3C+VjFsCLPgxSKnoJ UkH92/vFvX3LUQWtra0JvHb8AEbytYBVUeBee/g0iyILyNmydrDNlr1vQZunNxFFUIiKD5uI EgH/T4eOwI6feNdB+g0HgE0/h1m987kHQ40CUbDnKNRKVyEoyXu/w+Ys34UMoCM/gx5y79wH kJyOC6Kzjx5P5CVlF9i5aNSFYeePvChYNkkeLznQdXU6xVUoqEUX6vLHhAwfBBr6t/jO7Ux8 WNa4oCnpUoVcuMKgwECRgVKpRIBCD+O4Apnts/NWm0DcUXDnTdalLzhGahJ0LoXjYhTi6hXA UtmHMTrEPTqqx8XLLqDYWOGr1jrUWkpbT1dPyfPUvXb76AGsE4kXnGZBSJ6qEqtC5/V1eauH dChG6mYVKIPHi2Dg32EeuxtvMIgqLxY4nDy0YYAzVH/0metTcx5yDmrARuI6Rf1Ulfu9Ht6B QUTqiCuY5z3o2EEf6j9qVkUwHuQx4AE0Z6PrDkGKo8qPZxNo1wTnA+arqgi/l6egvuTOJXTu Zzy4AyEaAJn5K5iyoEIqRE3ujHx30wdVeAfzi4/KCZ3pgCdINQoF/uXIJO4gEipZzGwCa1q6 ZAPde9XHtc7Uv/aQQqQJlj1dqicSRkvkyYxi1z7oBqdQoJaHopyj9/Aq16TyFduE2JAfFame f0Xv5cfKhfNTvk+hImANnQSy1ZclYB31paIaaWhY/ubOSqMW1Zf3CiO7mtIjYLcfAbvzCNhd 9aVR+kxBDycifycvvoFgFEI5jJSNFEJ5SQtlGiaFNnRdG2+I+WA8PEgR6weRvnoPFi/G7wj7 EytsYYX0+sS/w7fR6zmsD8ukZT8Q+vcZ+cWzxgMrZjgbTPtojpC4I65SOYhBqHcem4aEinoW ZN8nMQ6tBjAW+9dgg7mDTeVnujmFkQF/Am+aQ4ZC+5F++Rv9UTfdAfA6t72SA2OwVavmlX2x Li5abXRYAJ08BrY2yx9q7fLJyUquclKXRUABK7lhr2PlAjCcKhdWu1K+bNZyuT/RDZv+5B+k xFa02wB4P5GUIRqNE2ApXfTxJlvcl2jY0BYIdF0/5+JdBiwZSz1u1y92V3JX3j/o+T+9CToQ 96CpZlgHqKCYn6glwUrkamEQaB3Duzw3nge6ypXiFCVxYNdn/9bjwmEq+rs7kNtIBNvWu3jk j/Emrl4plP933Exr92gHZfKPLDD04jA0DGBjJHZSMjYAy39AKEm6I1KhyVi3simhXK1Nv4Vi DJWOMz8sg4Ywe4FQ/ijXOmilwxTdvxoA1TQ8cYF2447HUpz78rqqXEEhN1E0pjzDeZopLEcv YY1hMroGExXmjrt1nIppNAw82kjr8dRIJXs0jSvvdVOLVnK1s0jYC79pq2pO/MdnSwKxIP6j Y+/Yyf2fneLOy/7P1/i8xH982Vh52Vj5t9tYeUz8xznRHNOhGeXuSTpoI4yJ2cAzBnp8CDrT jBCQ3dTim9/gLdslQ0MuiiY58owl9VPPsf0zPgjMCj6Z3RRTwpeMoJUqKymeO/GLXn8yRMlS p1qf7N0dvMpUrVVg7NTap5et2l/y7CQzhAF+XwiTocZBuDhyRgi8IZ7x8unWtZeuJDq/ZJge HuL27sSh4URyKS+jKJ5VPp/K/dK7K+DF72/II8YDQ/3qyi3Q6R0G6zKC2xLcsq4QoVsoRNe2 Vs/OzzBPNFH8mt0WpZtDfg0bgT416HWD53QDb5SHAsVbAWZDIXb9a/Xy7Kez849nqwexmHzI Cw6T35ziCe71QxQ/DwYS6wZ5Lur2cGuF4nDgqoUFUXij6eQBxpegq+MsN21iIwPk8bcMC0l/ OGrmGjoI8NcRkI0HvXQGveYPurcY5gBPH/GKN/yG9+MIYOTd6QDwE/E5ScDaGoYuhOVQeFEd gwfgkak6a9ZEJodRBiTBklZJINPGV0uJOqGoUtQIRYWqXtUr+2YSBQ6YjU11qw6YsCM/4nCR 4tUrWajuE2q85omI5tJl4RyVD3u3LMMfBtAymnEwU56Q0Vjxe7vrL+40omJd3YalTIhr8O9Y HdPDh7vhatbr4Zab6kTk2dJdIsmJd4msmmoTqngq9mAlDLaIMDQYJo9g/TwGz+WupYYO8XLZ YYMciI8Znf3w+9+B9wB663X+E3jfVAIdujPRmvP7gPdFXdbsYCbGb3IbJJ8L+O/j/iKnSfZR nuMo+Ip8P+d7aL46jAM9ucu1WGGTaYfyhhmHIAak2OJx2PDcAe7piQomMTIOOyjqD+t47ELV gTRhU7PEYSw7DfUetDPaVqPdFJhk5F3+KTbaiuLayFJ+YI/bqFD2NP4jpE3LasPUPGKQ0yRN zQb0qdwzFfWL+HWgpAHSlk1b2gKJenOOFRIB/S6WSLw7mMb/fBtE19SYJ9PUW9mD8N+qq7KG Z3rUxQbdv3kXG0fncn0b95Osn9VasZUfqRlZxBg0yqeiA0s+CmAOyzP0Re5pIzk2Myus31U3 YzT+FXXgFAtD3cfMljLE/DqH/iZlTSRsvOUUgr8K9Xvo3kNZ9IRqCF0280jUxttee+wHyHep QJnxDCp9vbUA27hImzdlaDMG1ioLwJK4tfjr7gZ5ksf3P8hWcxSffi+PK+VZgDHb18X49WsV 3ydLjqI4Ipz2ip594bIogDUQgE3vcLj6EQfQDS9yEpEc1v6Luo0FVL09VF6mSSkpbNgFIfFE NpTY4DvRRIQ/fuADAGpXEjY2ndESmxqc1d50c5HwlDBDWWG4Rb2bYalODJfz9pl/h/42uOnG wTvDQNV9mrlVKBYYCDyFY0f2R2136o/SrcZC1+I5KtYKeU0sC4g9jlzOM1R3dGegz+lb5xVJ NwCk632at6vfdTfVf6sUlSkPZdKnIC3E8Onbt0LsmZ7aO6anTkk95asVLBC822FkTShdaqSH YhR2iQQpyMFAojP1WXCUmKQbSYLzxHGiiEoNxPFMDkQcNesiDOguxbUgXv+meuMDT2kbUnop iZVPt7ZUlK+mtLYYDeT0uy7bhgqJHlEkLzkvb21pr5eZQ7T0JQIGCmds7ua12YTup+iGf8xq kEJNNzqWNB9Ir+TEYhMiBWg2I5JQJnvi39v2y7AMosBxSAu+IFZGAfQxUiEPryUuEZKGgSau Fbiig/llV2tHl+/KlUqt2VyqivhlmDUaRlFVC1RhTnEoHvNyngAnlikJo2UJsfw/uaeAyFgs dqjSBF3a79Kk6Ru8/zUc5+MAMM/QtbFNFvxVlJnVwmPEa869wEfUqwnSktUvvocVu3s1f+cr t9SqWKbpisK1Xvn+FKcweWP7IGmXN39uVlonoR6NRFK6utCVTjRloJP+xSOwcnHZfv9X4Ehn PNu4+ScoeePdIQ47FAYkxeiNGG3PKpVK6+Ls8uRknS7eRVIIv2MK78t6WOXRZZOrvJoFc6rk SETPUyUFiMUahyBuWfXBu+eprVlr1MtYHQcbzKpQBXvOCPIagWRSwtvnESX8W6MEz6zPznGc URTGLEpUFMc5lMikQ0+mhAJGASEUBimLDnr5PH2AkZGwOrfbz6wN3j1PZSe1crNWPQFDBqoc eJhnagAWTlbFEcTzVI/xlaBiDLuUVSW+e57KMPoTVIZBobIqw3fPUxmFaILaQFHIg96sOsMI T89TMRo9anrKGjQTk77YSVaWNhWiatPvNBIw+DQRwdvrWWTw2yUIiR2BGJpu2OIJBewCY1+g iFGs9swBlUqpsjR/+uMkV1JdAgRh/nCgQsaDX4YMCfocdKi7t6FqbTY/njdISqIY/MvQFAvZ P0flZuBI+i3L2L1JRaw9jM9QGHf4+KT8jqcpFbl/Gfo18KXp13Dmi2cfo+wukIQmZnfF2RzM oQ1Zsk54zEgydP3OzqP1QaOFk9dkSlMXb54uP+QAPtkmeBQb6g0a5wkNl3RyWRf27s6jZ2Bz ADUrKQtMg2Sapm3lGisGS1H3X1MQnXWxU1pXOQceVaJ1f9XrWOgOu7UGy4h7umUW9GV8YlUu j7nHtzhq38fy2UkNh+mdO4KpV1Ok8sFSHZkpIZJEEU5ZF+8a5SoaAvEg7AtGViIUwG+jKSTm w8VZ+6ejiyZKl4x2kTmPyPfPVHPr8uysdqIqlvEx5tUtQZ6p+spJvXbWUtXLKBvzqpcgv616 feputhpy7ga5nDd5UyiTOWpUwjzd9D4rn9aYGhnBJYuaMMDLHGokzNOpwcikTI2M45JFTRjm ZQ41Eubp1GgbUIldgQyqNJDfx/izvqx8wYU9b5IKWM9zWBJh57a26Cc6OP/4449Zq/wJzX+x pX5UyrrM1byq6AQFbm1vb6/rWwSCCBGWYFK0Xdk27Z6piuRVxzY3KHLBlLtdIWHtG1hqeROx ptUhn0W5tGOQh7TnFCueAfLJNgL56X06JhOvI+aNpBYOtN3o2N4JbUPX/nJx3oBp7OfTo/OT dPIVqG5WdAS7jOK6mOasNl6dmOZpi5DXyhRNBwBh9OoJ4+Rb2m6jO6pyi6JV1bLWYzjVHCBm bDWlQ//RWUB4EpcoV07Ijy6UNr1fi4gsukc2t6qz88Zp+WSpmjRv27lFHjeXKk5G65tbFPf1 UsWpAIfx8rTY/rIEKwagud1St3/JkBVQHCZRwedPkxUZa/AxXaVLhURfLBYyUiVJxhPlYmFd WqzGZQRjYXkyFOOykrGwPBW9Mls0tAQPRtlg7P+auEr/KZ/k/b9xpw/Lk2e7+kef+ff/bNvC O394/88pbm/vbgN8sbjjvNz/+xofvv93gn2Pa+TovtFFpS6C2RijoGwmLhotukr02ZvAuuYx 14JA6hLXlQyXmUwvr6c7JdveJuQVbssRR++gWBEjQVFnt6BRs0Hfpevy8m7dO3fQH3i+6Nzg BtidDHgx9UVw544JAgu7eph6GMTBG4kJrNbQaeCqf42GlDuSbJFW6ztYdjfqrVre74GZzN4q 4m+hBxZ91sBgHIBlCfYmTn1rBRljH3BpewFQ0cUFT56mPqzTi06ekwBrlTRq5WqsjmQl5L+F Tg9FB0uBwvLL1FtYiSxw6Ps2rxCoOiEs0ytqrrBj1jLPINCdV30/UMknee2QuJXED2k5o3ka CHVuDEXAwuNWrME/sffxUsDKjb/F5qnEybk47NUMjzGhvI23eAz3lnPZHiTBAKBN2R8IEv7p 6Y50UD60c6Kc5vJUKF1WevVK5CXu20PiU7X24fgsX7TXrQIeuKoyosxVaIvr4gokXiflM0/u wRi5pmjLdLpysweQ6Wa5urXuipEbgIDfuJ3Pm2G5WBYGceRBSQguheChJMEeWjgUYGXi4T4M wGKYhXVx6gb/mHm4P4Oe2ByRxO15Y4wixPFWVVyUntuZ8oV4b3pjISGrJ+UzYa9yXQAIz+3w ubO6iTmOYcCN8Ua+K67RPQJajxFiNq68QR8IUbffkcURh9U5O/K2eXLekuwucJxmW6YazIUd GPUBvC2u0+/jy7OKwqNzfuktNqfc4txynaxyOfS1jGyNi66BB9LFnRJG9KFwOtjSUH3gGK+f tRoUC6J9fgyL9P+Xjz07hbF7BKs1q31Ub4lfNW+eOG6r3IjgCkJFIm6C+I11v9R43dAYq105 fofHH1w9+W1QN/Dnhx9ScEeXzbPL03bz/XFB/MrwkltmeORWK4mRB66ILUwsa8Bo1N6F8EJi JGHYoK2dEV/C24yaosEOTSow6lw1NI2cqJZbZeYEaRYR9zHUUEk1L8TU83nSJWmXJAHvPrgT DD3iXsGcqzomLDMhE6iEVBvz/Av0z1w5mSsc5MWi2gL01Shau9/BXOpdDsiivWVZDoXXyL4n CPGyUpxKJxrbCpF2wEeVTV6J+h4pI3sH6aZ8yYGMfjV42BSiPoJucLuomOha+pRiwWn3bVxR dBQmR/Ryg89bMpQAZ1yHLgZ00IczCgt1546k7ZQ5Q2L5appEWyNvmv74WhDMdGK2J9Zu3QFO bvqMhDUfWkrg583BiZl9XVD5VPYrmjajeUrj8UoOa8WbxdTGt2/lYH2F4bpgsBYLhfC6VNgZ UNVR/bzZbl5SfceXJ9w7S/ECmbyIF9CTi5nBZNra1WNF11G5ilql3mzBYh50y1Gt8e/AwWV4 uBQLu8vwEM2lJXlYXJaHud+diQjyWySN/dMeNezmMEk+Ct/9Xo2Xhj1L0CtQqCguKDwpUaIp VRaRR5aZgB4p7KTYl6b1ifIb65gldcBzq4A/tDuzO1T8sT36PF26rE6SffoU7fMbWYA1P1Gm w0b54yBiAv2iM6n5M//6PABk21yArhEipefmQywug6rBE7I/etvq5fNMn+T+b4Crw+fd/l20 /1ssOkXe/8XcXSXa/922tl/2f7/Gh9dKstf/46P4vwSaewk09xJo7jHizSc/4akPK4JHnvdk neoEGNx+znFPqpyuZzgF6oxn6dMf9HilE+rUm/7kH3OjuIGdOfe9pCD0Cr+oVz5c1tJR6aD+ Xt+bUFlylzcyfjEeO6iANl544EPxhK95o3Z63qqxL5a69ES34iZB+/N196p94/ufycvqIPY6 cN03u0VLgyEXpDgQnb6P0WdPvdXDy3hDHww6cupi0rSXVKw/QuOP32n3sfAV9nTfHfT/6WHS QaoMH49mAwyq/ls/K//6zUUkClRf8Ko60BiF0lnbelqBX56NNlkgCU1+bTybVrFHKjfupEDe woWDZYugU6s8xgjUiuCOX7IEJcBxGT06+QmPOTA1uZIDuciBgUrLmmDabcvvBxkga+F7VYmE 40PASQdWZ0O6GPSpckI+NRg4UZdm5c5GTu6kn0wyDxKb+Y7uWJHs5vnmqYqQov4m4HHDuDeY Rhi4sk4wJ0MtjPud2xlrsfSK2B31O22cLKdqCay0SPuKYzjhDEPnmdQv8aCKhKgoHk8nhhPO NRm88FCM8YiSVsLq0SF5P+IqOgRa/YnOBMUFEoYRFMe3Hbnek1HqlDOpxT6HqkAMUcCvMCjj xYdK+0O9WT86qbVhqm/QveZUUa/476cU9C9UvK1dBT07b9WPf25Xz89q+t6CmWc6b/mJvtiO WA5sJffPlVz9rNU+Lf8FlQLGq4OZu+uj8dOjIO8w832JhDXViSjO0u0JA3Ln8XcfrI/r9pQy udNxkjG0lwZoKMonzztykOuDmXifWQ71f8wpFcjQxwXtheXUXMdCXJg/AeXIIVcGwVhtolcn SgjNEdfe5G8jyv7J+QGBxWAo8S1NUd86pyQ7ZITxlIIOI+sYChBMXZxOMN2FP+pwckAo4hwD /9/BYF1ne0qZnF3Mq8JBBdGQapbLONGhvTobq6Pg2NyFEWe0+UrmQ/Wm/Lo9nbjjwNDwd9Uj PChsnp/UdI9bLAgsHMwnlA99ZVekJxvPpXSsG0136pc2J4Lo8YmURFcZKGV3jQfuFBg1TPTW vI6hGTto69ODnB1kCB94qSt+pa4IURkL2dgKwlgEsmMqFYs7uSaVIhtm1IXycBn6S9C4C0cq dX04bKHA/ih0T86/4jEavobFzTR0RNeGddQp0Dgl8aHPYvhkgaBzOwBNn3mkYsuHL0HTwH/y 97pYRTE7nE4fmquFAsa0JU3K7gioGLgIVfbrMIqLjqfu6ktOYinfW99TfAjtic3xhVSckp9A WPfFJWfhlUOOTMqtrne7hQV/1wHyViL/l9WeOxiQl5ILmhBUWwhpUzgTWRnHhmDjVNV/yBT9 KCyxz9GHEmRQVCszFV0ZxC7AxSpWFMV6IMgfhQ2Fsts6Hlhz1aFTRy5m9eJLDv6iCy5QmhgI BKJLLoPoTzQHj38ptxlQEikj2lidafiY6jQNIoKLW9O2plW+rDydvVqHr47pXjVGSRl5MDU+ +LOJrrXXDdxP2P+2jOR0FOq5gEMvUhIyTgWTmmc4tfKXJezGnLIDD8WrmLWoXmy8TcyoCGmc ajNxfJWy3oTnS4/2RI75mDkZesawCzrldcMZUcvkwel4Jjii2FWbEq1zQmAMgeu1O2OrzQmx 8k10Vqh9WGeOx+bW+BRAkx7Prl+U20IFBjBv7vDMLfKUKOTK6+EeR6DmZgytBMt23D/guYW3 JQpJd4O4pRAatDztJMMSaXELQA+xpdkdusRC0B1sR8d/zAK0ltk6aN14uGkCZPLdRhRavOvo WJaMWE8MUyXi4Ze0v+XNpNMy+SNCaVFVKajji3dJMCZCg7x4/3MTXYLyUTnKfGVOYJg4epcn hW6hIg7p+iaylbWlQ8QInQ8xCrQ5ypRlGSk6PmllZ2CmYC6ZUSKiXMiZOZbdbr/A47k2omtN YXIx5QTT6w/gicyVvooee6scmi226FnQEHmNQnY6ex/eUSI9igI3IPsQPQujUcLkysekb1E6 8gcHMAN8oTRBntqsG6EnIiVhoiJxK0oN3vlXnvBn4eVs6lGf5PlPHzPibT1vHZZVcna3t7Py P+OHz392S0XLtvD8x9m1/j+x/bxkmD//5ec/5v4/dT97GLnreepYkP/b3t0pqv63SRbs0q6z +3L+9zU+f1r5kzgt/1Q7rp/U6DCm9b7Gp3gn9bPLv2i360T5rCow1jwtpd7VGiuI298g/xV1 EEfPyrPpjT/ZNx7sMTyf7P1pZaXfG+HsIo+5VtQX3Jz6Nn8J80xhY+oF09UVOQP8VGuc1U7a 9dPyuxoAfZtvnV9U643C1u2QNuAUQLNVbrQIIMD8ovD37LQA/+r46FRzPfHGot3DGIPwqzOb io2eLTa6fxMFVVTtrNX4edmi2Mu+zZkQkgWunFSblUb9onUoNlpgFQadSX883WSDcmWljLFJ mnQfeNOHCjeqbVkcWX2H1n1YKTWvIP4G83YERZXqUES5ghIfao1m/fzscPVvwFrJ58LfVlfV +1Yd78yXTy8OVUuhpzzx+rugIFZWmKr9ZLtXVs6P/qdWaTUPhaT7c51yqvorK9DCzav+aD8H X6CKb/MAWjm/AIo2zgW8cIFFG02BhrYEBWtDNGYDOk0bqnR6aKgPfLwjjSXuczlYJVg63+ZP qtgXJ1XiHX9lHkMtPpUdwUMzvsM2fLd5/U+FuzFBuG//LDauFE3f/oBw1/9EQCQqd/3P/lhs dHpi4w28FG8BfGVFthMbmGJKZltT8iqiYlZWOrCaG+2DlTMEoRFrwEP5VWNRDAH9o6HLzqrl RrVdbrYblyc4KuwVtSsd1YdsDTaRqXH7yKz/qS+bz6VjFul/yymp+3/FEn63S0UwA170/1f4 mM5Bqfcpa3aUg5WPzej3JqmjdbHq3q9yMlWRyM8qUKCKvKg+da9hKcru9n2MTNnvPVAi7ChR MskcrRI2ES7Hi4yf2jCY6hWr/aF8It+I+CubXvHGNBUhQynIgDJaiZiEij4Og3ON1A7e7cDL yxF4m96z2k0+A0gug7H9ntT5fNMJVTDtouC2yWyEmcYpkUM31ciYbk8+pHJWoiyl6lLCxAdN gAun3gwWQh5esr8OZLpcf3IN7SxZKxNvgJp7XxUaKvYIapugcO9oP4ddxidCcoZ4WUD9F33M +n+zcxtwGuvnqGOB/resbSvK/7qL9v+2A0uCF/3/FT6bfJlzZXNtk5QJ2ljKctNsnBed8H/0 Yx7/ycXJb6tj0fgvFncS438HFMDL+P8an/PL1sVlq11uVN7nUQxgRdeExRKYAU1yJCCLT+zD N75is5bXbMACPPqyskL+VVXcBgCjB3cI0CABVNoZKJ/U39FFaasQL4Zv6WMBQugGFyxgaOt+ U6bniN5yhBn0ETo/Dl9jRT76FIh9KjsHRa9xuS/BZhZ/UvFfyIGpjaHcvlL+d2vXLiXHf2nX eln/fZUPBpEQa+KCuh1duewdy7F20Emc4jN0J31YTkln4aNJ3x2J09lkfPMgfrjCX5tD+vVn r9/xR7StJxg47UCcHRYmO/d0lmuxN5mMfGOGawpC2AvMhU0BbzY2p8bGzIMTc5Eppz7OAHbb IQffgHzazjAWevMX+o5fT2pnr+1fYt61CgE1l45zkPBw40iO/YncRlxDPNkf+PggRsWaKhXD VOqloh/cKr6wVzEEInxxVtGzTQZyqdabFyfln9vVeoPCZYpVWcVqLCdNZ+IPBlgr+gOvq9/E Sb6Lax0kHfSIkeTHw18P4r5rWmsSaaM5oI1MANKX/oi4KTaJDgz7h9aB6P8QtRN+vX5t9DiM +qfPPoZ9PmdXKbdb5eZPJ7VWXmfv1A0+Dzx0QNKeyoCLiZ6kXqI7eFiJTG80holqXXbMGu+T rIh5H7/Xa+MuQo9vQHb82WgRCuX+8fye8gVV4W7Ue67dn/SvkRp0BoU/0iWMBMVXKWvEWkFd paYjZX75A6c8k7/Yv5N5zd46ym8lzoB9oIuTfUlElUCJfukpVWQaOEUuEYlOUyoJF7Fw9buA 0KNO5IJ+4SmfP7JAKmFDqBYfiMSF1LC3WDyou5LpaTzKNRT6u6nkMbqX9Jwuicsxd2JG7yBB SCkBYbAn/Pt79U7U4OW7JyROS6HExHJlUrnhkFNt0B4rapmBnwhiw/5FT5/HzzYo6ON0MuqM H/KpXo7S9xB0QSqDGAwXjnru+79Z32NxcvS26eIJzCj5V4axbRAgrckZksN6799TajrDLqUS xCtFqPum/iBM9sYRb20rvBueVODo/FKgUI6DNmnr/Cv6EyJQ6aGnXnw+OIiexGeEWA4+WUiY uSteCMVwMRWzAUgx/70kZhaiwmOnlmSrdNVj7P5wkqKOJzS8NmKaq9QVdY0smSMV8Yf+rZeX 0+yvjfq79y2sPow2pSG9zUA6qR23qCPYNvHux/2Jh750f+/3en349jo5IUMFUZtF2Ogv6SmY WkcnTporcjjzLphr0YnwllcJbKTkY1YIzrcJo4Xd+5NYq0z+6pLgSZuF5Zs4ZJDfL6Y4zmHT Y75wuSzLK6z7IOQNayKNVpWNbPgZfmTTSJKSQo1cza79qc/hCrGOeR3AI3E6iWtOZPoqOxrH DM0+asg+p+daWGrUYBxIMLlP5/cyx/82dB63VistamispXqVG2/JmqCk54cGGysJzbNbEjya 85LwMuLGqwR7mDULWh5JamaTs1sca/DiFnBVpIAxcV9SgbEyCK+yHRqUVTw8ONW8z3IbG/ba nZuN2tn5ae2URg0vx3iExMYLwMt33r3+TpYHr0/Pq5cnNTAGKrWzZi2/+u7iZPXFJe/f+JPc /8HL+dOvGv/B2rVtR53/lwgO4z+87P98lc/Wmvi23t0Xst/Xb4W9uYshFpwt/G9X2Lv79t5+ 0RGf73xRux+Lb+VmkMR4CeLwEsThJYjDHxvEoYFDkUjnEUW3AlRd35741/r4/pYxbvskkzja jcMdxztCdm4DsfEPMRt3xQb893cRjIvWxhWIRueGPV3g2d/hywa9mPr4F5os8q97/fvZOChs hlSGde5sOpuOVu+OsLf3i3v727YQ084NQp/62Mu8/awmp88+rHEooQkGccDukju1W24w3NBm MQLcvDFXbGsVb2PFpb19+03Y4OYFOiFT5mkww6JQvdwakb84qYpbh1olTvsjEFxp/gSmhqq6 bGKuA5zdLwHHpzfuShiJWYZZp0EA/USHYBiIXL9DIYMtB2NKZCY4fVhAAaP/VCpae+mqt6lq e8t2thxL2NY+tNSCtgdDqvo4xC85O7tp9FIKvbhf3A3RG7Q4A9r9oSdv/gYyqzoMSfTZJOek zRUVoJoCH4O+8+9hRN65D5Rkna9h4fos3lwDJ4sRPdBZQIxj7UM3KXpwMPoTdLMExhAJ2DLb ehNRQC9GgwcxBiPZR93tisrFJQ8NGMAjpBmjRNDw4cdpOhxJB3SqvU10FPe3d0PpOfUm15TW bYKamc4PHEfepqNmwkJz9Fnk6ZLZ1L2G0WKbRogdCipVZZWEXcKqbKqKjmzcKW5zhXXw0Oea UFqAu+4dv91wNkublqEWJ1aD9QY4um+XVA1lks6m2/MuMOw3Fb0EqUXh2DiYLUcVtLa2JqB/ YC4Z+Ndi6AUB+cKtrWWJnbVlW1vQJvvNvrOzX9rBAUNjExSztzGEGUKDyhQWCxoldYu9s1/c VqWcYlTzPm62D8f9gZfFlhC9BONmfztEZ7ZAS9RB11InXeheyeKefg4abeoNF4el0fdw+MrT 0O3cwEq2LdWGPIWQ4WeiwC8GjBt3kAwPY4Aa+3fepO33emEcDDAYLwOZKQE9PRkQf8qhHNdb t31X0JmcoC2qnsuRAKKAConclfETpaVbins4nUFf3ffH8OOGm42gOynzu/El9HhBJnOPsiWo PT/ajkd7EarHu+t819AIJa8pNmrNGv77Tt55jm7sxdort0TVrn2ilfsglRzq6Do5I8igDLnc WiYh1r3LTq8l5Op913O7V57XWxKr1yGsngd4V1eu2lJNcMG6v0KArh72ILral9p5zJJB7D90 IukHdG0xPKnly8gD3x/j7EgXA9GFVrILve7bGC2kUhOrTRpEAsv0upuSPVImlqYoIe+SrDCU OL3G07rQbMZJGe/ifg+UBgFYCq6KdWGi8YLva/Ouc49NVy5z5N/Np3luLBykMzlCwtgIiecH GigyKwWHD3WgkCcpyPDNS2Kn/9SPIf/TM+/+LHH/r1iM/H8wF5RdtIsv9/++ykcGHYBp1B9x zie08r5ewqcZ3f+jK4WYNkNdN9ceKH8VqU97w+nm5mZBRD8LMhdzBmQy8Ni8QM0wV7NdER4X ySjIrGvDIFukcFViO4yLk4z0I9Hih0zV8Gxef12Qah9JCGCawWACeSsKgcOUhcdIGTXR6pRQ tfZhzpa1K3PdEUIhjEChIqkRAKz48QwEZg1/NulkhMiXDxWQWMM0pVEEs/RrjAjLYQj5ERL3 haPgJVrkUQSDNqcoMtWuZuczMDsxeRentcbp9w5WCRz/AGMRqCRHGOcSJ8DZeFPQDB2LJmBi qjsAwyjiQHQ0b2o4tix+RowOq7J94QtZAzkXqFoCfAeVDbA7Ai+IJEZSaCcjjFPnxfs+iFLf yiy2S43/pP5/3psf/Fl4/8OxE/q/5LzEf/46n9T9jz+aoJfPV/2Y/b+/Zv5Pa7dY2k34fxd3 dl7O/77K59/C/7vrQVULt79+V6/xyMU7zHT5oYJ57X7O5az7PSv2mN1mcjkn9hQ9f05rp7lc Alp6RuZyGpDY0grSNiT0LJ3oXiG3mjhrJ2LwhlLo10Tx3UKfLowuSidZeZVERaAVoZVELmJf kgUgtMJHbxs2QIRK0T0dYqBFVUrkMwLPDYWF1LBzC6VXUkl5KJUSPiHrhvxxfmX30Zr08Iya IO/3MNSrQ/H/iH2YUe/0IMLFwjD9Tfiy+b5+3MosbESilnccq2CEwUQ8RE4KOM20Pckztxtv JAfm5XaGiX4WNjNOGTXrkP3Fwl7BFGEREwqYRSzV7Bi3lq1N9icTPLehiB+Zp6rF0gcpIvRA Y0Cs/Y2PByJBZKO5iMqSzpI4z2NCoupoYh3mEpMtVeMU78ifX7YEna7Fm6/8gO9cfS1HzoBA jkSU7oGgYOQGdu7uBgdyPh9nnepCVCyUMpbitfXRG5r2iPvsa4uR56iojRpWoLlzweMY4afn 1Vq7ftZsaTl66RlKhbDnjs287CNekeGm8sJejffcR0k17fQD4WHF5FEc7xL2fFXPH9v5CX3C uoQUyUISYlXpNOi0mUkIu70Q9wyOXTNhB/B0IG7SdRhVj9lLUU2FJjmW7tiPLsCUQTiaFeCR jQcSFJkPL0hgcAeYhKVnY9SLOD2JX2VVoTwUNCFEcsIwh33xQ8yPn/0+w9IQ9vXrdY2R5M35 +jXt8GuSd3RK4dphqb8XSV75L+2Lxvm7Rvn0tBxG+AYAzZkeHS/anWu64YDMGs2GPC30p0N3 /EkW+0vsIhD+5TiT0imd8YBF5hq1ZGHo2Fg7ayGmDBKpkNfEXoKPpSw+6n6zksD0vaO8bAH6 xca4F9tnUKzCFLhtPCKqnFbBwnCi4Stq6CvePvq5VcvlbZzcSlEGcHF8ftngdxpG6+N5m20S RihqCOdnNXqnw5+UG+9q7ePzs5ZEcDSE5mn55IRfJnVhOALQyTTwpqhBOsMu9VXEB71pwFDy /gfRjpr1a0jvrxElhUKc6xqvKJAVvUNmYZSTiNryZescUCo52RK7kHhXrcE7re2Vy0bzvAFV npycf2ySQSZRQe9mNJfcdVHFmBsco09rsaLtV0Odc5qLr9uVMyUaVjS++NX58bHeIH52ZuhJ qBZfGDiDb46gB36Kmk6NlQ1X3s2dUUYX6yRqDZak/MoV/xrWMqexp+cfarKhdqJRJ+WfDfLM vIx1KV2uyBkYgBcoEDLsSLpeYWyRoiPRmujuRnYTKie1ckO1IaqLby6yKR2rKoTPLPH9+ali ihMVeOMPPVN5CjpVnNK68W1obj4owmhAKr2qzT4wlzp0WwtAYabMR1ohGr2FaEZVYNF4/lUp HjWTKp2BvD+IblGgjEm5UY+j4aZGUCHu0W5wUpf+6S8O6I/7pPZ/MPbLMx8ALtj/cbaLYfy3 0q5N53/Fl/O/r/Ph878LjNoROehM/NkU7xQ9WyIwspRNbzrTh7FxC2dOsICh6Sl6RAyTPlSS Kh+98R6TQyzpdzU3V1H85AiDvZNOIpN1ct0Jb4PDj9vwhze6HfO6YI1Qbr0O6eYokLUW2huW HxTTu4H56fEBh6iv1S5UsJUcjmByy7iGvsPdmtNy5X37XeP88oLdm2SI+xAO+Y5+5Oj0GGZw cUcP0xv0NaJezwgPj05UWoVUkKwvBMDw4YOsApxFBTiyADzTpbtL4nLEOTDYsTmMOY7EB764 9v3uZhQkHJr5TrpDS/cwToOgsshgr7y1wlt0dAFZ79x17LfbTxaY8bKbNyg7Uc4kAXS3WV5A puvSMgkK1o7ZcSigvAq+jhRghpq+30aR5JQ/PzVr7+wwBQG61HlDf/JAjsewtGSySYTDk8hN 5eBjsWA02UH+yhNY2L348ccfcyY04BD7dMnPQRxZosk8GaAZckKPy85ZkugKB4juprcJbKUY rX060xXBFOXT74kxnmiO0NFzeHh/f3+6iQVt8c1UblybG4fH3KY49gCEZ6frFH24fVo7bcPy LopJHy7FceTgTY42feOiQzsnBiVjC+iXtUVvCO0gD4HwpJUsCx0I8wSwd2Yb5TR1Mmui/moo XQL+aN2+zCfj/OfmOetY5P9j7xZT5z/bpZf5/2t8fs/zn9/zxMS8F7fcLtzB19vEOtAoTSyo D77Kqt689D34vRbaxtXvgWkJ+7Im+7f4JPW/dPCFtfcgcKznmQfm6/+iAz8S/j/boIJe9P/X +PD67xzMO+pzsNg58CdehJmiCx3fcJG+Z7z0A7Md82T9SyYRHLdH/icbY53x7+vodyLCTe/a Mj1E9za+WYK0UMBrMO4pl5kLNKAFDVYl1z2b0FXMgNYrviI7ABu1Px57XSxAuea7EoWCj6/j QoGyE43EbAzqu8v3UuUiCm23yTC8citOPBdswGu8UdrvCG4v5Qfd1BNssaVo4g3+aHevyCcv dFMkL0Xt1iJeMpJogUqWpRJl0VVAvProqcUYr42OzsuNKm7OUcIoKPZiBwMob8AIExtixxKn 7/8ZXdnaxitSYGRTSi88o+KbhkAF2uP/EqsRNgaJe8e/yj/+iHEu7mGYAoVFm7/TD0t8Wc9G PIohlpZHrBhrLC1GrBprXAIR/v9IUlejwE3zmBPvlB+xU3Y2d3Z24x2zZK/YGRU7iyh2nopY fCpi6amI249BjHN3N4O720sxd/cRvZpL1LxnHGypKvYy2xarwjG07U1m23BIp2p6kzF+jTVl IR7FEEvLI1aMNZYWI1aNNS6BWDPW6CxGPDbWuATiu6dy9f1TuVp/Klf/56lc/empXD15KldP n8rVs6dy9fypXL14Klf/96lcbTyaq8vqmriysa1HKRvbeqKyiSE+RtnEEB+jbGKIj1E2McTH KJsY4mOUTQzxMcomhvgYZRNDfIyyiSE+RtnEEB+jbGKIj1E2McTHKJsY4mOUTQzxMcomhvgY ZRNDfIyyiSE+Rtkw4tLKJqFt7MyVSkrT2MstS9IE6ohzliXzEecsS+YjzlmWZCAutkNNRiIu L6oTfwxL2Yk/u77JVOMpe/HHJ1um9vKV1irnG/ZeaS/VrT8uNYHYaV79mNGt8UG5ADF7AlmA mD2BLEDMnkAWIGZPIAsQsyeQBYjZE8gCxOwJZAFi9gSyADF7AlmAmD2BLEDMnkAWIGZPIAsQ syeQBYjZE8gCxOwJZAFi9gSShbhQ/zBipH52NijIEKilmM45dYN/zDza06vXY8pmJ2sTxcaq rLAqgLRjNO5kbaJkIMZpLEYz3HzajNstNm07pGmL11Fato5S2Ec7kbLNqiML8ciIWFqMWDEi OnMQn8aO7Xkikae4X2eFFG+Mm09ZshGvcOcxMriT0QcLZXAnow+cRX2wk9EHzqI+MG52ZpGa SzBl9zFM2X0qU3afypTdpzJFR6w+ldTaUxGPn9rGd09t4/unklp/Kqn/82hSl5bRuIjuPUZE 954qontPFdG9p4qoca95OVU236KPc0ja9G9SrPpxKVbtpgn/cSlWLUDMZtUCxOzRvAAxezQv QMwezQsQs0fzAsTs0bwAMXs0L0DMHs1ZiAsldzcpuW/QtltuxftGmYHv+NfSm5ZJxCMjomFh n0Q0rzkNuytJxOpTSTWvOZcg9fjRpD5+HwFRney+o0jN7/tbvZEIHkYdCt1Kime3WEp1rPPU jnWe2rHOUzvWeWrHOk/tWOepHZt9grywY3/jBtGbmC6Z16d2muwfl+rTBYjZfboAMbtPFyBm 9+kCxOw+zUJcctEd9altpRVtptXEwETgNv1a1mpKIS5rNaUQl7WaIsQnrHYIedltCAZ+KlOc pzLFeSpTdMRlVzspRLN9tASpZvtoCVLN9tESpC672okQl5eYhMj8VlObC1lKlHbTtP+4lCgt QFzW1E4hLmtqpxCzRWkBYrYoLUDMFqUFiMua2hHiow1f255j+DrbIn+e3uxinEz172jq3zFV l2WrQXXJWrINh4W1LGk4GCrNntnmVuo8gZPOIzkZr235JmZW/vi2/u+s3/kMhXG6CXtnRwxv /iluOS1NACRgJPyBN/XEj1Qb3gq7SKyh7HAr/R3/0syy4jz7NYV4ZERM268pxIoRMW2/phCr TyW19lRSjx9NarpDjaRG0pSxcaN6N3mybjK17diyfW6f2mmyf1yqTxcgZvfpAsTsPl2AmN2n CxCz+zQLcWGfaudbp/+bNBp3YzK1q8/0xblWShLxyIhosMSSiBUjosESSyJWn0pq7amkHj+a 1PS8ayY1GnG780fcEsbbbkyk5nXpbprqH5fq0gWI2V26ADG7SxcgZnfpAsTsLs1CXNilu9GM DBNcwo7Ym6uKjXOrvOaeuJrhyKsZZ/7Ik5GpQUzuPM5gNvLp3kriOsvUD6+l4H0PU7EUm+53 KLda/1D+7eVGl/W1HGQ/hilBgMnEWmDiuiCX+mUjVL98fs9P8v5fmHnlGYPAzL//59jbxW0V /2V7Z6eI8b9Ljv1y/+9rfPj+n9br8qp3xeVEnifu6PradfECXYcfDf6M4oJXvdNZPe03b96I 0/pFU7S8zs3IH/jXfYyLj3kThSgPBhw+IqDkapNbL0xS+JI+9CV96Ev60D8qfagM90RsjO68 jvrj2YAoV2zS0nL1sFkqKyUNRCyJL68+W9gozG9ofDFwr8wFKTWWGVGqjVd3EyHAMeRTf/KP RwQgT7zsj+R74y1dE9r1dKdk29uEJeMWbUlF6Mn8k8HY6/R70BOUe0bF5MJfgQBqOSUNyhxn YYUvLmNiMWZk7hgKxpBfC8sohLn93Kk/7HfaUyofONnuQC9PKYaFDExOEauiOOUqXNWU2DoL DpaABD3/WWbpMzBrPv71Yyq71utLJAGCngCp+IxpKKPEavXG/4asiCXFG/gdd9C+umF+fDpr tCsXl81fDkxQyLpMME4LM55N+v4sYLB4wkN5lxwKcTs08tZu7iwqk39/IpbVz1rt2lmVE77I jEnJGF0rOUwYxGmDYv8+5wtl3f/uVVGAgCweTUqfp/2hN5E84jQ4jGvRf6uY5pVAVuO1zSt1 TeP63i96oUtR/SpBFdXFobXCOK+U5Ao6M3+vp7T605/uo8gq71rtrnzuTq6DOBw+SWW/ihc6 r6BwUNAQ6HLuRRS2fEyukQ8jSnmlVsVxeaa8MRxBNM+w4u2h0AVVxpiWGajubjwKOX7rDjDi LGN81/3bCDpH1oXR1sYwAXXyqzAo18nAGviBB1RTrqwvmRERKIh6nIj3H2NkBGAHtME2a2Oe RaKdqltLKQ2KHM6hblSRG8kSC/g2bOppuflTGIk/h/kWwSZpUx1RTV8E9tcSpBjokOx5QqVS SjKq/A01miuMIrWxcMlkXr+XbAnxrML1/NKljb7VGqcme9dCgoC2fWGQvV8xTt931t69Rvm6 WCSNqbqOPEybuq+Xla4sS/4xnu+CCpP1lXswve6LJep78ugwsBLmyCQvl2KkEu63b03C/Qhm mjiZZuPi0bscK5fi4+MG/PI0LhzvOKwxbCKWBKtUlan5ataLEmesi4E3YsuHHmA4fv6Vnob5 bxSFnwApi8EexeBfR+zXr3n4hRaANnn3fzmQGZi/4ScFgY4ZsB4Bm3iGuRRySM3rQ7DMOEwk 0PoaHoHh8J0DIvXdXld81xHfBavk0UGx3j7TOgJqCT5Zv3yCR7/QuzzXsPGWGCNeiWYZ5+Ja o3F50SqIH8X3r78X++J78T2BK+iRO6RMFtxEfnoYvgSb9UBINoiwhfprmUU6sxnr3wUh+Ytp XBWvV4HIVQmfIvLLPI6JTwDbuemPf5F5Lb+kO07X33P6MGH6vvTjV+zHfNhP2gSHRX6CXsGu xYLFJ7mOjfratBqh85DMNlVmk4mH+WdAD23xyk58t5mp8dSSQwVg9Tho6wonFf3HDNST0cxY F5TYnZa+N6APB96kgOEb13kBuBam9BxjwFzg51oB2RY3R6AcYjYVFgsm2/Vuka/rqhJMUNqm WLFChLbNPOUW2e2rWjP2Efjwu+66qgAE5rtATWXhU1yxqkqkjZKyk1ZyCiLMjFI/+1A+kQl0 vlFMyYZbiYZmPt2UwuehO4A1cB5D9/q9FERhXbw7vmhjPvTaCaftCQeyoc6z89PaaVTnxltJ H+oF/nYQveMRcBj2j/aKpjeeW/QBAI8k77QX3Gf8Cr7oKDA4ZSlJrTT5xy/hKMZ8CJGlC/9P 5y1ge5iiFpvFNCE+86fErM6OLbhakwcMxzz1ed8ajF42iJm+XBj7mOJX68tACZCpkKHpmQzB VTC8/IxVSk1ViEYqbz913NHIB0McbPV/ejQaheRZmIdlqnaOkuAhtBaNGX5ySGt3hIeXky7u wMLAxp8dTBAFJj7ugCEV8YEdpuXtT9u4DRR/y5GleZWSS1ECjc2gEYVc7bLltUxAXJ4mDowv GYlxYjGIYD6pkPBffamULRi5UJo64xnQFwzHGLW24wWBPwG54gxtcdUW7qtRpFy5baYyMMX0 k5FaOQMQhiwIkwamdwgzZ4jQGAX1ohUCxrm9g3nTOG75QawGWKjqe3xk8cZfryV3HvU48TB8 dHIPcbNoeqNOMtRuMohSINwBJkF7EFcevKbgtjKkHA3BeCEpfZbMIRWfWFUqqZgG1xoh7B9+ oDxxuSug4TNzGQb9IfZM5vYfNO89KUrxDoRx4Pn69n1IOBaj6Y53LVYdpk5MbL7m9A5LL/KS y5l3rQ0yFUQdQya7swAWUriwoXlffsWiX0W/eZozyKX+9FVsNZQlGrkY+4tOmL0r2X0as0Nu K2aL1wmLSK6z2CCZryUXDyA11avJXaUEAAJV0Ydyb5FE9M4TXX/0/ZQPtlw1K9IhDokvEK26 OVGC4E7Wu+e9xB72KXb/Pq2pm1un3BNb+M8h9dH11PQYiV7JKQlOjfqUIUcGVBb0qyRwCvba WPj10iivMjYlFDfO/Bg75f4CNLqv9U5i4qQzExxhedC5am6NLy+wS16LvV9evz5I2TV5Utdx S2RdkMqX04h3359qZXPP4iE0vsQk3pSNcDyjpIFdvy1f5TUb5CCXo0kH/Q37QWdTdCbuWPx9 FtD50WfPG5Po8FEZBkv/jHlbeNKMTxcwm1yRkdAGsUqlRbCimV4D7AG9KXs6MODpGVXUAVs8 iVU4B2LQYExTcYp6iKL+Dgaa5r56oLNZNH9WrVU6JMPTbczU4gd9GhP9EZcQV/mk1zBLRQBP ZAILVWdSXnHCih9FFVgPo5potsqtyybn7U0XoOa7THTaeyHkrD1Jg3gbSqQsI+VqtZHPw7Cv 1o7bR+VmDaTxHdXTqJQvm7X2+XGT9vTSe4GPL5EoVwUadhdxX84ybEXRc8zCZsc2od61Cgdz 3O2MpcQn+zP/DkzBHp3TBzJFi3ff8TjY9a3XmfqTzTBHC79p8+MwUQnYhoW0jJLZSKMQbCwt Ackf7dyzxCfy/xoOtzobk23Lsr5u/q+iU7R2Evk/nJ3tF/+vr/JRXgfo1ERjOxDB7OrvIPXK nYX9lDCLUseHwcTun5l+MxQ8nV1nNPcdKnq1cn7xc/3s3aryOBq6ffSZmtAQk744UD+KZP+W HHuy/HqkmO6LBn4R4dJG3LqYlGQa+T+cnl5uVdzOTTypmdFzbUdU3VsY1M1NmBwHOPfnu8M/ e6PryWZw3UdHtIIRb3cd/92jf9+ss2tawx30xJHrdW6g4cCd3p+vR7NNf3Kt/N18MN72lZfS BjeclqjIAOHfepOrge+ie9a4fy2Bhu4o9Fi6mlFc+8/uBB1xkGkepcPyetDqPu6nuTQXsv+W y85nMPNQXHso4IEwMCUjdih0H8zyRredLOec7ARtmW47nLlt6SxsYMoYkrZ1sDPTz/uGAsbu tQFyfE15DdIvOM9T+vlwOGvjJrN3z45DeB1g0h+6ILJEjBi7E3fowTgJNrXkALRyJoA2J7Pq Rj8O0G5p4t5Bn5ORBynE9kBh8beDyOA5ATFOIa9Q9jAcohFheZgsx+hqOZoWMqiM7T8FOrmB qhjnzvI1jNX1LGoDzIlD1UhvlkRHYqn+OEizdlL6HPbnyp/QN7InHRgq5cr7mnKKOh9FQzxg P7z/rVVFo7QDQy2YPsAYm97xpO4CTABsn4IGYS6skG3HCeNo5KCP402/cwPwA1A9/PTOfVBq iXknl1HsHdv17jGpELzAZsSyG8kuBnwsOK/1OO1cRA4Y3ThgNwUoG1vv0Yk0JuL7zFkuyOsL exYeulNuTDCd9TAnxhBN29mY1cbAp3EOKuJqNvj8wArFc6e8++ezApHGPbdyQBqR/EOhtraL 3dyONCQIR9eboJ4CAkXL/QzrzquJOwLUQK07i6Lz0IEegBWIO0B/zxF0zGdEcQrszkYIoj8F fveYUFhYY6oRtytxAYccSKlHt0ipUxqOYkHQLUhkgVR8PX8w8O+wRVLX02TkQWuEymlIRVFS w6sHqfe0VQ3mE+kCy3y9t6PBQetq+NYhDYraiTyHFE9A7jZVSpRUqmgQ53ZvMAtu2ty5oH/b 3aLTLzpa9l2zf0O7bT6ovQKzc9pmYYFiCgeCn/SjJ4hsPpVFO1WSyfRtx+mDjrn21DbjcNiW 39aGQz4xSnpjUNpB8yuws/XN6tthG+YXNyzxduimdhw13w6RHw433kolq7bQctHeGec7fHUo LsrvarQmCje+dHURrt871LJP33XXv7P2Bvf87y+r67TVU9DqWpdtIvqjwyUgFzQZDNtuG74C cRKuIA9L4KHcJ0uQ/s2h6PB51sZbXMtDl2qv5fFeUkbyfBoXeT7kxtfdNqYGvcYzCPg55J9D +XPq0c8pnXnSFi2WjozKZQpSLse8ha5xN95C/6hTww+n7dpfahUCAb0IozHP7P6BmMIEIUWA i3TBMh6zOMd4wjQiwDAEANgExBS3ypF4BTHUIAgE2YkAt+4gj+3Dbd829fmH8km9qohJjIo2 TvR5vSoqiDjOP3PxQZNG+EL/crtfSzHDDG709gvzNcPTAl9/kbsqcrIiCxZVyAxwVJZMTzRB y3TWKQsReaRfe5hOk1Jmkh4GXbIiNyJYK3VgCKEJSNErrx7Qad2bTNFqDsUXrTupyfDeBeLn 0VYH4ZuBaD2EGFT590FBJkECWzGux4wKDHSC1F8mJcH+HOkRQLlVTcMzGp/DIQxO04DUBmFu jjrlw+aUfksgYDdLjPYEp5Z8tnpitZYzOaFhMbpyizFBG1HDYZaO0wb0GH+F45l+hcN5LA9c 1GiWKVjBIvDvUD5GvmC/tnKzXhUP3nRddiXuZgX9K+humpSv/enUG8ldLbyvgH7OULAfyZbK ybpQ985Vs1hwqGXN+pWYF3VqlnoiEuMKHpk2TisdWSAycZzSOGPtPfAzpW+i9zp3p2QBII8C 3FAH0/4zdCCxej16mWT1lUf4utWoc/WbmCYbR6rsolFr1s5atE0LPeXjtiXSs1A/S4Krfp8k C+Rc3tlwga4bWK+SWICNKCmSjhVoPPUDlgYwAqEbYIk4G4DZDra4h5bkGEQKbDZuQ4CJfl3R OjkSU5hGA74CQuhYFyYlU+sLokH4Y49vheKC3+dzidBmlmRGnHLx9CeA9QXb4F3fI57jihd4 yiVGGpCs1lnnRmdsHgedaZ4FFr8SWVznCYRnENP0ocQmPnWY5g0FqU3YW9gr8Tavh7TTOh13 U67lpmNeipCHVWCvDK7AIu71BwO6V0vgHX+C+yKDh02C2SKf1WucQClhtCVeizyPmfhSYgMM dXbLNDSyLSmMGrsISPz/4uuWOId4OjbwKF3RQiioqZ+qiaZWGB77823crXAUy0zbXkBJqDnb HjwPou0f2veIhjbtg+Cs6fVxCKktGVjt1EeUTdvSMwfSyOAdKyX8kfbYlGseieis06YZDzIe NXIRS0WpsYWmgS+vsQmNfjynoO03WHzgyJGrF0x3aKBGohNNauUk6bDXcd5gakce1u9OHubO /dQ3U7+NOW670dxPvbQWToamQRQ/3ilQQbJJLArpRclKVG9fX5WYVh4Zaw6DOf0ltMY+r8sF s0eXbkDHBLPOZ1zzfqQ7jsjkIfnGEIdcfDbhtqJtRUesWBAmoKcOue1P0LRSXaXEgyZeKIbY IlzcT6B9hRt/oDYJKDklaT2kBxqCO5SwggWaaJPTu4c1dIAbF6EOp4UybgVcxxJPmhlH7B7P s3GEuSt5usqYeArxpZiZ2ZLbH/Ee5JXb+UyiL73wWcY9dNHXNs1YcGASRZ9qUT0tp0VyBder 3aEra4Pi2kEnIRic2jkhLOhNlF5rg7jAkAwPTmnj5VDf89InB9phbvPLfPqwFzQOiA+omNnQ 0xUP9mxfKo5NXArgO96kvmNzQVoRGm8GiEc97nLH4M4tjXvSIOpwkrOiwlB+35+27+/vJR/D 2TdQcyQuXZEc6ML/lw9XMjQzkH8artPyBPBahHOGGViuB13xw2G0GEwzKK7N3QJtGV7gs3rU TJrD3OTqioz47D6/Q2HCnn/ubu+au13baIlN8DGeqi1ZxaW5PE0BG3kqh5WkCleDyEbc7MXe DocV8rNdZVYyL8PtYTVbcivDDVkavKZhxByk9h/M74P/Au5HozGrCyJB/ur8pzHwf70HUvIP zTYPgfns1+YiqufO+36CU4+P2zF47x93uGGCvnK7NNMPaLMktLpCp6qONAvJbiMr3r1C95I7 XMDcuGOcqWMLGjAoLgPecnHB2LgeQufzygkXTi6utyiyQnc2HMvpkI1BtAFxkx90/QNaDeog bt7GBvQv2I/DsUEqDBLQZWnp4x+UA/o9r0PbbTcYttui3VY+H+12fnXkjw+0/6+ymudDmA/2 5i71S8jp9l3YY/qQorppeb4MIEiToo22XpOE9xOER4XGDCMqsJ+uOQMIau1HtcoFRlWeCZBJ /0+e9PEEAmxK7B65dt5M9pz0EJFeUGxOJBKgU1wEtsO0hdyh4Kt3toNLvbxMZf72rXiD42qX 1nhh8wF4h6A1uG2Es2mnQ+3XqGNLHAFoB6LfC1sR33U/X63zLiSW912Xz/k22a9P+aUmjqxg aRTnU2bDuwsa3l2m4TtRw7vzGl7Kbjjmk39Mi5OHdNa6Lo/R0hMP7OjUqY0+oyAabd6URa8K ecQOdfn+Z+HyFsB1p4PbPuMZrS1QqIbuZw+WJhOKwYK7IoI3m8Zs/gesIXCzmFecwOsOnQ/G t4yBNNwdgrrGrJvAJOvMpl5oltoiGGPEEdzKGfC6E6kn3dSZuLgEglqu0BsPdOTgYZODqNDy hnyf71xYiHZjOgr3LGP9HSzobxmFIbnGo21P0w7qupzwrrxrPIamKW3s3zlqv3Q4pg20IW74 6aJg7ypZwNsm8D5ay9BdjjSG4yBGETGCuz564SMWzlGo5IW1DwUEuvTRLop0FCYQOwFSdFIg TgJkp5QCKSYrcvZ0GFyDEDOQ/PiiW7xSjGQAusudL+GmhuWoP4X4coAhYbglwaQPckuenwc0 EeIReueGLk5/35UH1bSVckfHGiTJ/SmtWzw3eMBVcden0YBBoHCOQ4nrut5QuhLxFmR/+vCN XMJk7BITLccoqXTei6zZGMLM2sdAOtGBNnsIuHKvfOpes1cfCgyya0drHbqF5+WsQkw44MmF zr7kd0BR/MEi5B5iXErXxqmOEGsFwTNuLntCxWt0+2J1sirya+MCmzt4hV363OaY6B/AVLKj leeJD8ZLrz8BMyZq7j+9iS/ytE6kFbU0aQtR+9GrEX4M/LxF4s0/b/r8M3vOF/F/VplKl7Q8 BY5y/4nxarjfTIX8bfS36SY6Z4yAMH/S9Sb4ZHVFHbes0kt0QiwmXnCf7q2L/HdWIQvJMr3Q K4p4TP1YyG7ub6X0zX8Mpbb9/KRGXrYenoCGNxHu0MmcHdU4WFF8PIJq0wYkq2QrPjTDAagD F8KxmqfT+3mj9dFMzOZijI27CS5ms3ExH8k+LcxVFxljkUdgqDPwYuV1ONgLsZtDSYWSfa5N 3NxQajGypZJOZqiFu2jXfNf9aZE9RceDcqFI9lQh8jMjnRSzA6X2lPO1nWVi0vW69siXyGhw BZG/Dc4YUg7PahXxgfatmPRBeB7gDmBWCmCqZqJxT5emr3A5CA+nUp7Rweh+POh3+ng6Q3uW uTZdCGvLExpcrUUPcAsdhzHGm4tBqN8KILGzKsHMB+BJeNozRwyTh08SmA6tM4/6k9AayXPP 1iM87fwghpg4V2C3J0Ozk4+ikvsZJMU2wBHcsIMouWN4Y0AwA8cBTWVSafPENFNI0VNuAGuI gXDUzu5I7hz3eS3wD4oQGHqTkE8cn8te+36XgvQ2Sug5J2qbMOX3p2qvmWz3bn8yfeDxSUcW fbrWSOgjX1TI06RdRaB27b4DXMVzCBD4+/v7+P6j3Aaj3WZtE5w2qGnFgRci0FQMPZHVPKB1 KyGHR3J4IQPTfIXLGHrUKJ8ajhEIM3aUAFYlMi9I6KUh2JnBlJY1/ghdYAiTbUJaB2Lgyuvw ZPlFT7zoia+vJ9BlFd1r+E48L55RN7SnhcSy7sDocWrQLfGQAtqiWy89tk5vfw68a1vab6fu wxUrGLw6jqeegdz6dMVAqqYf1VZfogg0vmJtYGcFviX2Socv8GyvuY2nS5Or8uiqY7SpzvGh 0go1fVBnNA547yZ2y7DbRjd/GvRZvrpyk+AQD2W77aIDq+B2Z2y11S3BfOXCavM97ELkOCUv ZqNzXvvyjByoqrDGv8EBR+hcbB7h2pVT+K/c/GldqJ8KpRBeb18aFRHLRye19tn5WeX8fa2B TkfalbjYnmTI61xsxy56HBMxrWeM+9IGPaBepQZpqJKMfgC0x3yO2w6sQE2+s/8RF+3+TT/d SR/zAG0Np92toavCwD/vDcD59/+snaJtJ+7/FXfgz8v9v6/w4bOy4wFu/Ha9236H7E4SArxe TAaYA385sjN7R22tpK92+d1Z8k4Vv8EZLlj2ApnpJpesAOVzar5WxqKb9WrsTqZ8a9EEYYpK /ZjQz21JVCKMLDxt4602sTZ8gO8H2opAXqKOzdJrdzCzXfMla4z+U8jzHedj+PP+4wVeANcM gHZ7tieCcRvnob3QM9sdqxrdcfJo2O/FrtnDmt+9I/SrPEBjkCSMD9O/bdviNQHrixiozt5R 9dk7v63Cu+UqBAtbVqj5nj+pwsESFRLToT4ytXsTf5hRJXfO1E9WjiiwFsBtCzCtBt6ISBl6 w44sr+/nEStNCWMihokeOhnN6mGSgm6SFFeeADMD+Gg13zVV7fJp6PAqn113Zm+zTCxT+93T a8/sehaQZWofPKl2koOpv5TgYb9yJDiWjrmyMPVBEtLkYBlmSUhSAMTBdw5GjcHL9sVq8wLP yIIb3Ga7mgV3/e70Zl+U1nEsgH7YDzWFfGLv7EeDWT4rOvvReINn4UDYjw0LeMMiuR9Jp3om i5Xf1VNZsPyuSp76+xqbKTI2WHmhouamXoNhEqiL3+qOCyYU6biDCDZQdyI9KHHQ528UAb8/ uh54zBo1s+EViE3lKkybjLCuoIOTO/YF5YD6FBiCjlrVDVDG1w/3NT0f0pJoAcdqb5+2qhiW qfXLgcLlkIHh9EEFYGcGnyjM+OqR708HvtulcOWrTW+ClePXM38ydAf47RimEL6vjL8qNImt fjlYMZzIUnCKYBytamRILzSsaZciOmweuA/ACVhby1QXHm0qMQvpLil7r8otGPKi4MgAs/AX 7/Mgwh0GKQodjrX4KWonGSMBwtqkVa/UxOrlSBbBdxugABlQTE6Nv8ogVeGUWK036WYgDYhN bTgdMnrULW1yHs5HvXF0ft46OS9Xaw1a2HAJgR7Jjawd6sTNQb/N5bGb0dxGBOOYvO2L7wb3 tDM+4FhWuBGvVbcuUtQXEpHCVBDOUIrCwFUJWev/sinDGprkqk8RqMgUweiGfptrhIVefrXT 6/NXIPAVE6SuORKCPO7EGZlo5ss08qJ3jgsFfUYGIDxtva8326fn1cuTGr1f3Bh2AJP8T/Ud hfrjKwTpJksk5QFmgAip5S8EJZ+9jhBxpwAPPNqx8RzkBbVuPTGw1xPNENq2A51cfYmCPm7U zv5SPzfsCWM0J4ojN8JltT48Y4wXIEuDJFn8+gDfYkd2PdBG/kP0WHkhpqSLSzSNGSYbqOSO 5GhLUnVAkfIph6AKiUZp5a5un8AAOGvW8qvvLk5w3MrH5cvW+/NGfvUIr2qL09lkfPMgfrjC X38e0q/N7ue3GkK11qw06het+vlZfvWEliGYyXTcH3tbWoJFYD02XfDyFfH/6IXUf+hHrmu2 YFmzoaWBe9Y6LKvk7G5vZ63/8cPr/93izo69i+v/bdv+/8T2s1KR8fkvX/9n9P/tpLMNXbJ5 8xx1zN//sR17Nxn/qbS7U3rZ//kaH/Js7aGiJ2MaZ+sP3PfsS0DRbm4eArK6q2xGl+Vdl4bc +A5E/qJabgQFiaIinjSrjfKpBRMu5U21KHYNPRNH7uizsPQwKvTcVrB7SVhbh61Wmo6EtLlU SVjlpj/eaFJUF+EkMIoKYy8Lo5jAKEkMJ7OOUgJjW2Fk1rGdwNiRGMXMOnYSGLsKYy9nRkA/ bPQ30ZH2JFIpsxrOCx7iXFTqH1XP7TASPAp7/mN/1PXv4j2IKKoDd/ayULAjo2rqZ61KU+Ls WgJbBGsZMGYo/FYdozFibKpI0HCxwdQHet1o0UcFceW4ihKN89NYM/nqAIs1JoWiKnroDxvV oZWL+bta5ZYseI8ZgXhNjrOogWJTWo0TBco01MN4krJZCQws3GKMN1YCQ1ZhGVBsiZKsRKLY xKawefRKZkpJMv+kIQkuJ6uv4MF0ou6Li5picjnqYWMjKcQohbneWMDj09qpxrgK08GoJq6V K81W/bSmwPd08HKHblS0+hQVSe/H97BOU02txnAqN17ns6hR5uKoV1e4bRtHsyBGdWyEaGTX rJzkhoFkeFxuHCnIPQVZnlz18epHHLJ+VlcicRwWCpYvQubrqKfdqT8ppMYe4km5ON6bg8cD UMeMOHMUIkqGSE6cYGa7FC/CMk4qZ8fvuAhbqnnCEIhR0fNG89lBiNZsST1u2yk0bdDK/nTi dTZbRYW8txi5GOs8xJbq3XaWqLqUrHpbIS9R9TYr5Bi+1Pt2cYnKd5KV7yrkJSrfTSLLqcAu LVHznpxKSGPq88nxmSxl28qYhU5n91gCKqJzuucgNVBMcKCk+rkqKWs+KweivnUujvrTIC66 R9Aaibwb4wQqfkNrpDBXT8tmMYYXOKJ58Nl73DIAViPaSgA3G5WyAt5TwE1/NtFMpCQOLG8V zpuwgiqs3/sjHiA6Yi5Jmi0x95Kk2UlopE1Cl60M2uyod0XMXmAyFfrePDKlNkH/Ncx1aGZs y4o0pV0hcti0a3g9KOXGpDMB56zVUDh7JpzZKKE9W7ZWT5XqgUlQ6i23SyRuoCeLqT5bq6+6 Nw9X1RtxrOVoFfNUIKOiblzMJmM/8CR7oopjyFHNPDtkIYc1a9hFrWqeMD5iNPmufz2vzqJW J08XKayostxKbiWa3TRt3hxnzuof6lUu3rHCWeyDByYgmHXV2KCIAJ3QpJBqIA6JM+5pCFwK gSv+cIh6Jg7abDUV6E4ImjbbGjWN0simaQABlHQ7TkLlpNwMi30TTvmwZsaJruvFYZv1vyrY SghLvokntOTBzUvdEDoBw0YhVENSTtypN+o8yH7R4N+3fr6oKfhaCP/ew5MD0cJgiHF9WW5U JLgd9skRXjZKLuhMAwSwLYW9Z8S2EuByMeA45srsmDHQbEb94ITcas6uNpp0zGEWnmYzQqoZ kBhaN2FP6nLqcophLZEBS/2SsHkjhGoa4aIft2mg2dKkcUoLeOwk2FVUeGbuhnhxSwYQpSHj bC+osJRE3FaIC2rcTiJK68XZWVDjTqKJuwpvQYW7CTxpszi7C+rbS+AdKbwF9ZHFwOtfdto7 P9FPiVake7Y8N4ASi+yVLTfP0IdDjLw7eSxwWW600GOjyQHxoVwKzTvpo0b3J1OzwmSsowZR XGSlic8AmlLWT0QVnZaPZr1efPbJEWbrfQoz18IQQ8P+dJpCFiKODWsAib0XYhvWjnGk6smJ qpKUD2FV+6A4YZye4HQiTppHceNXYZ6mqosjnpoR63VJp20Z6KTRnsI5roQ4EZnH9eNzg5Zj jCPEULhCOoZ3/OEYZr2r/qA/feAD0nflk/pJ7VwE/mCmVjexgk7CqqN2korR5uQkuacKx+H9 EEI6hbllGMNKVNRUSImKwgkvXY9CKVqJarJxmoq2YlRNszOhHpPgMswfinyNj9C72duLL4c2 f/gnY/8/eAg608HzbP8v8v+00/kftu2X/f+v82H/T5q4BHc6XpGZeYHy8+xRUHaZWKz5c7PS Omm/D2et5HMc91sY2QQliGUJy/Ewwe+/VnIMDQur9vu/Htrr6sHRZRMfOOGD0/Nq7eSwGP5u 1hr18slhKXxwAarn7PxwO3xQq74vVw53ot/lav1wN/x5UoOpuArGX+1wL3xYb1bPDt+EP9/X j88ObSv8fdn8UGsc2hGZF4169dCOqKxf4MWGQzui86zWQh/8Q1untNn8eN4AxG29OR/qldrx SfndoR3R/KF2VsUaIrKbaIQc2hHJjVbl0AaSt9YUL4/fHTrWei6H5osqpnHo2BrMx/LZSa16 6DjrGtTlxbsGGDeHTkT9h4uz9k9HF81DJyK/dXl2VjuBRxH1lZN67awFj+KUN1tQbUT6Wfm0 Ro8i4nG9Qo/eJDmBJBcjzlOw2XKlUms2D4vQEnRs4pkFZ+OEzKF8/dGj6D/3k6H/6V9Q288y Ayw6/90pbrP+h3Wpte2w/t9+0f9f4wPj6dt6d19EHb5+K+zNN+j072xZ21v2rrCdfWtvv7gr gAeidj8W38ooqRGSSmtz4w/dQLz3J7C+GYkfpjc3f5YXSvzh23T2HMqVw5PPmTfFwLeBKG81 N2Vxf3qmj8qzQ2FMYHa6xhuHGJsH0+FimjzME3tAUUkoriqszib9q9mUYvG4o+4WpSEC9fOA cU2wJExVMtHSI2XmQ1LJkET+Ayz4cJHgFIQbUCFjhAhuKE8FoR8jPU1JD6w6oBYOrJzVgIjS ropDfeOPiWwK6HNFbq29mUwD9LHeen9+2aKiymc/i4/lRqN81vr5gNYzuLtJQYwoE95wPOhD qUAJrCKnlHfotNaovAf48lH9pN76WXDsIXFcb52BphbH5w1RFjgz1yuXJ+WGuLhsXJw3a1oe qGz+UElZ6Z4oAlFwQ9Fl6DLzhNfEXYyIDwK1BPtddNamsqRva8TIA/QCHvnTdUoV6CkP4KzO WBf1UWdzncrafiNa3hCjz1wMcCt0QzTpkjYsqtbFkR9Mob9Py8JybNveADt3d11cNsu/k3iT H4cXyiIPKzyQm8SOzzH/SRTxTt3oCQ09uqhIuICqW3rJF2qvRMvGB5M0n6P6k8nDupChedwp 9OtQBLPxGHc/MNEVh+4ePJDbsXsLfU07DNj/TLa8bsRXHsPjKy3vH6Y+VDcZ45dzsGkU4kom m+pJ+/Xs3SXGHQVzrHZ6dPKzSjcUXlANq4murN4XRB7++dW6d+VapRBWCooTmQ4G2Yb0Lo+y Rcb2t5v2jlVEww33hET4yWlXY617u7NnU/kFEyLalBGidb9rLL3Z0kunIGqOsbjKyU8pSMsI WS23yu0mGMZa0cLOghTJDxdtLC+7uhiX4BNn4By0cjUDDd/PxdObaKQ2if3+8h26qp6UfxYW SgIKLqb8vpIHI7TtMcBQAfoRU73yU7N9UWuA1Vs5P6vmcnmZFdPDi8Sz9s0/8wWxhZ0mQ1hW +wH55Jsl6+JDJcUs/CTkypFyq2GZutVKQ5zGy7Xuj49jQLVU1arL9+L1NT5mAb5JADazAG1o QkIRVOvNC+gB5EFO8iILBBaYP+fyHFhwVxQyoGpneF2ayqpl1fWRq/qY9b7J75sZ74npuXgf ZIDioMex3uuFIU2PL96V1axFR9qhZo9LhrwpAdBa+tmUwnETCkfDAiPh4rJlxCpmY0FdjdbF u1Mj3nY2Hiwes7B2JNaK2qc4E8GdOx7rjTe1HQCbH8sXxjKVos1Agb+2kpWdlKxoUI4uUYrA WpXCjeA27Vz6alWiLUWck0FcrWoBn45yqk7bTpNWq9pxGMcE48RhiiYYKac52za8I8GkWUg2 ms82RK120Tg/jbe23HpTNGkpY5cksVLTQViaEVJXaCUjhK7QWK2k8JNEfFxY9Me5RX/MLrrS TGpY2SfbIgV68lMCVoJi7yW6iLuBpCvNrwQITH3nx8fNWitnmUGkEirumV8DXTmNQjOQxoJc iilzUGLAGWU3UmU3FpXd0MpuzCsbHUqjngqVMKU0RPN0qYFO1ipGBWk1zk+M6siKq7jwUBJt CigIs7pTYnNYpPA1/VO+akULGAqHYlT+eE1OZhpaVC2sYWTUIr69Ju9yzS0T9Ed+LUoJLgNe 5s2VFzCmamTWUDgpod33Cy8NZjXko1mTW+Y5RWKQ7MpxktaECgqVYVL4tTuGegEqQWd44NiJ fJVl4nWO5KuljjfOzPG88Klm7RmbpWeDT6G8SQoRhxlkGgwUYN+0DDPQVWevlJxycT1GJ9Gq PFpCGoW93KzBP5dVWFWI3eKuAy0Bg9aGaVQkQOOH5DlqxBXWnAnHg9yJ1F346q+gk5nYd2CD DzxfvGvtlNCxk6/I6v20sA3vuBnJmblkJcYpesRp5RpKAghZVKxkVcD7/lZvpBVhIgaPJIzk dJLkVCYP46kPzFbODb3+AJuJBlaWbWgquBsVrOk7VjzxnYNMrcNuD4lyvajcpIJE132mJY7S 6yTaqKIQuzDEOhMfN2qAfbfeBGNToQ9HpRnmYVG57jCNVjD2SY1SqG2Vp4W3ubhhnZv+mJMB y+DYRkVOdLbOuZGVJu4O/G0FZuL8xfufm2q/4BW6h1g9+hTEryJ6meRQgXgRnWok9le+0rHG vP1/56vs/ztF3Ozn/X9rd7fI57+7uy/7/1/jQyMr3Mt39L18fzh8EM1NUbmZoMocBbSj33nZ 0X/Z0X/Z0f/jdvSdp+/oO1k7+s6/wY6+o+/opwwpENP6Wa36h2z2i3Cjg81J7Yqicmbrq6uK GXa/hGujNRBavD2uKAWUsstS2JFNRK6rugBkmC5GYy9lYaGLLF/UZF89eUcOhQzv4Lh0v86L 1wE47Y/1s+r5R7rYYvOqzDK8pxsltuTus5+g2KGFufAEBcB3affECGs6SDFDmg5SSssfpGx/ 3YOUfIKRr8FUTWy8LTocebP08YuZ4qi8VJ3akYqji0+6iA+1RhM0we9x7PJ85y52qEIWnLs4 pTRIclsQT16QnfEy4mVnH8bYO8uexti7Sx/H7P324xgeWPZ/1GlMr2ftsvZSOy2gG/3h3K2W Mug+0+mGbSWPfGMIR/VWzn7zTAcLkXJceLDwZvHBgmMtPlhwjAcU4cHCG8M77WAh/rJcYQDa q7tPnknAoNbeOsmC62c/aa9Lz3iUlM1Uw1HS3lJHSW+ibcbavTQpYD1wfa1vXeVR73W9q9n1 NRBfMBFd+0ur1ai/ewzRCkXfNjUIgwJDdi6G4h1UK2rV448wd3az90qzhpDEyzzGtHkUp5mA iM7cCjP2nBlvToXq/PMRZ2a53PwpJXFMBkMvRH2dmtpTpyO5PeO701zu8UdjOcf4LlHWgrOw UHVY5vOvSEXNPfRaWt61E66YT03qEMhEV+oYTCdu0TGYyCW1VOzcSztzwGs2/I5zVvB6lq6U qb1ZDNqJGdlk6ulQS5RoQcvJyWFtAEa8usAGy+Ek10wqxHBIyEK1+Cgu47iwEWveXrp51Ba+ pz//qE1YTzls02RhYQWlpSooiSyFtMRxHqaKADtztOgs76hc+Sn7KC9WZXSUFxU+r7y5x3iJ eukULzQUxVc+scxo5u95YpnH2/HSghaF+echjzsNsbKmEcLAxcWyWuwRxyfZx67r4uP7n0W9 ScE7xdl5S9TP4HtNNC9qlR/xQ+eeUxHg2grRpL6ZjWaBygX6J+jupGmWfXibOZHGDm/ZCefJ R7chumHT6TeShqc8yOBSFgFsbi4AQio5OBrr1dC39CucM9tAllXsPOacOUL5refMUNReXDrP /H7gzSvq7LzerJmLyvDoIozc3HEfFqortzfaaH/S8TeaPapT+fwb/nEWnYGnt/loiwbvVyf7 KHkqXjSeiu89y1GzbZld/giBuiNjbkx2ByNEm2uhxWSF3H5fPaksohNAmDmykBixjhq7FAFO 0880Wcjih8PZqN/hLSNtaJmrmmdSYiXh7GeoiE0KjBbvDoJ47CutgmbLSnLESTFbQooU84px 5lVo270/4szSyRZVKB/QvDG0oElR6XOaVW3V2tVKrd2sncSJdUrJdn0obrf/4tgG0O3Ucvn8 /AItkgRcanbgNsJcngDcTfpK0FI0/6E/mXr3hcf4SNjWjlnhVBo/X2RoO/M6VSKkx0TkLGXw 5xD5JgaDdkeZVDcvyiaTgPT3U51YHlcUFcJR8TdQjvhItFm/WHlKFQqBhgHCN2AZQXELSCzl 4WEor2tbIo1C2+oqEWnODpGnMkpGHFs/CdPPn1Sx3HP4pqlt1+ccChyF72DlRdG2bCNVEXo1 Qs8VI+yuFmzL2CxUpmH1uVyJUKsVVa3CySNgIRY2SGFWdYaIbVVAZs0xIypZv/Nb6y8urH8u 60rLs07vOlvru+1H912z7Gg74zspfCfBwPjhZiiZGGEoHx8LmOpYE3ZWCYXc4yT+/LKli/y8 KlrpKszjItmJsFDA7jeVrUmIVvbjZCTeBDGvmmqqmuUFgavJ5lNM5vRaqLezK1peixAfl6Kg aaIgwdH0eNVrspevys6ua9HgqJ/pg8NQT6wi57VdUHUtNYzC80FkK+VYFLFPukLrHuwPjHa4 tRaPYxfINLO83Iqvq2JSqUbL8cll8/08HkJVe6qqY0xYSItmGlY4T/b6mExo67/Nr9H5in6N L5/lPhn+nzee232m6D8L4/9Y26Vk/ofS9vZL/Iev8pFbTUPMlHzDkSOD6azXi7uQvcdDAM1z TP5OqJKf2qfld/WK1f5QPsGzcq/ruVdXrhnKllCWdYVw3VisoZT7VlZSSZmG6yrMmNWWjcDs vUUHFOp1v/PJ+eWAf96yx6b81cdWc3ao+BPOCoQPOEllDEY+8mCp83CAoWlCuy7Secyf/wRV N8//+7kUwAL/b2fHluPfKZZKOzT+d7d3Xsb/1/hsRc7fL1FcXny+X3y+/2if73iE7aT/9LrA aY7P4NwxNH086bso4XJ+7GFeyM2UC7jcRI4mcPVgTj7kRAJ7xqCwK1m5kCkS1FstLEsa35mH 78Txtwz8uBr4nc88qwtQNN18YNoDlVWSncGLwe9Pvv81/33l+x9+2CvAlyP4Yu/gNwe+wbKQ 9r1PKkfO/MLwcGxOYffxwu6TIRSTZk10oIz+9O5UjQDpCwGLvFAhRI5CNAyrfmc2BBOEuLJF hG55HsjDcHN6zyfjrhx/ML66XtCZ9McIiwXIWnp9b9CVK0YYR2xKrdNaOLpt8B6kjoZOrB+w FEKHdaXX6ffUaUp2vapSlq8QXx0dZ5h3ZjcSdACun5+JXWX+sT8vt78tn6EBqKfY1m2/2PNO 7/pT8Rf9MeVnvbnDJfWnnfQbyvzJyTX9T7aTBsDJxMpAC8jv65NdMqPZBjS/u6gyx4y1oK5i GssNgrtu+8YNbj7ZppbfdUezwSD1/BZHbDddSdCeeD3TY/zp99Kv0DtkAjPCJ9tO104ej3wF QX8HM8pkitztpro24NS5vYF7nXrXH2P/ph6PvCnu/6SlZNIpOmTuzxG69nji7S4veUhXkC17 lkn4+JW9UC7ffEWxzKjr95BKx4A1Tyr9yXNKZZzp1IdkbHQwWcYzSlhygzJUpKBevVHHJw+r DRBvtse6fkewSzDnyk6fyH602tVmBeOv5m8L5BEh4Eu4g8nbe72U5yKgHZ3WqzGct29xJ7A0 D6dycZmqitH25lZ12Wxe1Gqm6joLqquc/JTGsq15WJRN5qh89lPzrwbUue2LUA2Yc5t44lTK lfcGzth6C5N4Nkc3flzX2eRvMafr0o6qgIMhkQ0423NxqtygBM7OPBzcCjfUszsPh+Ix48Q/ R7CMiKXTcsXQVdabeUi1v7Q46rQB0Z2HSDvhzfpfTfI/R47tNiatOTlvmYRqjiQTnn1+0Xqc FBOaY0abI8KEVjSjxUQY3UhgKdrH66vKRgwdj+VixqCoUN2g99n/XtYwOrWTSzn4JSDAIMwl vQ4JpFk+rl3UL2oOZjlJulvHILYxr01xHgQsbHK50vwyEGR7HsgugewsqAdAdle2tuYAFReD bCPBe/NhdhEmeQuHIC7Pfjo7/4hZb3ATNwFxWv4LQ1F8bwB5A0poawtW3mAQTa5pO8UdCXv7 m5SzU7nJemyuQz0CtI/LmNkt06GeSipX61FB6fA+CIMKMIJJBzpDGFR4EUzJCBMFj2/Xj0PY bXOdVa19O2lljjHk5wt4AsIk4AQyV8BjEEYBj0EYBTxRhknAYyBmAY+BoOzmkjct4vUQKcn7 A/F6COSNkbNhg2wbYGwjbyNiHMsQ4i4BgyTbC9hL5cxl8DaXM5fFtk3lzOWxbVM5c5m8Y1Hb 57J5h/kzl887DsEkdURCcJBmZy6f0Y8LYObyGV3qAMZJrK76o56fXk8N+vLebsqGhjdXsyDj DS23jChDw9oRng+9oToKMpQV3LSz3nrdG7djfOF2+6bnN/1eenkIz/tB1/y8a6z3pjswVjvw 3MDrDoD3prezIGuBikXeZfMtvexXb5KrcVpGEaehe41bC7I4fF007HLA65E79Oa8pj2j7MLV DophtQ1v1Zp0O73AQ8LGo/bnq3FwgO4cn6/60y0yXcyA09lo5A3M/ILXnUHfG03x9RZ6+IN4 +7rHxsB9wA18Y+ksc+h8PkciecdjSaj50j3CPcnBgqIk0PySOr3rBcUgxPwyesGCInrBwhKc hUU4qow5O4s4jvkBqifjMOfXs/H1xO167TnDK7anhUt/j279irQW5K9kOMt6aZvAHeBGaw+q E4E3nY3zBbSyyfXWHWCCSZSt64F/5Q5EhKzKx9Q8XCESpGrr6/Xkb/1+t8C18Q0iLJHO0fBk Sd7eMxeKqLJU2ifR+aaX2wDKJyM+1cC05R3a5e9NvH/MKPVlfyTe/xPLxdsvsI7oj1CXiZCb dKcjFdSBKliB2WNCxac4uKnNI19SdAwolzDMJr+VGp6QlqJGzV1pakDhM49pG70fcF/OoyLq UCQC8JeigCaWdPU4P/2m+rGApQjgmdBAAUxtv40CKGA5CmgSTVMQTpM40KYyofRSVYeYS9Wv TcdpIsiyiPNBW1GnKer4o2CaRRcVthRN0qAxjBLv1hvA8qtDaW1Rdz4DXVSo06YySR+naMzn jVRG2mUTT3WsX3g/Qt22xH0KZ6+QbAffSe0Q5bgcfIYWoN223HgjA+/LSoqxpG0C9AgISO+g Ohen5YrmCqujWGhG+J+FPxEj7xrovPXwSc/tD2YTT+R9kKnewL9DACiQrudCMyfu6NorRLc3 E22MN2rodtqy9nzcglpDx9V1AofCqc34HR7dgoLP4d50viMOxfaB6Ii3h8KCvxsbBbTsc7fw fFFnyrO4DlpnOagKvgFW/la8pvq4l3HfPodti96IHw7pTUH8CBzaF3iM8SUSIgIGCPV6w6au YMfp1Lz4KBYc6HlCWjSd3MnB0p1QNtfebNRh52N2BJYGINsC+CyqmY2Tu3EeH8n7u56aOzE3 qZyEo4mX7VrddsGb9YzvB4CptS4OR/O0AlyXBynuIELR5nSFYiAMHeWYbDS86R4QO9ExKBnj AGcEwwEfg0p4DFCIJ3IUkOvJs/LZeeu9CK9cWidR+0iOieYR4eVjI3YUkBCC7OehI75BWQAh arcZNBk5SmyJvKxri1BfC7sgRUa5/n3DNHVFPn3eX+ANz2Qiuz/UT3Ce/197OH0WJ+BF/r/F 3R2V/23H3i1h/Ncdx3nx//san2zXC8rZGcoBDsYgSuF52tITZK/rj2VKx9izs/PGafkk9ui4 GfvJXjaxR/CtBWsioWVXD2ts4wEL6Ha6IbhCujJwb712rz8ZoruKpkDWefivkfpZF6hyBt7o enoDQ/eP5v4f/8kY/9fTnZJtbz+PB/Ci/I9Osaj8f7e3t3fQ/3fnJf/j1/mE8Z+px50o/HPF Ze/fEzARr12wzMAY4EeDP6OgoC9w2hXYfvPmjcAbP6LldW5G/sC/7nsBO1sKUR4MBMEGoU+F 8qJ88Tl+8Tl+8Tn+g3yOw4AP0a19DvrwTubTyMimkXI0prwb9rbmaRw9CR+dNn/KjyIPFv3O JgdggbcFYIhNbgTP9CGmh+2UgdD0mNnP9NE8Gt5xpvPz42aOLjBToJ/Y6/pZq1EpXzZrBMQw He1QToJQNB6tmI7diRVzUalbmAgcr2PqJfX2TFAUpk2HihdWb1ZjJO/sxV43K03bOomDWHsp iPdxCO0gliGKTqIMO1lG0UmU4cTKqDSdJBnOXhIgUUIxUUKR7MmqxgyruGcAeR8DKVlJrtbP E5SUUoyvnydo2U6Vcppsz3aqlNNki3bSpdiJUvYMIIlS9pIV2akWvUmWYqda9CZVSqpFbqqU VIvcdCnJFl2lS0m26ColtAlSYN2QS0K8T0CUklKdLCIl9skSOgmAhNCXUsMiIfMlO0lDMVlC atgkS+jEBTrJh+SoSnLBKcXfJ5mQHHRJHjiJ+pMsSI7JJAeKifqTDEgN2CR+rH5twCuA+HDW hnsIUEor26Mmq7lIL/ylY6W1LYMVHV3dxoWCwcqNml5S0aDeW+eRalcfLK30u82RytH4d50c P8JK/v1xzKMlenOKkVnzaC5wbIgYTsGAgCGzczF8A1D1L/y/nGV6CR+gZiVOqJxa4W/tjOgt 2tnvkeoE0Un8QjY2NsFUpJGgo8vm2eUplgjSkGBhHCQkai9JVFRGwVhHtfZBvtddpdIAYQ3b yRqiEsw1HF+eVVQVe/MAwiqKySq0Isx1NGrvVBXOnPdhDTvJGqICChkmHFhp5aPzRstiXqWs uCRUWk4yyiosKknKTEYlGeS2yg2d3DeLoOaRGysrg9wIJkVurJJsyzarD01A6Y7MKKqQWRLK VMsol2awU84wEhfQzBKz680ccCao9KjLKCu7vkgBJLSwCSqtRzLKyq6Pd3qNitQMl5a8zPKW qFVKX2ZVK889oZ72g87vNYVWa8cydF6UojL5nlp6Wju1wrxDThqQ3LrxRkv9rxiHz9neAdJt yynJP7hc31oTp+69gHenR+LKHX3W78q+w3wGrVYdRIRDWeV2ctJYQbz+qD+k44RpDpuwoh+D xTYPHBkiCD5/9Nbof8Vn3vlff/Q8IUAWnP9tl6L4H9tFC/f/t0s79sv+/9f4cBKuMAYIdfnL CUB6i/TlBODlBOD/8AlAlWZx3vTHBpSnMPTCkIjTeXv+WoA/DB1vzC/JL7Ijf6h4I3qaDXTN wnAjoKHOZsMr2rUX9cb/qrST0IPAoZs7jUprU7rFoceVOrsIXwcCO+O2P5nOyDUaJCDAIPui 6GzsFFOBP5Dm2lk1t5O4tPP+o3pTdNIYtFfPQdmtlfTrd63kfS8qrPXeSl7yks/t5NUuYmW1 krzPhY8va6fJS1z4uHJ+epG8uUXPGz8nb2vhY7oRt2soHQZnbs/YJgx9aVE1RUOB/N7m94aC +b3D7/ey3hf5/Rvyz0tLisOSgh2f6PAoNWkXEG+9CXQ8DFMo2VJ3L9Dn3NT9Wmcmr1wpGUg+ j6QD3mT06CMkAHvaIADMCxP4ScUkArAGKJtEAJ4fmWQAnldMMgDPq8nLefT8/GOt0T7/Sbwx i1nyIh7JGXQArHAp3vBH8saj/sjqC/i/nbMdDdxeAO7k7KIG7mjgeJfBEyOPRcEk6aQJ+VrQ 5o2xBhoPXIMlhp47CnC+FNP+EFRVfwRGDOcySiGCMOfsEt//UZrrmmYe1Gl3NzCLhpFib0BF USDmHgBiRB2MDES3PSiGLBA/9Ia8XjIxXmb/CMPK6++S11claRIlhYHUFLKqofSqCiUfq+W1 zJ5jrEvPNZePVaXQVBhjTkOseWT/GHrYphxTMaAJHmOHV0x0/8x8clpir8w/2g7/oz5q/cfe f90Ak60+W+BX+Vmw/oO3Nq//7GJpexeeg7WzY72s/77GRyZhrroDNPia3rAPpl531pnCMkyg MGB+ZuWzLo3FI9CKYJvOJuObB/HDFf7685B+bXY/vxUpA7GtUvxGpmH0aCV+b4olkN3V5fCl gS2fB940H0NIv2/DqmYIOjjm6Z0A80aYyMRUAayK9Fcr6A+LjSCY/JrKfd72xwX9BtvU/exh AG/l1Y+aGRZQHb6eF97IA/OewqvBug/jxXuUVVuuGZgAZJxOD+kxrdZ1oZNwEOnjVqN+Coss 3PIrX560NOsgfFNvcvoX6FBL6cT/WsX38qFPXP+P+53bmfe19b9T3Enq/1Lpxf/3q3yk/r+g jsek36B1HGsHd4coBTpr/mzFv8mK/88ezhu0Uxfpf6l/ML/2GUZPaepxSijrdr15cQqL1pzm pITPEfikdpbLaUBiSysoBv2h3qyjXqu8LzeatOwiBTq+7chbx7jPNbrOJ27s8bUteLcuZnvk CsjXt/DGkK5Yj07bfCqiLXzwuOSicf6uUT49LUd179FFBKxYbg+1O9d0EwHrGs2GVNNVfzp0 x59ksb9gVSG9yPXOCKa4PdEZ4tyiKhTIBUzDqi0e5bMzmedQyxkmKpcNfCHf2Ik3R5gTW77D 3Gth9UP/1suo+6QcZmyPl9Y8b+gxbESj/u59K2eg6aSGib8trbrOwHMnsUkYn974w3D6/aNH x8vn5fPyefm8fF4+L5+Xz8vn5fPyefm8fF4+L5+Xz8vn5fPyefm8fF4+L5+Xz8vn5fPyefn8 53z+/2mP4MQAwAMA --------------040102050900040803070107-- From owner-linux-mips@oss.sgi.com Sat Jun 1 12:42: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 g51JgmnC029987 for ; Sat, 1 Jun 2002 12:42:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51JgmtD029986 for linux-mips-outgoing; Sat, 1 Jun 2002 12:42:48 -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 g51JgjnC029983 for ; Sat, 1 Jun 2002 12:42:46 -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 17EEmw-0000hQ-00; Sat, 01 Jun 2002 14:43:46 -0500 Message-ID: <3CF923DB.6020906@realitydiluted.com> Date: Sat, 01 Jun 2002 14:43: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: James Simmons CC: linux-mips-kernel@lists.sourceforge.net, linux-mips Subject: Re: 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 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. > From my work on the 3912, my answer would be yes. -Steve From owner-linux-mips@oss.sgi.com Sun Jun 2 03:59: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 g52AxinC006589 for ; Sun, 2 Jun 2002 03:59:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52AxiYm006588 for linux-mips-outgoing; Sun, 2 Jun 2002 03:59:44 -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 g52AxenC006583 for ; Sun, 2 Jun 2002 03:59:40 -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 MAA05572; Sun, 2 Jun 2002 12:57:53 +0200 (MET DST) Date: Sun, 2 Jun 2002 12:57:54 +0200 (MEST) From: Geert Uytterhoeven To: Brian Murphy cc: linux-mips Subject: Re: Patch for support of Lasat 100 and 200 machines (~60k) In-Reply-To: <3CF7C9B0.20808@murphy.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 599 Lines: 19 On Fri, 31 May 2002, Brian Murphy wrote: > The files not patched (not existing in the oss CVS) are > in lasat.tar.gz. This includes arch/mips/lasat and > include/asm-mips/lasat - one file to support r5000 cache About : Vrc-5074 definitions already exist in . Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Sun Jun 2 18:13: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 g531DEnC020271 for ; Sun, 2 Jun 2002 18:13:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g531DEbt020270 for linux-mips-outgoing; Sun, 2 Jun 2002 18:13:14 -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 g531D9nC020267 for ; Sun, 2 Jun 2002 18:13:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g531EIQ16964; Sun, 2 Jun 2002 18:14:18 -0700 Date: Sun, 2 Jun 2002 18:14:18 -0700 From: Ralf Baechle To: Raymond Lo Cc: linux-mips@oss.sgi.com Subject: Re: virtual coherency issues with 4Kc ? Message-ID: <20020602181417.A959@dea.linux-mips.net> References: <3CF7F7B1.50300@broadon.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: <3CF7F7B1.50300@broadon.com>; from lo@broadon.com on Fri, May 31, 2002 at 03:22:41PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1658 Lines: 38 On Fri, May 31, 2002 at 03:22:41PM -0700, Raymond Lo wrote: > 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. We simply haven't converted to use the new interfaces yet. > 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. It's still a good idea to not rely on the virtual coherency exception mechanism which can result in a very significant overhead. > P.S. The link http://oss.sgi.com/mips/archive/ is stale. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 3 03:08: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 g53A8tnC026331 for ; Mon, 3 Jun 2002 03:08:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53A8tQV026330 for linux-mips-outgoing; Mon, 3 Jun 2002 03:08:55 -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 g53A8pnC026327 for ; Mon, 3 Jun 2002 03:08:51 -0700 Received: from aihana.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id DAA05135 for ; Mon, 3 Jun 2002 03:09:04 -0700 Date: Mon, 03 Jun 2002 19:09:18 +0900 Message-ID: From: Takeshi AIHANA To: linux-mips@oss.sgi.com Subject: Re: (Re-Send) shmctl() returns corrupt value on pb1000. In-Reply-To: <20020531.112847.74756483.nemoto@toshiba-tops.co.jp> References: <1022757017.1045.47.camel@aihana> <20020530.211902.102583216.nemoto@toshiba-tops.co.jp> <1022763778.1046.71.camel@aihana> <20020531.112847.74756483.nemoto@toshiba-tops.co.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Organization: MontaVista Software Japan 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 Content-Length: 1151 Lines: 30 Hello, At Fri, 31 May 2002 11:28:47 +0900 (JST), Atsushi Nemoto wrote: > 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). I did to check both bits/shm.h (glibc-2.2.3), bits/shm.h (glibc-2.2.4) and asm-mips/shmbuf.h for calling shmctl(); There are any differences 'struct shmid_ds' between glibc-2.2.3 and 2.2.4 that I saw. However, I do not think those diffs are caused this problem. Because the 'shm_segsz` which a member of this will be allocated on same location even if the follows members behind 'shm_segsz' are changed; i.e. it will have same value as 'shm_segsz' on both different structure. Is this right? > 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. I understood. It might to solve this problem as the most simple way. Thank you for your advice. Regards. --- (TAKESHI - MontaVista Software) From owner-linux-mips@oss.sgi.com Mon Jun 3 05:48: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 g53CmOnC029490 for ; Mon, 3 Jun 2002 05:48:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53CmOnh029489 for linux-mips-outgoing; Mon, 3 Jun 2002 05:48:24 -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 g53CmKnC029486 for ; Mon, 3 Jun 2002 05:48:21 -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; 3 Jun 2002 12:50:10 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 326E1B46B; Mon, 3 Jun 2002 21:50:08 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id VAA22291; Mon, 3 Jun 2002 21:50:08 +0900 (JST) Date: Mon, 03 Jun 2002 21:49:57 +0900 (JST) Message-Id: <20020603.214957.105435769.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: References: <1022763778.1046.71.camel@aihana> <20020531.112847.74756483.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: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 795 Lines: 16 >>>>> On Mon, 03 Jun 2002 19:09:18 +0900, Takeshi AIHANA said: takeshi_aihana> There are any differences 'struct shmid_ds' between takeshi_aihana> glibc-2.2.3 and 2.2.4 that I saw. However, I do not takeshi_aihana> think those diffs are caused this problem. Because takeshi_aihana> the 'shm_segsz` which a member of this will be takeshi_aihana> allocated on same location even if the follows members takeshi_aihana> behind 'shm_segsz' are changed; i.e. it will have same takeshi_aihana> value as 'shm_segsz' on both different structure. Is takeshi_aihana> this right? Did you check the contents of 'shm_perm'? The type of shm_perm is 'struct ipc64_perm' in kernel and 'struct ipc_perm' in libc. I suppose these definitions are differ. --- Atsushi Nemoto From owner-linux-mips@oss.sgi.com Mon Jun 3 09:44: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 g53GianC001954 for ; Mon, 3 Jun 2002 09:44:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53Giaas001953 for linux-mips-outgoing; Mon, 3 Jun 2002 09:44:36 -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 g53Gi2nC001949 for ; Mon, 3 Jun 2002 09:44:03 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA19600; Mon, 3 Jun 2002 18:45:51 +0200 (MET DST) Date: Mon, 3 Jun 2002 18:45:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux: mb() and friends again 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 Content-Length: 7702 Lines: 277 Hello, There was a discussion some time ago upon my proposal of a clean-up of mb() and related macros. The conclusion was a rewrite is desireable, but the patch wasn't accepted and no alternative was proposed. The need for the update is more and more crucial for me as I have more and more code to apply to the tree that needs the macros be set somehow. If there is a design flaw, I'd like to know of it, if there is an implementation problem, I'm willing to fix it. I'm aware about peripheral bus-specific coherency problems -- the patch is orthogonal to them and only addresses the host bus. Here is an updated version I'm using currently. It's fixed to apply against the current tree and adds for source code compatibility. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.18-20020530-mb-wb-8 diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/arch/mips/config.in linux-mips-2.4.18-20020530/arch/mips/config.in --- linux-mips-2.4.18-20020530.macro/arch/mips/config.in 2002-05-30 02:57:35.000000000 +0000 +++ linux-mips-2.4.18-20020530/arch/mips/config.in 2002-06-02 15:51:03.000000000 +0000 @@ -393,6 +393,11 @@ else fi fi fi +if [ "$CONFIG_CPU_R3000" = "y" ]; then + define_bool CONFIG_CPU_HAS_SYNC n +else + define_bool CONFIG_CPU_HAS_SYNC y +fi endmenu mainmenu_option next_comment diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips/system.h linux-mips-2.4.18-20020530/include/asm-mips/system.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips/system.h 2002-05-28 10:13:21.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips/system.h 2002-06-02 15:51:03.000000000 +0000 @@ -18,9 +18,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -166,32 +169,58 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli() #define local_irq_enable() __sti() -/* - * These are probably defined overly paranoid ... - */ +#ifdef CONFIG_CPU_HAS_SYNC +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + ".set mips2\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") +#else +#define __sync() do { } while(0) +#endif + +#define __fast_iob() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __fast_iob(); \ + } while (0) + #ifdef CONFIG_CPU_HAS_WB #include -#define rmb() do { } while(0) -#define wmb() wbflush() -#define mb() wbflush() - -#else /* CONFIG_CPU_HAS_WB */ - -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "# 8 nops to fool the R4400 pipeline\n\t" \ - "nop;nop;nop;nop;nop;nop;nop;nop\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() -#endif /* CONFIG_CPU_HAS_WB */ +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() wbflush(); +#define iob() wbflush(); + +#else /* !CONFIG_CPU_HAS_WB */ + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips/wbflush.h linux-mips-2.4.18-20020530/include/asm-mips/wbflush.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips/wbflush.h 2001-09-07 04:26:33.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips/wbflush.h 2002-02-04 02:52:11.000000000 +0000 @@ -6,29 +6,30 @@ * for more details. * * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki */ #ifndef __ASM_MIPS_WBFLUSH_H #define __ASM_MIPS_WBFLUSH_H #include -#if defined(CONFIG_CPU_HAS_WB) -/* - * R2000 or R3000 - */ -extern void (*__wbflush) (void); +#ifdef CONFIG_CPU_HAS_WB -#define wbflush() __wbflush() +extern void (*__wbflush)(void); +extern void wbflush_setup(void); -#else -/* - * we don't need no stinkin' wbflush - */ +#define wbflush() \ + do { \ + __sync(); \ + __wbflush(); \ + } while (0) -#define wbflush() do { } while(0) +#else /* !CONFIG_CPU_HAS_WB */ -#endif +#define wbflush_setup() do { } while (0) -extern void wbflush_setup(void); +#define wbflush() fast_iob() + +#endif /* !CONFIG_CPU_HAS_WB */ #endif /* __ASM_MIPS_WBFLUSH_H */ diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips64/system.h linux-mips-2.4.18-20020530/include/asm-mips64/system.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips64/system.h 2002-05-28 10:13:22.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips64/system.h 2002-06-02 15:55:32.000000000 +0000 @@ -12,9 +12,12 @@ #include #include -#include + #include +#include +#include + __asm__ ( ".macro\t__sti\n\t" ".set\tpush\n\t" @@ -161,20 +164,37 @@ extern void __global_restore_flags(unsig #define local_irq_disable() __cli() #define local_irq_enable() __sti() -/* - * These are probably defined overly paranoid ... - */ -#define mb() \ -__asm__ __volatile__( \ - "# prevent instructions being moved around\n\t" \ - ".set\tnoreorder\n\t" \ - "sync\n\t" \ - ".set\treorder" \ - : /* no output */ \ - : /* no input */ \ - : "memory") -#define rmb() mb() -#define wmb() mb() +#define __sync() \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "sync\n\t" \ + ".set pop" \ + : /* no output */ \ + : /* no input */ \ + : "memory") + +#define fast_wmb() __sync() +#define fast_rmb() __sync() +#define fast_mb() __sync() +#define fast_iob() \ + do { \ + __sync(); \ + __asm__ __volatile__( \ + ".set push\n\t" \ + ".set noreorder\n\t" \ + "lw $0,%0\n\t" \ + "nop\n\t" \ + ".set pop" \ + : /* no output */ \ + : "m" (*(int *)KSEG1) \ + : "memory"); \ + } while (0) + +#define wmb() fast_wmb() +#define rmb() fast_rmb() +#define mb() fast_mb() +#define iob() fast_iob() #ifdef CONFIG_SMP #define smp_mb() mb() diff -up --recursive --new-file linux-mips-2.4.18-20020530.macro/include/asm-mips64/wbflush.h linux-mips-2.4.18-20020530/include/asm-mips64/wbflush.h --- linux-mips-2.4.18-20020530.macro/include/asm-mips64/wbflush.h 1970-01-01 00:00:00.000000000 +0000 +++ linux-mips-2.4.18-20020530/include/asm-mips64/wbflush.h 2002-05-31 11:43:50.000000000 +0000 @@ -0,0 +1,18 @@ +/* + * Header file for using the wbflush routine + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (c) 1998 Harald Koerfgen + * Copyright (C) 2002 Maciej W. Rozycki + */ +#ifndef __ASM_MIPS64_WBFLUSH_H +#define __ASM_MIPS64_WBFLUSH_H + +#define wbflush_setup() do { } while (0) + +#define wbflush() fast_iob() + +#endif /* __ASM_MIPS64_WBFLUSH_H */ From owner-linux-mips@oss.sgi.com Mon Jun 3 10:21: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 g53HLpnC003045 for ; Mon, 3 Jun 2002 10:21:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53HLp9V003044 for linux-mips-outgoing; Mon, 3 Jun 2002 10:21:51 -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 g53HLinC003041; Mon, 3 Jun 2002 10:21:45 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA20558; Mon, 3 Jun 2002 19:23:56 +0200 (MET DST) Date: Mon, 3 Jun 2002 19:23:55 +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: <1022713145.7644.363.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 Content-Length: 671 Lines: 16 On 29 May 2002, Justin Carlson wrote: > 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. Userland drivers are justified in many cases, so they'd better not go away. Besides, not all display adapters are framebuffers -- do you want an X server in the kernel??? -- + 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 Jun 3 11:06: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 g53I6CnC003808 for ; Mon, 3 Jun 2002 11:06:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53I6Crv003807 for linux-mips-outgoing; Mon, 3 Jun 2002 11:06: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 g53I66nC003801 for ; Mon, 3 Jun 2002 11:06:06 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.1) id g538taa03126; Mon, 3 Jun 2002 01:55:36 -0700 Date: Mon, 3 Jun 2002 01:55:36 -0700 From: Ralf Baechle To: "Gleb O. Raiko" Cc: Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603015536.B2832@dea.linux-mips.net> References: <3CEEBBA9.5070809@niisi.msk.ru> <3CEEAC5F.6010802@mvista.com> <3CF2A17D.6050207@niisi.msk.ru> <3CF3BB4B.504@mvista.com> <3CF745B7.16CD0387@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3CF745B7.16CD0387@niisi.msk.ru>; from raiko@niisi.msk.ru on Fri, May 31, 2002 at 01:43:19PM +0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1571 Lines: 41 On Fri, May 31, 2002 at 01:43:19PM +0400, Gleb O. Raiko 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. Some gcc 3.0 versions definately misscompiles the kernel; anyway 3.0 enjoys a bad reputation for bugginess and being slow at generating slow code beyond just the MIPS port, so why both with 3.0. 2.95.4 seems quite reliable. > > > I understand, but is there any __official__ recommended versions of these > > > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :( Send patches. > > > > 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 Nah, I don't consider myself an officer :-) > Date: Fri, 1 Dec 2000 03:06:19 +0100 [embarrasingly old email deleted ...] The issues with newer toolchains have been discussed at various times on the list; at this time I don't have a tested toolchain that is usable for all configurations of the kernel. Also note that my recommendation of binutils 2.9.5 is only for the kernel. Anyway, binutils 2.12 is looking promising so far ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 3 11:28: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 g53IS5nC004442 for ; Mon, 3 Jun 2002 11:28:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53IS5cE004441 for linux-mips-outgoing; Mon, 3 Jun 2002 11:28:05 -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 g53IRvnC004436; Mon, 3 Jun 2002 11:27:58 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA22478; Mon, 3 Jun 2002 20:30:10 +0200 (MET DST) Date: Mon, 3 Jun 2002 20:30:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 In-Reply-To: <20020603015536.B2832@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 Content-Length: 1208 Lines: 29 On Mon, 3 Jun 2002, Ralf Baechle wrote: > Some gcc 3.0 versions definately misscompiles the kernel; anyway 3.0 enjoys > a bad reputation for bugginess and being slow at generating slow code > beyond just the MIPS port, so why both with 3.0. 2.95.4 seems quite > reliable. As gcc 3.1 is out, it may be worth checking. I actually plan to do that in not so distant future. > The issues with newer toolchains have been discussed at various times on > the list; at this time I don't have a tested toolchain that is usable for > all configurations of the kernel. Also note that my recommendation of > binutils 2.9.5 is only for the kernel. > > Anyway, binutils 2.12 is looking promising so far ... Well, 2.12.1 seem rock solid for me. The package I made available at my site only contains two patches that affect code (the rest is autoconf and similar stuff) and then only MIPS64. They can be safely discarded for pure MIPS work. For MIPS64 they definitely do not work, OTOH, including the N32 ABI. -- + 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 Jun 3 15:39: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 g53MdenC021484 for ; Mon, 3 Jun 2002 15:39:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53MddbU021483 for linux-mips-outgoing; Mon, 3 Jun 2002 15:39:39 -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 g53MdUnC021452 for ; Mon, 3 Jun 2002 15:39:36 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g53MeBl28484; Mon, 3 Jun 2002 15:40:11 -0700 Date: Mon, 3 Jun 2002 15:40:11 -0700 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603154011.A11393@dea.linux-mips.net> References: <20020603015536.B2832@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, Jun 03, 2002 at 08:30:09PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 441 Lines: 12 On Mon, Jun 03, 2002 at 08:30:09PM +0200, Maciej W. Rozycki wrote: > Well, 2.12.1 seem rock solid for me. The package I made available at my > site only contains two patches that affect code (the rest is autoconf and > similar stuff) and then only MIPS64. They can be safely discarded for > pure MIPS work. > > For MIPS64 they definitely do not work, OTOH, including the N32 ABI. Are they good enough to build 64-bit kernels? Ralf From owner-linux-mips@oss.sgi.com Mon Jun 3 15:59: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 g53MxbnC021888 for ; Mon, 3 Jun 2002 15:59:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53Mxbqx021887 for linux-mips-outgoing; Mon, 3 Jun 2002 15:59:37 -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 g53MxUnC021881; Mon, 3 Jun 2002 15:59:30 -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 17F0nx-000Iml-00; Tue, 04 Jun 2002 01:00:01 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17F0p1-0001Sb-00; Tue, 04 Jun 2002 01:01:07 +0200 Date: Tue, 4 Jun 2002 01:01:07 +0200 To: Ralf Baechle Cc: "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603015536.B2832@dea.linux-mips.net> <20020603154011.A11393@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020603154011.A11393@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 21 Ralf Baechle wrote: > On Mon, Jun 03, 2002 at 08:30:09PM +0200, Maciej W. Rozycki wrote: > > > Well, 2.12.1 seem rock solid for me. The package I made available at my > > site only contains two patches that affect code (the rest is autoconf and > > similar stuff) and then only MIPS64. They can be safely discarded for > > pure MIPS work. > > > > For MIPS64 they definitely do not work, OTOH, including the N32 ABI. > > Are they good enough to build 64-bit kernels? One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs are zeroed out in a few cases where the assembler resolves them itself. The rest works for me quite nice. Thiemo [1] http://sources.redhat.com/ml/binutils/2002-05/msg00188.html From owner-linux-mips@oss.sgi.com Mon Jun 3 16:03: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 g53N3RnC022037 for ; Mon, 3 Jun 2002 16:03:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53N3RkH022036 for linux-mips-outgoing; Mon, 3 Jun 2002 16:03:27 -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 g53N3OnC022033 for ; Mon, 3 Jun 2002 16:03:25 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g53N4QE28881; Mon, 3 Jun 2002 16:04:26 -0700 Date: Mon, 3 Jun 2002 16:04:25 -0700 From: Ralf Baechle To: Thiemo Seufer Cc: "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603160425.A28859@dea.linux-mips.net> References: <20020603015536.B2832@dea.linux-mips.net> <20020603154011.A11393@dea.linux-mips.net> <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jun 04, 2002 at 01:01:07AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 572 Lines: 15 On Tue, Jun 04, 2002 at 01:01:07AM +0200, Thiemo Seufer wrote: > > > For MIPS64 they definitely do not work, OTOH, including the N32 ABI. > > > > Are they good enough to build 64-bit kernels? > > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs > are zeroed out in a few cases where the assembler resolves them itself. > The rest works for me quite nice. Wonderful. Due to the hackish way we're using to build 64-bit kernels for the currently supported targets we don't run into this problems, there are no R_MIPS_HIGHEST relocs ever. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 3 16:09: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 g53N9gnC022210 for ; Mon, 3 Jun 2002 16:09:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53N9gnn022209 for linux-mips-outgoing; Mon, 3 Jun 2002 16:09:42 -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 g53N9ZnC022206; Mon, 3 Jun 2002 16:09:36 -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 17F0xo-000IgK-00; Tue, 04 Jun 2002 01:10:12 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17F0ys-0001Tj-00; Tue, 04 Jun 2002 01:11:18 +0200 Date: Tue, 4 Jun 2002 01:11:18 +0200 To: Ralf Baechle Cc: Thiemo Seufer , "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603231118.GI23411@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603015536.B2832@dea.linux-mips.net> <20020603154011.A11393@dea.linux-mips.net> <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> <20020603160425.A28859@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020603160425.A28859@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 744 Lines: 20 Ralf Baechle wrote: > On Tue, Jun 04, 2002 at 01:01:07AM +0200, Thiemo Seufer wrote: > > > > > For MIPS64 they definitely do not work, OTOH, including the N32 ABI. > > > > > > Are they good enough to build 64-bit kernels? > > > > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs > > are zeroed out in a few cases where the assembler resolves them itself. > > The rest works for me quite nice. > > Wonderful. Due to the hackish way we're using to build 64-bit kernels > for the currently supported targets we don't run into this problems, > there are no R_MIPS_HIGHEST relocs ever. Well, for my I2 Impact I do. :-) I hope to get it running again with the current kernel (plus my patches) in the next days. Thiemo From owner-linux-mips@oss.sgi.com Mon Jun 3 16:14: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 g53NEEnC022431 for ; Mon, 3 Jun 2002 16:14:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53NEEoq022430 for linux-mips-outgoing; Mon, 3 Jun 2002 16:14:14 -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 g53NECnC022427 for ; Mon, 3 Jun 2002 16:14:12 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g53NFIU00385; Mon, 3 Jun 2002 16:15:18 -0700 Date: Mon, 3 Jun 2002 16:15:18 -0700 From: Ralf Baechle To: Thiemo Seufer Cc: "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603161518.B28859@dea.linux-mips.net> References: <20020603015536.B2832@dea.linux-mips.net> <20020603154011.A11393@dea.linux-mips.net> <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> <20020603160425.A28859@dea.linux-mips.net> <20020603231118.GI23411@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020603231118.GI23411@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jun 04, 2002 at 01:11:18AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 510 Lines: 13 On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote: > > Wonderful. Due to the hackish way we're using to build 64-bit kernels > > for the currently supported targets we don't run into this problems, > > there are no R_MIPS_HIGHEST relocs ever. > > Well, for my I2 Impact I do. :-) I hope to get it running again with > the current kernel (plus my patches) in the next days. Interesting. So you don't place the kernel into any of the 32-bit compatibility address spaces on that machine? Ralf From owner-linux-mips@oss.sgi.com Mon Jun 3 16:51: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 g53NpZnC023151 for ; Mon, 3 Jun 2002 16:51:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53NpYr6023150 for linux-mips-outgoing; Mon, 3 Jun 2002 16:51:34 -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 g53NpSnC023146; Mon, 3 Jun 2002 16:51:28 -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 17F1cL-000Inn-00; Tue, 04 Jun 2002 01:52:05 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17F1dP-0001eB-00; Tue, 04 Jun 2002 01:53:11 +0200 Date: Tue, 4 Jun 2002 01:53:11 +0200 To: Ralf Baechle Cc: Thiemo Seufer , "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020603235311.GJ23411@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603015536.B2832@dea.linux-mips.net> <20020603154011.A11393@dea.linux-mips.net> <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> <20020603160425.A28859@dea.linux-mips.net> <20020603231118.GI23411@rembrandt.csv.ica.uni-stuttgart.de> <20020603161518.B28859@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020603161518.B28859@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 731 Lines: 19 Ralf Baechle wrote: > On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote: > > > > Wonderful. Due to the hackish way we're using to build 64-bit kernels > > > for the currently supported targets we don't run into this problems, > > > there are no R_MIPS_HIGHEST relocs ever. > > > > Well, for my I2 Impact I do. :-) I hope to get it running again with > > the current kernel (plus my patches) in the next days. > > Interesting. So you don't place the kernel into any of the 32-bit > compatibility address spaces on that machine? Load address is 0xa800000020002000 (and my diff against CVS > 300k). :-) I'm busy because of Linuxtag now, I think I have time to provide some parts of this in about two weeks. Thiemo From owner-linux-mips@oss.sgi.com Mon Jun 3 18:09:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54197nC024171 for ; Mon, 3 Jun 2002 18:09:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54196I9024170 for linux-mips-outgoing; Mon, 3 Jun 2002 18:09:06 -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 g54193nC024167 for ; Mon, 3 Jun 2002 18:09:03 -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 g5419GN00987; Mon, 3 Jun 2002 21:09:16 -0400 Message-ID: <3CFC133C.8090802@embeddededge.com> Date: Mon, 03 Jun 2002 21:09:16 -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: James Simmons CC: "Kevin D. Kissell" , Jun Sun , Geert Uytterhoeven , "Steven J. Hill" , 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 Content-Length: 428 Lines: 16 James Simmons wrote: >>>Dan Malek also wrote a driver for MQ200. > 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. I wouldn't spend much time on it since the part is obsolete. You and I probably have the only boards with that part :-) I thought the driver was public, but if you can't find it I'll send you what I have. -- Dan From owner-linux-mips@oss.sgi.com Mon Jun 3 20:14: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 g543ECnC025916 for ; Mon, 3 Jun 2002 20:14:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g543ECYh025915 for linux-mips-outgoing; Mon, 3 Jun 2002 20:14:12 -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 g543E9nC025910 for ; Mon, 3 Jun 2002 20:14:10 -0700 Received: from aihana.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id UAA31733 for ; Mon, 3 Jun 2002 20:14:24 -0700 Date: Tue, 04 Jun 2002 12:14:39 +0900 Message-ID: From: Takeshi AIHANA To: linux-mips@oss.sgi.com Subject: Re: (Re-Send) shmctl() returns corrupt value on pb1000. In-Reply-To: <20020603.214957.105435769.nemoto@toshiba-tops.co.jp> References: <1022763778.1046.71.camel@aihana> <20020531.112847.74756483.nemoto@toshiba-tops.co.jp> <20020603.214957.105435769.nemoto@toshiba-tops.co.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386-redhat-linux) Organization: MontaVista Software Japan 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 Content-Length: 451 Lines: 16 At Mon, 03 Jun 2002 21:49:57 +0900 (JST), Atsushi Nemoto wrote: --- > Did you check the contents of 'shm_perm'? The type of shm_perm is > 'struct ipc64_perm' in kernel and 'struct ipc_perm' in libc. I > suppose these definitions are differ. Oops, I lost that member before 'shm_segs' in. Yes, you're right. So I agree that it should be updated glibc to 2.2.4 and then try to do. Thanks for your help. Regards. --- (TAKESHI - MontaVista Software) From owner-linux-mips@oss.sgi.com Tue Jun 4 04:31: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 g54BVDnC022507 for ; Tue, 4 Jun 2002 04:31:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54BVD0O022506 for linux-mips-outgoing; Tue, 4 Jun 2002 04:31:13 -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 g54BV0nC022502; Tue, 4 Jun 2002 04:31:04 -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 PAA00680; Tue, 4 Jun 2002 15:33:04 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA11982; Tue, 4 Jun 2002 15:26: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 PAA24621; Tue, 4 Jun 2002 15:27:08 +0400 (MSK) Message-ID: <3CFCA520.C3D7DC03@niisi.msk.ru> Date: Tue, 04 Jun 2002 15:31:44 +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: Ralf Baechle CC: Jun Sun , Alexandr Andreev , 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> <3CF745B7.16CD0387@niisi.msk.ru> <20020603015536.B2832@dea.linux-mips.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 405 Lines: 16 Ralf Baechle wrote: > > > > I understand, but is there any __official__ recommended versions of these > > > > utils? http://oss.sgi.com/mips/mips-howto.html is out-of-date :( > > Send patches. Does anybody have ideas what the patch shall contain? In the other words, what versions of binutils and gcc will be considered stable. > Nah, I don't consider myself an officer :-) Sure. :-) Regards, Gleb. From owner-linux-mips@oss.sgi.com Tue Jun 4 04:41: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 g54BfCnC025199 for ; Tue, 4 Jun 2002 04:41:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54BfCwX025198 for linux-mips-outgoing; Tue, 4 Jun 2002 04:41:12 -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 g54Bf1nC025195 for ; Tue, 4 Jun 2002 04:41:05 -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 PAA01065; Tue, 4 Jun 2002 15:43:06 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA12041; Tue, 4 Jun 2002 15:36:18 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA25417; Tue, 4 Jun 2002 15:37:41 +0400 (MSK) Message-ID: <3CFCA790.9C698A6D@niisi.msk.ru> Date: Tue, 04 Jun 2002 15:42:08 +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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 499 Lines: 21 Maciej, In previous version of your patch there was the change in mm/c-r3k.c: static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size) { - wbflush(); + iob(); r3k_flush_dcache_range(start, start + size); } Why did you drop it? It's definetely required. While you patch operates in unusual terms from hw point of view, it does right thins by stating that external wbs do differ from internal wb. Regards, Gleb. Ah. The patch shall be applied, certainly. From owner-linux-mips@oss.sgi.com Tue Jun 4 07:31: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 g54EVunC027808 for ; Tue, 4 Jun 2002 07:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54EVuSt027807 for linux-mips-outgoing; Tue, 4 Jun 2002 07:31: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 g54EVmnC027795; Tue, 4 Jun 2002 07:31:49 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18216; Tue, 4 Jun 2002 16:34:06 +0200 (MET DST) Date: Tue, 4 Jun 2002 16:34:06 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 In-Reply-To: <20020603154011.A11393@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 Content-Length: 863 Lines: 21 On Mon, 3 Jun 2002, Ralf Baechle wrote: > > For MIPS64 they definitely do not work, OTOH, including the N32 ABI. > > Are they good enough to build 64-bit kernels? Not yet. For N32 gas complains about 64-bit immediates and fails. For 64 there are a few problems I'm currently resolving, but the kernel links. As N32 is low priority for me, I'll get 64 fixed first, at least to the point non-PIC static executables such as Linux work. PIC and dynamic linking are next on my to-do list. I'm working on 2.12.90, though, as the MIPS/ELF backend was positively but extensively restructured, so the ultimate target is 2.13. For plain MIPS 2.12.90 seem OK. -- + 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 Jun 4 07:34: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 g54EYxnC027972 for ; Tue, 4 Jun 2002 07:34:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54EYxGx027971 for linux-mips-outgoing; Tue, 4 Jun 2002 07:34: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 g54EYqnC027968; Tue, 4 Jun 2002 07:34:53 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18282; Tue, 4 Jun 2002 16:37:12 +0200 (MET DST) Date: Tue, 4 Jun 2002 16:37:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: Ralf Baechle , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 In-Reply-To: <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> 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 Content-Length: 620 Lines: 15 On Tue, 4 Jun 2002, Thiemo Seufer wrote: > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs > are zeroed out in a few cases where the assembler resolves them itself. > The rest works for me quite nice. How about R_MIPS_26 relocs? I discovered they are broken for the 64 ABI (likely a RELA problem) and I am currently working on a fix. As a result of the bug a kernel executable is useless. -- + 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 Jun 4 07:36: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 g54EarnC028061 for ; Tue, 4 Jun 2002 07:36:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54EarTg028060 for linux-mips-outgoing; Tue, 4 Jun 2002 07:36:53 -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 g54EalnC028055; Tue, 4 Jun 2002 07:36:47 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18336; Tue, 4 Jun 2002 16:39:08 +0200 (MET DST) Date: Tue, 4 Jun 2002 16:39:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 In-Reply-To: <20020603160425.A28859@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 Content-Length: 573 Lines: 14 On Mon, 3 Jun 2002, Ralf Baechle wrote: > Wonderful. Due to the hackish way we're using to build 64-bit kernels > for the currently supported targets we don't run into this problems, > there are no R_MIPS_HIGHEST relocs ever. I've already cleaned up the crap in my tree and I'll make the changes available as soon as I have a version of binutils that actually works. -- + 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 Jun 4 07:50: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 g54EomnC028218 for ; Tue, 4 Jun 2002 07:50:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54EomCi028217 for linux-mips-outgoing; Tue, 4 Jun 2002 07:50:48 -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 g54EognC028214 for ; Tue, 4 Jun 2002 07:50:43 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA18686; Tue, 4 Jun 2002 16:52:36 +0200 (MET DST) Date: Tue, 4 Jun 2002 16:52:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again In-Reply-To: <3CFCA790.9C698A6D@niisi.msk.ru> 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 Content-Length: 1204 Lines: 34 On Tue, 4 Jun 2002, Gleb O. Raiko wrote: > In previous version of your patch there was the change in mm/c-r3k.c: > > static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long > size) > { > - wbflush(); > + iob(); > r3k_flush_dcache_range(start, start + size); > } > > Why did you drop it? It's definetely required. Nope, it wasn't dropped. It's included in a different patch, namely "patch-mips-2.4.18-20020412-wbflush-5". The patch depends on the "patch-mips-2.4.18-20020530-mb-wb-8" one, so I am not going to resubmit the former one for discussion here until (unless) we decide on the latter one. > While you patch operates in unusual terms from hw point of view, it does > right thins by stating that external wbs do differ from internal wb. What do you mean by "unusual terms"? The names of the macros? Well, they are based on what's used for other platforms and if treated as abstract names (as they should be) they actually reflect reality. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jun 4 10:41: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 g54HfDnC002316 for ; Tue, 4 Jun 2002 10:41:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54HfD4B002315 for linux-mips-outgoing; Tue, 4 Jun 2002 10:41:13 -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 g54Hf5nC002310 for ; Tue, 4 Jun 2002 10:41:07 -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 VAA07238; Tue, 4 Jun 2002 21:43:01 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA13814; Tue, 4 Jun 2002 21:38:21 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id VAA07610; Tue, 4 Jun 2002 21:40:15 +0400 (MSK) Message-ID: <3CFCFC79.E846226B@niisi.msk.ru> Date: Tue, 04 Jun 2002 21:44:25 +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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1434 Lines: 40 "Maciej W. Rozycki" wrote: > > Why did you drop it? It's definetely required. > > Nope, it wasn't dropped. It's included in a different patch, namely > "patch-mips-2.4.18-20020412-wbflush-5". The patch depends on the > "patch-mips-2.4.18-20020530-mb-wb-8" one, so I am not going to resubmit > the former one for discussion here until (unless) we decide on the latter > one. Don't forget the latter one. :-) > > > While you patch operates in unusual terms from hw point of view, it does > > right thins by stating that external wbs do differ from internal wb. > > What do you mean by "unusual terms"? The names of the macros? Well, > they are based on what's used for other platforms and if treated as > abstract names (as they should be) they actually reflect reality. > Basically, the patch logically allows combination of a CPU with internal write-buffer and an external wb chip. It's impossible if hw designers don't smoke hard. :-) In fact, CONFIG_CPU_HAS_WB means !CONFIG_CPU_HAS_WB, i.e. CPU don't have built-in write-buffer logic and there is an external write-buffer chip somewhere in the box. ("Somewhere" means a place on the path from the local bus to a memory controller.) Then, __fast_iob just flushes internal wb while wbflush flushes an external wb. That's why I call it "unusual terms from hw POV". But, don't reimplement the patch, please. It's OK. Just from software point of view. Regards, Gleb. From owner-linux-mips@oss.sgi.com Tue Jun 4 10:42:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54Hg6nC002349 for ; Tue, 4 Jun 2002 10:42:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54Hg6Ls002348 for linux-mips-outgoing; Tue, 4 Jun 2002 10:42:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54HfmnC002341; Tue, 4 Jun 2002 10:41:48 -0700 Received: from ns.snowman.net (localhost [127.0.0.1]) by ns.snowman.net (8.12.3/8.12.3/Debian -4) with ESMTP id g54HfZjT003477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 4 Jun 2002 13:41:36 -0400 From: nick@snowman.net Received: from localhost (nick@localhost) by ns.snowman.net (8.12.3/8.12.3/Debian -4) with ESMTP id g54HfZtO003471; Tue, 4 Jun 2002 13:41:35 -0400 X-Authentication-Warning: ns.snowman.net: nick owned process doing -bs Date: Tue, 4 Jun 2002 13:41:34 -0400 (EDT) X-Sender: nick@ns To: Thiemo Seufer cc: Ralf Baechle , "Maciej W. Rozycki" , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 In-Reply-To: <20020603235311.GJ23411@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 930 Lines: 28 Do you have gfx working on i2 impact? Is it also an R10k system, or are you useing an r4k system? Thanks Nick On Tue, 4 Jun 2002, Thiemo Seufer wrote: > Ralf Baechle wrote: > > On Tue, Jun 04, 2002 at 01:11:18AM +0200, Thiemo Seufer wrote: > > > > > > Wonderful. Due to the hackish way we're using to build 64-bit kernels > > > > for the currently supported targets we don't run into this problems, > > > > there are no R_MIPS_HIGHEST relocs ever. > > > > > > Well, for my I2 Impact I do. :-) I hope to get it running again with > > > the current kernel (plus my patches) in the next days. > > > > Interesting. So you don't place the kernel into any of the 32-bit > > compatibility address spaces on that machine? > > Load address is 0xa800000020002000 (and my diff against CVS > 300k). :-) > I'm busy because of Linuxtag now, I think I have time to provide some > parts of this in about two weeks. > > > Thiemo > From owner-linux-mips@oss.sgi.com Tue Jun 4 11:05: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 g54I5xnC002854 for ; Tue, 4 Jun 2002 11:05:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54I5xkp002853 for linux-mips-outgoing; Tue, 4 Jun 2002 11:05:59 -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 g54I5qnC002850 for ; Tue, 4 Jun 2002 11:05: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 WAA07398; Tue, 4 Jun 2002 22:07:59 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id WAA13933; Tue, 4 Jun 2002 22:03: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 WAA07935; Tue, 4 Jun 2002 22:04:08 +0400 (MSK) Message-ID: <3CFD0211.17024F14@niisi.msk.ru> Date: Tue, 04 Jun 2002 22:08:17 +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: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Bug in copy_user Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 962 Lines: 36 There is bug in __copy_user (arch/mips*/lib/memcpy.S). Tested for 2.4.18 kernels, but versions 2.2, 2.4, and 2.5 for both mips and mips64 seems to have similar bug. For kernel 2.4.18 and mips __copy_user returns wrong value if len = 4...7 and dst isn't accessible. Other versions behave almost the same, just borders differ. For example, read(0,NULL,len), len=4...7 getsockopt/ioctl(fd, *GET*, NULL, sizeof(int)) returns success. Fortunately, they don't write to at address 0. The following patch seems to be OK for 2.4.18: less_than_4units: /* * rem = len % NBYTES */ beq rem, len, copy_bytes nop 1: EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES -EXC( STORE t0, 0(dst), s_exc) +EXC( STORE t0, 0(dst), s_exc_p1u) bne rem, len, 1b ADD dst, dst, NBYTES Any comments? Regards, Gleb. From owner-linux-mips@oss.sgi.com Tue Jun 4 11:53: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 g54IrOnC003742 for ; Tue, 4 Jun 2002 11:53:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54IrO5I003741 for linux-mips-outgoing; Tue, 4 Jun 2002 11:53:24 -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 g54IrEnC003736 for ; Tue, 4 Jun 2002 11:53:15 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA25734; Tue, 4 Jun 2002 20:55:20 +0200 (MET DST) Date: Tue, 4 Jun 2002 20:55:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux: mb() and friends again In-Reply-To: <3CFCFC79.E846226B@niisi.msk.ru> 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 Content-Length: 2439 Lines: 54 On Tue, 4 Jun 2002, Gleb O. Raiko wrote: > Basically, the patch logically allows combination of a CPU with internal > write-buffer and an external wb chip. It's impossible if hw designers > don't smoke hard. :-) Well, I believe it might be useful -- if a CPU uses a higher clock for its pipeline and a lower one for its external bus, it might be useful to buffer a few words internally to avoid stalls at two consecutive writes. Then you may have an additional buffer externally to lower the number of stalls on memory or I/O (generally the rest of a system) accesses. Essentially a buffer every time you cross a frequency domains' border, leaving the faster one. You need at least a single-word buffer at each such border anyway if you don't want to stall the whole system for any cycle accessing slower domains. Consider it a complement of a hierarchical cache organization -- I've seen (and actually used) systems with up to three levels of caches. > In fact, CONFIG_CPU_HAS_WB means !CONFIG_CPU_HAS_WB, i.e. CPU don't have > built-in write-buffer logic and there is an external write-buffer chip > somewhere in the box. > ("Somewhere" means a place on the path from the local bus to a memory > controller.) That's a bit awkward possibly, but "has" has a wide meaning and does not necessarily state "contains". It might mean "owns" as well. For R[23]k CPUs the option originally corresponded to external R2020 and R3220 chips (just like floating point units may be external but still be considered a part of a CPU) that were treated as a part of coprocessor 0 (with "bc0f" or "bc0t" instructions testing their state). Besides, who says discrete CPUs are forbidden? ;-) > Then, __fast_iob just flushes internal wb while wbflush flushes an > external wb. Well, that's used by __wbflush internally if it knows there is no external buffer that needs explicit handling (for the DECstation, at least -- other systems might make use of it as well). That's unused in this patch but is needed in the other one -- well, I had to split these patches logically somehow and this one only contains system-independent code. > That's why I call it "unusual terms from hw POV". Hopefully, I clarified the terms a bit. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jun 4 13:03: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 g54K3hnC006160 for ; Tue, 4 Jun 2002 13:03:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54K3hZN006159 for linux-mips-outgoing; Tue, 4 Jun 2002 13:03:43 -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 g54K3dnC006156 for ; Tue, 4 Jun 2002 13:03: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 g54K5RTP006694; Tue, 4 Jun 2002 13:05:27 -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 g54K5RnI006690; Tue, 4 Jun 2002 13:05:27 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 4 Jun 2002 13:05:27 -0700 (PDT) From: James Simmons To: Linux Fbdev development list cc: Linux Kernel Mailing List , , Subject: [PATCH] fbdev updates. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 512 Lines: 26 Hi! This patch includes the latest in the fbdev BK repository. I have modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the new api. Please test these changes out before I submit them to linus. Thank you. It is against the latest BK tree and 2.5.20. diff: http://www.transvirtual.com/~jsimmons/fbdev.diff.gz BK: http://fbdev.bkbits.net:8080/fbdev-2.5 . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ From owner-linux-mips@oss.sgi.com Tue Jun 4 22:23: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 g555N2nC020248 for ; Tue, 4 Jun 2002 22:23:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g555N1eR020247 for linux-mips-outgoing; Tue, 4 Jun 2002 22:23:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g555MwnC020244 for ; Tue, 4 Jun 2002 22:22:59 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id g555OrS17591 for ; Wed, 5 Jun 2002 07:24:53 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M24KSFFZ; Wed, 5 Jun 2002 07:24:52 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Wed, 05 Jun 2002 07:24:52 +0200 Received: by DLFW003A with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 07:25:04 +0200 Message-ID: <86048F07C015D311864100902760F1DD01B5EA6B@DLFW003A> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: kmalloc question Date: Wed, 5 Jun 2002 07:25:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 321 Lines: 16 Hi. I always thought that it is save to use kmalloc in an interrupt handler as long as you use GFP_ATOMIC. Now someone told me that it is not allowed to use these functions in any way in an interrupt. Can please someone clarify me here? regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Wed Jun 5 08:12: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 g55FC8nC008113 for ; Wed, 5 Jun 2002 08:12:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FC8Op008112 for linux-mips-outgoing; Wed, 5 Jun 2002 08:12:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FBgnC007957 for ; Wed, 5 Jun 2002 08:11:46 -0700 Received: from gladsmuir.algor.co.uk (gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g55FDRd18944; Wed, 5 Jun 2002 16:13:28 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MwF7gxnaJe" Content-Transfer-Encoding: 7bit Message-ID: <15614.10904.705392.925058@gladsmuir.algor.co.uk> Date: Wed, 5 Jun 2002 16:13:28 +0100 To: Joe Buck Cc: echristo@redhat.com (Eric Christopher), dom@algor.co.uk (Dominic Sweetman), js@convergence.de (Johannes Stezenbach), gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] In-Reply-To: <200205312144.OAA15256@atrus.synopsys.com> References: <1022870431.3668.19.camel@ghostwheel.cygnus.com> <200205312144.OAA15256@atrus.synopsys.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8851 Lines: 154 --MwF7gxnaJe Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Joe Buck (Joe.Buck@synopsys.com) writes: > 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. I signed the assignment/waiver. The companies involved are Algorithmics Ltd and DFS3 Ltd. It was faxed to Jim Wilson (then at Cygnus) in October 1993 in the form recommended at that time. Here's a PDF. Note the 'company stationery' has changed since 1993... --MwF7gxnaJe Content-Type: application/pdf Content-Disposition: attachment; filename="gnu-disclaimer.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nJ1WXXfaOBB996+Yt5KzoJVkyZJ4S0Og3UOTNGHP7kNfjHHAXX+0 xpwc/n1nJBtI2r5schLG0ujOvfMhw5kATr/9Z1ZF36M/HxVs95GAIpKGczDGWKgu7DKSCedM u/AotcSNxBmmRP+gnYUsCrZyllxPR5TAIx6LrCxSRvR2GSnLHaH4R2Xd+Xh4CLjB7gOejhCV gEVWFj1HMYcXlLFAuolllnyUYkZ6MbFggthowaSXpHVMltFJQr7oY1VC3iaRjnzL6ClCWi8R J0htFKM945jxzlIzOi0SFvsMCYuGUUayENAKdDRGxswGKEKxtldFCDYJdtnbmCSKLy2Xnoex qs8cWZRfTAFR9htaqPMR/zBUgWzlNLmejighT1WQ5DUE8Rs+/HDkxCvzrLfRdxC+aYaPrIL3 K2wbB5jx1XMUegl7wUmfEgmrKhqlV6uvkXAstri52kSjkhYcS7RzLixhKWCVRaNt09Keskzo 3rn4yXnUeUDUq/qFXVVktJZgkLhf29PC7Qo+Y9V+z1wIpIvMcUPARJAAbbiXg8yhBCAY9IsH P8uMvvBUhllcQG9scqEkpoyEXC8X948fVx8+fbx5GsNql8O8PRQdzNO2GsNteYTHJt2M4WZX dF3eFvUW7bRa7+HmvQb38AGd7hbL67vZSYZU1NWcOR1jA2mliSbH/vGmon/UXb9VqgcFLiiQ pEC5XivHUeJSB/awul1O3yjXTEinh4z/oRQIKbHPeSI5713PyZQXASROBo4PBQnoAAc4JfZ3 tKTSWHT5E7f59b9vqSmmtZT2V9S0p4aITCK4YdRVGlUo3ddMOK5MQH68XcD9fP7x5nb6hpxj nFsj+wD/o5qv+cYxc+rUqAAU+O7+bVCcUPaKsxEG2zvpecf043mjhFgKHYQmXqgNh5Q8C1X2 p8aE5Wo2BDVUs4sRRrWJE4w7Oj3Brgs5WjV+9iSLh3RgmXi/Of2LNvE2FWErlLuo4B9alwnT QwqLct/UmKPjtj74QZ1gLOeoaxQ54B1tic9LNJqlXT4F2+3IDe9coU7guHufdc06b0E4F3uc 4NHDSMtUorzjvG2qKcyaqqjDXSE4Xtv8FdjTS553VYrErku8iYqO7pVAb/DugTEhIuTzIdxu yFdeiEatvncRdJvvpyD6LLs+y5NwYGKMR8M3EmLTOSa59cdWDbz4rGFzJ+oCOlDdNRVgA1bp EbKmznJ/bTrFhiGo35QVA+LdiEAT6e9adLnUCMtuA2m9gdn8KfYPzTPEMGvTY9fU8OCZSHMS OUrb/8awbOoN7t5hw979Dbu8zddH2BT7rEyx6Gnp7/lJf67P3ChrvvmMGS81oB3bYrvroKhx ePI9GZDt0hpThwo3OSDsXbHNS3jq8m+7vN6PYZG3abmB+7po6j00Lc5eW+xhluNIpnWoWQgx BO4a2DeHNssxYxtERqJdW6xDL9A3ikHbocs3cKg32FYdjjpyqvaUD3pYoNBFXlNweDisyyID /ENG+RhZZ+Vhg8Pfd0zAHMJ/Ga3Dmwy/Z3BxCgV10yGvMi+PX65gcXPjyzCEatZf86yDQ1eU RVfkexZmpcc41/Kp2Nb5ZurfgTjvSxyb0Okw9PTVu4iI4M6ntE63yBJmRYvg+MZ9F+H0iaHL wqUyvvaJUSx51X2jN01zHg55zvQJGDdjxzR/jTz7NXLfeez0wvsc/QCNkIBPZW5kc3RyZWFt CmVuZG9iago3IDAgb2JqCjEyNzMKZW5kb2JqCjIwIDAgb2JqCjw8L1I0CjQgMCBSPj4KZW5k b2JqCjIxIDAgb2JqCjw8L1IxMQoxMSAwIFIvUjEzCjEzIDAgUi9SMTUKMTUgMCBSL1IxOQox OSAwIFIvUjE3CjE3IDAgUi9SOQo5IDAgUj4+CmVuZG9iago1IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMCAwIFIKL0ZvbnQgMjEg MCBSCj4+Ci9Db250ZW50cyA2IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL0tpZHMgWwo1IDAgUgpdIC9Db3VudCAxCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUg L0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvRXh0R1N0 YXRlL05hbWUvUjQvVFIvSWRlbnRpdHk+PgplbmRvYmoKMTEgMCBvYmoKPDwvU3VidHlwZS9U eXBlMS9CYXNlRm9udC9aYXBmRGluZ2JhdHMvVHlwZS9Gb250L05hbWUvUjExPj4KZW5kb2Jq CjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvWmFwZkRpbmdiYXRz Pj4KZW5kb2JqCjEzIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSGVsdmV0aWNh LUJvbGQvVHlwZS9Gb250L05hbWUvUjEzPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUvRm9u dERlc2NyaXB0b3IvRm9udE5hbWUvSGVsdmV0aWNhLUJvbGQ+PgplbmRvYmoKMTUgMCBvYmoK PDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9IZWx2ZXRpY2EvVHlwZS9Gb250L05hbWUvUjE1 Pj4KZW5kb2JqCjE4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGlt ZXMtQm9sZD4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRO YW1lL1RpbWVzLVJvbWFuPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvSGVsdmV0aWNhPj4KZW5kb2JqCjE5IDAgb2JqCjw8L1N1YnR5cGUvVHlw ZTEvQmFzZUZvbnQvVGltZXMtQm9sZC9UeXBlL0ZvbnQvTmFtZS9SMTkvRmlyc3RDaGFyIDAv TGFzdENoYXIgMjU1L1dpZHRoc1sKNTgxIDUyMCA1NTYgNjY3IDM4OSA0NDQgNzIyIDEwMDAg Mjc4IDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MAoyNTAgMjUwIDI1MCAyNTAgMjUwIDI1 MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAKMjUwIDMzMyA1NTUg NTAwIDUwMCAxMDAwIDgzMyAzMzMgMzMzIDMzMyA1MDAgNTcwIDI1MCAzMzMgMjUwIDI3OAo1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgNTcw IDU3MCA1MDAKOTMwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3 NzggNjY3IDk0NCA3MjIgNzc4CjYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcy MiA3MjIgNjY3IDMzMyAyNzggMzMzIDMzMyA1MDAKMzMzIDUwMCA1NTYgNDQ0IDU1NiA0NDQg MzMzIDUwMCA1NTYgMjc4IDMzMyA1NTYgMjc4IDgzMyA1NTYgNTAwCjU1NiA1NTYgNDQ0IDM4 OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUwMCA0NDQgMzk0IDIyMCAzOTQgMzMzIDI1MAozMzMg NTAwIDUwMCAzNTAgNTAwIDE2NyAxMDAwIDUwMCA1MDAgNTAwIDEwMDAgMjUwIDU1NiA1NTYg MjUwIDI1MAoyNzggMjUwIDMzMyAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyA1MDAgNTAwIDcy MiAyNzggNTAwIDEwMDAgNjY3CjI1MCAzMzMgNTAwIDUwMCA1MDAgNTAwIDIyMCA1MDAgMzMz IDc0NyAzMDAgMzMzIDU3MCA1NzAgNzQ3IDMzMwo0MDAgNTcwIDMwMCAzMDAgMzMzIDU1NiA1 NDAgMjUwIDMzMyAzMDAgMzMwIDMzMyA3NTAgNzUwIDc1MCA1MDAKNzIyIDcyMiA3MjIgNzIy IDcyMiA3MjIgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDM4OSAzODkgMzg5IDM4OQo3MjIg NzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTcwIDc3OCA3MjIgNzIyIDcyMiA3MjIgNzIyIDYx MSA1NTYKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNzIyIDQ0NCA0NDQgNDQ0IDQ0NCA0NDQg Mjc4IDI3OCAyNzggMjc4CjUwMCA1NTYgNTAwIDUwMCA1MDAgNTAwIDUwMCA1NzAgNTAwIDU1 NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMF0KPj4KZW5kb2JqCjE3IDAgb2JqCjw8L1N1YnR5 cGUvVHlwZTEvQmFzZUZvbnQvVGltZXMtUm9tYW4vVHlwZS9Gb250L05hbWUvUjE3L0ZpcnN0 Q2hhciAwL0xhc3RDaGFyIDI1NS9XaWR0aHNbCjQ2OSA1NDEgNTU2IDYxMSAzODkgNDQ0IDcy MiA5ODAgMTgwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MAoyNTAgMjUwIDI1MCAyNTAg MjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAgMjUwIDI1MCAyNTAKMjUwIDMz MyA0MDggNTAwIDUwMCA4MzMgNzc4IDMzMyAzMzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAg Mjc4CjUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2 NCA1NjQgNTY0IDQ0NAo5MjEgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMg Mzg5IDcyMiA2MTEgODg5IDcyMiA3MjIKNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgNzIyIDk0 NCA3MjIgNzIyIDYxMSAzMzMgMjc4IDMzMyAzMzMgNTAwCjMzMyA0NDQgNTAwIDQ0NCA1MDAg NDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMAo1MDAgNTAwIDMz MyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgwIDMzMyAyNTAK MzMzIDUwMCA1MDAgMzUwIDUwMCAxNjcgMTAwMCA1MDAgNTAwIDUwMCAxMDAwIDI1MCA1NTYg NTU2IDI1MCAyNTAKMjc4IDI1MCAzMzMgMzMzIDMzMyAzMzMgMzMzIDMzMyAzMzMgNDQ0IDQ0 NCA3MjIgMjc4IDQ0NCA4ODkgNjExCjI1MCAzMzMgNTAwIDUwMCA1MDAgNTAwIDIwMCA1MDAg MzMzIDc2MCAyNzYgMzMzIDU2NCA1NjQgNzYwIDMzMwo0MDAgNTY0IDMwMCAzMDAgMzMzIDUw MCA0NTMgMjUwIDMzMyAzMDAgMzEwIDMzMyA3NTAgNzUwIDc1MCA0NDQKNzIyIDcyMiA3MjIg NzIyIDcyMiA3MjIgODg5IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzCjcy MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NjQgNzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIg NTU2IDUwMAo0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0 NCAyNzggMjc4IDI3OCAyNzgKNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU2NCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwXQo+PgplbmRvYmoKOSAwIG9iago8PC9TdWJ0 eXBlL1R5cGUxL0Jhc2VGb250L0hlbHZldGljYS1PYmxpcXVlL1R5cGUvRm9udC9OYW1lL1I5 Pj4KZW5kb2JqCjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9IZWx2 ZXRpY2EtT2JsaXF1ZT4+CmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyIChHTlUgR2hvc3Rz Y3JpcHQgNi41MSkKPj5lbmRvYmoKeHJlZgowIDIyCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDAwMTcxMiAwMDAwMCBuIAowMDAwMDA0Nzc1IDAwMDAwIG4gCjAwMDAwMDE2NTMgMDAwMDAg biAKMDAwMDAwMTc2MCAwMDAwMCBuIAowMDAwMDAxNDkzIDAwMDAwIG4gCjAwMDAwMDAwMTUg MDAwMDAgbiAKMDAwMDAwMTM1OCAwMDAwMCBuIAowMDAwMDA0NzA4IDAwMDAwIG4gCjAwMDAw MDQ2MjkgMDAwMDAgbiAKMDAwMDAwMTg5MSAwMDAwMCBuIAowMDAwMDAxODE1IDAwMDAwIG4g CjAwMDAwMDIwMzIgMDAwMDAgbiAKMDAwMDAwMTk1NCAwMDAwMCBuIAowMDAwMDAyMjkzIDAw MDAwIG4gCjAwMDAwMDIwOTcgMDAwMDAgbiAKMDAwMDAwMjIzMSAwMDAwMCBuIAowMDAwMDAz NDkzIDAwMDAwIG4gCjAwMDAwMDIxNzAgMDAwMDAgbiAKMDAwMDAwMjM1MyAwMDAwMCBuIAow MDAwMDAxMzc4IDAwMDAwIG4gCjAwMDAwMDE0MDggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6 ZSAyMiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgo+PgpzdGFydHhyZWYKNDgyNwolJUVPRgo= --MwF7gxnaJe Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Let me know if you need a contemporary form. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk --MwF7gxnaJe-- From owner-linux-mips@oss.sgi.com Wed Jun 5 08:38: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 g55FcFnC017998 for ; Wed, 5 Jun 2002 08:38:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FcFYn017996 for linux-mips-outgoing; Wed, 5 Jun 2002 08:38:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FbsnC017885 for ; Wed, 5 Jun 2002 08:37:57 -0700 Received: from gladsmuir.algor.co.uk (gladsmuir.algor.co.uk [192.168.5.75]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g55Fdid20257; Wed, 5 Jun 2002 16:39:45 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15614.12481.424601.806779@gladsmuir.algor.co.uk> Date: Wed, 5 Jun 2002 16:39:45 +0100 To: Eric Christopher Cc: Dominic Sweetman , Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] In-Reply-To: <1022870431.3668.19.camel@ghostwheel.cygnus.com> References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> <1022870431.3668.19.camel@ghostwheel.cygnus.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4199 Lines: 108 Eric, > 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. I fear it's "when time permits" at the moment. The number of changes is sufficiently large that it will take concentrated effort for 2-4 weeks, and this is very difficult to find. > > 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... Hmm. Linux/MIPS suffers from widespread and diffuse toolchain problems: I thought that much was pretty clear to all involved. I agree it seems a pity that the scheme of work laid out above should be necessary... > 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. Rather than snow you with a hundred compiler patches, I wonder whether it might be better to share our regression test changes? The tests are likely to be a whole lot more portable than compiler patches. If you run them on a recent GCC 3.x compiler, you'll be in a much better position to know to what extent our 2.96+ work is still relevant. If this seems a good idea please mailto:sde@algor.co.uk and we'll ftp the test sources to the place of your choice, or point you at them on our web server. > I'm putting in a lot of effort to cleaning up the MIPS port and am > committed to the architecture. It sounds like you're in the role of maintainer of GCC for MIPS targets. You may not be free to answer this: but does that mean that Red Hat have guaranteed you'll have the time to fulfill that responsibility even during periods when Red Hat don't happen to win relevant contracts from MIPS vendors? If so that would be excellent... > > 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. During most of the last few years (as I understand it) it has been difficult to establish a baseline to patch against, or find someone who had the time to attend to bug reports. As you'll know it's much harder to test the compiler as used for 'embedded' targets, because the diversity of OS' used makes it hard to re-use tests. Something better should be possible now Linux/MIPS is less flaky. > Almost 90% of the bug reports I see are against IRIX. That does suggest you're missing some pretty large chunks of the community! > 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. We believe that a large number of man hours will be required to identify and merge all major valuable features and then chase out the bugs, before there can be a release which everyone has reason to adopt. We certainly can't afford to put in those hours unless we win contracts; I suspect Red Hat can't, either. -- Dominic Sweetman Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Wed Jun 5 09:00:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55G07nC026170 for ; Wed, 5 Jun 2002 09:00:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55G07fs026169 for linux-mips-outgoing; Wed, 5 Jun 2002 09:00:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from cygnus.com (sunnyvale.sfbay.redhat.com [205.180.83.203]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FxwnC026105 for ; Wed, 5 Jun 2002 08:59:59 -0700 Received: from porcupine.cygnus.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA15026 for ; Wed, 5 Jun 2002 09:01:49 -0700 (PDT) Received: from porcupine.cygnus.com (IDENT:Xg2PSi8d70GpS4P7V7SQr7G2jAfw6mgj@localhost.localdomain [127.0.0.1]) by porcupine.cygnus.com (8.12.2/8.12.2) with ESMTP id g55G52I7001379; Wed, 5 Jun 2002 10:05:02 -0600 Received: from porcupine.cygnus.com (law@localhost) by porcupine.cygnus.com (8.12.2/8.12.2/Submit) with ESMTP id g55G51HH001376; Wed, 5 Jun 2002 10:05:01 -0600 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Dominic Sweetman cc: Joe Buck , echristo@redhat.com (Eric Christopher), js@convergence.de (Johannes Stezenbach), gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] Reply-To: law@redhat.com From: law@redhat.com In-reply-to: Your message of Wed, 05 Jun 2002 16:13:28 BST. <15614.10904.705392.925058@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jun 2002 10:05:01 -0600 Message-ID: <1375.1023293101@porcupine.cygnus.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1389 Lines: 36 In message <15614.10904.705392.925058@gladsmuir.algor.co.uk>, Dominic Sweetman writes: > > --MwF7gxnaJe > Content-Type: text/plain; charset=us-ascii > Content-Description: message body text > Content-Transfer-Encoding: 7bit > > > Joe Buck (Joe.Buck@synopsys.com) writes: > > > 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. > > I signed the assignment/waiver. The companies involved are > Algorithmics Ltd and DFS3 Ltd. It was faxed to Jim Wilson (then at > Cygnus) in October 1993 in the form recommended at that time. Here's > a PDF. Note the 'company stationery' has changed since 1993... What's important here is the assignment that is on file with the FSF. That's what needs to be checked. jeff From owner-linux-mips@oss.sgi.com Wed Jun 5 09:31: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 g55GVBnC005909 for ; Wed, 5 Jun 2002 09:31:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55GVBD1005908 for linux-mips-outgoing; Wed, 5 Jun 2002 09:31:11 -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 g55GV7nC005863 for ; Wed, 5 Jun 2002 09:31:08 -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 g55HO6DS002883; Wed, 5 Jun 2002 18:24:07 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g55HO28D002871; Wed, 5 Jun 2002 18:24:02 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: kmalloc question From: Alan Cox To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com In-Reply-To: <86048F07C015D311864100902760F1DD01B5EA6B@DLFW003A> References: <86048F07C015D311864100902760F1DD01B5EA6B@DLFW003A> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Jun 2002 18:24:02 +0100 Message-Id: <1023297842.2443.2.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 449 Lines: 13 On Wed, 2002-06-05 at 06:25, Andre.Messerschmidt@infineon.com wrote: > Hi. > > I always thought that it is save to use kmalloc in an interrupt handler as > long as you use GFP_ATOMIC. > Now someone told me that it is not allowed to use these functions in any way > in an interrupt. > > Can please someone clarify me here? GFP_ATOMIC is safe in an interrupt handler. You might get NULL back and that it is your problem, but the kmalloc is safe From owner-linux-mips@oss.sgi.com Wed Jun 5 10:55: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 g55HtEnC013000 for ; Wed, 5 Jun 2002 10:55:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55HtE87012999 for linux-mips-outgoing; Wed, 5 Jun 2002 10:55:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (01-026.118.popsite.net [66.19.120.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55Ht7nC012994 for ; Wed, 5 Jun 2002 10:55:08 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17FeyE-00016J-00; Wed, 05 Jun 2002 13:53:18 -0400 Date: Wed, 5 Jun 2002 13:53:18 -0400 From: Daniel Jacobowitz To: Dominic Sweetman Cc: Eric Christopher , Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] Message-ID: <20020605175318.GA4030@nevyn.them.org> Mail-Followup-To: Dominic Sweetman , Eric Christopher , Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> <1022870431.3668.19.camel@ghostwheel.cygnus.com> <15614.12481.424601.806779@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15614.12481.424601.806779@gladsmuir.algor.co.uk> User-Agent: Mutt/1.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1362 Lines: 32 On Wed, Jun 05, 2002 at 04:39:45PM +0100, Dominic Sweetman wrote: > > I'm not certain what you are actually fixing here as I've not seen any > > descriptions of problems here... > > Hmm. Linux/MIPS suffers from widespread and diffuse toolchain > problems: I thought that much was pretty clear to all involved. I > agree it seems a pity that the scheme of work laid out above should be > necessary... ... > > Almost 90% of the bug reports I see are against IRIX. > > That does suggest you're missing some pretty large chunks of the > community! No, that's not what it suggests at all. It suggests to me that the dubious state of Linux/MIPS toolchains is due to one of two things: - A pre-existing acceptance of this rather than any real problems - A reluctance to file bug reports We've been using GCC for MIPS for several years now and seen relatively few significant problems, so I suspect the former. There's definitely some of the latter as well, since we've hit more roadblocks on MIPS than on, say, x86 or PowerPC; it's not our worst problem architecture, though. And we've been able to fix them all relatively easily. I'm sure GCC would benefit from access to your regression tests, though :) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Jun 5 13:13: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 g55KDInC016580 for ; Wed, 5 Jun 2002 13:13:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55KDIfA016579 for linux-mips-outgoing; Wed, 5 Jun 2002 13:13:18 -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 g55KCrnC016572 for ; Wed, 5 Jun 2002 13:12:53 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g55KCV510846; Wed, 5 Jun 2002 13:12:31 -0700 Date: Wed, 5 Jun 2002 13:12:31 -0700 From: William Jhun To: "linux-kernel@vger.kernel.org"@ayrnetworks.com Cc: "linux-mips@oss.sgi.com"@ayrnetworks.com, davem@redhat.com Subject: Deprecate pci_dma_sync_{single,sg}()? Message-ID: <20020605131231.B10773@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 Content-Length: 8586 Lines: 204 While introducing the pci_dma_prep_{single,sg}() interface, it occured to me that there are some subtle problems with the old interface and its implementation on non-cache-coherent systems. For example, a PCI driver might do the following on a buffer: pci_map_single(..., FROM_DEVICE) pci_dma_sync_single(..., FROM_DEVICE) pci_unmap_single(..., FROM_DEVICE) This happens in certain network drivers (tulip, pcnet32...) when determining whether the packet is small enough to make a copy (and leave the buffer on the RX ring). In the current linux-mips implementation, this has some subtle problems: pci_unmap_{single,sg}() is essentially a no-op. Thus, in the above example, a driver would break (stale cachelines from a previous pci_dma_sync_*/read would not be invalidated). One might argue that a cache invalidate should happen in the pci_unmap_single(). But then the other case (where a driver does a pci_map, DMAs, does a pci_unmap, and sends it up the stack) would require an additional cache flush/invalidate that is not needed at all. In fact, when using pci_dma_sync_{single,sg}() on a non-cache-coherent system, a cache flush/invalidate happens needlessly as the buffer had already been flushed in pci_map_{single,sg}(). These extra flushes do have significant performance hits, even if not noticeable through typical light use. As such, it seems that it makes sense to do cache flushes only in pci_map_{single,sg}() and pci_dma_prep_{single,sg}() (see Message-ID: <20020526000933.A8719@ayrnetworks.com>, [PATCH] DMA-mapping.txt) and mandate that pci_dma_prep_{single,sg}() be called when returning a "touched" buffer to the device for another DMA (between pci_map_* and pci_unmap_*). The cache flush in pci_dma_sync_{single,sg}() would be removed. The problem with this is that it will break some existing drivers that don't yet call pci_dma_prep_*() (e.g., tulip). Would it be possible to keep (but deprecate) pci_dma_sync_*() and make a similar call "pci_dma_release_{single,sg}()" which does the same thing as pci_dma_sync_*() while omitting the cache flushes? Thus, the above example would become: pci_map_single(..., FROM_DEVICE) [cache invalidate] pci_dma_release_single(..., FROM_DEVICE) [no cache invalidate, but might perform PCI controller-specific operations to allow the CPU to view DMAed data] pci_dma_prep_single(..., FROM_DEVICE) [cache invalidate] pci_unmap_single(..., FROM_DEVICE) [no need for cache invalidate] This interface allows for: 1) A clean abstraction of what (the device or the driver) "owns" the buffer and can touch it. pci_map_* and pci_dma_prep_* "give" the buffer to the device, pci_unmap_* and pci_dma_release_* "take" the buffer from the device. Adds an entry point into platform-specific code for each of these transitions. 2) More optimal behavior in non-cache-coherent I/O situations; a buffer is never needlessly flushed/invalidated in the cache when the buffer is "owned" by the device. 3) Ability to re-use a buffer for PCI_DMA_TODEVICE operations without having to unmap/map between DMA transfers. The usage of the calls are the same, regardless of DMA direction. 4) The old interface (using pci_dma_sync_*()) will still remain for the time being, allowing for gradual migration to the new interface. Changes to Documentation/DMA-mapping.txt in vger are attached. Thanks, William --- Index: Documentation/DMA-mapping.txt =================================================================== RCS file: /vger/linux/Documentation/DMA-mapping.txt,v retrieving revision 1.17.2.2 diff -u -r1.17.2.2 DMA-mapping.txt --- Documentation/DMA-mapping.txt 5 Mar 2002 12:40:36 -0000 1.17.2.2 +++ Documentation/DMA-mapping.txt 5 Jun 2002 20:07:43 -0000 @@ -239,9 +239,9 @@ in order to get correct behavior on all platforms. -- Streaming DMA mappings which are usually mapped for one DMA transfer, - unmapped right after it (unless you use pci_dma_sync below) and for which - hardware can optimize for sequential accesses. +- Streaming DMA mappings which are usually mapped for one DMA + transfer, unmapped right after it (unless you use pci_dma_release + below) and for which hardware can optimize for sequential accesses. This of "streaming" as "asynchronous" or "outside the coherency domain". @@ -508,21 +508,46 @@ the data in between the DMA transfers, just map it with pci_map_{single,sg}, and after each DMA transfer call either: - pci_dma_sync_single(dev, dma_handle, size, direction); + pci_dma_release_single(dev, dma_handle, size, direction); or: - pci_dma_sync_sg(dev, sglist, nents, direction); + pci_dma_release_sg(dev, sglist, nents, direction); as appropriate. +Once you have touched the region (after having called pci_dma_release_*()), +and need to give it back to the device for another DMA transfer, call: + + pci_dma_prep_single(dev, dma_handle, size, direction); + +or: + + pci_dma_prep_sg(dev, sglist, nents, direction); + +This will prepare the buffer for another DMA transfer and synchronize any +CPU writes to it with the device's view if direction is set to +PCI_DMA_TODEVICE or PCI_DMA_BIDIRECTIONAL. + +Note: Prior to the introduction of pci_dma_prep_*, drivers accessing a +DMAed region after a pci_dma_sync_* (now obsolete) implicitly returned +"ownership" of the region to the device without having to expressly call a +routine to do so. In these cases, data is only read from the buffer, and +the CPU "view" of the region is synchronized again on the next call to +pci_dma_sync_*. For repeated DMA transfers to a device, pci_dma_prep_*() is +used to synchronize any changes in the region (made by the driver) with the +device. New drivers should use pci_dma_release_* in place of pci_dma_sync_* +and use pci_dma_prep_* when returning the buffer back to the device, +regardless of the DMA direction. Eventually, all calls to pci_dma_sync_* +will be eliminated. + After the last DMA transfer call one of the DMA unmap routines pci_unmap_{single,sg}. If you don't touch the data from the first pci_map_* -call till pci_unmap_*, then you don't have to call the pci_dma_sync_* -routines at all. +call till pci_unmap_*, then you don't have to call the pci_dma_release_* or +pci_dma_prep_* routines at all. Here is pseudo code which shows a situation in which you would need -to use the pci_dma_sync_*() interfaces. +to use the pci_dma_release_*() and pci_dma_prep_*() interfaces. my_card_setup_receive_buffer(struct my_card *cp, char *buffer, int len) { @@ -552,7 +577,7 @@ * the DMA transfer with the CPU first * so that we see updated contents. */ - pci_dma_sync_single(cp->pdev, cp->rx_dma, cp->rx_len, + pci_dma_release_single(cp->pdev, cp->rx_dma, cp->rx_len, PCI_DMA_FROMDEVICE); /* Now it is safe to examine the buffer. */ @@ -563,7 +588,11 @@ pass_to_upper_layers(cp->rx_buf); make_and_setup_new_rx_buf(cp); } else { - /* Just give the buffer back to the card. */ + /* Prepare the buffer for another DMA transfer, + * then give the buffer back to the card. + */ + pci_dma_prep_single(cp->pdev, cp->rx_dma, + cp->rx_len, PCI_DMA_FROMDEVICE); give_rx_buf_to_card(cp); } } @@ -671,12 +700,20 @@ When the DMA transfer is complete, invoke: - void pci_dac_dma_sync_single(struct pci_dev *pdev, + void pci_dac_dma_release_single(struct pci_dev *pdev, dma64_addr_t dma_addr, size_t len, int direction); This must be done before the CPU looks at the buffer again. -This interface behaves identically to pci_dma_sync_{single,sg}(). + +After calling pci_dac_dma_release_{single,sg}, and before returning the +buffer to the device for another DMA operation, invoke: + + void pci_dac_dma_prep_single(struct pci_dev *pdev, dma64_addr_t + dma_addr, size_t len, int direction); + +These two interfaces behave identically to pci_dma_release_{single,sg}() +and pci_dma_prep_{single,sg}(), respectively. If you need to get back to the PAGE/OFFSET tuple from a dma64_addr_t the following interfaces are provided: From owner-linux-mips@oss.sgi.com Wed Jun 5 15:35: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 g55MZpnC023205 for ; Wed, 5 Jun 2002 15:35:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55MZpvf023204 for linux-mips-outgoing; Wed, 5 Jun 2002 15:35:51 -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 g55MZmnC023201 for ; Wed, 5 Jun 2002 15:35:49 -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 17FjOC-000Lgg-00; Thu, 06 Jun 2002 00:36:24 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17FjPM-0000G7-00; Thu, 06 Jun 2002 00:37:36 +0200 Date: Thu, 6 Jun 2002 00:37:36 +0200 To: nick@snowman.net Cc: linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020605223736.GN23411@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603235311.GJ23411@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 275 Lines: 13 nick@snowman.net wrote: > Do you have gfx working on i2 impact? Nothing more than the firmware will do. > Is it also an R10k system, or are > you useing an r4k system? IT's r10k. AFAIH the r4k systems have still ARCS32 and should be able to boot a 32 bit kernel. Thiemo From owner-linux-mips@oss.sgi.com Wed Jun 5 15:47: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 g55MlanC023477 for ; Wed, 5 Jun 2002 15:47:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55MlalW023476 for linux-mips-outgoing; Wed, 5 Jun 2002 15:47:36 -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 g55MlVnC023473; Wed, 5 Jun 2002 15:47:31 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) 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 PAA04048; Wed, 5 Jun 2002 15:49:34 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) 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 17FjPX-000Lfm-00; Thu, 06 Jun 2002 00:37:47 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17FjQh-0000GW-00; Thu, 06 Jun 2002 00:38:59 +0200 Date: Thu, 6 Jun 2002 00:38:59 +0200 To: "Maciej W. Rozycki" Cc: Ralf Baechle , "Gleb O. Raiko" , Jun Sun , Alexandr Andreev , linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020605223859.GO23411@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603230107.GH23411@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 558 Lines: 16 Maciej W. Rozycki wrote: > On Tue, 4 Jun 2002, Thiemo Seufer wrote: > > > One simple patch [1] is missing from the release. R_MIPS_HIGHEST relocs > > are zeroed out in a few cases where the assembler resolves them itself. > > The rest works for me quite nice. > > How about R_MIPS_26 relocs? I discovered they are broken for the 64 ABI > (likely a RELA problem) and I am currently working on a fix. As a result > of the bug a kernel executable is useless. I forgot about this one, sorry. I have a patch for it, I think it will go in for 2.13. Thiemo From owner-linux-mips@oss.sgi.com Wed Jun 5 16: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 g55NmknC023922 for ; Wed, 5 Jun 2002 16:48:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55NmkC4023921 for linux-mips-outgoing; Wed, 5 Jun 2002 16:48:46 -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 g55NmgnC023917 for ; Wed, 5 Jun 2002 16:48:42 -0700 Received: (qmail 7896 invoked by uid 502); 5 Jun 2002 23:50:41 -0000 Message-ID: <20020605235041.7895.qmail@gateway.total-knowledge.com> Content-Type: text/plain; charset="koi8-r" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total Knowledge To: Thiemo Seufer , nick@snowman.net Subject: Re: 3 questions about linux-2.4.18 and R3000 Date: Wed, 5 Jun 2002 16:50:36 -0700 X-Mailer: KMail [version 1.3.1] Cc: linux-mips@oss.sgi.com References: <20020603235311.GJ23411@rembrandt.csv.ica.uni-stuttgart.de> <20020605223736.GN23411@rembrandt.csv.ica.uni-stuttgart.de> In-Reply-To: <20020605223736.GN23411@rembrandt.csv.ica.uni-stuttgart.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 681 Lines: 25 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 05 June 2002 03:37 pm, Thiemo Seufer wrote: > nick@snowman.net wrote: > > Do you have gfx working on i2 impact? > > Nothing more than the firmware will do. > > > Is it also an R10k system, or are > > you useing an r4k system? > > IT's r10k. AFAIH the r4k systems have still ARCS32 and should be > able to boot a 32 bit kernel. And how are you dealing with R10K speculative execution in non-cache-coherent systems problem? > Thiemo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE8/qPR84S94bALfyURAiG0AKDoaTAi0vHNUpIO3ZRmL1NjLRHgOQCaA/En /WCTs3jSjNdYBBN5KI8o7VE= =0QL6 -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Wed Jun 5 23:29: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 g566TenC028592 for ; Wed, 5 Jun 2002 23:29:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g566Td5v028591 for linux-mips-outgoing; Wed, 5 Jun 2002 23:29:39 -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 g566TTnC028588 for ; Wed, 5 Jun 2002 23:29:29 -0700 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Wed, 05 Jun 2002 23:31:26 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from dt-sj3-118.sj.broadcom.com (dt-sj3-118 [10.21.64.118]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g566VR1S026256; Wed, 5 Jun 2002 23:31:27 -0700 (PDT) Received: (from cgd@localhost) by dt-sj3-118.sj.broadcom.com ( 8.9.1/SJ8.9.1) id XAA26787; Wed, 5 Jun 2002 23:31:26 -0700 (PDT) To: dom@algor.co.uk cc: "Eric Christopher" , "Johannes Stezenbach" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> <1022870431.3668.19.camel@ghostwheel.cygnus.com> <15614.12481.424601.806779@gladsmuir.algor.co.uk> From: cgd@broadcom.com Date: 05 Jun 2002 23:31:26 -0700 In-Reply-To: dom@algor.co.uk's message of "Wed, 5 Jun 2002 15:40:14 +0000 (UTC)" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 10E1DE341126298-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2995 Lines: 70 At Wed, 5 Jun 2002 15:40:14 +0000 (UTC), "Dominic Sweetman" wrote: > I fear it's "when time permits" at the moment. The number of changes > is sufficiently large that it will take concentrated effort for 2-4 > weeks, and this is very difficult to find. For what it's worth, if you expend the effort while you go, it saves much time in the long run, both in terms of maintaining the changes, and merging them. > During most of the last few years (as I understand it) it has been > difficult to establish a baseline to patch against, or find someone > who had the time to attend to bug reports. As someone who's been maintaining a MIPS toolchain (based on gcc, binutils, etc.) for a couple of years, I dunno that that makes sense. There seems to have been some confusion in the community about which versions to use, etc. But, for most purposes, i've found that the latest releases have worked "pretty well" -- certainly well enough to use for development with a small number of patches -- for linux mips and other mips targets. We've been using gcc 3.0.x now for a while; last i looked the linux mips pages recommended against that, and I really don't understand why... Soon we'll be switching to 3.1. > > Almost 90% of the bug reports I see are against IRIX. > > That does suggest you're missing some pretty large chunks of the > community! > > 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. > > We believe that a large number of man hours will be required to > identify and merge all major valuable features and then chase out > the bugs, before there can be a release which everyone has reason to > adopt. > > We certainly can't afford to put in those hours unless we win > contracts; I suspect Red Hat can't, either. This puts you into an interesting position: Presumably your customers desire both features of new GCC/binutils, but also want support for your improvements. The way it looks to me, by not getting your changes put back into the public sources as you go, you've managed both to make a large chunk of work for yourself if you want to catch up and to put yourself at a competitive disadvantage in the eyes of customers who place high value in current GCC features. FWIW, it's not that hard to get changes back in if you try. Over the past couple of years, basically starting as an "outsider," i've managed to get ... about a hundred fifty patches -- ranging from tiny or trivial bug fixes to fairly huge changes -- pushed back into the public sources, and have even managed to be appointed the mips gdb 'sim' maintainer... The result is, many of the tool problems we found have now been fixed, and since we put in test case entries where possible should stay fixed, and now our source merges are much easier and go much more quickly. cgd From owner-linux-mips@oss.sgi.com Thu Jun 6 00: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 g5678lnC031419 for ; Thu, 6 Jun 2002 00:08:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5678kRg031418 for linux-mips-outgoing; Thu, 6 Jun 2002 00:08:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5678hnC031415 for ; Thu, 6 Jun 2002 00:08:44 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id g567AZ217142; Thu, 6 Jun 2002 09:10:35 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MKXM3S9S; Thu, 6 Jun 2002 09:10:34 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 06 Jun 2002 09:10:34 +0200 Received: by DLFW003A with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Jun 2002 09:10:45 +0200 Message-ID: <86048F07C015D311864100902760F1DD01B5EA87@DLFW003A> From: Andre.Messerschmidt@infineon.com To: alan@lxorguk.ukuu.org.uk Cc: linux-mips@oss.sgi.com Subject: AW: kmalloc question Date: Thu, 6 Jun 2002 09:10:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 185 Lines: 9 > GFP_ATOMIC is safe in an interrupt handler. You might get NULL back and > that it is your problem, but the kmalloc is safe > Thanks. NULL is something I can handle. regards Andre From owner-linux-mips@oss.sgi.com Thu Jun 6 01:56: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 g568uunC032459 for ; Thu, 6 Jun 2002 01:56:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g568uuoc032458 for linux-mips-outgoing; Thu, 6 Jun 2002 01:56:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g568umnC032453 for ; Thu, 6 Jun 2002 01:56:51 -0700 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g568wJd19254; Thu, 6 Jun 2002 09:58:19 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id JAA03233; Thu, 6 Jun 2002 09:58:17 +0100 (BST) Date: Thu, 6 Jun 2002 09:58:17 +0100 (BST) Message-Id: <200206060858.JAA03233@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: law@redhat.com Cc: Dominic Sweetman , Joe Buck , echristo@redhat.com (Eric Christopher), js@convergence.de (Johannes Stezenbach), gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] In-Reply-To: <1375.1023293101@porcupine.cygnus.com> References: <15614.10904.705392.925058@gladsmuir.algor.co.uk> <1375.1023293101@porcupine.cygnus.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 591 Lines: 18 Jeff, > > I signed the assignment/waiver. The companies involved are > > Algorithmics Ltd and DFS3 Ltd. It was faxed to Jim Wilson (then at > > Cygnus) in October 1993 in the form recommended at that time. Here's > > a PDF. Note the 'company stationery' has changed since 1993... > > What's important here is the assignment that is on file with the FSF. That's > what needs to be checked. Are you in a position to do that? If not, who is? -- Dominic Sweetman, Algorithmics Ltd phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Thu Jun 6 02:13: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 g569DBnC000360 for ; Thu, 6 Jun 2002 02:13:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g569DBkA000359 for linux-mips-outgoing; Thu, 6 Jun 2002 02:13:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g569D1nC000355 for ; Thu, 6 Jun 2002 02:13:03 -0700 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g569EYd19700; Thu, 6 Jun 2002 10:14:34 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id KAA03263; Thu, 6 Jun 2002 10:14:33 +0100 (BST) Date: Thu, 6 Jun 2002 10:14:33 +0100 (BST) Message-Id: <200206060914.KAA03263@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: cgd@broadcom.com Cc: dom@algor.co.uk, "Eric Christopher" , "Johannes Stezenbach" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] In-Reply-To: References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> <1022870431.3668.19.camel@ghostwheel.cygnus.com> <15614.12481.424601.806779@gladsmuir.algor.co.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1707 Lines: 44 I wholeheatedly agree that it would be a really good thing if we were all working around a common, recent, source tree... I'm finding this discussion useful because it's identifying people who are working in the area, and I'm wondering whether we can come together in the short term on building a better regression test suite... > There seems to have been some confusion in the community about which > versions to use, etc. But, for most purposes, i've found that the > latest releases have worked "pretty well" -- certainly well enough to > use for development with a small number of patches... Difference in perception here. Algorithmics have been maintaining GNU C for about ten years for our 'embedded' customers, some of whom have very large and demanding code bases. Up to and including the 2.96+ release we currently work with, no GCC version we've taken on has been fit for use by our MIPS customers without a large number of fixes, including significant changes to nominally non-machine-dependent code. If you experienced a big improvement in quality on moving to some more recent version, I'd love to know and that's worth telling everyone. But if you're saying "it's always been more or less all right" then we are bound to suspect you're not looking hard enough... > Presumably your customers desire both features of new GCC/binutils, > but also want support for your improvements. They want high reliability (which requires fairly lengthy development schedules) and the latest version... I'm sure yours do too, but the requirements compete somewhat. > FWIW, it's not that hard to get changes back in if you try. Thanks for the encouragement. Dominic Sweetman, Algorithmics Ltd From owner-linux-mips@oss.sgi.com Thu Jun 6 02:57: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 g569vqnC008338 for ; Thu, 6 Jun 2002 02:57:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g569vplS008337 for linux-mips-outgoing; Thu, 6 Jun 2002 02:57:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from disaster.jaj.com (root@ns0.jaj.com [66.93.20.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g569vknC008334 for ; Thu, 6 Jun 2002 02:57:46 -0700 Received: (from phil@localhost) by disaster.jaj.com (8.11.4/8.11.4) id g569xIO13791; Thu, 6 Jun 2002 04:59:18 -0500 Date: Thu, 6 Jun 2002 05:59:18 -0400 From: Phil Edwards To: Dominic Sweetman Cc: law@redhat.com, Joe Buck , Eric Christopher , Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] Message-ID: <20020606055918.A13788@disaster.basement.lan> References: <15614.10904.705392.925058@gladsmuir.algor.co.uk> <1375.1023293101@porcupine.cygnus.com> <200206060858.JAA03233@mudchute.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206060858.JAA03233@mudchute.algor.co.uk>; from dom@algor.co.uk on Thu, Jun 06, 2002 at 09:58:17AM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1134 Lines: 35 > > > I signed the assignment/waiver. The companies involved are > > > Algorithmics Ltd and DFS3 Ltd. It was faxed to Jim Wilson (then at > > > Cygnus) in October 1993 in the form recommended at that time. Here's > > > a PDF. Note the 'company stationery' has changed since 1993... > > > > What's important here is the assignment that is on file with the FSF. That's > > what needs to be checked. > > Are you in a position to do that? If not, who is? > > -- > Dominic Sweetman, > Algorithmics Ltd Here's what's on file: BINUTILS Algorithmics Ltd. 1997-08-20 Assigns changes. GCC Algorithmics Ltd. 1997-08-20 Assigns changes. GDB Algorithmics Ltd. 1997-08-20 Assigns changes. There's also a disclaimer for changes to Emacs, if that matters here. :-) Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From owner-linux-mips@oss.sgi.com Thu Jun 6 08:04: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 g56F4HnC025544 for ; Thu, 6 Jun 2002 08:04:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56F4Hm6025543 for linux-mips-outgoing; Thu, 6 Jun 2002 08:04:17 -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 g56F48nC025538 for ; Thu, 6 Jun 2002 08:04:09 -0700 Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g56F65n25669 for ; Thu, 6 Jun 2002 17:06:05 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Thu, 6 Jun 2002 17:06:05 +0200 (MEST) From: Kjeld Borch Egevang To: linux-mips mailing list Subject: Float crash. Fix in exit_thread() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1863 Lines: 59 I'm running on a system with no FPU. Now, I've got a program do_float which seems to work fine. But if I enter: /bin/echo hello; ./do_float it terminates with a bus error or FP error. The bug is in exit_thread(). Can anyone explain to me, what good the "cfc1 $0,$31" does? Here is the patch: RCS file: /cvs/linux/arch/mips/kernel/process.c,v retrieving revision 1.36 diff -u -r1.36 process.c --- process.c 2002/05/29 18:36:28 1.36 +++ process.c 2002/06/06 14:51:32 @@ -54,9 +54,11 @@ void exit_thread(void) { /* Forget lazy fpu state */ - if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { - __enable_fpu(); - __asm__ __volatile__("cfc1\t$0,$31"); + if (last_task_used_math == current) { + if (mips_cpu.options & MIPS_CPU_FPU) { + __enable_fpu(); + __asm__ __volatile__("cfc1\t$0,$31"); + } last_task_used_math = NULL; } } @@ -64,9 +66,11 @@ void flush_thread(void) { /* Forget lazy fpu state */ - if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { - __enable_fpu(); - __asm__ __volatile__("cfc1\t$0,$31"); + if (last_task_used_math == current) { + if (mips_cpu.options & MIPS_CPU_FPU) { + __enable_fpu(); + __asm__ __volatile__("cfc1\t$0,$31"); + } last_task_used_math = NULL; } } /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 Thu Jun 6 08:11: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 g56FBNnC025709 for ; Thu, 6 Jun 2002 08:11:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56FBNjs025708 for linux-mips-outgoing; Thu, 6 Jun 2002 08:11:23 -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 g56FBHnC025704 for ; Thu, 6 Jun 2002 08:11:17 -0700 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Thu, 06 Jun 2002 08:12:48 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-2.sj.broadcom.com (mail-sj1-2 [10.16.128.232]) by mail-sj1-5.sj.broadcom.com (8.12.2/8.12.2) with ESMTP id g56FDE1S027666; Thu, 6 Jun 2002 08:13:14 -0700 (PDT) Received: (from cgd@localhost) by mail-sj1-2.sj.broadcom.com ( 8.9.1/SJ8.9.1) id IAA10448; Thu, 6 Jun 2002 08:13:14 -0700 (PDT) To: "Dominic Sweetman" cc: "Eric Christopher" , "Johannes Stezenbach" , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] References: <3CBFEAA9.9070707@algor.co.uk> <15566.28397.770794.272735@gladsmuir.algor.co.uk> <1022870431.3668.19.camel@ghostwheel.cygnus.com> <15614.12481.424601.806779@gladsmuir.algor.co.uk> <200206060914.KAA03263@mudchute.algor.co.uk> From: cgd@broadcom.com Date: 06 Jun 2002 08:13:14 -0700 In-Reply-To: "Dominic Sweetman"'s message of "Thu, 6 Jun 2002 10:14:33 +0100 (BST)" Message-ID: X-Mailer: Gnus v5.7/Emacs 20.4 MIME-Version: 1.0 X-WSS-ID: 10E1A47A1116645-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1826 Lines: 44 At Thu, 6 Jun 2002 10:14:33 +0100 (BST), Dominic Sweetman wrote: > Difference in perception here. Noted. > Up to and including the 2.96+ release we currently work with, no GCC > version we've taken on has been fit for use by our MIPS customers > without a large number of fixes, including significant changes to > nominally non-machine-dependent code. > > If you experienced a big improvement in quality on moving to some more > recent version, I'd love to know and that's worth telling everyone. > > But if you're saying "it's always been more or less all right" then we > are bound to suspect you're not looking hard enough... "I don't know." I didn't really spend a _lot_ of time staring at the gnu toolchain until about 2 or 3 years ago (mips tools, 2 or so years 8-). Before that, i relied on tools that others had massaged ... and invariably, yes, they did have at least a few "important" bug fixes (often pulled in from later development versions of the tools). I think even going back 2 and change years, we had some problems with the versions of gcc at that time, and, for some sets of compile flags (for us, -membedded-pic) a _lot_ of problems with binutils. As of gcc 3.0.4 and w/ binutils 2.12.1 (with patches to each, but generally not bug-fixes .... though we undoubtedly still have a few), at least for us, they seem to work well for linux and for some amount of stand-alone embedded development work. I wouldn't disagree, BTW, that the current tools for mips seem to have some shortcomings. I also wouldn't claim that we've comprehensively tested the tools. 8-) I think the goal of improving test suites to show additional bugs is a very good one. Personally, I've been trying to make sure regression tests get added for bugs we find & fix, but there will always be more bugs to find. chris From owner-linux-mips@oss.sgi.com Thu Jun 6 08:31: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 g56FVFnC025980 for ; Thu, 6 Jun 2002 08:31:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56FVEUW025979 for linux-mips-outgoing; Thu, 6 Jun 2002 08:31:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from cygnus.com (sunnyvale.sfbay.redhat.com [205.180.83.203]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56FV7nC025975 for ; Thu, 6 Jun 2002 08:31:08 -0700 Received: from porcupine.cygnus.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA16352 for ; Thu, 6 Jun 2002 08:33:07 -0700 (PDT) Received: from porcupine.cygnus.com (IDENT:VbnuvRnlaUY1LR9tOyR40Hp66/VNwhMw@localhost.localdomain [127.0.0.1]) by porcupine.cygnus.com (8.12.2/8.12.2) with ESMTP id g56FaII7008964; Thu, 6 Jun 2002 09:36:18 -0600 Received: from porcupine.cygnus.com (law@localhost) by porcupine.cygnus.com (8.12.2/8.12.2/Submit) with ESMTP id g56FaHcs008961; Thu, 6 Jun 2002 09:36:17 -0600 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Phil Edwards cc: Dominic Sweetman , Joe Buck , Eric Christopher , Johannes Stezenbach , gcc@gcc.gnu.org, linux-mips@oss.sgi.com, sde@algor.co.uk Subject: Re: [Fwd: Current state of MIPS16 support?] Reply-To: law@redhat.com From: law@redhat.com In-reply-to: Your message of Thu, 06 Jun 2002 05:59:18 EDT. <20020606055918.A13788@disaster.basement.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Jun 2002 09:36:17 -0600 Message-ID: <8960.1023377777@porcupine.cygnus.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1377 Lines: 39 In message <20020606055918.A13788@disaster.basement.lan>, Phil Edwards writes: > > > > I signed the assignment/waiver. The companies involved are > > > > Algorithmics Ltd and DFS3 Ltd. It was faxed to Jim Wilson (then at > > > > Cygnus) in October 1993 in the form recommended at that time. Here's > > > > a PDF. Note the 'company stationery' has changed since 1993... > > > > > > What's important here is the assignment that is on file with the FSF. T > hat's > > > what needs to be checked. > > > > Are you in a position to do that? If not, who is? > > > > -- > > Dominic Sweetman, > > Algorithmics Ltd > > Here's what's on file: > > BINUTILS Algorithmics Ltd. 1997-08-20 > Assigns changes. > > GCC Algorithmics Ltd. 1997-08-20 > Assigns changes. > > GDB Algorithmics Ltd. 1997-08-20 > Assigns changes. > > There's also a disclaimer for changes to Emacs, if that matters here. :-) Thanks. This likely means that we're better off getting a new assignment -- this kind of language "Assigns changes" typically means an assignment for a specific set of changes. If the scope of the changes increased over time, then the new changes would not be covered by the old assignment. I'd be much more comfortable if Algorithmics would sign a past & future assignment for binutils, gcc & gdb. jeff From owner-linux-mips@oss.sgi.com Thu Jun 6 10:41: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 g56Hf9nC007483 for ; Thu, 6 Jun 2002 10:41:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Hf9Iu007482 for linux-mips-outgoing; Thu, 6 Jun 2002 10:41:09 -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 g56Hf5nC007479 for ; Thu, 6 Jun 2002 10:41:06 -0700 Received: from ayrnetworks.com ([64.166.72.142]) by ayrnetworks.com (8.11.6/8.11.2) with ESMTP id g56Hh2o02940; Thu, 6 Jun 2002 10:43:02 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g56Hebq11998; Thu, 6 Jun 2002 10:40:37 -0700 Date: Thu, 6 Jun 2002 10:40:37 -0700 From: William Jhun To: "David S. Miller" Cc: "linux-kernel@vger.kernel.org"@ayrnetworks.com, "linux-mips@oss.sgi.com"@ayrnetworks.com Subject: Re: Deprecate pci_dma_sync_{single,sg}()? Message-ID: <20020606104036.A11943@ayrnetworks.com> References: <20020605131231.B10773@ayrnetworks.com> <20020605.154747.58455261.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020605.154747.58455261.davem@redhat.com>; from davem@redhat.com on Wed, Jun 05, 2002 at 03:47:47PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1037 Lines: 23 On Wed, Jun 05, 2002 at 03:47:47PM -0700, David S. Miller wrote: > From: William Jhun > Date: Wed, 5 Jun 2002 13:12:31 -0700 > > In the current linux-mips implementation, this has some subtle problems: > pci_unmap_{single,sg}() is essentially a no-op. > > Right, I see the problem. I'll think about this some more. > > As it stands now, I think the correct solution is to require > pci_dma_prep_single() before giving the buffer back to the > device after the read. Right, that's what I was thinking. Is it asking a lot to demand that all existing drivers that use this interface add pci_dma_prep_single()? How will backward compatiblility with older drivers work? That's why I suggested leaving pci_dma_sync_single() and adding pci_dma_release_single() which can leave the cache flush to pci_dma_prep_single(). It seems like elsewhere, like the D-cache flushing interface (for virtual aliasing), both old and new interfaces co-exist. Does this seem to work out O.K. in your experience? Will From owner-linux-mips@oss.sgi.com Thu Jun 6 11:13: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 g56ID0nC021875 for ; Thu, 6 Jun 2002 11:13:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56ID02S021874 for linux-mips-outgoing; Thu, 6 Jun 2002 11:13:00 -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 g56ICnnC021869 for ; Thu, 6 Jun 2002 11:12: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 LAA16577 for ; Thu, 6 Jun 2002 11:14:43 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA14030; Thu, 6 Jun 2002 11:14:39 -0700 (PDT) Message-ID: <007501c20d86$f339b7a0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Kjeld Borch Egevang" , "linux-mips mailing list" References: Subject: Re: Float crash. Fix in exit_thread() Date: Thu, 6 Jun 2002 20:21:15 +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 Content-Length: 2895 Lines: 87 It's been a while since I worked on the code, but I'm not sure why last_task_used_math needs to be cleared if there is no FPU. The way the FPU emulator was integrated, the FPU register storage *is* the thread context, so if there is no FPU, there was no FPU context switching, lazy or otherwise. Sounds like someone broke this. Beyond that, the CFC1 instruction is presumably there because in the R4000 (at least) it is specified as the means to force the FP pipeline to drain before the context switch. I would suppose this would be done in Linux to avoid mis-attribution of FP exceptions. (See chapter 6 of the R4000 User's manual, page 160 in the Second Edition). Kevin K. ----- Original Message ----- From: "Kjeld Borch Egevang" To: "linux-mips mailing list" Sent: Thursday, June 06, 2002 5:06 PM Subject: Float crash. Fix in exit_thread() > I'm running on a system with no FPU. Now, I've got a program do_float > which seems to work fine. But if I enter: > > /bin/echo hello; ./do_float > > it terminates with a bus error or FP error. The bug is in exit_thread(). > Can anyone explain to me, what good the "cfc1 $0,$31" does? > > > Here is the patch: > > RCS file: /cvs/linux/arch/mips/kernel/process.c,v > retrieving revision 1.36 > diff -u -r1.36 process.c > --- process.c 2002/05/29 18:36:28 1.36 > +++ process.c 2002/06/06 14:51:32 > @@ -54,9 +54,11 @@ > void exit_thread(void) > { > /* Forget lazy fpu state */ > - if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { > - __enable_fpu(); > - __asm__ __volatile__("cfc1\t$0,$31"); > + if (last_task_used_math == current) { > + if (mips_cpu.options & MIPS_CPU_FPU) { > + __enable_fpu(); > + __asm__ __volatile__("cfc1\t$0,$31"); > + } > last_task_used_math = NULL; > } > } > @@ -64,9 +66,11 @@ > void flush_thread(void) > { > /* Forget lazy fpu state */ > - if (last_task_used_math == current && mips_cpu.options & MIPS_CPU_FPU) { > - __enable_fpu(); > - __asm__ __volatile__("cfc1\t$0,$31"); > + if (last_task_used_math == current) { > + if (mips_cpu.options & MIPS_CPU_FPU) { > + __enable_fpu(); > + __asm__ __volatile__("cfc1\t$0,$31"); > + } > last_task_used_math = NULL; > } > } > > > > /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 Thu Jun 6 13:58: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 g56KwHnC026022 for ; Thu, 6 Jun 2002 13:58:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56KwHUT026021 for linux-mips-outgoing; Thu, 6 Jun 2002 13:58:17 -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 g56Kw9nC026011 for ; Thu, 6 Jun 2002 13:58:10 -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 OAA17311 for ; Thu, 6 Jun 2002 14:00:03 -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 OAA19070; Thu, 6 Jun 2002 14:00:04 -0700 (PDT) Received: from coplin19.mips.com (IDENT:root@coplin19 [192.168.205.89]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g56L04b02676; Thu, 6 Jun 2002 23:00:04 +0200 (MEST) Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g56L04B27079; Thu, 6 Jun 2002 23:00:04 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Thu, 6 Jun 2002 23:00:04 +0200 (CEST) From: Kjeld Borch Egevang To: "Kevin D. Kissell" cc: linux-mips mailing list Subject: Re: Float crash. Fix in exit_thread() In-Reply-To: <007501c20d86$f339b7a0$10eca8c0@grendel> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1761 Lines: 49 On Thu, 6 Jun 2002, Kevin D. Kissell wrote: > It's been a while since I worked on the code, > but I'm not sure why last_task_used_math > needs to be cleared if there is no FPU. > The way the FPU emulator was integrated, > the FPU register storage *is* the thread > context, so if there is no FPU, there was no > FPU context switching, lazy or otherwise. > Sounds like someone broke this. If you check do_cpu in traps.c you'll find: fp_emul: if (last_task_used_math != current) { if (!current->used_math) { fpu_emulator_init_fpu(); current->used_math = 1; } } sig = fpu_emulator_cop1Handler(0, regs, ¤t->thread.fpu.soft); last_task_used_math = current; if (sig) fpu_emulator_init_fpu() is not called, when two processes are created like I described. Alternatively the test "if (last_task_used_math != current)" could be removed. > Beyond that, the CFC1 instruction is presumably > there because in the R4000 (at least) it is specified > as the means to force the FP pipeline to drain > before the context switch. I would suppose this > would be done in Linux to avoid mis-attribution > of FP exceptions. (See chapter 6 of the R4000 > User's manual, page 160 in the Second Edition). Great. It was exactly something like that I was looking for. Perhaps a comment would be nice in the code here ;-) /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 Thu Jun 6 15:06: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 g56M6QnC027772 for ; Thu, 6 Jun 2002 15:06:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56M6QEL027770 for linux-mips-outgoing; Thu, 6 Jun 2002 15:06:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from Elf.ucw.cz (root@[195.39.17.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56M6LnC027752 for ; Thu, 6 Jun 2002 15:06:22 -0700 Received: from bug.ucw.cz (root@amd.ucw.cz [10.0.0.6]) by Elf.ucw.cz (8.8.8/8.8.5) with ESMTP id XAA20401; Thu, 6 Jun 2002 23:12:59 +0200 Received: (from pavel@localhost) by bug.ucw.cz (8.8.8/8.8.5) id XAA01479; Thu, 6 Jun 2002 23:12:52 +0200 Date: Thu, 6 Jun 2002 23:12:52 +0200 From: Pavel Machek To: James Simmons Cc: Linux Fbdev development list , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: tx3912 Re: [PATCH] fbdev updates. Message-ID: <20020606211252.GA1112@elf.ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Warning: Reading this can be dangerous to your mental health. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 514 Lines: 12 Hi! > This patch includes the latest in the fbdev BK repository. I have > modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the > new api. Please test these changes out before I submit them to linus. > Thank you. It is against the latest BK tree and 2.5.20. Does the code even boot on any machine having tx3912fb? Pavel -- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa From owner-linux-mips@oss.sgi.com Thu Jun 6 17:03: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 g5703InC029779 for ; Thu, 6 Jun 2002 17:03:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5703Iro029778 for linux-mips-outgoing; Thu, 6 Jun 2002 17:03:18 -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 g5703FnC029775 for ; Thu, 6 Jun 2002 17:03:15 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) 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 RAB02202 for ; Thu, 6 Jun 2002 17:05:25 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) 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 17G74T-000NB7-00; Fri, 07 Jun 2002 01:53:37 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17G75i-0001ln-00; Fri, 07 Jun 2002 01:54:54 +0200 Date: Fri, 7 Jun 2002 01:54:54 +0200 To: Ilya Volynets Cc: nick@snowman.net, linux-mips@oss.sgi.com Subject: Re: 3 questions about linux-2.4.18 and R3000 Message-ID: <20020606235453.GA5079@rembrandt.csv.ica.uni-stuttgart.de> References: <20020603235311.GJ23411@rembrandt.csv.ica.uni-stuttgart.de> <20020605223736.GN23411@rembrandt.csv.ica.uni-stuttgart.de> <20020605235041.7895.qmail@gateway.total-knowledge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020605235041.7895.qmail@gateway.total-knowledge.com> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 364 Lines: 14 Ilya Volynets wrote: [snip] > > > Is it also an R10k system, or are > > > you useing an r4k system? > > > > IT's r10k. AFAIH the r4k systems have still ARCS32 and should be > > able to boot a 32 bit kernel. > And how are you dealing with R10K speculative execution > in non-cache-coherent systems problem? Not yet. I plan to modify the assembler for it. Thiemo From owner-linux-mips@oss.sgi.com Fri Jun 7 08:09: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 g57F9mnC011768 for ; Fri, 7 Jun 2002 08:09:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57F9mga011767 for linux-mips-outgoing; Fri, 7 Jun 2002 08:09:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57F9inC011764 for ; Fri, 7 Jun 2002 08:09:45 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g57FBjg5058614 for ; Fri, 7 Jun 2002 11:11:45 -0400 Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.117.250.6]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57FBhl70304 for ; Fri, 7 Jun 2002 11:11:43 -0400 Subject: LTP RPM maintainers wanted To: linux-mips@oss.sgi.com Cc: lindajs@us.ibm.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Williamson" Date: Fri, 7 Jun 2002 10:11:00 -0500 X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/07/2002 11:11:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 753 Lines: 20 Hi all, The Linux Test Project is looking for a volunteer to maintain a MIPS binary RPM. All this person would have to do is build the binary RPM, from the source RPM and spec file supplied each month, and send this back to me. I would take care of the rest. The releases are once a month, and that's it. The maintainer would not be responsible for any problems that arise from installing the RPM. We basically just want to be able to provide the option of installing a pre-compiled testsuite...if problems arise, the source is installed as well, so users can always re-compile. - Robbie Robert V. Williamson Linux Test Project IBM Linux Technology Center Phone: (512) 838-9295 T/L: 638-9295 http://ltp.sourceforge.net From owner-linux-mips@oss.sgi.com Fri Jun 7 15:14: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 g57MEWnC028836 for ; Fri, 7 Jun 2002 15:14:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57MEWqK028835 for linux-mips-outgoing; Fri, 7 Jun 2002 15:14:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f 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 g57MDHnC028817 for ; Fri, 7 Jun 2002 15:13:18 -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 g57MFEi05217 for ; Sat, 8 Jun 2002 00:15:15 +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 g57MFETF015024 for ; Sat, 8 Jun 2002 00:15:15 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.34 #1 (Debian)) id 17GS0o-0000bh-00 for ; Sat, 08 Jun 2002 00:15:14 +0200 Date: Sat, 8 Jun 2002 00:15:14 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: linux-mips@oss.sgi.com Subject: R10K speculative store on non-coherent systems workaround proposal Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="279724308-1017530808-1023488114=:2120" X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 37340 Lines: 634 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-1017530808-1023488114=:2120 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Here is a proposal for a software workaround to speculative execution on a non-coherent system such as the i2 R10k and the o2 R10k. 1. Problem: =========== The R10000 processor can (and will) execute intructions ahead. These instructions will be cancelled if they're not supposed to execute, e.g. if a jump happened. If a load or store instruction is executed speculatively, and the accessed memory is not in the cache, the cache line will be fetched in main memory and, on a store, be marked dirty. These speculative loads and stores can happen anywhere, since there might be old values in registers used in a speculative load/store instruction that would be cancelled afterwards. The problem is: - on a speculative load, the fetched cache line will remain in the cache even if the speculative load is cancelled - on a speculative store, the *dirty* cache line will remain in the cache even if the speculative store is cancelled On non-coherent systems we need to flush the cache lines to main memory before doing DMA to device, so that the device can see them. We also need to invalidate lines before reading from a DMA'd buffer to make sure the CPU will read main memory and not the cache. However, if a speculative load or store happens during DMA transfer, the cache line will be fetched from memory and, on a store, be marked dirty. That means this cache line could be evicted when the line is needed, thus being written back in memory if it was dirty, thus overwritting the data a device could have put in the DMA buffer. Something we really don't want to happen ;) 2. Proposed solution ==================== Speculative execution will not happen in the following conditions: - access to memory is uncached - the speculated instruction causes an exception: that also means a speculative load/store will not happen in a mapped memory region which doesn't have a TLB line for it. This second point means that any mapped space can be made safe by removing the DMA'd buffer address translations from the TLB or by marking them 'uncached' during DMA transfer. The remaining unmapped adress spaces are: - kseg1, which is safe since uncached - kseg0, which can turned uncached with the K0 bits from the CPO Config register - xkphys which will cause adress error if the KX bit is not set, the aborting the speculative load/store before it can do harm ;) Since we need to turn KX off, xkseg will not be accessible either.. and since we need to have KSEG0 uncached, we need to remap the kernel elsewhere if we want performance ;). We could use the xsseg segment, available in Supervisor mode, which is mapped (safe) and moreover allows to access all memory (on o2 it can be up to 2G I think, whereas in 32bit mode, only 512Mb would be accessible). So the proposed workaround is to permanently map the lower 16MB of memory in xsseg in using a wired TLB entry and a page size of 16MB. This memory would not be usable for DMA. Everything else would, so we could for example reserve the upper 16Mb for DMA (and give them to the DMA zoned memory allocator). On exception or error, the handler (in KSEG0) would set CU0 to allow access to CPO, then switch to Supervisor mode and jump to the equivalent xsseg location and continue execution in Supervisor mode. The code for returning to userland would need to clear the CU0 bit, to prevent user access to CP0. Before DMA transfer, the DMA'd buffer cache lines would be flushed, and then it would be remapped 'uncached', thus preventing that any speculative load or store to this memory happens during transfer. After the DMA transfer, the cache would be invalidated to make sure main memory is read, and the DMA buffer would be remapped 'cacheable non-coherent'. A diagram is attached to illustrate the workaround. Comments, suggestions (and even flames) are welcome before anyone starts coding the workaround ;) regards, Vivien Chappelier. --279724308-1017530808-1023488114=:2120 Content-Type: APPLICATION/postscript; name="R10k_coherency_workaround.ps" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="R10k_coherency_workaround.ps" JSFQUy1BZG9iZS0yLjAKJSVUaXRsZTogd29ya2Fyb3VuZC5kaWEKJSVDcmVh dG9yOiBEaWEgdjAuODguMQolJUNyZWF0aW9uRGF0ZTogU3VuIEp1biAgMiAx NjowNDozMiAyMDAyCiUlRm9yOiBnbGF1cnVuZwolJURvY3VtZW50UGFwZXJT aXplczogQTQKJSVPcmllbnRhdGlvbjogUG9ydHJhaXQKJSVCZWdpblNldHVw CiUlRW5kU2V0dXAKJSVFbmRDb21tZW50cwolJUJlZ2luUHJvbG9nClsgLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYKLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYKLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5u b3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYgLy5ub3RkZWYKLy5u b3RkZWYgLy5ub3RkZWYgL3NwYWNlIC9leGNsYW0gL3F1b3RlZGJsIC9udW1i ZXJzaWduIC9kb2xsYXIgL3BlcmNlbnQgL2FtcGVyc2FuZCAvcXVvdGVyaWdo dAovcGFyZW5sZWZ0IC9wYXJlbnJpZ2h0IC9hc3RlcmlzayAvcGx1cyAvY29t bWEgL2h5cGhlbiAvcGVyaW9kIC9zbGFzaCAvemVybyAvb25lCi90d28gL3Ro cmVlIC9mb3VyIC9maXZlIC9zaXggL3NldmVuIC9laWdodCAvbmluZSAvY29s b24gL3NlbWljb2xvbgovbGVzcyAvZXF1YWwgL2dyZWF0ZXIgL3F1ZXN0aW9u IC9hdCAvQSAvQiAvQyAvRCAvRQovRiAvRyAvSCAvSSAvSiAvSyAvTCAvTSAv TiAvTwovUCAvUSAvUiAvUyAvVCAvVSAvViAvVyAvWCAvWQovWiAvYnJhY2tl dGxlZnQgL2JhY2tzbGFzaCAvYnJhY2tldHJpZ2h0IC9hc2NpaWNpcmN1bSAv dW5kZXJzY29yZSAvcXVvdGVsZWZ0IC9hIC9iIC9jCi9kIC9lIC9mIC9nIC9o IC9pIC9qIC9rIC9sIC9tCi9uIC9vIC9wIC9xIC9yIC9zIC90IC91IC92IC93 Ci94IC95IC96IC9icmFjZWxlZnQgL2JhciAvYnJhY2VyaWdodCAvYXNjaWl0 aWxkZSAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZgovLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZgovLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZgovLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5v dGRlZiAvLm5vdGRlZiAvLm5vdGRlZiAvLm5vdGRlZgovc3BhY2UgL2V4Y2xh bWRvd24gL2NlbnQgL3N0ZXJsaW5nIC9jdXJyZW5jeSAveWVuIC9icm9rZW5i YXIgL3NlY3Rpb24gL2RpZXJlc2lzIC9jb3B5cmlnaHQKL29yZGZlbWluaW5l IC9ndWlsbGVtb3RsZWZ0IC9sb2dpY2Fsbm90IC9oeXBoZW4gL3JlZ2lzdGVy ZWQgL21hY3JvbiAvZGVncmVlIC9wbHVzbWludXMgL3R3b3N1cGVyaW9yIC90 aHJlZXN1cGVyaW9yCi9hY3V0ZSAvbXUgL3BhcmFncmFwaCAvcGVyaW9kY2Vu dGVyZWQgL2NlZGlsbGEgL29uZXN1cGVyaW9yIC9vcmRtYXNjdWxpbmUgL2d1 aWxsZW1vdHJpZ2h0IC9vbmVxdWFydGVyIC9vbmVoYWxmCi90aHJlZXF1YXJ0 ZXJzIC9xdWVzdGlvbmRvd24gL0FncmF2ZSAvQWFjdXRlIC9BY2lyY3VtZmxl eCAvQXRpbGRlIC9BZGllcmVzaXMgL0FyaW5nIC9BRSAvQ2NlZGlsbGEKL0Vn cmF2ZSAvRWFjdXRlIC9FY2lyY3VtZmxleCAvRWRpZXJlc2lzIC9JZ3JhdmUg L0lhY3V0ZSAvSWNpcmN1bWZsZXggL0lkaWVyZXNpcyAvRXRoIC9OdGlsZGUK L09ncmF2ZSAvT2FjdXRlIC9PY2lyY3VtZmxleCAvT3RpbGRlIC9PZGllcmVz aXMgL211bHRpcGx5IC9Pc2xhc2ggL1VncmF2ZSAvVWFjdXRlIC9VY2lyY3Vt ZmxleAovVWRpZXJlc2lzIC9ZYWN1dGUgL1Rob3JuIC9nZXJtYW5kYmxzIC9h Z3JhdmUgL2FhY3V0ZSAvYWNpcmN1bWZsZXggL2F0aWxkZSAvYWRpZXJlc2lz IC9hcmluZwovYWUgL2NjZWRpbGxhIC9lZ3JhdmUgL2VhY3V0ZSAvZWNpcmN1 bWZsZXggL2VkaWVyZXNpcyAvaWdyYXZlIC9pYWN1dGUgL2ljaXJjdW1mbGV4 IC9pZGllcmVzaXMKL2V0aCAvbnRpbGRlIC9vZ3JhdmUgL29hY3V0ZSAvb2Np cmN1bWZsZXggL290aWxkZSAvb2RpZXJlc2lzIC9kaXZpZGUgL29zbGFzaCAv dWdyYXZlCi91YWN1dGUgL3VjaXJjdW1mbGV4IC91ZGllcmVzaXMgL3lhY3V0 ZSAvdGhvcm4gL3lkaWVyZXNpc10gL2lzb2xhdGluMWVuY29kaW5nIGV4Y2gg ZGVmCi9UaW1lcy1Sb21hbi1sYXRpbjEKICAgIC9UaW1lcy1Sb21hbiBmaW5k Zm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklE IG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5n IGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRl ZmluZWZvbnQgcG9wCi9UaW1lcy1JdGFsaWMtbGF0aW4xCiAgICAvVGltZXMt SXRhbGljIGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4KCXsx IGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxs CgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJyZW50 ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL1RpbWVzLUJvbGQtbGF0aW4xCiAg ICAvVGltZXMtQm9sZCBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJl Z2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9 IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAg Y3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQgcG9wCi9UaW1lcy1Cb2xkSXRh bGljLWxhdGluMQogICAgL1RpbWVzLUJvbGRJdGFsaWMgZmluZGZvbnQKICAg IGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7ZGVm fSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29sYXRp bjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVmb250 IHBvcAovQXZhbnRHYXJkZS1Cb29rLWxhdGluMQogICAgL0F2YW50R2FyZGUt Qm9vayBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBp bmRleCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJ L0VuY29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3VycmVudGRp Y3QgZW5kCmRlZmluZWZvbnQgcG9wCi9BdmFudEdhcmRlLUJvb2tPYmxpcXVl LWxhdGluMQogICAgL0F2YW50R2FyZGUtQm9va09ibGlxdWUgZmluZGZvbnQK ICAgIGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7 ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29s YXRpbjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVm b250IHBvcAovQXZhbnRHYXJkZS1EZW1pLWxhdGluMQogICAgL0F2YW50R2Fy ZGUtRGVtaSBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7 MSBpbmRleCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFs bAoJL0VuY29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3VycmVu dGRpY3QgZW5kCmRlZmluZWZvbnQgcG9wCi9BdmFudEdhcmRlLURlbWlPYmxp cXVlLWxhdGluMQogICAgL0F2YW50R2FyZGUtRGVtaU9ibGlxdWUgZmluZGZv bnQKICAgIGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBu ZSB7ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBp c29sYXRpbjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZp bmVmb250IHBvcAovQm9va21hbi1MaWdodC1sYXRpbjEKICAgIC9Cb29rbWFu LUxpZ2h0IGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4KCXsx IGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxs CgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJyZW50 ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL0Jvb2ttYW4tTGlnaHRJdGFsaWMt bGF0aW4xCiAgICAvQm9va21hbi1MaWdodEl0YWxpYyBmaW5kZm9udAogICAg ZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9 IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGlu MWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQg cG9wCi9Cb29rbWFuLURlbWktbGF0aW4xCiAgICAvQm9va21hbi1EZW1pIGZp bmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4KCXsxIGluZGV4IC9G SUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxsCgkvRW5jb2Rp bmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJyZW50ZGljdCBlbmQK ZGVmaW5lZm9udCBwb3AKL0Jvb2ttYW4tRGVtaUl0YWxpYy1sYXRpbjEKICAg IC9Cb29rbWFuLURlbWlJdGFsaWMgZmluZGZvbnQKICAgIGR1cCBsZW5ndGgg ZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7ZGVmfSB7cG9wIHBvcH0g aWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29sYXRpbjFlbmNvZGluZyBk ZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVmb250IHBvcAovQ291cmll ci1sYXRpbjEKICAgIC9Db3VyaWVyIGZpbmRmb250CiAgICBkdXAgbGVuZ3Ro IGRpY3QgYmVnaW4KCXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9 IGlmZWxzZX0gZm9yYWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2Rpbmcg ZGVmCiAgICBjdXJyZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL0NvdXJp ZXItT2JsaXF1ZS1sYXRpbjEKICAgIC9Db3VyaWVyLU9ibGlxdWUgZmluZGZv bnQKICAgIGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBu ZSB7ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBp c29sYXRpbjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZp bmVmb250IHBvcAovQ291cmllci1Cb2xkLWxhdGluMQogICAgL0NvdXJpZXIt Qm9sZCBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBp bmRleCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJ L0VuY29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3VycmVudGRp Y3QgZW5kCmRlZmluZWZvbnQgcG9wCi9Db3VyaWVyLUJvbGRPYmxpcXVlLWxh dGluMQogICAgL0NvdXJpZXItQm9sZE9ibGlxdWUgZmluZGZvbnQKICAgIGR1 cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7ZGVmfSB7 cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29sYXRpbjFl bmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVmb250IHBv cAovSGVsdmV0aWNhLWxhdGluMQogICAgL0hlbHZldGljYSBmaW5kZm9udAog ICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtk ZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xh dGluMWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZv bnQgcG9wCi9IZWx2ZXRpY2EtT2JsaXF1ZS1sYXRpbjEKICAgIC9IZWx2ZXRp Y2EtT2JsaXF1ZSBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2lu Cgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZv cmFsbAoJL0VuY29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3Vy cmVudGRpY3QgZW5kCmRlZmluZWZvbnQgcG9wCi9IZWx2ZXRpY2EtQm9sZC1s YXRpbjEKICAgIC9IZWx2ZXRpY2EtQm9sZCBmaW5kZm9udAogICAgZHVwIGxl bmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9IHtwb3Ag cG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGluMWVuY29k aW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQgcG9wCi9I ZWx2ZXRpY2EtQm9sZE9ibGlxdWUtbGF0aW4xCiAgICAvSGVsdmV0aWNhLUJv bGRPYmxpcXVlIGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4K CXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9y YWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJy ZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL0hlbHZldGljYS1OYXJyb3ct bGF0aW4xCiAgICAvSGVsdmV0aWNhLU5hcnJvdyBmaW5kZm9udAogICAgZHVw IGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9IHtw b3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGluMWVu Y29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQgcG9w Ci9IZWx2ZXRpY2EtTmFycm93LU9ibGlxdWUtbGF0aW4xCiAgICAvSGVsdmV0 aWNhLU5hcnJvdy1PYmxpcXVlIGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRp Y3QgYmVnaW4KCXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlm ZWxzZX0gZm9yYWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVm CiAgICBjdXJyZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL0hlbHZldGlj YS1OYXJyb3ctQm9sZC1sYXRpbjEKICAgIC9IZWx2ZXRpY2EtTmFycm93LUJv bGQgZmluZGZvbnQKICAgIGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5k ZXggL0ZJRCBuZSB7ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9F bmNvZGluZyBpc29sYXRpbjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0 IGVuZApkZWZpbmVmb250IHBvcAovSGVsdmV0aWNhLU5hcnJvdy1Cb2xkT2Js aXF1ZS1sYXRpbjEKICAgIC9IZWx2ZXRpY2EtTmFycm93LUJvbGRPYmxpcXVl IGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4KCXsxIGluZGV4 IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxsCgkvRW5j b2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJyZW50ZGljdCBl bmQKZGVmaW5lZm9udCBwb3AKL05ld0NlbnR1cnlTY2hvb2xib29rLVJvbWFu LWxhdGluMQogICAgL05ld0NlbnR1cnlTY2hvb2xib29rLVJvbWFuIGZpbmRm b250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4KCXsxIGluZGV4IC9GSUQg bmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9yYWxsCgkvRW5jb2Rpbmcg aXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJyZW50ZGljdCBlbmQKZGVm aW5lZm9udCBwb3AKL05ld0NlbnR1cnlTY2hvb2xib29rLUl0YWxpYy1sYXRp bjEKICAgIC9OZXdDZW50dXJ5U2Nob29sYm9vay1JdGFsaWMgZmluZGZvbnQK ICAgIGR1cCBsZW5ndGggZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7 ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29s YXRpbjFlbmNvZGluZyBkZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVm b250IHBvcAovTmV3Q2VudHVyeVNjaG9vbGJvb2stQm9sZC1sYXRpbjEKICAg IC9OZXdDZW50dXJ5U2Nob29sYm9vay1Cb2xkIGZpbmRmb250CiAgICBkdXAg bGVuZ3RoIGRpY3QgYmVnaW4KCXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3Bv cCBwb3B9IGlmZWxzZX0gZm9yYWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5j b2RpbmcgZGVmCiAgICBjdXJyZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AK L05ld0NlbnR1cnlTY2hvb2xib29rLUJvbGRJdGFsaWMtbGF0aW4xCiAgICAv TmV3Q2VudHVyeVNjaG9vbGJvb2stQm9sZEl0YWxpYyBmaW5kZm9udAogICAg ZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9 IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGlu MWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQg cG9wCi9QYWxhdGluby1Sb21hbi1sYXRpbjEKICAgIC9QYWxhdGluby1Sb21h biBmaW5kZm9udAogICAgZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRl eCAvRklEIG5lIHtkZWZ9IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0Vu Y29kaW5nIGlzb2xhdGluMWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3Qg ZW5kCmRlZmluZWZvbnQgcG9wCi9QYWxhdGluby1JdGFsaWMtbGF0aW4xCiAg ICAvUGFsYXRpbm8tSXRhbGljIGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRp Y3QgYmVnaW4KCXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlm ZWxzZX0gZm9yYWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVm CiAgICBjdXJyZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL1BhbGF0aW5v LUJvbGQtbGF0aW4xCiAgICAvUGFsYXRpbm8tQm9sZCBmaW5kZm9udAogICAg ZHVwIGxlbmd0aCBkaWN0IGJlZ2luCgl7MSBpbmRleCAvRklEIG5lIHtkZWZ9 IHtwb3AgcG9wfSBpZmVsc2V9IGZvcmFsbAoJL0VuY29kaW5nIGlzb2xhdGlu MWVuY29kaW5nIGRlZgogICAgY3VycmVudGRpY3QgZW5kCmRlZmluZWZvbnQg cG9wCi9QYWxhdGluby1Cb2xkSXRhbGljLWxhdGluMQogICAgL1BhbGF0aW5v LUJvbGRJdGFsaWMgZmluZGZvbnQKICAgIGR1cCBsZW5ndGggZGljdCBiZWdp bgoJezEgaW5kZXggL0ZJRCBuZSB7ZGVmfSB7cG9wIHBvcH0gaWZlbHNlfSBm b3JhbGwKCS9FbmNvZGluZyBpc29sYXRpbjFlbmNvZGluZyBkZWYKICAgIGN1 cnJlbnRkaWN0IGVuZApkZWZpbmVmb250IHBvcAovU3ltYm9sLWxhdGluMQog ICAgL1N5bWJvbCBmaW5kZm9udApkZWZpbmVmb250IHBvcAovWmFwZkNoYW5j ZXJ5LU1lZGl1bUl0YWxpYy1sYXRpbjEKICAgIC9aYXBmQ2hhbmNlcnktTWVk aXVtSXRhbGljIGZpbmRmb250CiAgICBkdXAgbGVuZ3RoIGRpY3QgYmVnaW4K CXsxIGluZGV4IC9GSUQgbmUge2RlZn0ge3BvcCBwb3B9IGlmZWxzZX0gZm9y YWxsCgkvRW5jb2RpbmcgaXNvbGF0aW4xZW5jb2RpbmcgZGVmCiAgICBjdXJy ZW50ZGljdCBlbmQKZGVmaW5lZm9udCBwb3AKL1phcGZEaW5nYmF0cy1sYXRp bjEKICAgIC9aYXBmRGluZ2JhdHMgZmluZGZvbnQKICAgIGR1cCBsZW5ndGgg ZGljdCBiZWdpbgoJezEgaW5kZXggL0ZJRCBuZSB7ZGVmfSB7cG9wIHBvcH0g aWZlbHNlfSBmb3JhbGwKCS9FbmNvZGluZyBpc29sYXRpbjFlbmNvZGluZyBk ZWYKICAgIGN1cnJlbnRkaWN0IGVuZApkZWZpbmVmb250IHBvcAovY3Age2Ns b3NlcGF0aH0gYmluZCBkZWYKL2Mge2N1cnZldG99IGJpbmQgZGVmCi9mIHtm aWxsfSBiaW5kIGRlZgovYSB7YXJjfSBiaW5kIGRlZgovZWYge2VvZmlsbH0g YmluZCBkZWYKL2V4IHtleGNofSBiaW5kIGRlZgovZ3Ige2dyZXN0b3JlfSBi aW5kIGRlZgovZ3Mge2dzYXZlfSBiaW5kIGRlZgovc2Ege3NhdmV9IGJpbmQg ZGVmCi9ycyB7cmVzdG9yZX0gYmluZCBkZWYKL2wge2xpbmV0b30gYmluZCBk ZWYKL20ge21vdmV0b30gYmluZCBkZWYKL3JtIHtybW92ZXRvfSBiaW5kIGRl ZgovbiB7bmV3cGF0aH0gYmluZCBkZWYKL3Mge3N0cm9rZX0gYmluZCBkZWYK L3NoIHtzaG93fSBiaW5kIGRlZgovc2xjIHtzZXRsaW5lY2FwfSBiaW5kIGRl Zgovc2xqIHtzZXRsaW5lam9pbn0gYmluZCBkZWYKL3NsdyB7c2V0bGluZXdp ZHRofSBiaW5kIGRlZgovc3JnYiB7c2V0cmdiY29sb3J9IGJpbmQgZGVmCi9y b3Qge3JvdGF0ZX0gYmluZCBkZWYKL3NjIHtzY2FsZX0gYmluZCBkZWYKL3Nk IHtzZXRkYXNofSBiaW5kIGRlZgovZmYge2ZpbmRmb250fSBiaW5kIGRlZgov c2Yge3NldGZvbnR9IGJpbmQgZGVmCi9zY2Yge3NjYWxlZm9udH0gYmluZCBk ZWYKL3N3IHtzdHJpbmd3aWR0aCBwb3B9IGJpbmQgZGVmCi90ciB7dHJhbnNs YXRlfSBiaW5kIGRlZgoKL2VsbGlwc2VkaWN0IDggZGljdCBkZWYKZWxsaXBz ZWRpY3QgL210cnggbWF0cml4IHB1dAovZWxsaXBzZQp7IGVsbGlwc2VkaWN0 IGJlZ2luCiAgIC9lbmRhbmdsZSBleGNoIGRlZgogICAvc3RhcnRhbmdsZSBl eGNoIGRlZgogICAveXJhZCBleGNoIGRlZgogICAveHJhZCBleGNoIGRlZgog ICAveSBleGNoIGRlZgogICAveCBleGNoIGRlZiAgIC9zYXZlbWF0cml4IG10 cnggY3VycmVudG1hdHJpeCBkZWYKICAgeCB5IHRyIHhyYWQgeXJhZCBzYwog ICAwIDAgMSBzdGFydGFuZ2xlIGVuZGFuZ2xlIGFyYwogICBzYXZlbWF0cml4 IHNldG1hdHJpeAogICBlbmQKfSBkZWYKCi9tZXJnZXByb2NzIHsKZHVwIGxl bmd0aAozIC0xIHJvbGwKZHVwCmxlbmd0aApkdXAKNSAxIHJvbGwKMyAtMSBy b2xsCmFkZAphcnJheSBjdngKZHVwCjMgLTEgcm9sbAowIGV4Y2gKcHV0aW50 ZXJ2YWwKZHVwCjQgMiByb2xsCnB1dGludGVydmFsCn0gYmluZCBkZWYKJSVF bmRQcm9sb2cKCgolJVBhZ2U6IDEgMQpncwo4Ljg0NzA5MCAtOC44NDcwOTAg c2NhbGUKMTUuMTQyNDUwIC04NS4zNjM2NTQgdHJhbnNsYXRlCm4gLTYuMTAw MDAwIC0wLjc1Mzk2OCBtIDQzLjEwMDAwMSAtMC43NTM5NjggbCA0My4xMDAw MDEgNzYuMzIxMjA0IGwgLTYuMTAwMDAwIDc2LjMyMTIwNCBsIC02LjEwMDAw MCAtMC43NTM5NjggbCBjbGlwCjEuMDAwMDAwIDEuMDAwMDAwIDEuMDAwMDAw IHNyZ2IKbiAxMi4wMDAwMDAgOC4wMDAwMDAgbSAxMi4wMDAwMDAgMjQuMDAw MDAwIGwgMjAuMDAwMDAwIDI0LjAwMDAwMCBsIDIwLjAwMDAwMCA4LjAwMDAw MCBsIGYKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAowIHNsagowLjAw MDAwMCAwLjAwMDAwMCAwLjAwMDAwMCBzcmdiCm4gMTIuMDAwMDAwIDguMDAw MDAwIG0gMTIuMDAwMDAwIDI0LjAwMDAwMCBsIDIwLjAwMDAwMCAyNC4wMDAw MDAgbCAyMC4wMDAwMDAgOC4wMDAwMDAgbCBjcCBzCjEuMDAwMDAwIDEuMDAw MDAwIDEuMDAwMDAwIHNyZ2IKbiAxMi4wMDAwMDAgNS4wMDAwMDAgbSAxMi4w MDAwMDAgNi4wMDAwMDAgbCAyMC4wMDAwMDAgNi4wMDAwMDAgbCAyMC4wMDAw MDAgNS4wMDAwMDAgbCBmCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QK MCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAgMC4wMDAwMDAgc3JnYgpuIDEyLjAw MDAwMCA1LjAwMDAwMCBtIDEyLjAwMDAwMCA2LjAwMDAwMCBsIDIwLjAwMDAw MCA2LjAwMDAwMCBsIDIwLjAwMDAwMCA1LjAwMDAwMCBsIGNwIHMKL0hlbHZl dGljYS1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCihleGNlcHRpb24gdmVj dG9ycykgZHVwIHN3IDIgZGl2IDE2LjAwMDAwMCBleCBzdWIgNi4wMDAwMDAg bSBncyAxIC0xIHNjIHNoIGdyCjEuMDAwMDAwIDEuMDAwMDAwIDEuMDAwMDAw IHNyZ2IKbiAxMi4wMDAwMDAgNi4wMDAwMDAgbSAxMi4wMDAwMDAgOC4wMDAw MDAgbCAyMC4wMDAwMDAgOC4wMDAwMDAgbCAyMC4wMDAwMDAgNi4wMDAwMDAg bCBmCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGoKMC4wMDAw MDAgMC4wMDAwMDAgMC4wMDAwMDAgc3JnYgpuIDEyLjAwMDAwMCA2LjAwMDAw MCBtIDEyLjAwMDAwMCA4LjAwMDAwMCBsIDIwLjAwMDAwMCA4LjAwMDAwMCBs IDIwLjAwMDAwMCA2LjAwMDAwMCBsIGNwIHMKL0NvdXJpZXItbGF0aW4xIGZm IDAuODAwMDAwIHNjZiBzZgooa2VybmVsKSBkdXAgc3cgMiBkaXYgMTYuMDAw MDAwIGV4IHN1YiA3LjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAw MDAgMS4wMDAwMDAgMS4wMDAwMDAgc3JnYgpuIDEyLjAwMDAwMCAyNC4wMDAw MDAgbSAxMi4wMDAwMDAgMjguMDAwMDAwIGwgMjAuMDAwMDAwIDI4LjAwMDAw MCBsIDIwLjAwMDAwMCAyNC4wMDAwMDAgbCBmCjAuMTAwMDAwIHNsdwpbXSAw IHNkCltdIDAgc2QKMCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAgMC4wMDAwMDAg c3JnYgpuIDEyLjAwMDAwMCAyNC4wMDAwMDAgbSAxMi4wMDAwMDAgMjguMDAw MDAwIGwgMjAuMDAwMDAwIDI4LjAwMDAwMCBsIDIwLjAwMDAwMCAyNC4wMDAw MDAgbCBjcCBzCi9Db3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Ygc2YK KERNQSkgZHVwIHN3IDIgZGl2IDE2LjAwMDAwMCBleCBzdWIgMjYuMDAwMDAw IG0gZ3MgMSAtMSBzYyBzaCBncgoocmVzZXJ2ZWQpIGR1cCBzdyAyIGRpdiAx Ni4wMDAwMDAgZXggc3ViIDI2LjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IK L0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgooMHgwMDAwMDAw MCkgZHVwIHN3IDIgZGl2IDkuMDAwMDAwIGV4IHN1YiA1LjAwMDAwMCBtIGdz IDEgLTEgc2Mgc2ggZ3IKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNj ZiBzZgooMHgwMDAwMjAwMCkgZHVwIHN3IDIgZGl2IDkuMDAwMDAwIGV4IHN1 YiA2LjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKL0NvdXJpZXItbGF0aW4x IGZmIDAuODAwMDAwIHNjZiBzZgooMHg4MDAwMDAwMCkgZHVwIHN3IDIgZGl2 IDkuMDAwMDAwIGV4IHN1YiAyOC4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdy Ci9Db3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Ygc2YKKDB4N0YwMDAw MDApIGR1cCBzdyAyIGRpdiA5LjAwMDAwMCBleCBzdWIgMjQuMDAwMDAwIG0g Z3MgMSAtMSBzYyBzaCBncgowLjEwMDAwMCBzbHcKWzAuMjAwMDAwXSAwIHNk ClswLjIwMDAwMF0gMCBzZAowIHNsYwpuIDEyLjAwMDAwMCA5LjAwMDAwMCBt IDIwLjAwMDAwMCA5LjAwMDAwMCBsIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAu ODAwMDAwIHNjZiBzZgooMHgwMTAwMDAwMCkgZHVwIHN3IDIgZGl2IDkuMDAw MDAwIGV4IHN1YiA5LjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAw MDAgMC44MDAwMDAgMC44MDAwMDAgc3JnYgpuIDEyLjAwMDAwMCAzLjAwMDAw MCBtIDEyLjAwMDAwMCA1LjAwMDAwMCBsIDIwLjAwMDAwMCA1LjAwMDAwMCBs IDIwLjAwMDAwMCAzLjAwMDAwMCBsIGYKMC4yMDAwMDAgc2x3CltdIDAgc2QK W10gMCBzZAowIHNsagowLjAwMDAwMCAwLjAwMDAwMCAwLjAwMDAwMCBzcmdi Cm4gMTIuMDAwMDAwIDMuMDAwMDAwIG0gMTIuMDAwMDAwIDUuMDAwMDAwIGwg MjAuMDAwMDAwIDUuMDAwMDAwIGwgMjAuMDAwMDAwIDMuMDAwMDAwIGwgY3Ag cwovSGVsdmV0aWNhLUJvbGQtbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgoo cGh5c2ljYWwpIGR1cCBzdyAyIGRpdiAxNi4wMDAwMDAgZXggc3ViIDQuMDAw MDAwIG0gZ3MgMSAtMSBzYyBzaCBncgoobWVtb3J5KSBkdXAgc3cgMiBkaXYg MTYuMDAwMDAwIGV4IHN1YiA0LjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IK L0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgood2lyZWQpIGR1 cCBzdyAyIGRpdiAyMi4wMDAwMDAgZXggc3ViIDEyLjAwMDAwMCBtIGdzIDEg LTEgc2Mgc2ggZ3IKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAowIHNs YwpuIDI1LjAwMDAwMCAxMS4wMDAwMDAgbSAyMC4wMDAwMDAgNS4wMDAwMDAg bCBzCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAyNS4w MDAwMDAgMTIuMDAwMDAwIG0gMjAuMDAwMDAwIDkuMDAwMDAwIGwgcwowLjEw MDAwMCBzbHcKW10gMCBzZApbXSAwIHNkCjAgc2xjCm4gMjUuMDAwMDAwIDE3 LjAwMDAwMCBtIDIwLjAwMDAwMCAyNC4wMDAwMDAgbCBzCjAuMTAwMDAwIHNs dwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAyNS4wMDAwMDAgMTguMDAwMDAw IG0gMjAuMDAwMDAwIDI1LjAwMDAwMCBsIHMKMC44MDAwMDAgMS4wMDAwMDAg MC44MDAwMDAgc3JnYgpuIC02LjAwMDAwMCAzLjAwMDAwMCBtIC02LjAwMDAw MCA1LjAwMDAwMCBsIDIuMDAwMDAwIDUuMDAwMDAwIGwgMi4wMDAwMDAgMy4w MDAwMDAgbCBmCjAuMjAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGoK MC4wMDAwMDAgMC4wMDAwMDAgMC4wMDAwMDAgc3JnYgpuIC02LjAwMDAwMCAz LjAwMDAwMCBtIC02LjAwMDAwMCA1LjAwMDAwMCBsIDIuMDAwMDAwIDUuMDAw MDAwIGwgMi4wMDAwMDAgMy4wMDAwMDAgbCBjcCBzCi9IZWx2ZXRpY2EtQm9s ZC1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCih2aXJ0dWFsKSBkdXAgc3cg MiBkaXYgLTIuMDAwMDAwIGV4IHN1YiA0LjAwMDAwMCBtIGdzIDEgLTEgc2Mg c2ggZ3IKKGtzZWcwKSBkdXAgc3cgMiBkaXYgLTIuMDAwMDAwIGV4IHN1YiA0 LjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAwMDAgMS4wMDAwMDAg MS4wMDAwMDAgc3JnYgpuIC02LjAwMDAwMCA1LjAwMDAwMCBtIC02LjAwMDAw MCAxMy4wMDAwMDAgbCAyLjAwMDAwMCAxMy4wMDAwMDAgbCAyLjAwMDAwMCA1 LjAwMDAwMCBsIGYKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAowIHNs agowLjAwMDAwMCAwLjAwMDAwMCAwLjAwMDAwMCBzcmdiCm4gLTYuMDAwMDAw IDUuMDAwMDAwIG0gLTYuMDAwMDAwIDEzLjAwMDAwMCBsIDIuMDAwMDAwIDEz LjAwMDAwMCBsIDIuMDAwMDAwIDUuMDAwMDAwIGwgY3AgcwovQ291cmllci1s YXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCig1MTJNYikgZHVwIHN3IDIgZGl2 IC0yLjAwMDAwMCBleCBzdWIgOS4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdy Cih1bmNhY2hlZCkgZHVwIHN3IDIgZGl2IC0yLjAwMDAwMCBleCBzdWIgOS44 MDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAwMDAwIHNsdwpbXSAwIHNk CltdIDAgc2QKMCBzbGMKbiAyLjAwMDAwMCA1LjAwMDAwMCBtIDEyLjAwMDAw MCA1LjAwMDAwMCBsIHMKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAow IHNsYwpuIDIuMDAwMDAwIDEzLjAwMDAwMCBtIDEyLjAwMDAwMCAxMy4wMDAw MDAgbCBzCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAt Ni4wMDAwMDAgNi4wMDAwMDAgbSAyLjAwMDAwMCA2LjAwMDAwMCBsIHMKL0hl bHZldGljYS1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCihleGNlcHRpb24g dmVjdG9ycykgZHVwIHN3IDIgZGl2IC0yLjAwMDAwMCBleCBzdWIgNi4wMDAw MDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltd IDAgc2QKMCBzbGMKbiAyLjAwMDAwMCA2LjAwMDAwMCBtIDEyLjAwMDAwMCA2 LjAwMDAwMCBsIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBz ZgooMHgyMDAwMDAwMCkgZHVwIHN3IDIgZGl2IDkuMDAwMDAwIGV4IHN1YiAx My4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAwMDAwIHNsdwpbXSAw IHNkCltdIDAgc2QKMCBzbGMKbiAzNS4wMDAwMDAgNS4wMDAwMDAgbSAzMS4w MDAwMDAgMTEuMDAwMDAwIGwgcwowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAw IHNkCjAgc2xjCm4gMzUuMDAwMDAwIDkuMDAwMDAwIG0gMzEuMDAwMDAwIDEy LjAwMDAwMCBsIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBz ZgooMkdiKSBkdXAgc3cgMiBkaXYgMTYuMDAwMDAwIGV4IHN1YiAxNi4wMDAw MDAgbSBncyAxIC0xIHNjIHNoIGdyCihtZW1vcnkpIGR1cCBzdyAyIGRpdiAx Ni4wMDAwMDAgZXggc3ViIDE2LjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IK MC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAowIHNsYwpuIDM1LjAwMDAw MCAxNC4wMDAwMDAgbSAzMS4wMDAwMDAgMTcuMDAwMDAwIGwgcwowLjEwMDAw MCBzbHcKW10gMCBzZApbXSAwIHNkCjAgc2xjCm4gMzEuMDAwMDAwIDE4LjAw MDAwMCBtIDM1LjAwMDAwMCAxNS4wMDAwMDAgbCBzCi9IZWx2ZXRpY2EtQm9s ZE9ibGlxdWUtbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgooMTZNYikgZHVw IHN3IDIgZGl2IDIyLjAwMDAwMCBleCBzdWIgOS4wMDAwMDAgbSBncyAxIC0x IHNjIHNoIGdyCihwYWdlKSBkdXAgc3cgMiBkaXYgMjIuMDAwMDAwIGV4IHN1 YiA5LjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMC4xMDAwMDAgc2x3Cltd IDAgc2QKW10gMCBzZAowIHNsYwpuIDIzLjAwMDAwMCAxMi4wMDAwMDAgbSAy NS4wMDAwMDAgMTIuMDAwMDAwIGwgcwowIHNsagpuIDI0LjIwMDAwMCAxMi4y NTAwMDAgbSAyNS4wMDAwMDAgMTIuMDAwMDAwIGwgMjQuMjAwMDAwIDExLjc1 MDAwMCBsIGYKL0hlbHZldGljYS1Cb2xkT2JsaXF1ZS1sYXRpbjEgZmYgMC44 MDAwMDAgc2NmIHNmCig0S2IpIGR1cCBzdyAyIGRpdiAyMi41MDAwMDAgZXgg c3ViIDIwLjUwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKKHBhZ2UpIGR1cCBz dyAyIGRpdiAyMi41MDAwMDAgZXggc3ViIDIxLjMwMDAwMCBtIGdzIDEgLTEg c2Mgc2ggZ3IKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10gMCBzZAowIHNsYwpu IDM1LjAwMDAwMCAxMS4wMDAwMDAgbSAzMS4wMDAwMDAgMTQuMDAwMDAwIGwg cwowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAwIHNkCjAgc2xjCm4gMzUuMDAw MDAwIDEyLjAwMDAwMCBtIDMxLjAwMDAwMCAxNS4wMDAwMDAgbCBzCjAuMTAw MDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAyNS4wMDAwMDAgMTQu MDAwMDAwIG0gMjAuMDAwMDAwIDE4LjAwMDAwMCBsIHMKMC4xMDAwMDAgc2x3 CltdIDAgc2QKW10gMCBzZAowIHNsYwpuIDI1LjAwMDAwMCAxNS4wMDAwMDAg bSAyMC4wMDAwMDAgMTkuMDAwMDAwIGwgcwovSGVsdmV0aWNhLUJvbGRPYmxp cXVlLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Ygc2YKKDRLYikgZHVwIHN3IDIg ZGl2IDIyLjUwMDAwMCBleCBzdWIgMTYuMDAwMDAwIG0gZ3MgMSAtMSBzYyBz aCBncgoocGFnZSkgZHVwIHN3IDIgZGl2IDIyLjUwMDAwMCBleCBzdWIgMTYu ODAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgovQ291cmllci1sYXRpbjEgZmYg MC44MDAwMDAgc2NmIHNmCih0YXNrIHN3aXRjaCwpIGR1cCBzdyAyIGRpdiAy My4wMDAwMDAgZXggc3ViIDUyLjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IK KCByZXR1cm4gZnJvbSBzeXNjYWxsLCkgZHVwIHN3IDIgZGl2IDIzLjAwMDAw MCBleCBzdWIgNTIuODAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgooIC4uLikg ZHVwIHN3IDIgZGl2IDIzLjAwMDAwMCBleCBzdWIgNTMuNjAwMDAwIG0gZ3Mg MSAtMSBzYyBzaCBncgovSGVsdmV0aWNhLUJvbGQtbGF0aW4xIGZmIDEuMDAw MDAwIHNjZiBzZgooTWVtb3J5IG1hcHBpbmcpIGR1cCBzdyAyIGRpdiAxNy4w MDAwMDAgZXggc3ViIDAuMDAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgooXChL WD0wLFNYPTEsVVg9MVwpKSBkdXAgc3cgMiBkaXYgMTcuMDAwMDAwIGV4IHN1 YiAxLjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAwMDAgMS4wMDAw MDAgMS4wMDAwMDAgc3JnYgpuIDEzLjAwMDAwMCA1Mi4wMDAwMDAgMy4wMDAw MDAgMy4wMDAwMDAgMCAzNjAgZWxsaXBzZSBmCjAuMTAwMDAwIHNsdwpbXSAw IHNkCltdIDAgc2QKMC4wMDAwMDAgMC4wMDAwMDAgMC4wMDAwMDAgc3JnYgpu IDEzLjAwMDAwMCA1Mi4wMDAwMDAgMy4wMDAwMDAgMy4wMDAwMDAgMCAzNjAg ZWxsaXBzZSBjcCBzCi9Db3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Yg c2YKKDY0LWJpdCkgZHVwIHN3IDIgZGl2IDEzLjAwMDAwMCBleCBzdWIgNTIu MDAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgoodXNlcikgZHVwIHN3IDIgZGl2 IDEzLjAwMDAwMCBleCBzdWIgNTIuODAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBn cgoobW9kZSkgZHVwIHN3IDIgZGl2IDEzLjAwMDAwMCBleCBzdWIgNTMuNjAw MDAwIG0gZ3MgMSAtMSBzYyBzaCBncgoxLjAwMDAwMCAxLjAwMDAwMCAxLjAw MDAwMCBzcmdiCm4gMjUuMDAwMDAwIDU3LjAwMDAwMCAzLjAwMDAwMCAzLjAw MDAwMCAwIDM2MCBlbGxpcHNlIGYKMC4xMDAwMDAgc2x3CltdIDAgc2QKW10g MCBzZAowLjAwMDAwMCAwLjAwMDAwMCAwLjAwMDAwMCBzcmdiCm4gMjUuMDAw MDAwIDU3LjAwMDAwMCAzLjAwMDAwMCAzLjAwMDAwMCAwIDM2MCBlbGxpcHNl IGNwIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgooNjQt Yml0KSBkdXAgc3cgMiBkaXYgMjUuMDAwMDAwIGV4IHN1YiA1Ny4wMDAwMDAg bSBncyAxIC0xIHNjIHNoIGdyCihzdXBlcnZpc29yKSBkdXAgc3cgMiBkaXYg MjUuMDAwMDAwIGV4IHN1YiA1Ny44MDAwMDAgbSBncyAxIC0xIHNjIHNoIGdy Cihtb2RlKSBkdXAgc3cgMiBkaXYgMjUuMDAwMDAwIGV4IHN1YiA1OC42MDAw MDAgbSBncyAxIC0xIHNjIHNoIGdyCjEuMDAwMDAwIDEuMDAwMDAwIDEuMDAw MDAwIHNyZ2IKbiAxMy4wMDAwMDAgNjIuMDAwMDAwIDMuMDAwMDAwIDMuMDAw MDAwIDAgMzYwIGVsbGlwc2UgZgowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAw IHNkCjAuMDAwMDAwIDAuMDAwMDAwIDAuMDAwMDAwIHNyZ2IKbiAxMy4wMDAw MDAgNjIuMDAwMDAwIDMuMDAwMDAwIDMuMDAwMDAwIDAgMzYwIGVsbGlwc2Ug Y3AgcwovQ291cmllci1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCigzMi1i aXQpIGR1cCBzdyAyIGRpdiAxMy4wMDAwMDAgZXggc3ViIDYyLjAwMDAwMCBt IGdzIDEgLTEgc2Mgc2ggZ3IKKGtlcm5lbCkgZHVwIHN3IDIgZGl2IDEzLjAw MDAwMCBleCBzdWIgNjIuODAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgoobW9k ZSkgZHVwIHN3IDIgZGl2IDEzLjAwMDAwMCBleCBzdWIgNjMuNjAwMDAwIG0g Z3MgMSAtMSBzYyBzaCBncgowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAwIHNk CjAgc2xjCm4gMTMuMDAwMDAwIDU1LjAwMDAwMCBtIDEzLjAwMDAwMCA1OS4w MDAwMDAgbCBzCjAgc2xqCm4gMTIuNjAwMDAwIDU4LjIwMDAwMCBtIDEzLjAw MDAwMCA1OS4wMDAwMDAgbCAxMy40MDAwMDAgNTguMjAwMDAwIGwgZgovQ291 cmllci1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCihleGNlcHRpb24sZXJy b3IpIGR1cCBzdyAyIGRpdiA5LjAwMDAwMCBleCBzdWIgNTcuMDAwMDAwIG0g Z3MgMSAtMSBzYyBzaCBncgowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAwIHNk CjAgc2xjCm4gMTYuMDAwMDAwIDYyLjAwMDAwMCBtIDIyLjg3ODY4MCA1OS4x MjEzMjAgbCBzCjAgc2xqCm4gMjIuMjk1MTE4IDU5Ljc5OTE1MiBtIDIyLjg3 ODY4MCA1OS4xMjEzMjAgbCAyMS45ODYyNzcgNTkuMDYxMTcwIGwgZgovQ291 cmllci1sYXRpbjEgZmYgMC44MDAwMDAgc2NmIHNmCihleGNlcHRpb24pIGR1 cCBzdyAyIGRpdiAyMC4wMDAwMDAgZXggc3ViIDYyLjAwMDAwMCBtIGdzIDEg LTEgc2Mgc2ggZ3IKKGhhbmRsZXIpIGR1cCBzdyAyIGRpdiAyMC4wMDAwMDAg ZXggc3ViIDYyLjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKKFwoaW4ga3Nl ZzBcKSkgZHVwIHN3IDIgZGl2IDIwLjAwMDAwMCBleCBzdWIgNjMuNjAwMDAw IG0gZ3MgMSAtMSBzYyBzaCBncgowLjEwMDAwMCBzbHcKW10gMCBzZApbXSAw IHNkCjAgc2xjCm4gMjIuODc4NjgwIDU0Ljg3ODY4MCBtIDE2LjAwMDAwMCA1 Mi4wMDAwMDAgbCBzCjAgc2xqCm4gMTYuODkyNDAyIDUxLjkzOTg0OSBtIDE2 LjAwMDAwMCA1Mi4wMDAwMDAgbCAxNi41ODM1NjIgNTIuNjc3ODMxIGwgZgov SGVsdmV0aWNhLUJvbGQtbGF0aW4xIGZmIDEuMDAwMDAwIHNjZiBzZgooU3dp dGNoaW5nIGJldHdlZW4gbW9kZXMpIGR1cCBzdyAyIGRpdiAyMC4wMDAwMDAg ZXggc3ViIDQ3LjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAwMDAg MS4wMDAwMDAgMS4wMDAwMDAgc3JnYgpuIDM1LjAwMDAwMCA4LjAwMDAwMCBt IDM1LjAwMDAwMCAzNC4wMDAwMDAgbCA0My4wMDAwMDAgMzQuMDAwMDAwIGwg NDMuMDAwMDAwIDguMDAwMDAwIGwgZgowLjEwMDAwMCBzbHcKW10gMCBzZApb XSAwIHNkCjAgc2xqCjAuMDAwMDAwIDAuMDAwMDAwIDAuMDAwMDAwIHNyZ2IK biAzNS4wMDAwMDAgOC4wMDAwMDAgbSAzNS4wMDAwMDAgMzQuMDAwMDAwIGwg NDMuMDAwMDAwIDM0LjAwMDAwMCBsIDQzLjAwMDAwMCA4LjAwMDAwMCBsIGNw IHMKMS4wMDAwMDAgMS4wMDAwMDAgMS4wMDAwMDAgc3JnYgpuIDM1LjAwMDAw MCAxNC4wMDAwMDAgbSAzNS4wMDAwMDAgMTUuMDAwMDAwIGwgNDMuMDAwMDAw IDE1LjAwMDAwMCBsIDQzLjAwMDAwMCAxNC4wMDAwMDAgbCBmCjAuMTAwMDAw IHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAg MC4wMDAwMDAgc3JnYgpuIDM1LjAwMDAwMCAxNC4wMDAwMDAgbSAzNS4wMDAw MDAgMTUuMDAwMDAwIGwgNDMuMDAwMDAwIDE1LjAwMDAwMCBsIDQzLjAwMDAw MCAxNC4wMDAwMDAgbCBjcCBzCjEuMDAwMDAwIDEuMDAwMDAwIDEuMDAwMDAw IHNyZ2IKbiAzNS4wMDAwMDAgNS4wMDAwMDAgbSAzNS4wMDAwMDAgNi4wMDAw MDAgbCA0My4wMDAwMDAgNi4wMDAwMDAgbCA0My4wMDAwMDAgNS4wMDAwMDAg bCBmCjAuMTAwMDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGoKMC4wMDAw MDAgMC4wMDAwMDAgMC4wMDAwMDAgc3JnYgpuIDM1LjAwMDAwMCA1LjAwMDAw MCBtIDM1LjAwMDAwMCA2LjAwMDAwMCBsIDQzLjAwMDAwMCA2LjAwMDAwMCBs IDQzLjAwMDAwMCA1LjAwMDAwMCBsIGNwIHMKL0hlbHZldGljYS1sYXRpbjEg ZmYgMC44MDAwMDAgc2NmIHNmCihleGNlcHRpb24gdmVjdG9ycykgZHVwIHN3 IDIgZGl2IDM5LjAwMDAwMCBleCBzdWIgNi4wMDAwMDAgbSBncyAxIC0xIHNj IHNoIGdyCjEuMDAwMDAwIDEuMDAwMDAwIDEuMDAwMDAwIHNyZ2IKbiAzNS4w MDAwMDAgNi4wMDAwMDAgbSAzNS4wMDAwMDAgOC4wMDAwMDAgbCA0My4wMDAw MDAgOC4wMDAwMDAgbCA0My4wMDAwMDAgNi4wMDAwMDAgbCBmCjAuMTAwMDAw IHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAg MC4wMDAwMDAgc3JnYgpuIDM1LjAwMDAwMCA2LjAwMDAwMCBtIDM1LjAwMDAw MCA4LjAwMDAwMCBsIDQzLjAwMDAwMCA4LjAwMDAwMCBsIDQzLjAwMDAwMCA2 LjAwMDAwMCBsIGNwIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNj ZiBzZgooa2VybmVsKSBkdXAgc3cgMiBkaXYgMzkuMDAwMDAwIGV4IHN1YiA3 LjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKL0NvdXJpZXItbGF0aW4xIGZm IDAuODAwMDAwIHNjZiBzZgooRE1BIGJ1ZmZlcikgZHVwIHN3IDIgZGl2IDM5 LjAwMDAwMCBleCBzdWIgMTUuMDAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgow LjEwMDAwMCBzbHcKWzAuMjAwMDAwXSAwIHNkClswLjIwMDAwMF0gMCBzZAow IHNsYwpuIDM1LjAwMDAwMCA5LjAwMDAwMCBtIDQzLjAwMDAwMCA5LjAwMDAw MCBsIHMKMC44MDAwMDAgMS4wMDAwMDAgMC44MDAwMDAgc3JnYgpuIDM1LjAw MDAwMCAzLjAwMDAwMCBtIDM1LjAwMDAwMCA1LjAwMDAwMCBsIDQzLjAwMDAw MCA1LjAwMDAwMCBsIDQzLjAwMDAwMCAzLjAwMDAwMCBsIGYKMC4yMDAwMDAg c2x3CltdIDAgc2QKW10gMCBzZAowIHNsagowLjAwMDAwMCAwLjAwMDAwMCAw LjAwMDAwMCBzcmdiCm4gMzUuMDAwMDAwIDMuMDAwMDAwIG0gMzUuMDAwMDAw IDUuMDAwMDAwIGwgNDMuMDAwMDAwIDUuMDAwMDAwIGwgNDMuMDAwMDAwIDMu MDAwMDAwIGwgY3AgcwovSGVsdmV0aWNhLUJvbGQtbGF0aW4xIGZmIDAuODAw MDAwIHNjZiBzZgoodmlydHVhbCkgZHVwIHN3IDIgZGl2IDM5LjAwMDAwMCBl eCBzdWIgNC4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCih4c3NlZykgZHVw IHN3IDIgZGl2IDM5LjAwMDAwMCBleCBzdWIgNC44MDAwMDAgbSBncyAxIC0x IHNjIHNoIGdyCi9Db3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Ygc2YK KDE2IFRiKSBkdXAgc3cgMiBkaXYgMzkuMDAwMDAwIGV4IHN1YiAyMS4wMDAw MDAgbSBncyAxIC0xIHNjIHNoIGdyCihtYXBwZWQpIGR1cCBzdyAyIGRpdiAz OS4wMDAwMDAgZXggc3ViIDIxLjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IK MS4wMDAwMDAgMS4wMDAwMDAgMS4wMDAwMDAgc3JnYgpuIDM1LjAwMDAwMCAx MS4wMDAwMDAgbSAzNS4wMDAwMDAgMTIuMDAwMDAwIGwgNDMuMDAwMDAwIDEy LjAwMDAwMCBsIDQzLjAwMDAwMCAxMS4wMDAwMDAgbCBmCjAuMTAwMDAwIHNs dwpbXSAwIHNkCltdIDAgc2QKMCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAgMC4w MDAwMDAgc3JnYgpuIDM1LjAwMDAwMCAxMS4wMDAwMDAgbSAzNS4wMDAwMDAg MTIuMDAwMDAwIGwgNDMuMDAwMDAwIDEyLjAwMDAwMCBsIDQzLjAwMDAwMCAx MS4wMDAwMDAgbCBjcCBzCi9Db3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBz Y2Ygc2YKKG5vcm1hbCBidWZmZXIpIGR1cCBzdyAyIGRpdiAzOS4wMDAwMDAg ZXggc3ViIDEyLjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKMS4wMDAwMDAg MS4wMDAwMDAgMS4wMDAwMDAgc3JnYgpuIDI1LjAwMDAwMCAxMS4wMDAwMDAg bSAyNS4wMDAwMDAgMTkuMDAwMDAwIGwgMzEuMDAwMDAwIDE5LjAwMDAwMCBs IDMxLjAwMDAwMCAxMS4wMDAwMDAgbCBmCjAuMTAwMDAwIHNsdwpbXSAwIHNk CltdIDAgc2QKMCBzbGoKMC4wMDAwMDAgMC4wMDAwMDAgMC4wMDAwMDAgc3Jn YgpuIDI1LjAwMDAwMCAxMS4wMDAwMDAgbSAyNS4wMDAwMDAgMTkuMDAwMDAw IGwgMzEuMDAwMDAwIDE5LjAwMDAwMCBsIDMxLjAwMDAwMCAxMS4wMDAwMDAg bCBjcCBzCjAuODAwMDAwIDAuODAzOTIyIDEuMDAwMDAwIHNyZ2IKbiAyNS4w MDAwMDAgMTAuMDAwMDAwIG0gMjUuMDAwMDAwIDExLjAwMDAwMCBsIDMxLjAw MDAwMCAxMS4wMDAwMDAgbCAzMS4wMDAwMDAgMTAuMDAwMDAwIGwgZgowLjEw MDAwMCBzbHcKW10gMCBzZApbXSAwIHNkCjAgc2xqCjAuMDAwMDAwIDAuMDAw MDAwIDAuMDAwMDAwIHNyZ2IKbiAyNS4wMDAwMDAgMTAuMDAwMDAwIG0gMjUu MDAwMDAwIDExLjAwMDAwMCBsIDMxLjAwMDAwMCAxMS4wMDAwMDAgbCAzMS4w MDAwMDAgMTAuMDAwMDAwIGwgY3AgcwovSGVsdmV0aWNhLUJvbGQtbGF0aW4x IGZmIDAuODAwMDAwIHNjZiBzZgooVExCKSBkdXAgc3cgMiBkaXYgMjguMDAw MDAwIGV4IHN1YiAxMS4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAw MDAwIHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAyNS4wMDAwMDAgMTcu MDAwMDAwIG0gMzEuMDAwMDAwIDE3LjAwMDAwMCBsIHMKMC4xMDAwMDAgc2x3 ClswLjIwMDAwMF0gMCBzZApbMC4yMDAwMDBdIDAgc2QKMCBzbGMKbiAyNS4w MDAwMDAgMTIuMDAwMDAwIG0gMzEuMDAwMDAwIDEyLjAwMDAwMCBsIHMKL0Nv dXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBzZgoodW5jYWNoZWQpIGR1 cCBzdyAyIGRpdiAyOC4wMDAwMDAgZXggc3ViIDE4LjAwMDAwMCBtIGdzIDEg LTEgc2Mgc2ggZ3IKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNjZiBz ZgooY2FjaGVhYmxlKSBkdXAgc3cgMiBkaXYgMjguMDAwMDAwIGV4IHN1YiAx Mi4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAwMDAwIHNsdwpbXSAw IHNkCltdIDAgc2QKMCBzbGMKbiAyNS4wMDAwMDAgMTguMDAwMDAwIG0gMzEu MDAwMDAwIDE4LjAwMDAwMCBsIHMKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAw MDAwIHNjZiBzZgooY2FjaGVhYmxlKSBkdXAgc3cgMiBkaXYgMjguMDAwMDAw IGV4IHN1YiAxNS4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCjAuMTAwMDAw IHNsdwpbXSAwIHNkCltdIDAgc2QKMCBzbGMKbiAyNS4wMDAwMDAgMTQuMDAw MDAwIG0gMzEuMDAwMDAwIDE0LjAwMDAwMCBsIHMKMC4xMDAwMDAgc2x3Cltd IDAgc2QKW10gMCBzZAowIHNsYwpuIDI1LjAwMDAwMCAxNS4wMDAwMDAgbSAz MS4wMDAwMDAgMTUuMDAwMDAwIGwgcwovQ291cmllci1sYXRpbjEgZmYgMS40 MDAwMDAgc2NmIHNmCjEuMDAwMDAwIDAuMDAwMDAwIDAuMDAwMDAwIHNyZ2IK KCopIDMwLjAwMDAwMCAxOC4wMDAwMDAgbSBncyAxIC0xIHNjIHNoIGdyCi9D b3VyaWVyLWxhdGluMSBmZiAwLjgwMDAwMCBzY2Ygc2YKMC4wMDAwMDAgMC4w MDAwMDAgMC4wMDAwMDAgc3JnYgooYmVmb3JlIERNQSBcKGUuZy4gcGNpX21h cF9zaW5nbGVcKTopIC0yLjAwMDAwMCAzMy4wMDAwMDAgbSBncyAxIC0xIHNj IHNoIGdyCigtIHdyaXRlIGJhY2sgYW5kIGludmFsaWRpZGF0ZSBjYWNoZSkg LTIuMDAwMDAwIDMzLjgwMDAwMCBtIGdzIDEgLTEgc2Mgc2ggZ3IKKC0gbWFy ayBwYWdlcyBhcyB1bmNhY2hlZCkgLTIuMDAwMDAwIDM0LjYwMDAwMCBtIGdz IDEgLTEgc2Mgc2ggZ3IKL0NvdXJpZXItbGF0aW4xIGZmIDAuODAwMDAwIHNj ZiBzZgooYWZ0ZXIgRE1BIFwoZS5nLiBwY2lfdW5tYXBfc2luZ2xlXCk6KSAt Mi4wMDAwMDAgMzYuMDAwMDAwIG0gZ3MgMSAtMSBzYyBzaCBncgooLSB3cml0 ZSBiYWNrIGFuZCBpbnZhbGlkYXRlIGNhY2hlKSAtMi4wMDAwMDAgMzYuODAw MDAwIG0gZ3MgMSAtMSBzYyBzaCBncgooIFwoaWYgRE1BIHRyYW5zZmVyIHdh cyBub3Qgb25seSB0byBkZXZpY2VcKSkgLTIuMDAwMDAwIDM3LjYwMDAwMCBt IGdzIDEgLTEgc2Mgc2ggZ3IKKC0gbWFyayBwYWdlcyBhcyBjYWNoZWFibGUg bm9uLWNvaGVyZW50KSAtMi4wMDAwMDAgMzguNDAwMDAwIG0gZ3MgMSAtMSBz YyBzaCBncgovQ291cmllci1sYXRpbjEgZmYgMS40MDAwMDAgc2NmIHNmCjEu MDAwMDAwIDAuMDAwMDAwIDAuMDAwMDAwIHNyZ2IKKCopIGR1cCBzdyAyIGRp diAtMy4wMDAwMDAgZXggc3ViIDMzLjAwMDAwMCBtIGdzIDEgLTEgc2Mgc2gg Z3IKZ3IKc2hvd3BhZ2UKCg== --279724308-1017530808-1023488114=:2120-- From owner-linux-mips@oss.sgi.com Sat Jun 8 00: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 g587G0nC032601 for ; Sat, 8 Jun 2002 00:16:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g587G04S032599 for linux-mips-outgoing; Sat, 8 Jun 2002 00:16:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from web15003.mail.bjs.yahoo.com (web15003.mail.bjs.yahoo.com [61.135.128.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g587FrnC032596 for ; Sat, 8 Jun 2002 00:15:55 -0700 Message-ID: <20020608071755.96467.qmail@web15003.mail.bjs.yahoo.com> Received: from [61.187.56.10] by web15003.mail.bjs.yahoo.com via HTTP; Sat, 08 Jun 2002 15:17:55 CST Date: Sat, 8 Jun 2002 15:17:55 +0800 (CST) From: =?gb2312?q?Qingbo=20Wu?= Subject: can linux work well on sgi-ip27 system To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 367 Lines: 16 Hi, all, I read the code under arch/mips64, and find some code about sgi-ip27. I do not know if linux can work well on sgi-ip27 system. If someone knows, please give me a reply. Thanks in advance! Best Regards, Barry _________________________________________________________ Do You Yahoo!? 2002ÄêÊÀ½ç±­ÈºÐÛ÷éÕ½ ÑÅ»¢Öйú¾Û½¹ÈÕº« http://cn.fifaworldcup.yahoo.com/ From owner-linux-mips@oss.sgi.com Sat Jun 8 06:42: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 g58DgxnC003330 for ; Sat, 8 Jun 2002 06:42:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g58DgxfC003329 for linux-mips-outgoing; Sat, 8 Jun 2002 06:42: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 g58DgpnC003326 for ; Sat, 8 Jun 2002 06:42:51 -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 GAA03132; Sat, 8 Jun 2002 06:44:53 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA14837; Sat, 8 Jun 2002 06:44:50 -0700 (PDT) Message-ID: <009001c20ef3$98874980$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Kjeld Borch Egevang" , "Brad Parker" Cc: "linux-mips mailing list" References: <200206081240.g58Cewe10560@p2.parker.boston.ma.us> Subject: Re: float crash Date: Sat, 8 Jun 2002 15:51:27 +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 Content-Length: 2326 Lines: 62 The FP sr value does of course get initialized by default, but the bug which Kjeld identified could prevent it. The proper initialization of the emulated FPU state is done only if last_task_used_math != current, under the assumption that if the current task is the last task to have used the "FPU", the current emulation cannot be its first. But in exit_thread()/flush_thread(), we set last_task_used_math to NULL only if we have an FPU. Kjeld's patch breaks down the code so that the *hardware* shutdown is done only if there is an FPU, but the clearing of last_task_used_math must be done whenever the current process has done FP. Sorry about my offhand remark about no understanding its relevance in my earlier response about the usefulness of cfc1 $0,$31. Without Kjeld's patch, a process inheriting a thread context slot from a process which had done FP emulation would have inherited the FP register state, including SR, of that previous process. If you're seeing the problem only *with* Kjeld's patch, there must have been a typo inserted in the chain somewhere... Kevin K. ----- Original Message ----- From: "Brad Parker" To: "Kjeld Borch Egevang" ; "Kevin D. Kissell" Cc: "linux-mips mailing list" Sent: Saturday, June 08, 2002 2:40 PM Subject: re: float crash > > Quick question - > > I'm running a 2.4.17 kernel on an Au1000 (MIPS32). Trying to run > Kaffe I get SIGFPE's in odd places (like dividing 11 by 44). I tracked > it down to the fpe emulator setting the cx bit which is setting > the "inexact" bit in the fp status reg. > > I think the real problem is that the fp sr is not being initialized. > It doesn't happen in a trivial program but in Kaffe it happens a lot. > it's somewhat random, however, as if something is not initialized. > > I wonder if the fix you two where talking about is the problem; i.e. > in traps.c "if (last_task_used_math != current) {" > > Is there a recommended fix? Just comment out the test? > > thanks! > > -brad > > ps: I tried to subscribe to the linux-mips list but the sendmail on > oss.sgi.com is rejecting my email with "access denied". I don't have > any open relays and I'm not a spammer :-) I can't even send email > to the postmaster... > > From owner-linux-mips@oss.sgi.com Sat Jun 8 17: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 g590DmnC006940 for ; Sat, 8 Jun 2002 17:13:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g590DlDH006936 for linux-mips-outgoing; Sat, 8 Jun 2002 17:13: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 (c-180-196-40.ka.dial.de.ignite.net [62.180.196.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g590DFnC006858 for ; Sat, 8 Jun 2002 17:13:17 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g590EAK07868 for linux-mips@oss.sgi.com; Sun, 9 Jun 2002 02:14:10 +0200 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 g57CwJnC010310 for ; Fri, 7 Jun 2002 05:58: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 GAA20147 for ; Fri, 7 Jun 2002 06:00:17 -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 GAA11407 for ; Fri, 7 Jun 2002 06:00:15 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g57D0Fb21789 for ; Fri, 7 Jun 2002 15:00:15 +0200 (MEST) Message-ID: <3D00AE5F.ED130473@mips.com> Date: Fri, 07 Jun 2002 15:00:15 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips mailing list Subject: 64-bit linux Content-Type: multipart/mixed; boundary="------------6A228B530B40164C0D9211A7" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 82155 Lines: 3002 This is a multi-part message in MIME format. --------------6A228B530B40164C0D9211A7 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit There has been some interest for the 64-bit kernel, so I have pull together a patch against the latest sources, which contains our local fixes and changes. Could some please apply these fixes. Added file are arch/mips64/mm/c-mips64.c arch/mips64/mm/pg-mips64.c arch/mips64/mm/tlb-r4k.c include/asm-mips64/mips64_cache.h /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 --------------6A228B530B40164C0D9211A7 Content-Type: text/plain; charset=iso-8859-15; name="linux-2.4.18.64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux-2.4.18.64.patch" Index: arch/mips64/Makefile =================================================================== RCS file: /cvs/linux/arch/mips64/Makefile,v retrieving revision 1.22.2.3 diff -u -r1.22.2.3 Makefile --- arch/mips64/Makefile 2002/02/26 23:59:53 1.22.2.3 +++ arch/mips64/Makefile 2002/06/07 12:26:00 @@ -66,6 +66,9 @@ ifdef CONFIG_CPU_SB1 CFLAGS += -mcpu=r8000 -mips4 endif +ifdef CONFIG_CPU_MIPS64 +CFLAGS += -mcpu=r8000 -mips4 +endif # # We unconditionally build the math emulator Index: arch/mips64/config.in =================================================================== RCS file: /cvs/linux/arch/mips64/config.in,v retrieving revision 1.50.2.9 diff -u -r1.50.2.9 config.in --- arch/mips64/config.in 2002/05/29 14:30:57 1.50.2.9 +++ arch/mips64/config.in 2002/06/07 12:26:00 @@ -70,10 +70,14 @@ if [ "$CONFIG_MIPS_MALTA" = "y" ]; then define_bool CONFIG_BOOT_ELF32 y define_bool CONFIG_I8259 y + define_bool CONFIG_HAVE_STD_PC_SERIAL_PORT y + define_bool CONFIG_NEW_IRQ y + define_bool CONFIG_NEW_TIME_C y define_int CONFIG_L1_CACHE_SHIFT 5 define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI y define_bool CONFIG_SWAP_IO_SPACE y + define_bool CONFIG_PC_KEYB y fi if [ "$CONFIG_SGI_IP22" = "y" ]; then define_bool CONFIG_ARC32 y @@ -118,20 +122,25 @@ mainmenu_option next_comment comment 'CPU selection' -choice 'CPU type' \ - "R4300 CONFIG_CPU_R4300 \ - R4x00 CONFIG_CPU_R4X00 \ - R5000 CONFIG_CPU_R5000 \ - R52x0 CONFIG_CPU_NEVADA \ - R8000 CONFIG_CPU_R8000 \ - R10000 CONFIG_CPU_R10000 \ - SB1 CONFIG_CPU_SB1" R4x00 +choice 'CPU type' \ + "R4300 CONFIG_CPU_R4300 \ + R4x00 CONFIG_CPU_R4X00 \ + R5000 CONFIG_CPU_R5000 \ + R52x0 CONFIG_CPU_NEVADA \ + R8000 CONFIG_CPU_R8000 \ + R10000 CONFIG_CPU_R10000 \ + SB1 CONFIG_CPU_SB1 \ + MIPS64 CONFIG_CPU_MIPS64" R4x00 endmenu if [ "$CONFIG_CPU_SB1" = "y" ]; then bool ' Workarounds for pass 1 sb1 bugs' CONFIG_SB1_PASS_1_WORKAROUNDS bool ' Support for SB1 Cache Error handler' CONFIG_SB1_CACHE_ERROR define_bool CONFIG_VTAG_ICACHE y +fi + +if [ "$CONFIG_CPU_MIPS64" = "y" ]; then + bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE fi define_bool CONFIG_CPU_HAS_LLSC y Index: arch/mips64/kernel/Makefile =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/Makefile,v retrieving revision 1.11.2.5 diff -u -r1.11.2.5 Makefile --- arch/mips64/kernel/Makefile 2002/06/03 15:16:49 1.11.2.5 +++ arch/mips64/kernel/Makefile 2002/06/07 12:26:00 @@ -15,12 +15,15 @@ export-objs = irq.o mips64_ksyms.o pci-dma.o setup.o smp.o -obj-y := branch.o entry.o irq.o proc.o process.o ptrace.o r4k_cache.o \ - r4k_fpu.o r4k_genex.o r4k_switch.o reset.o scall_64.o semaphore.o \ - setup.o signal.o syscall.o time.o traps.o unaligned.o +obj-y := branch.o entry.o proc.o process.o ptrace.o r4k_cache.o \ + r4k_fpu.o r4k_genex.o r4k_switch.o reset.o scall_64.o \ + semaphore.o setup.o signal.o syscall.o traps.o unaligned.o +obj-$(CONFIG_NEW_IRQ) += irq.o obj-$(CONFIG_I8259) += i8259.o obj-$(CONFIG_IRQ_CPU) += irq_cpu.o + +obj-$(CONFIG_NEW_TIME_C) += time.o obj-$(CONFIG_MODULES) += mips64_ksyms.o obj-$(CONFIG_MIPS32_COMPAT) += linux32.o scall_o32.o signal32.o ioctl32.o Index: arch/mips64/kernel/entry.S =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/entry.S,v retrieving revision 1.11.2.4 diff -u -r1.11.2.4 entry.S --- arch/mips64/kernel/entry.S 2002/05/29 03:03:17 1.11.2.4 +++ arch/mips64/kernel/entry.S 2002/06/07 12:26:00 @@ -24,7 +24,7 @@ FEXPORT(ret_from_fork) move a0, v0 # prev jal schedule_tail - lw t0, TASK_PTRACE($28) # syscall tracing enabled? + ld t0, TASK_PTRACE($28) # syscall tracing enabled? andi t0, PT_TRACESYS bnez t0, tracesys_exit j ret_from_sys_call Index: arch/mips64/kernel/head.S =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/head.S,v retrieving revision 1.34.2.4 diff -u -r1.34.2.4 head.S --- arch/mips64/kernel/head.S 2002/02/26 05:59:03 1.34.2.4 +++ arch/mips64/kernel/head.S 2002/06/07 12:26:00 @@ -92,7 +92,7 @@ __INIT NESTED(kernel_entry, 16, sp) # kernel entry point - + .set noreorder ori sp, 0xf # align stack on 16 byte. xori sp, 0xf @@ -111,8 +111,22 @@ set_saved_sp sp, t0 dsubu sp, 4*SZREG # init stack pointer + + /* The firmware/bootloader passes argc/argp/envp + * to us as arguments. But clear bss first because + * the romvec and other important info is stored there + * by prom_init(). + */ + la t0, _edata + sd zero, (t0) + la t1, (_end - 8) +1: + daddiu t0, 8 + bne t0, t1, 1b + sd zero, (t0) j init_arch + nop END(kernel_entry) #ifdef CONFIG_SMP Index: arch/mips64/kernel/ioctl32.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/ioctl32.c,v retrieving revision 1.10.2.1 diff -u -r1.10.2.1 ioctl32.c --- arch/mips64/kernel/ioctl32.c 2001/12/03 07:26:20 1.10.2.1 +++ arch/mips64/kernel/ioctl32.c 2002/06/07 12:26:00 @@ -27,6 +27,7 @@ #include #include #include +#include #include #undef __KERNEL__ /* This file was born to be ugly ... */ #include @@ -834,7 +835,25 @@ IOCTL32_DEFAULT(AUTOFS_IOC_CATATONIC), IOCTL32_DEFAULT(AUTOFS_IOC_PROTOVER), IOCTL32_HANDLER(AUTOFS_IOC_SETTIMEOUT32, ioc_settimeout), - IOCTL32_DEFAULT(AUTOFS_IOC_EXPIRE) + IOCTL32_DEFAULT(AUTOFS_IOC_EXPIRE), + + /* Little p (/dev/rtc, /dev/envctrl, etc.) */ + IOCTL32_DEFAULT(_IOR('p', 20, int[7])), /* RTCGET */ + IOCTL32_DEFAULT(_IOW('p', 21, int[7])), /* RTCSET */ + IOCTL32_DEFAULT(RTC_AIE_ON), + IOCTL32_DEFAULT(RTC_AIE_OFF), + IOCTL32_DEFAULT(RTC_UIE_ON), + IOCTL32_DEFAULT(RTC_UIE_OFF), + IOCTL32_DEFAULT(RTC_PIE_ON), + IOCTL32_DEFAULT(RTC_PIE_OFF), + IOCTL32_DEFAULT(RTC_WIE_ON), + IOCTL32_DEFAULT(RTC_WIE_OFF), + IOCTL32_DEFAULT(RTC_ALM_SET), + IOCTL32_DEFAULT(RTC_ALM_READ), + IOCTL32_DEFAULT(RTC_RD_TIME), + IOCTL32_DEFAULT(RTC_SET_TIME), + IOCTL32_DEFAULT(RTC_WKALM_SET), + IOCTL32_DEFAULT(RTC_WKALM_RD) }; #define NR_IOCTL32_HANDLERS (sizeof(ioctl32_handler_table) / \ Index: arch/mips64/kernel/pci-dma.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/Attic/pci-dma.c,v retrieving revision 1.1.2.2 diff -u -r1.1.2.2 pci-dma.c --- arch/mips64/kernel/pci-dma.c 2002/05/29 03:03:17 1.1.2.2 +++ arch/mips64/kernel/pci-dma.c 2002/06/07 12:26:00 @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -22,24 +23,31 @@ void *ret; int gfp = GFP_ATOMIC; - if (hwdev != NULL && hwdev->dma_mask != 0xffffffff) + if (hwdev == NULL || hwdev->dma_mask != 0xffffffff) gfp |= GFP_DMA; ret = (void *) __get_free_pages(gfp, get_order(size)); - if (ret != NULL) { memset(ret, 0, size); + *dma_handle = __pa(ret); #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long) ret, size); ret = KSEG1ADDR(ret); #endif - *dma_handle = __pa(ret); - return ret; } - return NULL; + + return ret; } void pci_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle) { - free_pages((unsigned long) KSEG0ADDR(vaddr), get_order(size)); + unsigned long addr = (unsigned long) vaddr; + +#ifdef CONFIG_NONCOHERENT_IO + addr = KSEG0ADDR(addr); +#endif + free_pages(addr, get_order(size)); } + +EXPORT_SYMBOL(pci_alloc_consistent); +EXPORT_SYMBOL(pci_free_consistent); Index: arch/mips64/kernel/r4k_fpu.S =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/r4k_fpu.S,v retrieving revision 1.3 diff -u -r1.3 r4k_fpu.S --- arch/mips64/kernel/r4k_fpu.S 2001/05/25 20:07:50 1.3 +++ arch/mips64/kernel/r4k_fpu.S 2002/06/07 12:26:00 @@ -31,7 +31,7 @@ .set noreorder /* Save floating point context */ -LEAF(save_fp_context) +LEAF(_save_fp_context) mfc0 t1, CP0_STATUS sll t2, t1,5 @@ -79,7 +79,7 @@ jr ra li v0, 0 # success - END(save_fp_context) + END(_save_fp_context) /* * Restore FPU state: @@ -90,7 +90,7 @@ * frame on the current content of c0_status, not on the content of the * stack frame which might have been changed by the user. */ -LEAF(restore_fp_context) +LEAF(_restore_fp_context) mfc0 t1, CP0_STATUS sll t0, t1,5 bgez t0, 1f @@ -139,7 +139,7 @@ ctc1 t0, fcr31 jr ra li v0, 0 # success - END(restore_fp_context) + END(_restore_fp_context) .type fault@function .ent fault Index: arch/mips64/kernel/setup.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/setup.c,v retrieving revision 1.31.2.6 diff -u -r1.31.2.6 setup.c --- arch/mips64/kernel/setup.c 2002/06/03 15:16:49 1.31.2.6 +++ arch/mips64/kernel/setup.c 2002/06/07 12:26:00 @@ -141,9 +141,6 @@ case CPU_NEVADA: case CPU_RM7000: case CPU_TX49XX: - case CPU_4KC: - case CPU_4KEC: - case CPU_4KSC: case CPU_5KC: /* case CPU_20KC:*/ cpu_wait = r4k_wait; @@ -182,6 +179,20 @@ #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); + __enable_fpu(); + fpu_id = read_32bit_cp1_register(CP1_REVISION); + write_32bit_cp0_register(CP0_STATUS, tmp); + return fpu_id; +} + /* declaration of the global struct */ struct mips_cpu mips_cpu = { processor_id: PRID_IMP_UNKNOWN, @@ -194,15 +205,16 @@ static inline void cpu_probe(void) { -#ifdef CONFIG_CPU_MIPS32 - unsigned long config0 = read_32bit_cp0_register(CP0_CONFIG); - unsigned long config1; +#ifdef CONFIG_CPU_MIPS64 + unsigned int config0 = read_32bit_cp0_register(CP0_CONFIG); + unsigned int config1; if (config0 & (1 << 31)) { - /* MIPS32 compliant CPU. Read Config 1 register. */ - mips_cpu.isa_level = MIPS_CPU_ISA_M32; + /* MIPS64 compliant CPU. Read Config 1 register. */ + mips_cpu.isa_level = MIPS_CPU_ISA_M64; mips_cpu.options = MIPS_CPU_TLB | MIPS_CPU_4KEX | - MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC; + MIPS_CPU_4KTLB | MIPS_CPU_COUNTER | MIPS_CPU_DIVEC | + MIPS_CPU_32FPR; config1 = read_mips32_cp0_config1(); if (config1 & (1 << 3)) mips_cpu.options |= MIPS_CPU_WATCH; @@ -399,25 +411,15 @@ break; } break; -#ifdef CONFIG_CPU_MIPS32 +#ifdef CONFIG_CPU_MIPS64 case PRID_COMP_MIPS: switch (mips_cpu.processor_id & 0xff00) { - case PRID_IMP_4KC: - mips_cpu.cputype = CPU_4KC; - break; - case PRID_IMP_4KEC: - mips_cpu.cputype = CPU_4KEC; - break; - case PRID_IMP_4KSC: - mips_cpu.cputype = CPU_4KSC; - break; case PRID_IMP_5KC: mips_cpu.cputype = CPU_5KC; - mips_cpu.isa_level = MIPS_CPU_ISA_M64; break; case PRID_IMP_20KC: mips_cpu.cputype = CPU_20KC; - mips_cpu.isa_level = MIPS_CPU_ISA_M64; + break; default: mips_cpu.cputype = CPU_UNKNOWN; break; @@ -459,6 +461,8 @@ default: mips_cpu.cputype = CPU_UNKNOWN; } + if (mips_cpu.options & MIPS_CPU_FPU) + mips_cpu.fpu_id = cpu_get_fpu_id(); } static inline void cpu_report(void) @@ -721,10 +725,11 @@ #endif #ifdef CONFIG_SIBYTE_SWARM swarm_setup(); - bootmem_init(); /* XXX */ #endif - -#ifdef CONFIG_ARC_MEMORY +#ifdef CONFIG_MIPS_MALTA + malta_setup(); +#endif +#if defined(CONFIG_ARC_MEMORY) || defined(CONFIG_SIBYTE_SWARM) || defined(CONFIG_MIPS_MALTA) bootmem_init(); #endif Index: arch/mips64/kernel/traps.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/traps.c,v retrieving revision 1.30.2.13 diff -u -r1.30.2.13 traps.c --- arch/mips64/kernel/traps.c 2002/05/28 06:33:13 1.30.2.13 +++ arch/mips64/kernel/traps.c 2002/06/07 12:26:00 @@ -607,6 +607,15 @@ } } +asmlinkage int (*save_fp_context)(struct sigcontext *sc); +asmlinkage int (*restore_fp_context)(struct sigcontext *sc); +extern asmlinkage int _save_fp_context(struct sigcontext *sc); +extern asmlinkage int _restore_fp_context(struct sigcontext *sc); + +extern asmlinkage int fpu_emulator_save_context(struct sigcontext *sc); +extern asmlinkage int fpu_emulator_restore_context(struct sigcontext *sc); + + void __init per_cpu_trap_init(void) { unsigned int cpu = smp_processor_id(); @@ -630,6 +639,7 @@ void __init trap_init(void) { extern char except_vec0; +/* extern char except_vec1_r4k;*/ extern char except_vec1_r10k; extern char except_vec2_generic, except_vec2_sb1; extern char except_vec3_generic, except_vec3_r4000; @@ -692,14 +702,18 @@ case CPU_R4600: case CPU_R5000: case CPU_NEVADA: - /* Cache error vector */ - memcpy((void *)(KSEG0 + 0x100), (void *) KSEG0, 0x80); - + case CPU_5KC: + case CPU_20KC: + case CPU_RM7000: nocache: /* Debug TLB refill handler. */ memcpy((void *)KSEG0, &except_vec0, 0x80); - memcpy((void *)KSEG0 + 0x080, &except_vec1_r10k, 0x80); - +/* if ((mips_cpu.options & MIPS_CPU_4KEX) + && (mips_cpu.options & MIPS_CPU_4KTLB)) { + memcpy((void *)KSEG0 + 0x080, &except_vec1_r4k, 0x80); + } else { */ + memcpy((void *)KSEG0 + 0x080, &except_vec1_r10k, 0x80); +/* }*/ if (mips_cpu.options & MIPS_CPU_VCE) { memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, 0x80); @@ -746,6 +760,15 @@ default: panic("Unknown CPU type"); } + + if (mips_cpu.options & MIPS_CPU_FPU) { + save_fp_context = _save_fp_context; + restore_fp_context = _restore_fp_context; + } else { + save_fp_context = fpu_emulator_save_context; + restore_fp_context = fpu_emulator_restore_context; + } + flush_icache_range(KSEG0, KSEG0 + 0x200); if (mips_cpu.isa_level == MIPS_CPU_ISA_IV) Index: arch/mips64/mm/Makefile =================================================================== RCS file: /cvs/linux/arch/mips64/mm/Makefile,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 Makefile --- arch/mips64/mm/Makefile 2002/02/21 04:38:01 1.8.2.2 +++ arch/mips64/mm/Makefile 2002/06/07 12:26:00 @@ -17,6 +17,8 @@ obj-$(CONFIG_CPU_R10000) += andes.o tlbex-r4k.o tlb-glue-r4k.o obj-$(CONFIG_CPU_SB1) += pg-sb1.o c-sb1.o tlb-sb1.o tlbex-r4k.o \ tlb-glue-r4k.o +obj-$(CONFIG_CPU_MIPS64) += pg-mips64.o c-mips64.o tlb-r4k.o \ + tlbex-r4k.o tlb-glue-r4k.o # # Debug TLB exception handler, currently unused Index: arch/mips64/mm/loadmmu.c =================================================================== RCS file: /cvs/linux/arch/mips64/mm/loadmmu.c,v retrieving revision 1.14.2.3 diff -u -r1.14.2.3 loadmmu.c --- arch/mips64/mm/loadmmu.c 2002/02/18 01:14:46 1.14.2.3 +++ arch/mips64/mm/loadmmu.c 2002/06/07 12:26:01 @@ -54,33 +54,27 @@ extern void ld_mmu_andes(void); extern void ld_mmu_sb1(void); extern void sb1_tlb_init(void); +extern void ld_mmu_mips64(void); +extern void r4k_tlb_init(void); + void __init load_mmu(void) { - switch(mips_cpu.cputype) { + if (mips_cpu.options & MIPS_CPU_4KTLB) { #if defined (CONFIG_CPU_R4300) \ || defined (CONFIG_CPU_R4X00) \ || defined (CONFIG_CPU_R5000) \ || defined (CONFIG_CPU_NEVADA) - case CPU_R4000PC: - case CPU_R4000SC: - case CPU_R4000MC: - case CPU_R4200: - case CPU_R4300: - case CPU_R4400PC: - case CPU_R4400SC: - case CPU_R4400MC: - case CPU_R4600: - case CPU_R4640: - case CPU_R4650: - case CPU_R4700: - case CPU_R5000: - case CPU_R5000A: - case CPU_NEVADA: printk("Loading R4000 MMU routines.\n"); ld_mmu_r4xx0(); - break; #endif +#if defined(CONFIG_CPU_MIPS64) + printk("Loading MIPS64 MMU routines.\n"); + ld_mmu_mips64(); + r4k_tlb_init(); +#endif + + } else switch(mips_cpu.cputype) { #ifdef CONFIG_CPU_R10000 case CPU_R10000: printk("Loading R10000 MMU routines.\n"); @@ -94,8 +88,7 @@ sb1_tlb_init(); break; #endif - default: /* XXX We need an generic routine in the MIPS port * XXX to jabber stuff onto the screen on all machines Index: include/asm-mips64/addrspace.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/addrspace.h,v retrieving revision 1.10 diff -u -r1.10 addrspace.h --- include/asm-mips64/addrspace.h 2001/07/09 00:25:37 1.10 +++ include/asm-mips64/addrspace.h 2002/06/07 12:26:15 @@ -29,15 +29,15 @@ * Returns the physical address of a KSEG0/KSEG1 address */ #define CPHYSADDR(a) (((unsigned long)(a)) & 0x000000001fffffffUL) -#define PHYSADDR(a) (((unsigned long)(a)) & 0x000000ffffffffffUL) +#define PHYSADDR(a) (((unsigned long)(a)) & 0x000000001fffffffUL) /* * Map an address to a certain kernel segment */ -#define KSEG0ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000ffffffffffUL) | KSEG0)) -#define KSEG1ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000ffffffffffUL) | KSEG1)) -#define KSEG2ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000ffffffffffUL) | KSEG2)) -#define KSEG3ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000ffffffffffUL) | KSEG3)) +#define KSEG0ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000001fffffffUL) | KSEG0)) +#define KSEG1ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000001fffffffUL) | KSEG1)) +#define KSEG2ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000001fffffffUL) | KSEG2)) +#define KSEG3ADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x000000001fffffffUL) | KSEG3)) /* * Memory segments (64bit kernel mode addresses) Index: include/asm-mips64/cache.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/cache.h,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 cache.h --- include/asm-mips64/cache.h 2002/05/29 03:03:18 1.7.2.1 +++ include/asm-mips64/cache.h 2002/06/07 12:26:15 @@ -23,6 +23,11 @@ }; #endif +/* + * Flag definitions + */ +#define MIPS_CACHE_NOT_PRESENT 0x00000001 + /* bytes per L1 cache line */ #define L1_CACHE_BYTES (1 << CONFIG_L1_CACHE_SHIFT) Index: include/asm-mips64/checksum.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/checksum.h,v retrieving revision 1.12 diff -u -r1.12 checksum.h --- include/asm-mips64/checksum.h 2001/10/31 02:31:23 1.12 +++ include/asm-mips64/checksum.h 2002/06/07 12:26:15 @@ -161,9 +161,9 @@ : "=r" (sum) : "0" (daddr), "r"(saddr), #ifdef __MIPSEL__ - "r" ((ntohs(len)<<16)+proto*256), + "r" (((unsigned long)ntohs(len)<<16)+proto*256), #else - "r" (((proto)<<16)+len), + "r" ((((unsigned long)proto)<<16)+len), #endif "r" (sum)); Index: include/asm-mips64/ide.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/ide.h,v retrieving revision 1.6 diff -u -r1.6 ide.h --- include/asm-mips64/ide.h 2001/08/22 03:25:05 1.6 +++ include/asm-mips64/ide.h 2002/06/07 12:26:15 @@ -18,6 +18,7 @@ #ifdef __KERNEL__ #include +#include #ifndef MAX_HWIFS # ifdef CONFIG_BLK_DEV_IDEPCI @@ -79,11 +80,19 @@ typedef union { unsigned all : 8; /* all of the bits together */ struct { +#ifdef __MIPSEB__ + unsigned bit7 : 1; /* always 1 */ + unsigned lba : 1; /* using LBA instead of CHS */ + unsigned bit5 : 1; /* always 1 */ + unsigned unit : 1; /* drive select number, 0 or 1 */ + unsigned head : 4; /* always zeros here */ +#else unsigned head : 4; /* always zeros here */ unsigned unit : 1; /* drive select number, 0 or 1 */ unsigned bit5 : 1; /* always 1 */ unsigned lba : 1; /* using LBA instead of CHS */ unsigned bit7 : 1; /* always 1 */ +#endif } b; } select_t; @@ -118,54 +127,141 @@ #if defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) -#ifdef insl -#undef insl -#endif -#ifdef outsl -#undef outsl -#endif +/* get rid of defs from io.h - ide has its private and conflicting versions */ #ifdef insw #undef insw #endif #ifdef outsw #undef outsw #endif +#ifdef insl +#undef insl +#endif +#ifdef outsl +#undef outsl +#endif + +#define insw(port, addr, count) ide_insw(port, addr, count) +#define insl(port, addr, count) ide_insl(port, addr, count) +#define outsw(port, addr, count) ide_outsw(port, addr, count) +#define outsl(port, addr, count) ide_outsl(port, addr, count) + +static inline void ide_insw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u16 *)addr = *(volatile u16 *)(mips_io_port_base + port); + addr += 2; + } +} + +static inline void ide_outsw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(volatile u16 *)(mips_io_port_base + (port)) = *(u16 *)addr; + addr += 2; + } +} + +static inline void ide_insl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u32 *)addr = *(volatile u32 *)(mips_io_port_base + port); + addr += 4; + } +} + +static inline void ide_outsl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(volatile u32 *)(mips_io_port_base + (port)) = *(u32 *)addr; + addr += 4; + } +} + +#define T_CHAR (0x0000) /* char: don't touch */ +#define T_SHORT (0x4000) /* short: 12 -> 21 */ +#define T_INT (0x8000) /* int: 1234 -> 4321 */ +#define T_TEXT (0xc000) /* text: 12 -> 21 */ + +#define T_MASK_TYPE (0xc000) +#define T_MASK_COUNT (0x3fff) + +#define D_CHAR(cnt) (T_CHAR | (cnt)) +#define D_SHORT(cnt) (T_SHORT | (cnt)) +#define D_INT(cnt) (T_INT | (cnt)) +#define D_TEXT(cnt) (T_TEXT | (cnt)) + +static u_short driveid_types[] = { + D_SHORT(10), /* config - vendor2 */ + D_TEXT(20), /* serial_no */ + D_SHORT(3), /* buf_type - ecc_bytes */ + D_TEXT(48), /* fw_rev - model */ + D_CHAR(2), /* max_multsect - vendor3 */ + D_SHORT(1), /* dword_io */ + D_CHAR(2), /* vendor4 - capability */ + D_SHORT(1), /* reserved50 */ + D_CHAR(4), /* vendor5 - tDMA */ + D_SHORT(4), /* field_valid - cur_sectors */ + D_INT(1), /* cur_capacity */ + D_CHAR(2), /* multsect - multsect_valid */ + D_INT(1), /* lba_capacity */ + D_SHORT(194) /* dma_1word - reservedyy */ +}; -#define insw(p,a,c) \ -do { \ - unsigned short *ptr = (unsigned short *)(a); \ - unsigned int i = (c); \ - while (i--) \ - *ptr++ = inw(p); \ -} while (0) -#define insl(p,a,c) \ -do { \ - unsigned long *ptr = (unsigned long *)(a); \ - unsigned int i = (c); \ - while (i--) \ - *ptr++ = inl(p); \ -} while (0) -#define outsw(p,a,c) \ -do { \ - unsigned short *ptr = (unsigned short *)(a); \ - unsigned int i = (c); \ - while (i--) \ - outw(*ptr++, (p)); \ -} while (0) -#define outsl(p,a,c) { \ - unsigned long *ptr = (unsigned long *)(a); \ - unsigned int i = (c); \ - while (i--) \ - outl(*ptr++, (p)); \ -} while (0) +#define num_driveid_types (sizeof(driveid_types)/sizeof(*driveid_types)) -#endif /* defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) */ +static __inline__ void ide_fix_driveid(struct hd_driveid *id) +{ + u_char *p = (u_char *)id; + int i, j, cnt; + u_char t; + + for (i = 0; i < num_driveid_types; i++) { + cnt = driveid_types[i] & T_MASK_COUNT; + switch (driveid_types[i] & T_MASK_TYPE) { + case T_CHAR: + p += cnt; + break; + case T_SHORT: + for (j = 0; j < cnt; j++) { + t = p[0]; + p[0] = p[1]; + p[1] = t; + p += 2; + } + break; + case T_INT: + for (j = 0; j < cnt; j++) { + t = p[0]; + p[0] = p[3]; + p[3] = t; + t = p[1]; + p[1] = p[2]; + p[2] = t; + p += 4; + } + break; + case T_TEXT: + for (j = 0; j < cnt; j += 2) { + t = p[0]; + p[0] = p[1]; + p[1] = t; + p += 2; + } + break; + }; + } +} +#else /* defined(CONFIG_SWAP_IO_SPACE) && defined(__MIPSEB__) */ + +#define ide_fix_driveid(id) do {} while (0) + +#endif /* * The following are not needed for the non-m68k ports */ #define ide_ack_intr(hwif) (1) -#define ide_fix_driveid(id) do {} while (0) #define ide_release_lock(lock) do {} while (0) #define ide_get_lock(lock, hdlr, data) do {} while (0) Index: include/asm-mips64/io.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/io.h,v retrieving revision 1.25.2.5 diff -u -r1.25.2.5 io.h --- include/asm-mips64/io.h 2002/02/07 02:39:41 1.25.2.5 +++ include/asm-mips64/io.h 2002/06/07 12:26:15 @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef CONFIG_MIPS_ATLAS #include @@ -98,23 +99,23 @@ /* * This assumes sane hardware. The Origin is. */ -#define readb(addr) (*(volatile unsigned char *) (addr)) -#define readw(addr) (*(volatile unsigned short *) (addr)) -#define readl(addr) (*(volatile unsigned int *) (addr)) +#define readb(addr) (*(volatile unsigned char *)(addr)) +#define readw(addr) __ioswab16((*(volatile unsigned short *)(addr))) +#define readl(addr) __ioswab32((*(volatile unsigned int *)(addr))) #define __raw_readb(addr) (*(volatile unsigned char *)(addr)) #define __raw_readw(addr) (*(volatile unsigned short *)(addr)) #define __raw_readl(addr) (*(volatile unsigned int *)(addr)) -#define writeb(b,addr) (*(volatile unsigned char *) (addr) = (b)) -#define writew(w,addr) (*(volatile unsigned short *) (addr) = (w)) -#define writel(l,addr) (*(volatile unsigned int *) (addr) = (l)) +#define writeb(b,addr) ((*(volatile unsigned char *)(addr)) = (__ioswab8(b))) +#define writew(b,addr) ((*(volatile unsigned short *)(addr)) = (__ioswab16(b))) +#define writel(b,addr) ((*(volatile unsigned int *)(addr)) = (__ioswab32(b))) #define __raw_writeb(b,addr) ((*(volatile unsigned char *)(addr)) = (b)) #define __raw_writew(w,addr) ((*(volatile unsigned short *)(addr)) = (w)) #define __raw_writel(l,addr) ((*(volatile unsigned int *)(addr)) = (l)) -#define memset_io(a,b,c) memset((void *) a,(b),(c)) +#define memset_io(a,b,c) memset((void *)(a),(b),(c)) #define memcpy_fromio(a,b,c) memcpy((a),(void *)(b),(c)) #define memcpy_toio(a,b,c) memcpy((void *)(a),(b),(c)) @@ -154,12 +155,12 @@ */ static inline unsigned long virt_to_phys(volatile void * address) { - return (unsigned long)address - PAGE_OFFSET; + return (unsigned long)address & ~PAGE_OFFSET; } static inline void * phys_to_virt(unsigned long address) { - return (void *)(address + PAGE_OFFSET); + return (void *)(address | PAGE_OFFSET); } /* @@ -167,12 +168,12 @@ */ static inline unsigned long virt_to_bus(volatile void * address) { - return (unsigned long)address - PAGE_OFFSET; + return (unsigned long)address & ~PAGE_OFFSET; } static inline void * bus_to_virt(unsigned long address) { - return (void *)(address + PAGE_OFFSET); + return (void *)(address | PAGE_OFFSET); } @@ -229,202 +230,131 @@ return retval; } -/* - * Talk about misusing macros.. - */ -#define __OUT1(s) \ -static inline void __out##s(unsigned int value, unsigned long port) { +#define outb(val,port) \ +do { \ + *(volatile u8 *)(mips_io_port_base + (port)) = __ioswab8(val); \ +} while(0) + +#define outw(val,port) \ +do { \ + *(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\ +} while(0) + +#define outl(val,port) \ +do { \ + *(volatile u32 *)(mips_io_port_base + (port)) = __ioswab32(val);\ +} while(0) + +#define outb_p(val,port) \ +do { \ + *(volatile u8 *)(mips_io_port_base + (port)) = __ioswab8(val); \ + SLOW_DOWN_IO; \ +} while(0) + +#define outw_p(val,port) \ +do { \ + *(volatile u16 *)(mips_io_port_base + (port)) = __ioswab16(val);\ + SLOW_DOWN_IO; \ +} while(0) + +#define outl_p(val,port) \ +do { \ + *(volatile u32 *)(mips_io_port_base + (port)) = __ioswab32(val);\ + SLOW_DOWN_IO; \ +} while(0) -#define __OUT2(m) \ -__asm__ __volatile__ ("s" #m "\t%0,%1(%2)" +static inline unsigned char inb(unsigned long port) +{ + return __ioswab8(*(volatile u8 *)(mips_io_port_base + port)); +} -#define __OUT(m,s) \ -__OUT1(s) __OUT2(m) : : "r" (value), "i" (0), "r" (mips_io_port_base+port)); } \ -__OUT1(s##c) __OUT2(m) : : "r" (value), "ir" (port), "r" (mips_io_port_base)); } \ -__OUT1(s##_p) __OUT2(m) : : "r" (value), "i" (0), "r" (mips_io_port_base+port)); \ - SLOW_DOWN_IO; } \ -__OUT1(s##c_p) __OUT2(m) : : "r" (value), "ir" (port), "r" (mips_io_port_base)); \ - SLOW_DOWN_IO; } - -#define __IN1(t,s) \ -static inline t __in##s(unsigned long port) { t _v; - -/* - * Required nops will be inserted by the assembler - */ -#define __IN2(m) \ -__asm__ __volatile__ ("l" #m "\t%0,%1(%2)" - -#define __IN(t,m,s) \ -__IN1(t,s) __IN2(m) : "=r" (_v) : "i" (0), "r" (mips_io_port_base+port)); return _v; } \ -__IN1(t,s##c) __IN2(m) : "=r" (_v) : "ir" (port), "r" (mips_io_port_base)); return _v; } \ -__IN1(t,s##_p) __IN2(m) : "=r" (_v) : "i" (0), "r" (mips_io_port_base+port)); SLOW_DOWN_IO; return _v; } \ -__IN1(t,s##c_p) __IN2(m) : "=r" (_v) : "ir" (port), "r" (mips_io_port_base)); SLOW_DOWN_IO; return _v; } - -#define __INS1(s) \ -static inline void __ins##s(unsigned long port, void * addr, unsigned long count) { - -#define __INS2(m) \ -if (count) \ -__asm__ __volatile__ ( \ - ".set\tnoreorder\n\t" \ - ".set\tnoat\n" \ - "1:\tl" #m "\t$1, %4(%5)\n\t" \ - "dsubu\t%1, 1\n\t" \ - "s" #m "\t$1,(%0)\n\t" \ - "bnez\t%1, 1b\n\t" \ - "daddiu\t%0, %6\n\t" \ - ".set\tat\n\t" \ - ".set\treorder" - -#define __INS(m,s,i) \ -__INS1(s) __INS2(m) \ - : "=r" (addr), "=r" (count) \ - : "0" (addr), "1" (count), "i" (0), "r" (mips_io_port_base+port), \ - "I" (i));} \ -__INS1(s##c) __INS2(m) \ - : "=r" (addr), "=r" (count) \ - : "0" (addr), "1" (count), "ir" (port), "r" (mips_io_port_base), \ - "I" (i));} - -#define __OUTS1(s) \ -static inline void __outs##s(unsigned long port, const void * addr, unsigned long count) { - -#define __OUTS2(m) \ -if (count) \ -__asm__ __volatile__ ( \ - ".set\tnoreorder\n\t" \ - ".set\tnoat\n" \ - "1:\tl" #m "\t$1, (%0)\n\t" \ - "dsubu\t%1, 1\n\t" \ - "s" #m "\t$1, %4(%5)\n\t" \ - "bnez\t%1, 1b\n\t" \ - "daddiu\t%0, %6\n\t" \ - ".set\tat\n\t" \ - ".set\treorder" - -#define __OUTS(m,s,i) \ -__OUTS1(s) __OUTS2(m) \ - : "=r" (addr), "=r" (count) \ - : "0" (addr), "1" (count), "i" (0), "r" (mips_io_port_base+port), \ - "I" (i));} \ -__OUTS1(s##c) __OUTS2(m) \ - : "=r" (addr), "=r" (count) \ - : "0" (addr), "1" (count), "ir" (port), "r" (mips_io_port_base), \ - "I" (i));} - -__IN(unsigned char,b,b) -__IN(unsigned short,h,w) -__IN(unsigned int,w,l) - -__OUT(b,b) -__OUT(h,w) -__OUT(w,l) - -__INS(b,b,1) -__INS(h,w,2) -__INS(w,l,4) - -__OUTS(b,b,1) -__OUTS(h,w,2) -__OUTS(w,l,4) - -/* - * Note that due to the way __builtin_constant_p() works, you - * - can't use it inside an inline function (it will never be true) - * - you don't have to worry about side effects within the __builtin.. - */ -#define outb(val,port) \ -((__builtin_constant_p((port)^(3)) && ((port)^(3)) < 32768) ? \ - __outbc((val),(port)^(3)) : \ - __outb((val),(port)^(3))) - -#define inb(port) \ -((__builtin_constant_p((port)^(3)) && ((port)^(3)) < 32768) ? \ - __inbc((port)^(3)) : \ - __inb((port)^(3))) - -#define outb_p(val,port) \ -((__builtin_constant_p((port)^(3)) && ((port)^(3)) < 32768) ? \ - __outbc_p((val),(port)^(3)) : \ - __outb_p((val),(port)^(3))) - -#define inb_p(port) \ -((__builtin_constant_p((port)^(3)) && ((port)^(3)) < 32768) ? \ - __inbc_p((port)^(3)) : \ - __inb_p((port)^(3))) - -#define outw(val,port) \ -((__builtin_constant_p(((port)^(2))) && ((port)^(2)) < 32768) ? \ - __outwc((val),((port)^(2))) : \ - __outw((val),((port)^(2)))) - -#define inw(port) \ -((__builtin_constant_p(((port)^(2))) && ((port)^(2)) < 32768) ? \ - __inwc((port)^(2)) : \ - __inw((port)^(2))) - -#define outw_p(val,port) \ -((__builtin_constant_p((port)^(2)) && ((port)^(2)) < 32768) ? \ - __outwc_p((val),(port)^(2)) : \ - __outw_p((val),(port)^(2))) - -#define inw_p(port) \ -((__builtin_constant_p((port)^(2)) && ((port)^(2)) < 32768) ? \ - __inwc_p((port)^(2)) : \ - __inw_p((port)^(2))) - -#define outl(val,port) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __outlc((val),(port)) : \ - __outl((val),(port))) - -#define inl(port) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __inlc(port) : \ - __inl(port)) - -#define outl_p(val,port) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __outlc_p((val),(port)) : \ - __outl_p((val),(port))) - -#define inl_p(port) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __inlc_p(port) : \ - __inl_p(port)) - - -#define outsb(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __outsbc((port),(addr),(count)) : \ - __outsb ((port),(addr),(count))) - -#define insb(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __insbc((port),(addr),(count)) : \ - __insb((port),(addr),(count))) - -#define outsw(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __outswc((port),(addr),(count)) : \ - __outsw ((port),(addr),(count))) - -#define insw(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __inswc((port),(addr),(count)) : \ - __insw((port),(addr),(count))) - -#define outsl(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __outslc((port),(addr),(count)) : \ - __outsl ((port),(addr),(count))) - -#define insl(port,addr,count) \ -((__builtin_constant_p((port)) && (port) < 32768) ? \ - __inslc((port),(addr),(count)) : \ - __insl((port),(addr),(count))) +static inline unsigned short inw(unsigned long port) +{ + return __ioswab16(*(volatile u16 *)(mips_io_port_base + port)); +} + +static inline unsigned int inl(unsigned long port) +{ + return __ioswab32(*(volatile u32 *)(mips_io_port_base + port)); +} + +static inline unsigned char inb_p(unsigned long port) +{ + u8 __val; + + __val = *(volatile u8 *)(mips_io_port_base + port); + SLOW_DOWN_IO; + + return __ioswab8(__val); +} + +static inline unsigned short inw_p(unsigned long port) +{ + u16 __val; + + __val = *(volatile u16 *)(mips_io_port_base + port); + SLOW_DOWN_IO; + + return __ioswab16(__val); +} + +static inline unsigned int inl_p(unsigned long port) +{ + u32 __val; + + __val = *(volatile u32 *)(mips_io_port_base + port); + SLOW_DOWN_IO; + return __ioswab32(__val); +} + +static inline void outsb(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + outb(*(u8 *)addr, port); + addr++; + } +} + +static inline void insb(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u8 *)addr = inb(port); + addr++; + } +} + +static inline void outsw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + outw(*(u16 *)addr, port); + addr += 2; + } +} + +static inline void insw(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u16 *)addr = inw(port); + addr += 2; + } +} + +static inline void outsl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + outl(*(u32 *)addr, port); + addr += 4; + } +} + +static inline void insl(unsigned long port, void *addr, unsigned int count) +{ + while (count--) { + *(u32 *)addr = inl(port); + addr += 4; + } +} /* * The caches on some architectures aren't dma-coherent and have need to Index: include/asm-mips64/irq.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/irq.h,v retrieving revision 1.4 diff -u -r1.4 irq.h --- include/asm-mips64/irq.h 2001/03/02 03:04:55 1.4 +++ include/asm-mips64/irq.h 2002/06/07 12:26:15 @@ -48,6 +48,12 @@ extern void disable_irq(unsigned int); extern void enable_irq(unsigned int); +#ifndef CONFIG_NEW_IRQ +#define disable_irq_nosync disable_irq +#else +extern void disable_irq_nosync(unsigned int); +#endif + /* Machine specific interrupt initialization */ extern void (*irq_setup)(void); Index: include/asm-mips64/page.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/page.h,v retrieving revision 1.10.2.6 diff -u -r1.10.2.6 page.h --- include/asm-mips64/page.h 2002/01/24 23:14:28 1.10.2.6 +++ include/asm-mips64/page.h 2002/06/07 12:26:15 @@ -29,6 +29,10 @@ */ void sb1_clear_page(void * page); void sb1_copy_page(void * to, void * from); +void mips64_clear_page_dc(unsigned long page); +void mips64_clear_page_sc(unsigned long page); +void mips64_copy_page_dc(unsigned long to, unsigned long from); +void mips64_copy_page_sc(unsigned long to, unsigned long from); extern void (*_clear_page)(void * page); extern void (*_copy_page)(void * to, void * from); @@ -94,8 +98,8 @@ #define PAGE_OFFSET 0xa800000000000000UL #endif -#define __pa(x) ((unsigned long) (x) - PAGE_OFFSET) -#define __va(x) ((void *)((unsigned long) (x) + PAGE_OFFSET)) +#define __pa(x) ((unsigned long) (x) & ~PAGE_OFFSET) +#define __va(x) ((void *)((unsigned long) (x) | PAGE_OFFSET)) #ifndef CONFIG_DISCONTIGMEM #define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT)) #define VALID_PAGE(page) ((page - mem_map) < max_mapnr) Index: include/asm-mips64/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pci.h,v retrieving revision 1.16.2.2 diff -u -r1.16.2.2 pci.h --- include/asm-mips64/pci.h 2002/02/26 06:00:25 1.16.2.2 +++ include/asm-mips64/pci.h 2002/06/07 12:26:15 @@ -173,7 +173,7 @@ dma_cache_wback_inv(addr, size); #endif - return virt_to_bus(addr); + return virt_to_bus((void *)addr); } static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address, @@ -213,7 +213,7 @@ #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long)sg->address, sg->length); #endif - sg->dma_address = (char *)(__pa(sg->address)); +/* sg->dma_address = (char *)(__pa(sg->address));*/ } return nents; @@ -250,7 +250,7 @@ if (direction == PCI_DMA_NONE) BUG(); #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)__va(dma_handle - bus_to_baddr[hwdev->bus->number]), size); + dma_cache_wback_inv((unsigned long)bus_to_virt(dma_handle), size); #endif } @@ -287,7 +287,7 @@ * so we can't guarantee allocations that must be * within a tighter range than GFP_DMA.. */ - if (mask < 0x00ffffff) + if (mask < 0x1fffffff) return 0; return 1; @@ -339,7 +339,7 @@ * returns, or alternatively stop on the first sg_dma_len(sg) which * is 0. */ -#define sg_dma_address(sg) ((unsigned long)((sg)->address)) +#define sg_dma_address(sg) (virt_to_bus((sg)->address)) #define sg_dma_len(sg) ((sg)->length) #endif /* __KERNEL__ */ Index: include/asm-mips64/pgtable.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pgtable.h,v retrieving revision 1.47.2.10 diff -u -r1.47.2.10 pgtable.h --- include/asm-mips64/pgtable.h 2002/05/28 09:49:45 1.47.2.10 +++ include/asm-mips64/pgtable.h 2002/06/07 12:26:15 @@ -74,23 +74,13 @@ #else -extern void (*_flush_icache_all)(void); -extern void (*_flush_icache_range)(unsigned long start, unsigned long end); -extern void (*_flush_icache_page)(struct vm_area_struct *vma, struct page *page); - #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_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) -#ifdef CONFIG_VTAG_ICACHE -#define flush_icache_all() _flush_icache_all() -#else -#define flush_icache_all() do { } while(0) -#endif - #endif /* !CONFIG_CPU_R10000 */ #define flush_cache_sigtramp(addr) _flush_cache_sigtramp(addr) @@ -198,11 +188,11 @@ #ifdef CONFIG_MIPS_UNCACHED #define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED #else /* ! UNCACHED */ -#ifdef CONFIG_SGI_IP22 -#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT -#else /* ! IP22 */ +#if defined(CONFIG_SGI_IP27) || defined(CONFIG_SGI_IP32) #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW -#endif /* IP22 */ +#else +#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT +#endif #endif /* UNCACHED */ #define PAGE_NONE __pgprot(_PAGE_PRESENT | PAGE_CACHABLE_DEFAULT) @@ -569,6 +559,8 @@ #ifndef CONFIG_DISCONTIGMEM #define kern_addr_valid(addr) (1) #endif + +#define io_remap_page_range remap_page_range /* * No page table caches to initialise Index: include/asm-mips64/serial.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/serial.h,v retrieving revision 1.7.2.3 diff -u -r1.7.2.3 serial.h --- include/asm-mips64/serial.h 2002/05/29 03:03:18 1.7.2.3 +++ include/asm-mips64/serial.h 2002/06/07 12:26:15 @@ -65,7 +65,6 @@ /* * The IP32 (SGI O2) has standard serial ports (UART 16550A) mapped in memory */ - /* Standard COM flags (except for COM4, because of the 8514 problem) */ #ifdef CONFIG_SERIAL_DETECT_IRQ #define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ) @@ -88,13 +87,37 @@ iomem_base: (u8*)MACE_BASE+MACEISA_SER2_BASE, \ iomem_reg_shift: 8, \ io_type: SERIAL_IO_MEM}, + #else #define IP32_SERIAL_PORT_DEFNS #endif /* CONFIG_SGI_IP31 */ +#ifdef CONFIG_HAVE_STD_PC_SERIAL_PORT + +/* Standard COM flags (except for COM4, because of the 8514 problem) */ +#ifdef CONFIG_SERIAL_DETECT_IRQ +#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ) +#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ) +#else +#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST) +#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF +#endif + +#define STD_SERIAL_PORT_DEFNS \ + /* UART CLK PORT IRQ FLAGS */ \ + { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, /* ttyS0 */ \ + { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS }, /* ttyS1 */ \ + { 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS }, /* ttyS2 */ \ + { 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS }, /* ttyS3 */ + +#else /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */ +#define STD_SERIAL_PORT_DEFNS +#endif /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */ + #define SERIAL_PORT_DFNS \ IP27_SERIAL_PORT_DEFNS \ - IP32_SERIAL_PORT_DEFNS + IP32_SERIAL_PORT_DEFNS \ + STD_SERIAL_PORT_DEFNS #define RS_TABLE_SIZE 64 Index: include/asm-mips64/system.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/system.h,v retrieving revision 1.18.2.7 diff -u -r1.18.2.7 system.h --- include/asm-mips64/system.h 2002/05/28 05:53:06 1.18.2.7 +++ include/asm-mips64/system.h 2002/06/07 12:26:15 @@ -202,9 +202,9 @@ extern asmlinkage void lazy_fpu_switch(void *, void *); extern asmlinkage void init_fpu(void); -extern asmlinkage void save_fp(struct task_struct *); -extern asmlinkage void restore_fp(struct task_struct *); +extern asmlinkage void save_fp(void *); +extern asmlinkage void restore_fp(void *); #ifdef CONFIG_SMP #define SWITCH_DO_LAZY_FPU \ --------------6A228B530B40164C0D9211A7 Content-Type: text/plain; charset=iso-8859-15; name="c-mips64.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="c-mips64.c" /* * Carsten Langgaard, carstenl@mips.com * Copyright (C) 2002 MIPS Technologies, Inc. All rights reserved. * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. * * MIPS64 CPU variant specific Cache routines. * These routine are not optimized in any way, they are done in a generic way * so they can be used on all MIPS64 compliant CPUs, and also done in an * attempt not to break anything for the R4xx0 style CPUs. */ #include #include #include #include #include #include #include #include #include #include #include #include /* CP0 hazard avoidance. */ #define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ "nop; nop; nop; nop; nop; nop;\n\t" \ ".set reorder\n\t") /* Primary cache parameters. */ int icache_size, dcache_size; /* Size in bytes */ int ic_lsize, dc_lsize; /* LineSize in bytes */ /* Secondary cache (if present) parameters. */ unsigned int scache_size, sc_lsize; /* Again, in bytes */ #include #include #undef DEBUG_CACHE /* * Dummy cache handling routines for machines without boardcaches */ static void no_sc_noop(void) {} static struct bcache_ops no_sc_ops = { (void *)no_sc_noop, (void *)no_sc_noop, (void *)no_sc_noop, (void *)no_sc_noop }; struct bcache_ops *bcops = &no_sc_ops; static inline void mips64_flush_cache_all_sc(void) { unsigned long flags; __save_and_cli(flags); blast_dcache(); blast_icache(); blast_scache(); __restore_flags(flags); } static inline void mips64_flush_cache_all_pc(void) { unsigned long flags; __save_and_cli(flags); blast_dcache(); blast_icache(); __restore_flags(flags); } static void mips64_flush_cache_range_sc(struct mm_struct *mm, unsigned long start, unsigned long end) { struct vm_area_struct *vma; unsigned long flags; if(mm->context == 0) return; start &= PAGE_MASK; #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif vma = find_vma(mm, start); if(vma) { if(mm->context != current->mm->context) { mips64_flush_cache_all_sc(); } else { pgd_t *pgd; pmd_t *pmd; pte_t *pte; __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); pte = pte_offset(pmd, start); if(pte_val(*pte) & _PAGE_VALID) blast_scache_page(start); start += PAGE_SIZE; } __restore_flags(flags); } } } static void mips64_flush_cache_range_pc(struct mm_struct *mm, unsigned long start, unsigned long end) { if(mm->context != 0) { unsigned long flags; #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif __save_and_cli(flags); blast_dcache(); blast_icache(); __restore_flags(flags); } } /* * On architectures like the Sparc, we could get rid of lines in * the cache created only by a certain context, but on the MIPS * (and actually certain Sparc's) we cannot. */ static void mips64_flush_cache_mm_sc(struct mm_struct *mm) { if(mm->context != 0) { #ifdef DEBUG_CACHE printk("cmm[%d]", (int)mm->context); #endif mips64_flush_cache_all_sc(); } } static void mips64_flush_cache_mm_pc(struct mm_struct *mm) { if(mm->context != 0) { #ifdef DEBUG_CACHE printk("cmm[%d]", (int)mm->context); #endif mips64_flush_cache_all_pc(); } } static void mips64_flush_cache_page_sc(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm = vma->vm_mm; unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; /* * If ownes no valid ASID yet, cannot possibly have gotten * this page into the cache. */ if (mm->context == 0) return; #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif __save_and_cli(flags); page &= PAGE_MASK; pgdp = pgd_offset(mm, page); pmdp = pmd_offset(pgdp, page); ptep = pte_offset(pmdp, page); /* * If the page isn't marked valid, the page cannot possibly be * in the cache. */ if (!(pte_val(*ptep) & _PAGE_VALID)) goto out; /* * Doing flushes for another ASID than the current one is * too difficult since R4k caches do a TLB translation * for every cache flush operation. So we do indexed flushes * in that case, which doesn't overly flush the cache too much. */ if (mm->context != current->active_mm->context) { /* * Do indexed flush, too much work to get the (possible) * tlb refills to work correctly. */ page = (KSEG0 + (page & (scache_size - 1))); blast_dcache_page_indexed(page); blast_scache_page_indexed(page); } else blast_scache_page(page); out: __restore_flags(flags); } static void mips64_flush_cache_page_pc(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm = vma->vm_mm; unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; /* * If ownes no valid ASID yet, cannot possibly have gotten * this page into the cache. */ if (mm->context == 0) return; #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif __save_and_cli(flags); page &= PAGE_MASK; pgdp = pgd_offset(mm, page); pmdp = pmd_offset(pgdp, page); ptep = pte_offset(pmdp, page); /* * If the page isn't marked valid, the page cannot possibly be * in the cache. */ if (!(pte_val(*ptep) & _PAGE_VALID)) goto out; /* * Doing flushes for another ASID than the current one is * too difficult since Mips64 caches do a TLB translation * for every cache flush operation. So we do indexed flushes * in that case, which doesn't overly flush the cache too much. */ if (mm == current->active_mm) { blast_dcache_page(page); } else { /* Do indexed flush, too much work to get the (possible) * tlb refills to work correctly. */ page = (KSEG0 + (page & ((unsigned long)dcache_size - 1))); blast_dcache_page_indexed(page); } out: __restore_flags(flags); } /* If the addresses passed to these routines are valid, they are * either: * * 1) In KSEG0, so we can do a direct flush of the page. * 2) In KSEG2, and since every process can translate those * addresses all the time in kernel mode we can do a direct * flush. * 3) In KSEG1, no flush necessary. */ static void mips64_flush_page_to_ram_sc(struct page *page) { blast_scache_page((unsigned long)page_address(page)); } static void mips64_flush_page_to_ram_pc(struct page *page) { blast_dcache_page((unsigned long)page_address(page)); } static void mips64_flush_icache_page_s(struct vm_area_struct *vma, struct page *page) { /* * We did an scache flush therefore PI is already clean. */ } static void mips64_flush_icache_range(unsigned long start, unsigned long end) { flush_cache_all(); } static void mips64_flush_icache_page(struct vm_area_struct *vma, struct page *page) { unsigned long address; if (!(vma->vm_flags & VM_EXEC)) return; address = KSEG0 + ((unsigned long)page_address(page) & PAGE_MASK & ((unsigned long)dcache_size - 1)); blast_icache_page_indexed(address); } /* * Writeback and invalidate the primary cache dcache before DMA. */ static void mips64_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size) { unsigned long end, a; unsigned int flags; if (size >= (unsigned long)dcache_size) { flush_cache_all(); } else { __save_and_cli(flags); a = addr & ~(dc_lsize - 1); end = (addr + size) & ~((unsigned long)dc_lsize - 1); while (1) { flush_dcache_line(a); /* Hit_Writeback_Inv_D */ if (a == end) break; a += dc_lsize; } __restore_flags(flags); } bc_wback_inv(addr, size); } static void mips64_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size) { unsigned long end, a; if (size >= scache_size) { flush_cache_all(); return; } a = addr & ~(sc_lsize - 1); end = (addr + size) & ~(sc_lsize - 1); while (1) { flush_scache_line(a); /* Hit_Writeback_Inv_SD */ if (a == end) break; a += sc_lsize; } } static void mips64_dma_cache_inv_pc(unsigned long addr, unsigned long size) { unsigned long end, a; unsigned int flags; if (size >= (unsigned long)dcache_size) { flush_cache_all(); } else { __save_and_cli(flags); a = addr & ~((unsigned long)dc_lsize - 1); end = (addr + size) & ~((unsigned long)dc_lsize - 1); while (1) { flush_dcache_line(a); /* Hit_Writeback_Inv_D */ if (a == end) break; a += (unsigned long)dc_lsize; } __restore_flags(flags); } bc_inv(addr, size); } static void mips64_dma_cache_inv_sc(unsigned long addr, unsigned long size) { unsigned long end, a; if (size >= scache_size) { flush_cache_all(); return; } a = addr & ~(sc_lsize - 1); end = (addr + size) & ~(sc_lsize - 1); while (1) { flush_scache_line(a); /* Hit_Writeback_Inv_SD */ if (a == end) break; a += sc_lsize; } } static void mips64_dma_cache_wback(unsigned long addr, unsigned long size) { panic("mips64_dma_cache called - should not happen.\n"); } /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation * fault will dump the process later on anyway ... */ static void mips64_flush_cache_sigtramp(unsigned long addr) { protected_writeback_dcache_line(addr & ~(dc_lsize - 1)); protected_flush_icache_line(addr & ~(ic_lsize - 1)); } static void mips64_flush_icache_all(void) { if (mips_cpu.cputype == CPU_20KC) { blast_icache(); } } /* Detect and size the various caches. */ static void __init probe_icache(unsigned long config) { unsigned long config1; unsigned int lsize; if (!(config & (1 << 31))) { /* * Not a MIPS64 complainant CPU. * Config 1 register not supported, we assume R4k style. */ icache_size = 1 << (12 + ((config >> 9) & 7)); ic_lsize = 16 << ((config >> 5) & 1); mips_cpu.icache.linesz = ic_lsize; /* * We cannot infer associativity - assume direct map * unless probe template indicates otherwise */ if(!mips_cpu.icache.ways) mips_cpu.icache.ways = 1; mips_cpu.icache.sets = (icache_size / ic_lsize) / mips_cpu.icache.ways; } else { config1 = read_mips32_cp0_config1(); if ((lsize = ((config1 >> 19) & 7))) mips_cpu.icache.linesz = 2 << lsize; else mips_cpu.icache.linesz = lsize; mips_cpu.icache.sets = 64 << ((config1 >> 22) & 7); mips_cpu.icache.ways = 1 + ((config1 >> 16) & 7); ic_lsize = mips_cpu.icache.linesz; icache_size = mips_cpu.icache.sets * mips_cpu.icache.ways * ic_lsize; } printk("Primary instruction cache %dkb, linesize %d bytes (%d ways)\n", icache_size >> 10, ic_lsize, mips_cpu.icache.ways); } static void __init probe_dcache(unsigned long config) { unsigned long config1; unsigned int lsize; if (!(config & (1 << 31))) { /* * Not a MIPS64 complainant CPU. * Config 1 register not supported, we assume R4k style. */ dcache_size = 1 << (12 + ((config >> 6) & 7)); dc_lsize = 16 << ((config >> 4) & 1); mips_cpu.dcache.linesz = dc_lsize; /* * We cannot infer associativity - assume direct map * unless probe template indicates otherwise */ if(!mips_cpu.dcache.ways) mips_cpu.dcache.ways = 1; mips_cpu.dcache.sets = (dcache_size / dc_lsize) / mips_cpu.dcache.ways; } else { config1 = read_mips32_cp0_config1(); if ((lsize = ((config1 >> 10) & 7))) mips_cpu.dcache.linesz = 2 << lsize; else mips_cpu.dcache.linesz= lsize; mips_cpu.dcache.sets = 64 << ((config1 >> 13) & 7); mips_cpu.dcache.ways = 1 + ((config1 >> 7) & 7); dc_lsize = mips_cpu.dcache.linesz; dcache_size = mips_cpu.dcache.sets * mips_cpu.dcache.ways * dc_lsize; } printk("Primary data cache %dkb, linesize %d bytes (%d ways)\n", dcache_size >> 10, dc_lsize, mips_cpu.dcache.ways); } /* If you even _breathe_ on this function, look at the gcc output * and make sure it does not pop things on and off the stack for * the cache sizing loop that executes in KSEG1 space or else * you will crash and burn badly. You have been warned. */ static int __init probe_scache(unsigned long config) { extern unsigned long stext; unsigned long flags, addr, begin, end, pow2; int tmp; if (mips_cpu.scache.flags == MIPS_CACHE_NOT_PRESENT) return 0; tmp = ((config >> 17) & 1); if(tmp) return 0; tmp = ((config >> 22) & 3); switch(tmp) { case 0: sc_lsize = 16; break; case 1: sc_lsize = 32; break; case 2: sc_lsize = 64; break; case 3: sc_lsize = 128; break; } begin = (unsigned long) &stext; begin &= ~((4 * 1024 * 1024) - 1); end = begin + (4 * 1024 * 1024); /* This is such a bitch, you'd think they would make it * easy to do this. Away you daemons of stupidity! */ __save_and_cli(flags); /* Fill each size-multiple cache line with a valid tag. */ pow2 = (64 * 1024); for(addr = begin; addr < end; addr = (begin + pow2)) { unsigned long *p = (unsigned long *) addr; __asm__ __volatile__("nop" : : "r" (*p)); /* whee... */ pow2 <<= 1; } /* Load first line with zero (therefore invalid) tag. */ set_taglo(0); set_taghi(0); __asm__ __volatile__("nop; nop; nop; nop;"); /* avoid the hazard */ __asm__ __volatile__("\n\t.set noreorder\n\t" "cache 8, (%0)\n\t" ".set reorder\n\t" : : "r" (begin)); __asm__ __volatile__("\n\t.set noreorder\n\t" "cache 9, (%0)\n\t" ".set reorder\n\t" : : "r" (begin)); __asm__ __volatile__("\n\t.set noreorder\n\t" "cache 11, (%0)\n\t" ".set reorder\n\t" : : "r" (begin)); /* Now search for the wrap around point. */ pow2 = (128 * 1024); tmp = 0; for(addr = (begin + (128 * 1024)); addr < (end); addr = (begin + pow2)) { __asm__ __volatile__("\n\t.set noreorder\n\t" "cache 7, (%0)\n\t" ".set reorder\n\t" : : "r" (addr)); __asm__ __volatile__("nop; nop; nop; nop;"); /* hazard... */ if(!get_taglo()) break; pow2 <<= 1; } __restore_flags(flags); addr -= begin; printk("Secondary cache sized at %dK linesize %d bytes.\n", (int) (addr >> 10), sc_lsize); scache_size = addr; return 1; } static void __init setup_noscache_funcs(void) { _clear_page = (void *)mips64_clear_page_dc; _copy_page = (void *)mips64_copy_page_dc; _flush_cache_all = mips64_flush_cache_all_pc; ___flush_cache_all = mips64_flush_cache_all_pc; _flush_cache_mm = mips64_flush_cache_mm_pc; _flush_cache_range = mips64_flush_cache_range_pc; _flush_cache_page = mips64_flush_cache_page_pc; _flush_page_to_ram = mips64_flush_page_to_ram_pc; _flush_icache_page = mips64_flush_icache_page; _dma_cache_wback_inv = mips64_dma_cache_wback_inv_pc; _dma_cache_wback = mips64_dma_cache_wback; _dma_cache_inv = mips64_dma_cache_inv_pc; } static void __init setup_scache_funcs(void) { _flush_cache_all = mips64_flush_cache_all_sc; ___flush_cache_all = mips64_flush_cache_all_sc; _flush_cache_mm = mips64_flush_cache_mm_sc; _flush_cache_range = mips64_flush_cache_range_sc; _flush_cache_page = mips64_flush_cache_page_sc; _flush_page_to_ram = mips64_flush_page_to_ram_sc; _clear_page = (void *)mips64_clear_page_sc; _copy_page = (void *)mips64_copy_page_sc; _flush_icache_page = mips64_flush_icache_page_s; _dma_cache_wback_inv = mips64_dma_cache_wback_inv_sc; _dma_cache_wback = mips64_dma_cache_wback; _dma_cache_inv = mips64_dma_cache_inv_sc; } typedef int (*probe_func_t)(unsigned long); static inline void __init setup_scache(unsigned int config) { probe_func_t probe_scache_kseg1; int sc_present = 0; /* Maybe the cpu knows about a l2 cache? */ probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache)); sc_present = probe_scache_kseg1(config); if (sc_present) { mips_cpu.scache.linesz = sc_lsize; /* * We cannot infer associativity - assume direct map * unless probe template indicates otherwise */ if(!mips_cpu.scache.ways) mips_cpu.scache.ways = 1; mips_cpu.scache.sets = (scache_size / sc_lsize) / mips_cpu.scache.ways; setup_scache_funcs(); return; } setup_noscache_funcs(); } void __init ld_mmu_mips64(void) { unsigned long config = read_32bit_cp0_register(CP0_CONFIG); #ifdef CONFIG_MIPS_UNCACHED change_cp0_config(CONF_CM_CMASK, CONF_CM_UNCACHED); #else change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); #endif probe_icache(config); probe_dcache(config); setup_scache(config); _flush_cache_sigtramp = mips64_flush_cache_sigtramp; _flush_icache_range = mips64_flush_icache_range; /* Ouch */ _flush_icache_all = mips64_flush_icache_all; _flush_cache_l1 = _flush_cache_all; _flush_cache_l2 = _flush_cache_all; __flush_cache_all(); } --------------6A228B530B40164C0D9211A7 Content-Type: text/plain; charset=iso-8859-15; name="pg-mips64.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pg-mips64.c" /* * Carsten Langgaard, carstenl@mips.com * Copyright (C) 2002 MIPS Technologies, Inc. All rights reserved. * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. * * MIPS64 CPU variant specific Cache routines. * These routine are not optimized in any way, they are done in a generic way * so they can be used on all MIPS64 compliant CPUs, and also done in an * attempt not to break anything for the R4xx0 style CPUs. */ #include #include #include #include #include extern int dc_lsize, ic_lsize, sc_lsize; /* * Zero an entire page. */ void mips64_clear_page_dc(unsigned long page) { unsigned long i; if (mips_cpu.options & MIPS_CPU_CACHE_CDEX) { for (i=page; i #include #include #include #include #include #include #include #undef DEBUG_TLB #undef DEBUG_TLBUPDATE /*extern char except_vec1_r4k;*/ /* CP0 hazard avoidance. */ #define BARRIER __asm__ __volatile__(".set noreorder\n\t" \ "nop; nop; nop; nop; nop; nop;\n\t" \ ".set reorder\n\t") void local_flush_tlb_all(void) { unsigned long flags; unsigned long old_ctx; int entry; #ifdef DEBUG_TLB printk("[tlball]"); #endif __save_and_cli(flags); /* Save old context and create impossible VPN2 value */ old_ctx = (get_entryhi() & 0xff); set_entryhi(KSEG0); set_entrylo0(0); set_entrylo1(0); BARRIER; entry = get_wired(); /* Blast 'em all away. */ while(entry < mips_cpu.tlbsize) { /* Make sure all entries differ. */ set_entryhi(KSEG0+entry*0x2000); set_index(entry); BARRIER; tlb_write_indexed(); BARRIER; entry++; } BARRIER; set_entryhi(old_ctx); __restore_flags(flags); } void local_flush_tlb_mm(struct mm_struct *mm) { if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { unsigned long flags; #ifdef DEBUG_TLB printk("[tlbmm<%d>]", mm->context); #endif __save_and_cli(flags); get_new_mmu_context(mm, smp_processor_id()); if (mm == current->active_mm) set_entryhi(CPU_CONTEXT(smp_processor_id(), mm) & 0xff); __restore_flags(flags); } } void local_flush_tlb_range(struct mm_struct *mm, unsigned long start, unsigned long end) { if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { unsigned long flags; int size; #ifdef DEBUG_TLB printk("[tlbrange<%02x,%08lx,%08lx>]", (mm->context & 0xff), start, end); #endif __save_and_cli(flags); size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT; size = (size + 1) >> 1; if(size <= mips_cpu.tlbsize/2) { int oldpid = (get_entryhi() & 0xff); int newpid = (CPU_CONTEXT(smp_processor_id(), mm) & 0xff); start &= (PAGE_MASK << 1); end += ((PAGE_SIZE << 1) - 1); end &= (PAGE_MASK << 1); while(start < end) { int idx; set_entryhi(start | newpid); start += (PAGE_SIZE << 1); BARRIER; tlb_probe(); BARRIER; idx = get_index(); set_entrylo0(0); set_entrylo1(0); if(idx < 0) continue; /* Make sure all entries differ. */ set_entryhi(KSEG0+idx*0x2000); BARRIER; tlb_write_indexed(); BARRIER; } set_entryhi(oldpid); } else { get_new_mmu_context(mm, smp_processor_id()); if (mm == current->active_mm) set_entryhi(CPU_CONTEXT(smp_processor_id(), mm) & 0xff); } __restore_flags(flags); } } void local_flush_tlb_page(struct vm_area_struct *vma, unsigned long page) { if (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) != 0) { unsigned long flags; unsigned long oldpid, newpid, idx; #ifdef DEBUG_TLB printk("[tlbpage<%d,%08lx>]", vma->vm_mm->context, page); #endif newpid = (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff); page &= (PAGE_MASK << 1); __save_and_cli(flags); oldpid = (get_entryhi() & 0xff); set_entryhi(page | newpid); BARRIER; tlb_probe(); BARRIER; idx = get_index(); set_entrylo0(0); set_entrylo1(0); if(idx < 0) goto finish; /* Make sure all entries differ. */ set_entryhi(KSEG0+idx*0x2000); BARRIER; tlb_write_indexed(); finish: BARRIER; set_entryhi(oldpid); __restore_flags(flags); } } /* * Updates the TLB with the new pte(s). */ void mips64_update_mmu_cache(struct vm_area_struct * vma, unsigned long address, pte_t pte) { unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; int idx, pid; /* * Handle debugger faulting in for debugee. */ if (current->active_mm != vma->vm_mm) return; pid = get_entryhi() & 0xff; #ifdef DEBUG_TLB if((pid != (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff)) || (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) == 0)) { printk("update_mmu_cache: Wheee, bogus tlbpid mmpid=%d tlbpid=%d\n", (int) (CPU_CONTEXT(smp_processor_id(), vma->vm_mm) & 0xff), pid); } #endif __save_and_cli(flags); address &= (PAGE_MASK << 1); set_entryhi(address | (pid)); pgdp = pgd_offset(vma->vm_mm, address); BARRIER; tlb_probe(); BARRIER; pmdp = pmd_offset(pgdp, address); idx = get_index(); ptep = pte_offset(pmdp, address); BARRIER; set_entrylo0(pte_val(*ptep++) >> 6); set_entrylo1(pte_val(*ptep) >> 6); set_entryhi(address | (pid)); BARRIER; if(idx < 0) { tlb_write_random(); } else { tlb_write_indexed(); } BARRIER; set_entryhi(pid); BARRIER; __restore_flags(flags); } void dump_mm_page(unsigned long addr) { pgd_t *page_dir, *pgd; pmd_t *pmd; pte_t *pte, page; unsigned long val; page_dir = pgd_offset(current->mm, 0); pgd = pgd_offset(current->mm, addr); pmd = pmd_offset(pgd, addr); pte = pte_offset(pmd, addr); page = *pte; printk("Memory Mapping: VA = %08x, PA = %08x ", addr, (unsigned int) pte_val(page)); val = pte_val(page); if (val & _PAGE_PRESENT) printk("present "); if (val & _PAGE_READ) printk("read "); if (val & _PAGE_WRITE) printk("write "); if (val & _PAGE_ACCESSED) printk("accessed "); if (val & _PAGE_MODIFIED) printk("modified "); if (val & _PAGE_R4KBUG) printk("r4kbug "); if (val & _PAGE_GLOBAL) printk("global "); if (val & _PAGE_VALID) printk("valid "); printk("\n"); } void show_tlb(void) { unsigned int flags; unsigned int old_ctx; unsigned int entry; unsigned int entrylo0, entrylo1, entryhi; __save_and_cli(flags); /* Save old context */ old_ctx = (get_entryhi() & 0xff); printk("TLB content:\n"); entry = 0; while(entry < mips_cpu.tlbsize) { set_index(entry); BARRIER; tlb_read(); BARRIER; entryhi = get_entryhi(); entrylo0 = get_entrylo0(); entrylo1 = get_entrylo1(); printk("%02d: ASID=%02d%s VA=0x%08x ", entry, entryhi & ASID_MASK, (entrylo0 & entrylo1 & 1) ? "(G)" : " ", entryhi & ~ASID_MASK); printk("PA0=0x%08x C0=%x %s%s%s\n", (entrylo0>>6)<<12, (entrylo0>>3) & 7, (entrylo0 & 4) ? "Dirty " : "", (entrylo0 & 2) ? "Valid " : "Invalid ", (entrylo0 & 1) ? "Global" : ""); printk("\t\t\t PA1=0x%08x C1=%x %s%s%s\n", (entrylo1>>6)<<12, (entrylo1>>3) & 7, (entrylo1 & 4) ? "Dirty " : "", (entrylo1 & 2) ? "Valid " : "Invalid ", (entrylo1 & 1) ? "Global" : ""); dump_mm_page(entryhi & ~0xff); dump_mm_page((entryhi & ~0xff) | 0x1000); entry++; } BARRIER; set_entryhi(old_ctx); __restore_flags(flags); } void add_wired_entry(unsigned long entrylo0, unsigned long entrylo1, unsigned long entryhi, unsigned long pagemask) { unsigned long flags; unsigned long wired; unsigned long old_pagemask; unsigned long old_ctx; __save_and_cli(flags); /* Save old context and create impossible VPN2 value */ old_ctx = (get_entryhi() & 0xff); old_pagemask = get_pagemask(); wired = get_wired(); set_wired (wired + 1); set_index (wired); BARRIER; set_pagemask (pagemask); set_entryhi(entryhi); set_entrylo0(entrylo0); set_entrylo1(entrylo1); BARRIER; tlb_write_indexed(); BARRIER; set_entryhi(old_ctx); BARRIER; set_pagemask (old_pagemask); local_flush_tlb_all(); __restore_flags(flags); } /* * Used for loading TLB entries before trap_init() has started, when we * don't actually want to add a wired entry which remains throughout the * lifetime of the system */ static int temp_tlb_entry __initdata; __init int add_temporary_entry(unsigned long entrylo0, unsigned long entrylo1, unsigned long entryhi, unsigned long pagemask) { int ret = 0; unsigned long flags; unsigned long wired; unsigned long old_pagemask; unsigned long old_ctx; __save_and_cli(flags); /* Save old context and create impossible VPN2 value */ old_ctx = get_entryhi() & 0xff; old_pagemask = get_pagemask(); wired = get_wired(); if (--temp_tlb_entry < wired) { printk(KERN_WARNING "No TLB space left for add_temporary_entry\n"); ret = -ENOSPC; goto out; } set_index(temp_tlb_entry); BARRIER; set_pagemask(pagemask); set_entryhi(entryhi); set_entrylo0(entrylo0); set_entrylo1(entrylo1); BARRIER; tlb_write_indexed(); BARRIER; set_entryhi(old_ctx); BARRIER; set_pagemask(old_pagemask); out: __restore_flags(flags); return ret; } static void __init probe_tlb(unsigned long config) { unsigned long config1; if (!(config & (1 << 31))) { /* * Not a MIPS64 complainant CPU. * Config 1 register not supported, we assume R4k style. */ mips_cpu.tlbsize = 48; } else { config1 = read_mips32_cp0_config1(); if (!((config >> 7) & 3)) panic("No MMU present"); else mips_cpu.tlbsize = ((config1 >> 25) & 0x3f) + 1; } printk("Number of TLB entries %d.\n", mips_cpu.tlbsize); } void __init r4k_tlb_init(void) { unsigned long config = read_32bit_cp0_register(CP0_CONFIG); probe_tlb(config); _update_mmu_cache = mips64_update_mmu_cache; set_pagemask(PM_4K); write_32bit_cp0_register(CP0_WIRED, 0); temp_tlb_entry = mips_cpu.tlbsize - 1; local_flush_tlb_all(); /* memcpy((void *)(KSEG0 + 0x80), &except_vec1_r4k, 0x80);*/ flush_icache_range(KSEG0, KSEG0 + 0x80); } --------------6A228B530B40164C0D9211A7 Content-Type: text/plain; charset=iso-8859-15; name="mips64_cache.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mips64_cache.h" /* * mips64_cache.h * * Carsten Langgaard, carstenl@mips.com * Copyright (C) 2002 MIPS Technologies, Inc. All rights reserved. * * ######################################################################## * * This program is free software; you can distribute it and/or modify it * under the terms of the GNU General Public License (Version 2) as * published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA. * * ######################################################################## * * Inline assembly cache operations. * * This file is the original r4cache.c file with modification that makes the * cache handling more generic. * * FIXME: Handle split L2 caches. * */ #ifndef _MIPS_MIPS64_CACHE_H #define _MIPS_MIPS64_CACHE_H #include #include static inline void flush_icache_line_indexed(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\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" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Index_Writeback_Inv_D)); } static inline void flush_scache_line_indexed(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Index_Writeback_Inv_SD)); } static inline void flush_icache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Hit_Invalidate_I)); } static inline void flush_dcache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Hit_Writeback_Inv_D)); } static inline void invalidate_dcache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Hit_Invalidate_D)); } static inline void invalidate_scache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Hit_Invalidate_SD)); } static inline void flush_scache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "cache %1, (%0)\n\t" ".set reorder" : : "r" (addr), "i" (Hit_Writeback_Inv_SD)); } /* * The next two are for badland addresses like signal trampolines. */ static inline void protected_flush_icache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "1:\tcache %1,(%0)\n" "2:\t.set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" ".dword\t1b,2b\n\t" ".previous" : : "r" (addr), "i" (Hit_Invalidate_I)); } static inline void protected_writeback_dcache_line(unsigned long addr) { __asm__ __volatile__( ".set noreorder\n\t" "1:\tcache %1,(%0)\n" "2:\t.set reorder\n\t" ".section\t__ex_table,\"a\"\n\t" ".dword\t1b,2b\n\t" ".previous" : : "r" (addr), "i" (Hit_Writeback_D)); } #define cache_unroll(base,op) \ __asm__ __volatile__(" \ .set noreorder; \ cache %1, (%0); \ .set reorder" \ : \ : "r" (base), \ "i" (op)); static inline void blast_dcache(void) { unsigned long start = KSEG0; unsigned long end = (start + dcache_size); while(start < end) { cache_unroll(start,Index_Writeback_Inv_D); start += dc_lsize; } } static inline void blast_dcache_page(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Hit_Writeback_Inv_D); start += dc_lsize; } } static inline void blast_dcache_page_indexed(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Index_Writeback_Inv_D); start += dc_lsize; } } static inline void blast_icache(void) { unsigned long start = KSEG0; unsigned long end = (start + icache_size); while(start < end) { cache_unroll(start,Index_Invalidate_I); start += ic_lsize; } } static inline void blast_icache_page(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Hit_Invalidate_I); start += ic_lsize; } } static inline void blast_icache_page_indexed(unsigned long page) { unsigned long start = page; unsigned long end = (start + PAGE_SIZE); while(start < end) { cache_unroll(start,Index_Invalidate_I); start += ic_lsize; } } static inline void blast_scache(void) { unsigned long start = KSEG0; unsigned long end = KSEG0 + scache_size; while(start < end) { cache_unroll(start,Index_Writeback_Inv_SD); start += sc_lsize; } } static inline void blast_scache_page(unsigned long page) { unsigned long start = page; unsigned long end = page + PAGE_SIZE; while(start < end) { cache_unroll(start,Hit_Writeback_Inv_SD); start += sc_lsize; } } static inline void blast_scache_page_indexed(unsigned long page) { unsigned long start = page; unsigned long end = page + PAGE_SIZE; while(start < end) { cache_unroll(start,Index_Writeback_Inv_SD); start += sc_lsize; } } #endif /* !(_MIPS_MIPS64_CACHE_H) */ --------------6A228B530B40164C0D9211A7-- From owner-linux-mips@oss.sgi.com Mon Jun 10 04:58: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 g5ABwjnC005067 for ; Mon, 10 Jun 2002 04:58:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ABwjQQ005066 for linux-mips-outgoing; Mon, 10 Jun 2002 04:58:45 -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 (c-180-196-56.ka.dial.de.ignite.net [62.180.196.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ABwcnC005053 for ; Mon, 10 Jun 2002 04:58:40 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5ABxch20688 for linux-mips@oss.sgi.com; Mon, 10 Jun 2002 13:59:38 +0200 Received: from dea.linux-mips.net (c-180-196-56.ka.dial.de.ignite.net [62.180.196.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ABfanC004792 for ; Mon, 10 Jun 2002 04:41:37 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5AB6j519865; Mon, 10 Jun 2002 13:06:45 +0200 X-Authentication-Warning: dea.linux-mips.net: ralf set sender to ralf@uni-koblenz.de using -f Subject: Re: R10K speculative store on non-coherent systems workaround proposal From: Ralf Baechle To: Vivien Chappelier Cc: linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-b/ZucXlTj8M9BXTILjaK" Message-Id: <1023707152.18634.18.camel@dea.linux-mips.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 10 Jun 2002 13:06:45 +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9975 Lines: 204 --=-b/ZucXlTj8M9BXTILjaK Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2002-06-08 at 00:15, Vivien Chappelier wrote: > Here is a proposal for a software workaround to speculative > execution on a non-coherent system such as the i2 R10k and the o2 R10k. > > 1. Problem: > =========== > > The R10000 processor can (and will) execute intructions ahead. > These instructions will be cancelled if they're not supposed to execute, > e.g. if a jump happened. If a load or store instruction is executed > speculatively, and the accessed memory is not in the cache, the cache > line will be fetched in main memory and, on a store, be marked dirty. > These speculative loads and stores can happen anywhere, since there might > be old values in registers used in a speculative load/store > instruction that would be cancelled afterwards. > > The problem is: > - on a speculative load, the fetched cache line will remain in the > cache even if the speculative load is cancelled > - on a speculative store, the *dirty* cache line will remain in > the cache even if the speculative store is cancelled > > On non-coherent systems we need to flush the cache lines to main > memory before doing DMA to device, so that the device can see them. We > also need to invalidate lines before reading from a DMA'd buffer to make > sure the CPU will read main memory and not the cache. > However, if a speculative load or store happens during DMA > transfer, the cache line will be fetched from memory and, on a store, > be marked dirty. That means this cache line could be evicted when the > line is needed, thus being written back in memory if it was dirty, > thus overwritting the data a device could have put in the DMA > buffer. Something we really don't want to happen ;) > > 2. Proposed solution > ==================== > > Speculative execution will not happen in the following conditions: > - access to memory is uncached > - the speculated instruction causes an exception: that > also means a speculative load/store will not happen in a mapped memory > region which doesn't have a TLB line for it. > > This second point means that any mapped space can be made safe by > removing the DMA'd buffer address translations from the TLB or by marking > them 'uncached' during DMA transfer. > The remaining unmapped adress spaces are: > - kseg1, which is safe since uncached > - kseg0, which can turned uncached with the K0 bits > from the CPO Config register > - xkphys which will cause adress error if the KX bit is > not set, the aborting the speculative load/store before it can do harm ;) > > Since we need to turn KX off, xkseg will not be accessible > either.. and since we need to have KSEG0 uncached, we need to remap the > kernel elsewhere if we want performance ;). We could use the xsseg > segment, available in Supervisor mode, which is mapped (safe) and moreover > allows to access all memory (on o2 it can be up to 2G I think, whereas in > 32bit mode, only 512Mb would be accessible). So the proposed workaround is > to permanently map the lower 16MB of memory in xsseg in using a wired TLB > entry and a page size of 16MB. This memory would not be usable for > DMA. Everything else would, so we could for example reserve the upper 16Mb > for DMA (and give them to the DMA zoned memory allocator). On exception or > error, the handler (in KSEG0) would set CU0 to allow access to CPO, then > switch to Supervisor mode and jump to the equivalent xsseg location and > continue execution in Supervisor mode. The code for returning to userland > would need to clear the CU0 bit, to prevent user access to CP0. > Before DMA transfer, the DMA'd buffer cache lines would be > flushed, and then it would be remapped 'uncached', thus preventing that > any speculative load or store to this memory happens during > transfer. After the DMA transfer, the cache would be invalidated to make > sure main memory is read, and the DMA buffer would be remapped 'cacheable > non-coherent'. > A diagram is attached to illustrate the workaround. Comments, > suggestions (and even flames) are welcome before anyone starts coding > the workaround ;) Looks like a good start but unfortunately your concept is ignoring userspace entirely. You might have to deal with mmapped pages that are being written to backing storage. In such a case you'll have to trackdown all mappings and disable access to them and that's something that is pretty hard in the current memory managment code. The solution would be Rik's rmap patches which themselves are still under development.. Intially I guess you can simply avoid this hairy job by doing all DMA using bounce buffers only. Expensive but doable ... Ralf (Testing evolution ...) --=-b/ZucXlTj8M9BXTILjaK Content-Type: text/html; charset=utf-8 
On Sat, 2002-06-08 at 00:15, Vivien Chappelier wrote:

> 	Here is a proposal for a software workaround to speculative
> execution on a non-coherent system such as the i2 R10k and the o2 R10k.
> 
> 1. Problem:
> ===========
> 
> 	The R10000 processor can (and will) execute intructions ahead.
> These instructions will be cancelled if they're not supposed to execute,
> e.g. if a jump happened. If a load or store instruction is executed
> speculatively, and the accessed memory is not in the cache, the cache
> line will be fetched in main memory and, on a store, be marked dirty.
> These speculative loads and stores can happen anywhere, since there might
> be old values in registers used in a speculative load/store
> instruction that would be cancelled afterwards.
> 
> The problem is:
> 	- on a speculative load, the fetched cache line will remain in the
> cache even if the speculative load is cancelled
> 	- on a speculative store, the *dirty* cache line will remain in
> the cache even if the speculative store is cancelled
> 
> 	On non-coherent systems we need to flush the cache lines to main
> memory before doing DMA to device, so that the device can see them. We
> also need to invalidate lines before reading from a DMA'd buffer to make
> sure the CPU will read main memory and not the cache.
> 	However, if a speculative load or store happens during DMA
> transfer, the cache line will be fetched from memory and, on a store, 
> be marked dirty. That means this cache line could be evicted when the
> line is needed, thus being written back in memory if it was dirty,
> thus overwritting the data a device could have put in the DMA
> buffer. Something we really don't want to happen ;)
> 
> 2. Proposed solution
> ====================
> 
> 	Speculative execution will not happen in the following conditions:
> 		- access to memory is uncached
> 		- the speculated instruction causes an exception: that
> also means a speculative load/store will not happen in a mapped memory
> region which doesn't have a TLB line for it.
> 
> 	This second point means that any mapped space can be made safe by
> removing the DMA'd buffer address translations from the TLB or by marking
> them 'uncached' during DMA transfer.
> 	The remaining unmapped adress spaces are:
> 		- kseg1, which is safe since uncached
> 		- kseg0, which can turned uncached with the K0 bits
> from the CPO Config register
> 		- xkphys which will cause adress error if the KX bit is
> not set, the aborting the speculative load/store before it can do harm ;)
> 
> 	Since we need to turn KX off, xkseg will not be accessible
> either.. and since we need to have KSEG0 uncached, we need to remap the
> kernel elsewhere if we want performance ;). We could use the xsseg
> segment, available in Supervisor mode, which is mapped (safe) and moreover
> allows to access all memory (on o2 it can be up to 2G I think, whereas in
> 32bit mode, only 512Mb would be accessible). So the proposed workaround is
> to permanently map the lower 16MB of memory in xsseg in using a wired TLB
> entry and a page size of 16MB. This memory would not be usable for
> DMA. Everything else would, so we could for example reserve the upper 16Mb
> for DMA (and give them to the DMA zoned memory allocator). On exception or
> error, the handler (in KSEG0) would set CU0 to allow access to CPO, then
> switch to Supervisor mode and jump to the equivalent xsseg location and
> continue execution in Supervisor mode. The code for returning to userland
> would need to clear the CU0 bit, to prevent user access to CP0.
> 	Before DMA transfer, the DMA'd buffer cache lines would be
> flushed, and then it would be remapped 'uncached', thus preventing that
> any speculative load or store to this memory happens during
> transfer. After the DMA transfer, the cache would be invalidated to make
> sure main memory is read, and the DMA buffer would be remapped 'cacheable
> non-coherent'.
> 	A diagram is attached to illustrate the workaround. Comments,
> suggestions (and even flames) are welcome before anyone starts coding
> the workaround ;)

Looks like a good start but unfortunately your concept is ignoring
userspace entirely.  You might have to deal with mmapped pages that are
being written to backing storage.  In such a case you'll have to
trackdown all mappings and disable access to them and that's something
that is pretty hard in the current memory managment code.  The solution
would be Rik's rmap patches which themselves are still under
development..  Intially I guess you can simply avoid this hairy job by
doing all DMA using bounce buffers only.  Expensive but doable ...

  Ralf

(Testing evolution ...)
--=-b/ZucXlTj8M9BXTILjaK-- From owner-linux-mips@oss.sgi.com Mon Jun 10 12:35: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 g5AJZdnC026652 for ; Mon, 10 Jun 2002 12:35:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AJZdXr026651 for linux-mips-outgoing; Mon, 10 Jun 2002 12:35: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 g5AJZTnC026647 for ; Mon, 10 Jun 2002 12:35:29 -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 MAA09058; Mon, 10 Jun 2002 12:37:40 -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 MAA10598; Mon, 10 Jun 2002 12:37:41 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5AJbfb04195; Mon, 10 Jun 2002 21:37:41 +0200 (MEST) Message-ID: <3D0500F6.333B7CA1@mips.com> Date: Mon, 10 Jun 2002 21:41:42 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: linux-mips@oss.sgi.com Subject: Re: Bug in the _save_fp_context. References: <3C46D2ED.9BCA458A@mips.com> <20020610114323.A25705@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2225 Lines: 68 "H . J . Lu" wrote: > On Thu, Jan 17, 2002 at 02:34:37PM +0100, Carsten Langgaard wrote: > > I posted the following problem on the list almost a year ago, but it > > still hasn't made into the SGI CVS. > > I think there is a bug in the _save_fp_context function in > > arch/mips/kernel/r4k_fpu.S > > > > The problem is the following piece of code: > > > > jr ra > > .set nomacro > > EX(sw t0,SC_FPC_EIR(a0)) > > .set macro > > > > We do not handle entries in the __ex_table which is located in a branch > > delay. > > So we need to handle the situation where we take a page fault on an > > instruction which is located in a brach delay slot, or we don't put the > > "potential" faulting instruction in a delay slot. > > > > This situation probably doesn't generally hit people since it hasn't > > been fix yet, but if you try run something nasty like Crashme, you will > > get hit by this problem. > > I suggest the following patch. > > > > /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 > > > > > > > Index: arch/mips/kernel/r4k_fpu.S > > =================================================================== > > RCS file: /cvs/linux/arch/mips/kernel/r4k_fpu.S,v > > retrieving revision 1.12 > > diff -u -r1.12 r4k_fpu.S > > --- arch/mips/kernel/r4k_fpu.S 2001/04/11 05:19:46 1.12 > > +++ arch/mips/kernel/r4k_fpu.S 2002/01/17 14:21:09 > > @@ -50,11 +50,10 @@ > > EX(sdc1 $f30,(SC_FPREGS+240)(a0)) > > EX(sw t1,SC_FPC_CSR(a0)) > > cfc1 t0,$0 # implementation/version > > + EX(sw t0,SC_FPC_EIR(a0)) > > > > jr ra > > - .set nomacro > > - EX(sw t0,SC_FPC_EIR(a0)) > > - .set macro > > + nop > > END(_save_fp_context) > > > > /* > > Do we still need this patch for 2.4 on OSS? > > H.J. No, this fix is not needed any more, as we now handle entries in the __ex_table which is located in a branch delay. From owner-linux-mips@oss.sgi.com Mon Jun 10 12:42: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 g5AJgZnC026769 for ; Mon, 10 Jun 2002 12:42:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AJgZUq026768 for linux-mips-outgoing; Mon, 10 Jun 2002 12:42:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AJgVnC026765 for ; Mon, 10 Jun 2002 12:42:31 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5AJi8k01696; Mon, 10 Jun 2002 12:44:08 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Atomicity & preemptive kernels From: Justin Carlson To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:44:07 -0700 Message-Id: <1023738247.1133.56.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 984 Lines: 27 I know we're not there yet, but I'm trying to understand some issues with rml's preemptive kernel and ASID's. While doing a virtually-tagged hit invalidate of a cache, I was going to write code something like this; set_entryhi(CPU_CONTEXT(cpu, mm->vm_mm)); hit_invalidate_range(start, end); set_entryhi(CPU_CONTEXT(cpu, current->mm)); Insofar as I understand current kernel scheduling guarantees, this is safe because we won't reschedule while running in kernel mode. But, if I'm looking ahead to the preemptive kernel, then I think there is a slight window for a race in between the reading of current->mm and the setting of entryhi. Something like this: current->mm->context is read * kernel reschedules. * switch_mm() called * current->mm->context changes on return to this process entryhi is set to the wrong context. Is this a real race? If so, is there any way around it other than locally disabling interrupts around the restoration of the context? -Justin From owner-linux-mips@oss.sgi.com Mon Jun 10 13:35: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 g5AKZnnC027397 for ; Mon, 10 Jun 2002 13:35:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AKZnGZ027396 for linux-mips-outgoing; Mon, 10 Jun 2002 13:35:49 -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 g5AKYenC027389 for ; Mon, 10 Jun 2002 13:34:41 -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 <20020610203655.ESMT1024.sccrmhc01.attbi.com@ocean.lucon.org>; Mon, 10 Jun 2002 20:36:55 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 735E2125C0; Mon, 10 Jun 2002 13:36:52 -0700 (PDT) Date: Mon, 10 Jun 2002 13:36:52 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.11 is released. Message-ID: <20020610133652.A27414@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 Content-Length: 15756 Lines: 571 This is the beta release of binutils 2.12.90.0.11 for Linux, which is based on binutils 2002 0608 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.11 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.9: 1. Update from binutils 2002 0608. 2. Fix an ELF/mips SHF_MERGE bug. 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.11.tar.gz. Source code. 2. binutils-2.12.90.0.9-2.12.90.0.11.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.11-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.11.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 06/10/2002 From owner-linux-mips@oss.sgi.com Mon Jun 10 13:51: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 g5AKpHnC027571 for ; Mon, 10 Jun 2002 13:51:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AKpHhN027570 for linux-mips-outgoing; Mon, 10 Jun 2002 13:51:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AKpEnC027567 for ; Mon, 10 Jun 2002 13:51:14 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5AKr6g5274302; Mon, 10 Jun 2002 16:53:08 -0400 Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.117.250.6]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AKr3m40312; Mon, 10 Jun 2002 16:53:04 -0400 Subject: MIPS RPM binaries now available for LTP. To: ltp-list@lists.sourceforge.net, linux-mips@oss.sgi.com Cc: Carsten Langgaard , Eric LEBOEUF X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Williamson" Date: Mon, 10 Jun 2002 15:52:33 -0500 X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/10/2002 04:53:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 438 Lines: 15 Thanks to Carsten Langgaard for volunteering to create the MIPS binary RPMS. Carsten doesn't have time right now to actually run and test the testsuite, so could some MIPS users please download the appropriate binary (big or little endian) and give us feedback. Thanks, - Robbie Robert V. Williamson Linux Test Project IBM Linux Technology Center Phone: (512) 838-9295 T/L: 638-9295 http://ltp.sourceforge.net From owner-linux-mips@oss.sgi.com Mon Jun 10 15:15: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 g5AMFsnC028654 for ; Mon, 10 Jun 2002 15:15:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AMFsqx028653 for linux-mips-outgoing; Mon, 10 Jun 2002 15:15: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 g5AMFmnC028649 for ; Mon, 10 Jun 2002 15:15:48 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id PAA15096; Mon, 10 Jun 2002 15:16:02 -0700 Message-ID: <3D0524B5.403@mvista.com> Date: Mon, 10 Jun 2002 15:14:13 -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: linux-mips@oss.sgi.com Subject: Re: Atomicity & preemptive kernels References: <1023738247.1133.56.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1516 Lines: 41 Justin Carlson wrote: > I know we're not there yet, but I'm trying to understand some issues > with rml's preemptive kernel and ASID's. > > While doing a virtually-tagged hit invalidate of a cache, I was going to > write code something like this; > > set_entryhi(CPU_CONTEXT(cpu, mm->vm_mm)); > hit_invalidate_range(start, end); > set_entryhi(CPU_CONTEXT(cpu, current->mm)); > > Insofar as I understand current kernel scheduling guarantees, this is > safe because we won't reschedule while running in kernel mode. But, if > I'm looking ahead to the preemptive kernel, then I think there is a > slight window for a race in between the reading of current->mm and > the setting of entryhi. Something like this: > > current->mm->context is read > * kernel reschedules. > * switch_mm() called > * current->mm->context changes on return to this process > entryhi is set to the wrong context. > > Is this a real race? I am not sure if I am following your logic, but I don't see a race condition here. Once current->mm is read into a register, the register is saved into stack when an interrupt happens (which later incurs a reschedule presumbably). When the current preempted process comes back later, it goes back to the "tail" of do_IRQ(), followed by restoring the registers. Since the register now holds the right value, set_entryhi() should be correct. BTW, I have preemptiable kernel working fine under both UP and SMP. If there is much interestes, I will publish it on the list. Jun From owner-linux-mips@oss.sgi.com Mon Jun 10 16:58: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 g5ANwXnC032756 for ; Mon, 10 Jun 2002 16:58:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ANwXxn032755 for linux-mips-outgoing; Mon, 10 Jun 2002 16:58:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ANwRnC032752 for ; Mon, 10 Jun 2002 16:58:28 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5B003m01181; Mon, 10 Jun 2002 17:00:03 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: Atomicity & preemptive kernels From: Justin Carlson To: Jun Sun Cc: linux-mips@oss.sgi.com In-Reply-To: <3D0524B5.403@mvista.com> References: <1023738247.1133.56.camel@localhost.localdomain> <3D0524B5.403@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 17:00:03 -0700 Message-Id: <1023753603.1152.28.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1553 Lines: 35 On Mon, 2002-06-10 at 15:14, Jun Sun wrote: > I am not sure if I am following your logic, but I don't see a race condition here. > > Once current->mm is read into a register, the register is saved into stack > when an interrupt happens (which later incurs a reschedule presumbably). When > the current preempted process comes back later, it goes back to the "tail" of > do_IRQ(), followed by restoring the registers. Since the register now holds > the right value, set_entryhi() should be correct. > You've described exactly what happens. The only problem is, it's possible the underlying value for current->mm has changed. It's a *really* narrow window, at most a cycle or two, but I think it is there. In addition, even if you hit the window, to trigger wrong behavior it requires that you also saturate the local ASID space, invoking the tlb flush and asid reset in get_mmu_context(). The change that's introduced by the preemptive kernel is that switch_mm() can be called after an interrupt. So, with some hypothetical assembly, the code flow looks like this: lw $1, 120($29) ; Load current->mm->context into a register * Interrupt happens * * reschedule happens, switch_mm() is called * * get_new_mmu_context() invoked, starts a new ASID cycle. * current->mm->context for the original process changes * (sometime later) switch back to original process mtc0 $entryhi, $1 ; stale context put back into entryhi! Does that make more sense? It's really a tiny race, but I think it's a real one. -Justin From owner-linux-mips@oss.sgi.com Tue Jun 11 04:59: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 g5BBxUnC009357 for ; Tue, 11 Jun 2002 04:59:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BBxUNa009356 for linux-mips-outgoing; Tue, 11 Jun 2002 04:59: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 g5BBxPnC009353 for ; Tue, 11 Jun 2002 04:59:25 -0700 Received: from mail5.triad.rr.com ([24.93.67.52]) 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 FAA05094 for ; Tue, 11 Jun 2002 05:01:55 -0700 (PDT) mail_from (justin@cs.cmu.edu) Received: from mail pickup service by mail5.triad.rr.com with Microsoft SMTPSVC; Tue, 11 Jun 2002 07:50:51 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail5.triad.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:33:25 -0400 Received: from oss.sgi.com (oss.SGI.COM [128.167.58.27]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AJlJIa026960 for ; Mon, 10 Jun 2002 15:47:19 -0400 (EDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AJiXnC026815; Mon, 10 Jun 2002 12:44:33 -0700 Received: from localhost (mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) with SMTP id g5AJiXa1026814; Mon, 10 Jun 2002 12:44:33 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 10 Jun 2002 12:42:36 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AJgZnC026769 for ; Mon, 10 Jun 2002 12:42:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AJgZUq026768 for linux-mips-outgoing; Mon, 10 Jun 2002 12:42:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AJgVnC026765 for ; Mon, 10 Jun 2002 12:42:31 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5AJi8k01696; Mon, 10 Jun 2002 12:44:08 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Atomicity & preemptive kernels From: Justin Carlson To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Jun 2002 12:44:07 -0700 Message-Id: <1023738247.1133.56.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 984 Lines: 27 I know we're not there yet, but I'm trying to understand some issues with rml's preemptive kernel and ASID's. While doing a virtually-tagged hit invalidate of a cache, I was going to write code something like this; set_entryhi(CPU_CONTEXT(cpu, mm->vm_mm)); hit_invalidate_range(start, end); set_entryhi(CPU_CONTEXT(cpu, current->mm)); Insofar as I understand current kernel scheduling guarantees, this is safe because we won't reschedule while running in kernel mode. But, if I'm looking ahead to the preemptive kernel, then I think there is a slight window for a race in between the reading of current->mm and the setting of entryhi. Something like this: current->mm->context is read * kernel reschedules. * switch_mm() called * current->mm->context changes on return to this process entryhi is set to the wrong context. Is this a real race? If so, is there any way around it other than locally disabling interrupts around the restoration of the context? -Justin From owner-linux-mips@oss.sgi.com Tue Jun 11 11:46: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 g5BIkNnC017069 for ; Tue, 11 Jun 2002 11:46:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BIkNHb017068 for linux-mips-outgoing; Tue, 11 Jun 2002 11:46: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 g5BIkGnC017065 for ; Tue, 11 Jun 2002 11:46:16 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA14072; Tue, 11 Jun 2002 11:46:30 -0700 Message-ID: <3D0644F4.8070902@mvista.com> Date: Tue, 11 Jun 2002 11:44:04 -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: linux-mips@oss.sgi.com Subject: Re: Atomicity & preemptive kernels References: <1023738247.1133.56.camel@localhost.localdomain> <3D0524B5.403@mvista.com> <1023753603.1152.28.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1892 Lines: 48 Justin Carlson wrote: > On Mon, 2002-06-10 at 15:14, Jun Sun wrote: > >>I am not sure if I am following your logic, but I don't see a race condition here. >> >>Once current->mm is read into a register, the register is saved into stack >>when an interrupt happens (which later incurs a reschedule presumbably). When >>the current preempted process comes back later, it goes back to the "tail" of >>do_IRQ(), followed by restoring the registers. Since the register now holds >>the right value, set_entryhi() should be correct. >> >> > > You've described exactly what happens. The only problem is, it's > possible the underlying value for current->mm has changed. It's a > *really* narrow window, at most a cycle or two, but I think it is > there. In addition, even if you hit the window, to trigger wrong > behavior it requires that you also saturate the local ASID space, > invoking the tlb flush and asid reset in get_mmu_context(). > > The change that's introduced by the preemptive kernel is that > switch_mm() can be called after an interrupt. So, with some > hypothetical assembly, the code flow looks like this: > > lw $1, 120($29) ; Load current->mm->context into a register > * Interrupt happens * > * reschedule happens, switch_mm() is called * > * get_new_mmu_context() invoked, starts a new ASID cycle. > * current->mm->context for the original process changes > * (sometime later) switch back to original process > mtc0 $entryhi, $1 ; stale context put back into entryhi! > > Does that make more sense? It's really a tiny race, but I think it's a > real one. > I see your point now. However, the race is not there. switch_mm() is only called from inside schedule() function, which as a whole is preemption-safe. In other words, the above event sequence won't cause a context switch until we exit from schedule() function. Jun From owner-linux-mips@oss.sgi.com Tue Jun 11 12:55: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 g5BJtRnC020123 for ; Tue, 11 Jun 2002 12:55:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BJtR4n020122 for linux-mips-outgoing; Tue, 11 Jun 2002 12:55:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BJtOnC020113 for ; Tue, 11 Jun 2002 12:55:24 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5BJv0v02919; Tue, 11 Jun 2002 12:57:00 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: Atomicity & preemptive kernels From: Justin Carlson To: Jun Sun Cc: linux-mips@oss.sgi.com In-Reply-To: <3D0644F4.8070902@mvista.com> References: <1023738247.1133.56.camel@localhost.localdomain> <3D0524B5.403@mvista.com> <1023753603.1152.28.camel@localhost.localdomain> <3D0644F4.8070902@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 12:56:59 -0700 Message-Id: <1023825419.2776.13.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 598 Lines: 17 On Tue, 2002-06-11 at 11:44, Jun Sun wrote: > I see your point now. > > However, the race is not there. switch_mm() is only called from inside > schedule() function, which as a whole is preemption-safe. In other words, the > above event sequence won't cause a context switch until we exit from > schedule() function. > Yes, but the initial code I cited was explicitly not in the schedule function. It was an icache_flush_page() implementation. Just something to be careful of. I think it's going to bite more than a few people as a bug that's about impossible to track down... -Justin From owner-linux-mips@oss.sgi.com Tue Jun 11 23:08: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 g5C68KnC027739 for ; Tue, 11 Jun 2002 23:08:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C68KP2027738 for linux-mips-outgoing; Tue, 11 Jun 2002 23:08:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-1.us4.outblaze.com (205-158-62-91.outblaze.com [205.158.62.91]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C68InC027735 for ; Tue, 11 Jun 2002 23:08:18 -0700 Received: (qmail 13345 invoked by uid 1001); 12 Jun 2002 06:10:40 -0000 Message-ID: <20020612061040.13344.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-1.us4.outblaze.com with http for domca_psg@email.com; Wed, 12 Jun 2002 01:10:40 -0500 From: "Shanmmuga Raja" To: linux-mips@oss.sgi.com Date: Wed, 12 Jun 2002 01:10:40 -0500 Subject: Accessing the serial port X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-1.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 554 Lines: 10 Hello, I am using a Galileo Board with a RM 7000 MIPS processor. I have connected a Linux box to the board and set up a Cross-Compiler for Linux-MIPS (gcc). How do I access the serial port and print a string to the Hyperterminal on a Win NT machine which is also connected to the board. If someone could reply ASAP, please. If u can suggest any websites which contain such info. Thanks in advance. Domcan -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Email.com http://www.email.com/?sr=signup From owner-linux-mips@oss.sgi.com Wed Jun 12 05:40: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 g5CCegnC014443 for ; Wed, 12 Jun 2002 05:40:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CCegvr014442 for linux-mips-outgoing; Wed, 12 Jun 2002 05:40:42 -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 g5CCcnnC014361 for ; Wed, 12 Jun 2002 05:38:50 -0700 Received: (qmail 9126 invoked from network); 12 Jun 2002 12:29:27 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.150) by 159.226.39.4 with SMTP; 12 Jun 2002 12:29:27 -0000 Message-ID: <3D0740ED.2060907@ict.ac.cn> Date: Wed, 12 Jun 2002 20:39:09 +0800 From: Zhang Fuxin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org Subject: NAPI for eepro100 Content-Type: multipart/mixed; boundary="------------070502030508090306010005" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 24980 Lines: 953 This is a multi-part message in MIME format. --------------070502030508090306010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi,all Recently i've converted eepro100 driver to use napi,in order to improve network performance of my poor 150M mips machine. It does eliminate the interrupt live lock seen before,maintaining a peak throughput under heavy load. In case anybody are interested,i post the patches to the list. They are 3 incremental patchs: eepro100-napi.patch is against 2.5.20 eepro100.c and provide basic napi support eepro100-proc.patch is proc file system support adapted from intel's e100 driver. I am using it for debugging. eepro100-mips.patch is mips specific patch to make it work(well) for my mips platform. (i suppose people use: patch eepro100.c < x.patch to apply patch) Tests are mainly done on my mips machine for 2.4 kernel,though i think it should work for at least x86 on which minimal test is performed. Be careful. A little pitty is that to achieve good performance under heavy load, the /proc/sys/net/core/netdev_max_backlog value may need to be adjusted. Feedbacks are always welcome:). But i am not on linux-kernel list,so people there please CC me. --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-mips.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-mips.patch" --- eepro100-napi-proc.c Wed Jun 12 17:33:51 2002 +++ eepro100-mips.c Wed Jun 12 19:22:29 2002 @@ -45,7 +45,7 @@ /* Set the copy breakpoint for the copy-only-tiny-buffer Rx method. Lower values use more memory, but are faster. */ -#if defined(__alpha__) || defined(__sparc__) || defined(__mips__) || \ +#if defined(__alpha__) || defined(__sparc__) || /*defined(__mips__) ||*/ \ defined(__arm__) static int rx_copybreak = 1518; #else @@ -66,8 +66,8 @@ /* A few values that may be tweaked. */ /* The ring sizes should be a power of two for efficiency. */ -#define TX_RING_SIZE 64 -#define RX_RING_SIZE 64 +#define TX_RING_SIZE 32 +#define RX_RING_SIZE 32 /* How much slots multicast filter setup may take. Do not descrease without changing set_rx_mode() implementaion. */ #define TX_MULTICAST_SIZE 2 @@ -1298,7 +1298,14 @@ if (skb == NULL) break; /* OK. Just initially short of Rx bufs. */ skb->dev = dev; /* Mark as being used by this device. */ +#ifndef __mips__ rxf = (struct RxFD *)skb->tail; +#else + /* use uncached address,use pci_dma_sync_xx seems + * problematic in my mips platform + */ + rxf = (struct RxFD *)(KSEG1ADDR(skb->tail)); +#endif sp->rx_ringp[i] = rxf; sp->rx_ring_dma[i] = pci_map_single(sp->pdev, rxf, @@ -1306,8 +1313,10 @@ skb_reserve(skb, sizeof(struct RxFD)); if (last_rxf) { last_rxf->link = cpu_to_le32(sp->rx_ring_dma[i]); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, last_rxf_dma, sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif } last_rxf = rxf; last_rxf_dma = sp->rx_ring_dma[i]; @@ -1316,14 +1325,18 @@ /* This field unused by i82557. */ rxf->rx_buf_addr = 0xffffffff; rxf->count = cpu_to_le32(PKT_BUF_SZ << 16); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[i], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif } sp->dirty_rx = (unsigned int)(i - RX_RING_SIZE); /* Mark the last entry as end-of-list. */ last_rxf->status = cpu_to_le32(0xC0000002); /* '2' is flag value only. */ +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[RX_RING_SIZE-1], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif sp->last_rxf = last_rxf; sp->last_rxf_dma = last_rxf_dma; } @@ -1733,15 +1746,21 @@ #endif return NULL; } +#ifndef __mips__ rxf = sp->rx_ringp[entry] = (struct RxFD *)skb->tail; +#else + rxf = sp->rx_ringp[entry] = (struct RxFD *)(KSEG1ADDR(skb->tail)); +#endif sp->rx_ring_dma[entry] = pci_map_single(sp->pdev, rxf, PKT_BUF_SZ + sizeof(struct RxFD), PCI_DMA_FROMDEVICE); skb->dev = dev; skb_reserve(skb, sizeof(struct RxFD)); rxf->rx_buf_addr = 0xffffffff; +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[entry], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif return rxf; } @@ -1754,8 +1773,10 @@ rxf->count = cpu_to_le32(PKT_BUF_SZ << 16); sp->last_rxf->link = cpu_to_le32(rxf_dma); sp->last_rxf->status &= cpu_to_le32(~0xC0000000); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->last_rxf_dma, sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif sp->last_rxf = rxf; sp->last_rxf_dma = rxf_dma; } @@ -2274,8 +2295,10 @@ int status; int pkt_len; +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[entry], sizeof(struct RxFD), PCI_DMA_FROMDEVICE); +#endif status = le32_to_cpu(sp->rx_ringp[entry]->status); pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff; --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-napi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-napi.patch" --- eepro100.c.ori Wed Jun 12 17:25:28 2002 +++ eepro100-napi.c Wed Jun 12 17:11:38 2002 @@ -25,6 +25,8 @@ Disabled FC and ER, to avoid lockups when when we get FCP interrupts. 2000 Jul 17 Goutham Rao PCI DMA API fixes, adding pci_dma_sync_single calls where neccesary + 2002 Jun 12 Zhang Fuxin + add NAPI support */ static const char *version = @@ -115,6 +117,8 @@ #include #include +#define CONFIG_EEPRO100_NAPI + MODULE_AUTHOR("Maintainer: Andrey V. Savochkin "); MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver"); MODULE_LICENSE("GPL"); @@ -494,8 +498,34 @@ #ifdef CONFIG_PM u32 pm_state[16]; #endif + + /* added by zfx for NAPI*/ +#ifdef CONFIG_EEPRO100_NAPI + + /* used to pass rx_work_limit into speedo_rx,i don't want to + * change its prototype + */ + int curr_work_limit; + unsigned long poll_switch; + unsigned long failed_poll_switch; + unsigned long done_poll; + unsigned long notdone_poll; + unsigned long empty_poll; + unsigned long soft_reset_count; + unsigned long rx_resume_count; + unsigned long alloc_fail; + unsigned long long poll_cycles; + +#ifdef CONFIG_NET_FASTROUTE + unsigned long fastroute_hit; + unsigned long fastroute_success; + unsigned long fastroute_defer; +#endif + +#endif }; + /* The parameters for a CmdConfigure operation. There are so many options that it would be difficult to document each bit. We mostly use the default or recommended settings. */ @@ -546,6 +576,14 @@ static void set_rx_mode(struct net_device *dev); static void speedo_show_state(struct net_device *dev); +#ifdef CONFIG_EEPRO100_NAPI + +static int speedo_poll (struct net_device *dev, int *budget); +static void enable_rx_and_rxnobuf_ints(struct net_device *dev); +static void disable_rx_and_rxnobuf_ints(struct net_device *dev); + +#endif + #ifdef honor_default_port @@ -842,6 +880,10 @@ dev->set_multicast_list = &set_rx_mode; dev->do_ioctl = &speedo_ioctl; +#ifdef CONFIG_EEPRO100_NAPI + dev->poll = speedo_poll; + dev->quota = dev->weight = RX_RING_SIZE; +#endif return 0; } @@ -1517,6 +1559,9 @@ struct speedo_private *sp; long ioaddr, boguscnt = max_interrupt_work; unsigned short status; +#ifdef CONFIG_EEPRO100_NAPI + int first = 1; +#endif #ifndef final_version if (dev == NULL) { @@ -1543,16 +1588,21 @@ /* Acknowledge all of the current interrupt sources ASAP. */ /* Will change from 0xfc00 to 0xff00 when we start handling FCP and ER interrupts --Dragan */ +#ifndef CONFIG_EEPRO100_NAPI outw(status & 0xfc00, ioaddr + SCBStatus); +#else + /* Rx & RxNoBuf is acked in speedo_poll */ + outw(status & 0xac00, ioaddr + SCBStatus); +#endif if (speedo_debug > 4) printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n", dev->name, status); +#ifndef CONFIG_EEPRO100_NAPI if ((status & 0xfc00) == 0) break; - if ((status & 0x5000) || /* Packet received, or Rx error. */ (sp->rx_ring_state&(RrNoMem|RrPostponed)) == RrPostponed) /* Need to gather the postponed packet. */ @@ -1560,8 +1610,33 @@ /* Always check if all rx buffers are allocated. --SAW */ speedo_refill_rx_buffers(dev, 0); +#else + /* Packet received, or Rx error. */ + if (first && ((status & 0x5000) || (sp->rx_ring_state&(RrNoMem|RrPostponed)) == RrPostponed || (status & 0x3c) != 0x10 )) + /* Need to gather the postponed packet. */ + { + if (speedo_debug > 4) + printk("switching to poll,status=%x\n",status); + first = 0; + if (netif_rx_schedule_prep(dev)) { + sp->poll_switch++; + /* disable interrupts caused by arriving packets */ + disable_rx_and_rxnobuf_ints(dev); + /* tell system we have work to be done. */ + __netif_rx_schedule(dev); + }else { + sp->failed_poll_switch++; + } + + } + + if ((status & 0xac00) == 0) + break; +#endif spin_lock(&sp->lock); + +#ifndef CONFIG_EEPRO100_NAPI /* * The chip may have suspended reception for various reasons. * Check for that, and re-prime it should this be the case. @@ -1581,7 +1656,7 @@ /* these are all reserved values */ break; } - +#endif /* User interrupt, Command/Tx unit interrupt or CU not active. */ if (status & 0xA400) { @@ -1602,7 +1677,12 @@ /* Clear all interrupt sources. */ /* Will change from 0xfc00 to 0xff00 when we start handling FCP and ER interrupts --Dragan */ +#ifndef CONFIG_EEPRO100_NAPI outw(0xfc00, ioaddr + SCBStatus); +#else + outw(0xac00, ioaddr + SCBStatus); +#endif + break; } } while (1); @@ -1611,7 +1691,9 @@ printk(KERN_DEBUG "%s: exiting interrupt, status=%#4.4x.\n", dev->name, inw(ioaddr + SCBStatus)); +#ifndef final_version clear_bit(0, (void*)&sp->in_interrupt); +#endif return; } @@ -1625,6 +1707,9 @@ sp->rx_skbuff[entry] = skb; if (skb == NULL) { sp->rx_ringp[entry] = NULL; +#ifdef CONFIG_EEPRO100_NAPI + sp->alloc_fail++; +#endif return NULL; } rxf = sp->rx_ringp[entry] = (struct RxFD *)skb->tail; @@ -1705,12 +1790,112 @@ speedo_refill_rx_buf(dev, force) != -1); } +#ifdef CONFIG_EEPRO100_NAPI +static void enable_rx_and_rxnobuf_ints(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + outw(SCBMaskEarlyRx | SCBMaskFlowCtl, ioaddr + SCBCmd); + inw(ioaddr + SCBStatus); /* flushes last write, read-safe */ +}; + +static void disable_rx_and_rxnobuf_ints(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + outw(SCBMaskRxDone | SCBMaskRxSuspend | SCBMaskEarlyRx | SCBMaskFlowCtl, ioaddr + SCBCmd); + inw(ioaddr + SCBStatus); /* flushes last write, read-safe */ +}; + +static int speedo_poll (struct net_device *dev, int *budget) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + long ioaddr, received = 0; + unsigned short intr_status; + + ioaddr = dev->base_addr; + intr_status = inw(ioaddr + SCBStatus); + + if (speedo_debug > 4) + printk(KERN_DEBUG " In speedo_poll().\n"); + + sp->curr_work_limit = *budget; + if (sp->curr_work_limit > dev->quota) + sp->curr_work_limit = dev->quota; + + do { + /* ack Rx & RxNobuf intrs*/ + outw(intr_status & 0x5000, ioaddr + SCBStatus); + + received += speedo_rx(dev); + + if (sp->curr_work_limit < 0) /* out of quota */ + goto not_done; + + /* no packets on ring; but new ones can arrive since we last checked */ + intr_status = inw(ioaddr + SCBStatus); + + if ((intr_status & 0x5000) == 0) { + /* If something arrives in this narrow window,an interrupt + * will be generated + */ + goto done; + } + /* done! at least thats what it looks like ;-> + if new packets came in after our last check on status bits + they'll be caught by the while check and we go back and clear them + since we havent exceeded our quota + */ + } while (intr_status & 0x5000); + +done: + if (!received) { + if (speedo_debug > 4) printk("received==0\n"); + received = 1; + sp->empty_poll++; + } + dev->quota -= received; + *budget -= received; + + /* we are happy/done, no more packets on ring; put us back + * to where we can start processing interrupts again + */ + netif_rx_complete(dev); + enable_rx_and_rxnobuf_ints(dev); + + sp->done_poll++; + + if (speedo_debug > 3) + printk("done,received=%lu\n",received); + + return 0; /* done */ + +not_done: + if (!received) { + if (speedo_debug > 4) printk("received==0\n"); + received = 1; + sp->empty_poll++; + } + dev->quota -= received; + *budget -= received; + + sp->notdone_poll++; + + if (speedo_debug > 3) + printk("not done,received=%lu\n",received); + + return 1; /* not_done */ +} + +#endif /* NAPI */ + static int speedo_rx(struct net_device *dev) { struct speedo_private *sp = (struct speedo_private *)dev->priv; int entry = sp->cur_rx % RX_RING_SIZE; +#ifndef CONFIG_EEPRO100_NAPI int rx_work_limit = sp->dirty_rx + RX_RING_SIZE - sp->cur_rx; +#endif + int received = 0; int alloc_ok = 1; if (speedo_debug > 4) @@ -1725,11 +1910,42 @@ status = le32_to_cpu(sp->rx_ringp[entry]->status); pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff; +#ifndef CONFIG_EEPRO100_NAPI if (!(status & RxComplete)) break; if (--rx_work_limit < 0) break; +#else + if (!(status & RxComplete)) { + int intr_status; + unsigned long ioaddr = dev->base_addr; + + intr_status = inw(ioaddr + SCBStatus); + /* We check receiver state here because if + * we have to do soft reset,sp->cur_rx should + * point to an empty entry or something + * unexpected will happen + */ + if (intr_status | 0x1000) { /* suspended */ + outw(0x5000,ioaddr + SCBStatus); + /* No resources */ + if ((intr_status & 0x3c) == 0x28) { + outw(RxResumeNoResources,ioaddr+SCBCmd); + sp->rx_resume_count++; + }else if ((intr_status & 0x3c) == 0x8) { + if (speedo_debug > 4) + printk("No resource,reset\n"); + speedo_rx_soft_reset(dev); + sp->soft_reset_count++; + } + } + break; + } + + if (--sp->curr_work_limit < 0) + break; +#endif /* Check for a rare out-of-memory case: the current buffer is the last buffer allocated in the RX ring. --SAW */ @@ -1793,7 +2009,12 @@ PKT_BUF_SZ + sizeof(struct RxFD), PCI_DMA_FROMDEVICE); } skb->protocol = eth_type_trans(skb, dev); +#ifndef CONFIG_EEPRO100_NAPI netif_rx(skb); +#else + netif_receive_skb(skb); + received ++; +#endif dev->last_rx = jiffies; sp->stats.rx_packets++; sp->stats.rx_bytes += pkt_len; @@ -1811,7 +2032,7 @@ sp->last_rx_time = jiffies; - return 0; + return received; } static int --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-proc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-proc.patch" --- eepro100-napi.c Wed Jun 12 17:11:38 2002 +++ eepro100-napi-proc.c Wed Jun 12 17:33:51 2002 @@ -119,6 +119,10 @@ #define CONFIG_EEPRO100_NAPI +#ifdef CONFIG_PROC_FS +#include +#endif + MODULE_AUTHOR("Maintainer: Andrey V. Savochkin "); MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver"); MODULE_LICENSE("GPL"); @@ -516,6 +520,10 @@ unsigned long alloc_fail; unsigned long long poll_cycles; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *proc_parent; +#endif + #ifdef CONFIG_NET_FASTROUTE unsigned long fastroute_hit; unsigned long fastroute_success; @@ -582,6 +590,11 @@ static void enable_rx_and_rxnobuf_ints(struct net_device *dev); static void disable_rx_and_rxnobuf_ints(struct net_device *dev); +#ifdef CONFIG_PROC_FS +int __devinit speedo_create_proc_subdir(struct net_device *sp); +void speedo_remove_proc_subdir(struct net_device *sp); +#endif + #endif @@ -883,6 +896,14 @@ #ifdef CONFIG_EEPRO100_NAPI dev->poll = speedo_poll; dev->quota = dev->weight = RX_RING_SIZE; + +#ifdef CONFIG_PROC_FS + if (speedo_create_proc_subdir(dev) < 0) { + printk(KERN_ERR "Failed to create proc directory for %s\n", + dev->name); + } +#endif + #endif return 0; } @@ -1885,6 +1906,354 @@ return 1; /* not_done */ } +#ifdef CONFIG_PROC_FS +/* adapted from intel's e100 code */ +static struct proc_dir_entry *adapters_proc_dir = 0; + +static void speedo_proc_cleanup(void); +static unsigned char speedo_init_proc_dir(void); + +#define ADAPTERS_PROC_DIR "eepro100" +#define WRITE_BUF_MAX_LEN 20 +#define READ_BUF_MAX_LEN 256 +#define SPEEDO_PE_LEN 25 + +#define sp_off(off) (unsigned long)(offsetof(struct speedo_private, off)) + +typedef struct _speedo_proc_entry { + char *name; + read_proc_t *read_proc; + write_proc_t *write_proc; + unsigned long offset; /* offset into sp. ~0 means no value, pass NULL. */ +} speedo_proc_entry; + +static int +generic_read(char *page, char **start, off_t off, int count, int *eof, int len) +{ + if (len <= off + count) + *eof = 1; + + *start = page + off; + len -= off; + if (len > count) + len = count; + + if (len < 0) + len = 0; + + return len; +} + +static int +read_ulong(char *page, char **start, off_t off, + int count, int *eof, unsigned long l) +{ + int len; + + len = sprintf(page, "%lu\n", l); + + return generic_read(page, start, off, count, eof, len); +} + +static int +read_gen_ulong(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + unsigned long val = 0; + + if (data) + val = *((unsigned long *) data); + + return read_ulong(page, start, off, count, eof, val); +} + +static int +read_ulonglong(char *page, char **start, off_t off, + int count, int *eof, unsigned long long ll) +{ + int len; + + len = sprintf(page, "%llu\n", ll); + + return generic_read(page, start, off, count, eof, len); +} + +static int +read_gen_ulonglong(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + unsigned long val = 0; + + if (data) + val = *((unsigned long long *) data); + + return read_ulonglong(page, start, off, count, eof, val); +} + +static int +set_debug(struct file *file, const char *buffer, + unsigned long count, void *data) + +{ + if (speedo_debug == 1) + speedo_debug = 6; + else + speedo_debug = 1; + return count; +} + +static int +_speedo_show_state(struct file *file, const char *buffer, + unsigned long count, void *data) +{ + + struct net_device *dev = (struct net_device *)data; + + speedo_show_state(dev); + + return count; +} + +static speedo_proc_entry speedo_proc_list[] = { + {"set_debug", 0, set_debug, ~0}, + {"show_state", 0, _speedo_show_state, ~0}, + {"poll_switch",read_gen_ulong,0,sp_off(poll_switch)}, + {"failed_poll_switch",read_gen_ulong,0,sp_off(failed_poll_switch)}, + {"done_poll",read_gen_ulong,0,sp_off(done_poll)}, + {"notdone_poll",read_gen_ulong,0,sp_off(notdone_poll)}, + {"empty_poll",read_gen_ulong,0,sp_off(empty_poll)}, + {"soft_reset_count",read_gen_ulong,0,sp_off(soft_reset_count)}, + {"rx_resume_count",read_gen_ulong,0,sp_off(rx_resume_count)}, + {"alloc_fail",read_gen_ulong,0,sp_off(alloc_fail)}, + {"poll_cycles",read_gen_ulonglong,0,sp_off(poll_cycles)}, + {"fastroute_hit",read_gen_ulonglong,0,sp_off(fastroute_hit)}, + {"fastroute_success",read_gen_ulonglong,0,sp_off(fastroute_success)}, + {"fastroute_defer",read_gen_ulonglong,0,sp_off(fastroute_defer)}, + {"", 0, 0, 0} +}; + +static int +read_info(char *page, char **start, off_t off, int count, int *eof, void *data) +{ + struct speedo_private *sp = data; + speedo_proc_entry *pe; + int tmp; + void *val; + int len = 0; + + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') { + len += sprintf(page + len, "\n"); + continue; + } + + if (pe->read_proc) { + if ((len + READ_BUF_MAX_LEN + SPEEDO_PE_LEN + 1) >= + PAGE_SIZE) + break; + + if (pe->offset != ~0) + val = ((char *) sp) + pe->offset; + else + val = NULL; + + len += sprintf(page + len, "%-" + __MODULE_STRING(SPEEDO_PE_LEN) + "s ", pe->name); + len += pe->read_proc(page + len, start, 0, + READ_BUF_MAX_LEN + 1, &tmp, val); + } + } + + return generic_read(page, start, off, count, eof, len); +} + +static struct proc_dir_entry * __devinit +create_proc_rw(char *name, void *data, struct proc_dir_entry *parent, + read_proc_t * read_proc, write_proc_t * write_proc) +{ + struct proc_dir_entry *pdep; + mode_t mode = S_IFREG; + + if (write_proc) { + mode |= S_IWUSR; + if (read_proc) { + mode |= S_IRUSR; + } + + } else if (read_proc) { + mode |= S_IRUGO; + } + + if (!(pdep = create_proc_entry(name, mode, parent))) + return NULL; + + pdep->read_proc = read_proc; + pdep->write_proc = write_proc; + pdep->data = data; + return pdep; +} + +void +speedo_remove_proc_subdir(struct net_device *dev) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + speedo_proc_entry *pe; + char info[256]; + int len; + + /* If our root /proc dir was not created, there is nothing to remove */ + if (adapters_proc_dir == NULL) { + return; + } + + len = strlen(dev->name); + strncpy(info, dev->name, sizeof (info)); + strncat(info + len, ".info", sizeof (info) - len); + + if (sp->proc_parent) { + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') + continue; + + remove_proc_entry(pe->name, sp->proc_parent); + } + + remove_proc_entry(dev->name, adapters_proc_dir); + sp->proc_parent = NULL; + } + + remove_proc_entry(info, adapters_proc_dir); + + /* try to remove the main /proc dir, if it's empty */ + speedo_proc_cleanup(); +} + +int __devinit +speedo_create_proc_subdir(struct net_device *dev) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + struct proc_dir_entry *dev_dir; + speedo_proc_entry *pe; + char info[256]; + int len; + void *data; + + /* create the main /proc dir if needed */ + if (!adapters_proc_dir) { + if (!speedo_init_proc_dir()) + return -ENOMEM; + } + + strncpy(info, dev->name, sizeof (info)); + len = strlen(info); + strncat(info + len, ".info", sizeof (info) - len); + + /* info */ + if (!(create_proc_rw(info, sp, adapters_proc_dir, read_info, 0))) { + speedo_proc_cleanup(); + return -ENOMEM; + } + + dev_dir = create_proc_entry(dev->name, S_IFDIR, + adapters_proc_dir); + sp->proc_parent = dev_dir; + + if (!dev_dir) { + speedo_remove_proc_subdir(dev); + return -ENOMEM; + } + + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') + continue; + + if (pe->offset != ~0) + data = ((char *) sp) + pe->offset; + else + data = dev; + + if (!(create_proc_rw(pe->name, data, dev_dir, + pe->read_proc, pe->write_proc))) { + speedo_remove_proc_subdir(dev); + return -ENOMEM; + } + } + + return 0; +} + +/**************************************************************************** + * Name: speedo_init_proc_dir + * + * Description: This routine creates the top-level /proc directory for the + * driver in /proc/net + * + * Arguments: none + * + * Returns: true on success, false on fail + * + ***************************************************************************/ +static unsigned char +speedo_init_proc_dir(void) +{ + int len; + + /* first check if adapters_proc_dir already exists */ + len = strlen(ADAPTERS_PROC_DIR); + for (adapters_proc_dir = proc_net->subdir; + adapters_proc_dir; adapters_proc_dir = adapters_proc_dir->next) { + + if ((adapters_proc_dir->namelen == len) && + (!memcmp(adapters_proc_dir->name, ADAPTERS_PROC_DIR, len))) + break; + } + + if (!adapters_proc_dir) + adapters_proc_dir = + create_proc_entry(ADAPTERS_PROC_DIR, S_IFDIR, proc_net); + + if (!adapters_proc_dir) + return 0; + + return 1; +} + +/**************************************************************************** + * Name: speedo_proc_cleanup + * + * Description: This routine clears the top-level /proc directory, if empty. + * + * Arguments: none + * + * Returns: none + * + ***************************************************************************/ +static void +speedo_proc_cleanup(void) +{ + struct proc_dir_entry *de; + + if (adapters_proc_dir == NULL) { + return; + } + + /* check if subdir list is empty before removing adapters_proc_dir */ + for (de = adapters_proc_dir->subdir; de; de = de->next) { + /* ignore . and .. */ + if (*(de->name) != '.') + break; + } + + if (de) + return; + + remove_proc_entry(ADAPTERS_PROC_DIR, proc_net); + adapters_proc_dir = NULL; +} + +#endif /* CONFIG_PROC_FS */ + #endif /* NAPI */ static int @@ -2474,6 +2843,9 @@ unregister_netdev(dev); +#if defined(CONFIG_EEPRO100_NAPI) && defined(CONFIG_PROC_FS) + speedo_remove_proc_subdir(dev); +#endif release_region(pci_resource_start(pdev, 1), pci_resource_len(pdev, 1)); release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0)); --------------070502030508090306010005-- From owner-linux-mips@oss.sgi.com Wed Jun 12 16:01: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 g5CN15nC017347 for ; Wed, 12 Jun 2002 16:01:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CN15ur017346 for linux-mips-outgoing; Wed, 12 Jun 2002 16:01:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CN10nC017311; Wed, 12 Jun 2002 16:01:00 -0700 Received: from adsl-17-114-120.asm.bellsouth.net ([68.17.114.120] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17IH98-0004BT-00; Thu, 13 Jun 2002 00:03:22 +0100 Message-ID: <3D07D270.5060902@mandrakesoft.com> Date: Wed, 12 Jun 2002 19:00:00 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zhang Fuxin CC: linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 989 Lines: 30 Zhang Fuxin wrote: > hi,all > Recently i've converted eepro100 driver to use napi,in order to improve > network performance of my poor 150M mips machine. It does eliminate > the interrupt live lock seen before,maintaining a peak throughput under > heavy load. > In case anybody are interested,i post the patches to the list. They are > 3 incremental patchs: > eepro100-napi.patch is against 2.5.20 eepro100.c and provide basic > napi support Nifty, I'll take a look at this. > eepro100-proc.patch is proc file system support adapted from intel's > e100 driver. I am using it for debugging. > eepro100-mips.patch is mips specific patch to make it work(well) for > my mips > platform. Just FWIW I'm not gonna apply these... for the 'proc' patch, that either needs to be moved to ethtool, or we should make a filesystem for net drivers that exports procfs-like inodes. for the 'mips' patch, it looks like the arch maintainer(s) need to fix the PCI DMA support... Jeff From owner-linux-mips@oss.sgi.com Wed Jun 12 16:07: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 g5CN7WnC017724 for ; Wed, 12 Jun 2002 16:07:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CN7WAm017723 for linux-mips-outgoing; Wed, 12 Jun 2002 16:07:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CN7SnC017712; Wed, 12 Jun 2002 16:07:28 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA32547; Wed, 12 Jun 2002 16:05:32 -0700 Date: Wed, 12 Jun 2002 16:05:32 -0700 (PDT) Message-Id: <20020612.160532.134201977.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <3D07D270.5060902@mandrakesoft.com> References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 352 Lines: 12 From: Jeff Garzik Date: Wed, 12 Jun 2002 19:00:00 -0400 for the 'mips' patch, it looks like the arch maintainer(s) need to fix the PCI DMA support... No, it's worse than that. See how non-consistent memory is used by the eepro100 driver for descriptor bits? The skb->tail bits? That is very problematic. From owner-linux-mips@oss.sgi.com Wed Jun 12 16:18: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 g5CNIrnC017957 for ; Wed, 12 Jun 2002 16:18:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CNIrTM017956 for linux-mips-outgoing; Wed, 12 Jun 2002 16:18:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CNImnC017953; Wed, 12 Jun 2002 16:18:49 -0700 Received: from adsl-17-114-120.asm.bellsouth.net ([68.17.114.120] helo=mandrakesoft.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17IHQT-0004V8-00; Thu, 13 Jun 2002 00:21:17 +0100 Message-ID: <3D07D6A6.7090308@mandrakesoft.com> Date: Wed, 12 Jun 2002 19:17:58 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 824 Lines: 28 David S. Miller wrote: > From: Jeff Garzik > Date: Wed, 12 Jun 2002 19:00:00 -0400 > > for the 'mips' patch, it looks > like the arch maintainer(s) need to fix the PCI DMA support... > > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. Oh crap, you're right... eepro100 in general does funky stuff with the way packets are handled, mainly due to the need to issue commands to the NIC engine instead of the normal per-descriptor owner bit way of doing things. Well, I accept patches to that clean eepro100 up... I'm not terribly motivated to clean it up myself, as we have e100 and an e100 maintainer we can beat on if such uglies arise :) Jeff From owner-linux-mips@oss.sgi.com Wed Jun 12 16:35: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 g5CNZhnC018210 for ; Wed, 12 Jun 2002 16:35:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CNZhG3018209 for linux-mips-outgoing; Wed, 12 Jun 2002 16:35:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CNZdnC018197; Wed, 12 Jun 2002 16:35:39 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA00328; Wed, 12 Jun 2002 16:33:44 -0700 Date: Wed, 12 Jun 2002 16:33:44 -0700 (PDT) Message-Id: <20020612.163344.31410429.davem@redhat.com> To: jgarzik@mandrakesoft.com Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <3D07D6A6.7090308@mandrakesoft.com> References: <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> <3D07D6A6.7090308@mandrakesoft.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 453 Lines: 10 From: Jeff Garzik Date: Wed, 12 Jun 2002 19:17:58 -0400 Oh crap, you're right... eepro100 in general does funky stuff with the way packets are handled, mainly due to the need to issue commands to the NIC engine instead of the normal per-descriptor owner bit way of doing things. The question is, do the descriptor bits have to live right before the RX packet data buffer or can other schemes be used? From owner-linux-mips@oss.sgi.com Wed Jun 12 19:23: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 g5D2NDnC019935 for ; Wed, 12 Jun 2002 19:23:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D2NCCQ019934 for linux-mips-outgoing; Wed, 12 Jun 2002 19:23:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (dsl093-054-208.blt1.dsl.speakeasy.net [66.93.54.208]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D2N3nC019922; Wed, 12 Jun 2002 19:23:04 -0700 Received: from localhost (becker@localhost) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id WAA01410; Wed, 12 Jun 2002 22:25:22 -0400 Date: Wed, 12 Jun 2002 22:25:22 -0400 (EDT) From: Donald Becker X-X-Sender: To: "David S. Miller" cc: Jeff Garzik , , Linux Kernel Mailing List , Subject: Re: NAPI for eepro100 In-Reply-To: <20020612.163344.31410429.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1049 Lines: 25 On Wed, 12 Jun 2002, David S. Miller wrote: > From: Jeff Garzik > Oh crap, you're right... eepro100 in general does funky stuff with the > way packets are handled, mainly due to the need to issue commands to the > NIC engine instead of the normal per-descriptor owner bit way of doing > things. The eepro100 has a unique design in many different aspects. > The question is, do the descriptor bits have to live right before > the RX packet data buffer or can other schemes be used? With the current driver structure, yes, the descriptor words must be immediately before the packet data. You can use other Rx and Tx structures/modes to avoid this, but they use less efficient memory access. For instance, the current Tx structure allows transmitting a packet with a single PCI burst, rather than multiple transfers. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From owner-linux-mips@oss.sgi.com Thu Jun 13 00:17: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 g5D7HWnC023699 for ; Thu, 13 Jun 2002 00:17:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D7HWI4023698 for linux-mips-outgoing; Thu, 13 Jun 2002 00:17:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from 127.0.0.1 (chello080109133020.tirol.surfer.at [80.109.133.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D7HSnC023693 for ; Thu, 13 Jun 2002 00:17:28 -0700 Message-Id: <200206130717.g5D7HSnC023693@oss.sgi.com> From: xcd4u@yahoo.de To: Cc: Subject: Falls du Kinder hast - wichtig! Gegen Gewalt am Computer! Date: Donnerstag, 13 Juni 2002 06:03:33 0100 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-GCMulti: 1 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 827 Lines: 14 Hi du! Hab noch irgendwo am Computer deine Mailadresse gefunden. Will dir auch nicht weiter deine Zeit stehlen - wollte dich nur auf eine, wie ich finde, wichtige Initiative aufmerksam machen: http://www.netkids.info - gegen Gewalt im Internet Kostet nichts - außer ein bißchen Zeit - hilft aber ungemein falls man Kinder im Haushalt hat die am Computer surfen oder spielen. Mit diesem Gratisvideo ist es mir unglaublich leicht gefallen den Computer meiner Kinder so einzurichten daß sie wirklich nur Seiten sehen die für Sie geeignet sind. Außerdem weiß ich jetzt endlich welche Spiele sie spielen - und ob die auch schon wirklich für ihr Alter gedacht sind! Das wars auch schon - außer vielleicht - wenn du jemanden kennst der auch Kinder hat - schick ihm doch bitte das Mail weiter. Schöne Grüße aus Salzburg Paula From owner-linux-mips@oss.sgi.com Thu Jun 13 01:11: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 g5D8BHnC024481 for ; Thu, 13 Jun 2002 01:11:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8BHq9024480 for linux-mips-outgoing; Thu, 13 Jun 2002 01:11:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from msr.hinet.net (msr96.hinet.net [168.95.4.196]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8AunC024476 for ; Thu, 13 Jun 2002 01:10:57 -0700 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id QAA05012 for ; Thu, 13 Jun 2002 16:13:26 +0800 (CST) Message-ID: <004801c212b2$295c7900$780411ac@sam> From: "Sam" To: Subject: # ld.script syntax Date: Thu, 13 Jun 2002 16:13:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Content-Length: 4506 Lines: 166 Hi everybody, I try to find the relation about the setup of ramdisk initrd >From the sample of Philp Nino, I found the ld.script.in on /arch/mips/ But I do not understand the syntax of ld script, Does anybody tell me where to find the relevent document to understand the file, thanks all, --Sam ==== OUTPUT_ARCH(mips) ENTRY(kernel_entry) SECTIONS { /* Read-only sections, merged into text segment: */ . = @@LOADADDR@@; .init : { *(.init) } =0 .text : { _ftext = . ; *(.text) *(.rodata) *(.rodata1) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) } =0 .kstrtab : { *(.kstrtab) } . = ALIGN(16); /* Exception table */ __start___ex_table = .; __ex_table : { *(__ex_table) } __stop___ex_table = .; __start___dbe_table = .; /* Exception table for data bus errors */ __dbe_table : { *(__dbe_table) } __stop___dbe_table = .; __start___ksymtab = .; /* Kernel symbol table */ __ksymtab : { *(__ksymtab) } __stop___ksymtab = .; _etext = .; . = ALIGN(8192); .data.init_task : { *(.data.init_task) } /* Startup code */ . = ALIGN(4096); __init_begin = .; .text.init : { *(.text.init) } .data.init : { *(.data.init) } . = ALIGN(16); __setup_start = .; .setup.init : { *(.setup.init) } __setup_end = .; __initcall_start = .; .initcall.init : { *(.initcall.init) } __initcall_end = .; . = ALIGN(4096); /* Align double page for init_task_union */ __init_end = .; . = ALIGN(4096); .data.page_aligned : { *(.data.idt) } . = ALIGN(32); .data.cacheline_aligned : { *(.data.cacheline_aligned) } .fini : { *(.fini) } =0 .reginfo : { *(.reginfo) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. It would be more correct to do this: . = .; The current expression does not correctly handle the case of a text segment ending precisely at the end of a page; it causes the data segment to skip a page. The above expression does not have this problem, but it will currently (2/95) cause BFD to allocate a single segment, combining both text and data, for this case. This will prevent the text segment from being shared among multiple executions of the program; I think that is more important than losing a page of the virtual address space (note that no actual memory is lost; the page which is skipped can not be referenced). */ . = .; .data : { _fdata = . ; *(.data) /* Align the initial ramdisk image (INITRD) on page boundaries. */ . = ALIGN(4096); __rd_start = .; *(.initrd) __rd_end = .; . = ALIGN(4096); CONSTRUCTORS } .data1 : { *(.data1) } _gp = . + 0x8000; .lit8 : { *(.lit8) } .lit4 : { *(.lit4) } .ctors : { *(.ctors) } .dtors : { *(.dtors) } .got : { *(.got.plt) *(.got) } .dynamic : { *(.dynamic) } /* We want the small data sections together, so single-instruction offsets can access them all, and initialized data all before uninitialized, so we can shorten the on-disk segment size. */ .sdata : { *(.sdata) } . = ALIGN(4); _edata = .; PROVIDE (edata = .); __bss_start = .; _fbss = .; .sbss : { *(.sbss) *(.scommon) } .bss : { *(.dynbss) *(.bss) *(COMMON) . = ALIGN(4); _end = . ; PROVIDE (end = .); } /* Sections to be discarded */ /DISCARD/ : { *(.text.exit) *(.data.exit) *(.exitcall.exit) } /* This is the MIPS specific mdebug section. */ .mdebug : { *(.mdebug) } /* These are needed for ELF backends which have not yet been converted to the new style linker. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } /* DWARF debug sections. Symbols in the .debug DWARF section are relative to the beginning of the section so we begin .debug at 0. It's not clear yet what needs to happen for the others. */ .debug 0 : { *(.debug) } .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } .debug_sfnames 0 : { *(.debug_sfnames) } .line 0 : { *(.line) } /* These must appear regardless of . */ .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } .gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) } .comment : { *(.comment) } .note : { *(.note) } } ==== From owner-linux-mips@oss.sgi.com Thu Jun 13 01:26: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 g5D8Q0nC024673 for ; Thu, 13 Jun 2002 01:26:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8Q0D9024672 for linux-mips-outgoing; Thu, 13 Jun 2002 01:26:00 -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 g5D8PvnC024669 for ; Thu, 13 Jun 2002 01:25:57 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) 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 ESMTP id BAA03216 for ; Thu, 13 Jun 2002 01:28:27 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g5D8RPEd9956954; Thu, 13 Jun 2002 01:27:26 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 751673000BA; Thu, 13 Jun 2002 18:27:24 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 6714D94; Thu, 13 Jun 2002 18:27:24 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Sam" Cc: linux-mips@oss.sgi.com Subject: Re: # ld.script syntax In-reply-to: Your message of "Thu, 13 Jun 2002 16:13:11 +0800." <004801c212b2$295c7900$780411ac@sam> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 18:27:19 +1000 Message-ID: <4102.1023956839@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 369 Lines: 10 On Thu, 13 Jun 2002 16:13:11 +0800, "Sam" wrote: >I try to find the relation about the setup of ramdisk initrd >From the sample of Philp Nino, I found the ld.script.in on /arch/mips/ >But I do not understand the syntax of ld script, >Does anybody tell me where to find the relevent document to understand the >file, info ld, option 'Scripts'. From owner-linux-mips@oss.sgi.com Thu Jun 13 01:27: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 g5D8RLnC024739 for ; Thu, 13 Jun 2002 01:27:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8RLlj024738 for linux-mips-outgoing; Thu, 13 Jun 2002 01:27:21 -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 g5D8RInC024735 for ; Thu, 13 Jun 2002 01:27:19 -0700 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 614F08D40; Thu, 13 Jun 2002 10:29:49 +0200 (CEST) Date: Thu, 13 Jun 2002 10:29:49 +0200 From: Guido Guenther To: Sam Cc: linux-mips@oss.sgi.com Subject: Re: # ld.script syntax Message-ID: <20020613102949.A21623@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Sam , linux-mips@oss.sgi.com References: <004801c212b2$295c7900$780411ac@sam> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004801c212b2$295c7900$780411ac@sam>; from iskoo@ms45.hinet.net on Thu, Jun 13, 2002 at 04:13:11PM +0800 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 406 Lines: 11 On Thu, Jun 13, 2002 at 04:13:11PM +0800, Sam wrote: > Hi everybody, > > I try to find the relation about the setup of ramdisk initrd > >From the sample of Philp Nino, I found the ld.script.in on /arch/mips/ > But I do not understand the syntax of ld script, > Does anybody tell me where to find the relevent document to understand the > file, "info ld". See section "Scripts". Hope this helps, -- Guido From owner-linux-mips@oss.sgi.com Thu Jun 13 01:45: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 g5D8jsnC025168 for ; Thu, 13 Jun 2002 01:45:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8jsOo025167 for linux-mips-outgoing; Thu, 13 Jun 2002 01:45:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from castle.nmd.msu.ru (castle.nmd.msu.ru [193.232.112.53]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8jonC025153 for ; Thu, 13 Jun 2002 01:45:51 -0700 Received: (qmail 23773 invoked by uid 577); 13 Jun 2002 08:57:53 -0000 Message-ID: <20020613125753.A23693@castle.nmd.msu.ru> Date: Thu, 13 Jun 2002 12:57:53 +0400 From: Andrey Savochkin To: "David S. Miller" Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: NAPI for eepro100 References: <3D0740ED.2060907@ict.ac.cn> <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20020612.160532.134201977.davem@redhat.com>; from "David S. Miller" on Wed, Jun 12, 2002 at 04:05:32PM Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 558 Lines: 19 On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote: > From: Jeff Garzik > Date: Wed, 12 Jun 2002 19:00:00 -0400 > > for the 'mips' patch, it looks > like the arch maintainer(s) need to fix the PCI DMA support... > > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. What's the problem? If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL mappings? Andrey From owner-linux-mips@oss.sgi.com Thu Jun 13 01:49: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 g5D8n4nC025387 for ; Thu, 13 Jun 2002 01:49:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8n4XA025386 for linux-mips-outgoing; Thu, 13 Jun 2002 01:49:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8mvnC025363; Thu, 13 Jun 2002 01:48:57 -0700 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id BAA03164; Thu, 13 Jun 2002 01:47:00 -0700 Date: Thu, 13 Jun 2002 01:47:00 -0700 (PDT) Message-Id: <20020613.014700.26430433.davem@redhat.com> To: saw@saw.sw.com.sg Cc: fxzhang@ict.ac.cn, linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@mandrakesoft.com Subject: Re: NAPI for eepro100 From: "David S. Miller" In-Reply-To: <20020613125753.A23693@castle.nmd.msu.ru> References: <3D07D270.5060902@mandrakesoft.com> <20020612.160532.134201977.davem@redhat.com> <20020613125753.A23693@castle.nmd.msu.ru> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 796 Lines: 22 From: Andrey Savochkin Date: Thu, 13 Jun 2002 12:57:53 +0400 On Wed, Jun 12, 2002 at 04:05:32PM -0700, David S. Miller wrote: > No, it's worse than that. > > See how non-consistent memory is used by the eepro100 driver > for descriptor bits? The skb->tail bits? > > That is very problematic. What's the problem? If it isn't allowed to do, then what is the meaning of PCI_DMA_BIDIRECTIONAL mappings? It's slow. Not wrong, just inefficient. Descriptors were meant to be done using consistent mappings, not "pci_map_*()"'d memory. The latter is meant to be used for long linear DMA transfers to/from the device. It is not meant for things the cpu pokes small bits of data in and out of, that is what consistent DMA memory is for. From owner-linux-mips@oss.sgi.com Thu Jun 13 05:36: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 g5DCaYnC007995 for ; Thu, 13 Jun 2002 05:36:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DCaY2X007994 for linux-mips-outgoing; Thu, 13 Jun 2002 05:36:34 -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 g5DCYfnC007980 for ; Thu, 13 Jun 2002 05:34:41 -0700 Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) 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 CAA08760 for ; Thu, 13 Jun 2002 02:47:35 -0700 (PDT) mail_from (fxzhang@ict.ac.cn) Received: from mail pickup service by mail5.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 05:46:34 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 12 Jun 2002 08:44:34 -0400 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5CCiWbK010834 for ; Wed, 12 Jun 2002 08:44:33 -0400 (EDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 12 Jun 2002 08:41:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 12 Jun 2002 08:41:33 -0400 Received: from [159.226.39.4] ([159.226.39.4]:38329 "HELO mail.ict.ac.cn") by vger.kernel.org with SMTP id ; Wed, 12 Jun 2002 08:41:18 -0400 Received: (qmail 9126 invoked from network); 12 Jun 2002 12:29:27 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.150) by 159.226.39.4 with SMTP; 12 Jun 2002 12:29:27 -0000 Message-ID: <3D0740ED.2060907@ict.ac.cn> Date: Wed, 12 Jun 2002 20:39:09 +0800 From: Zhang Fuxin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com, saw@saw.sw.com.sg, linux-kernel@vger.kernel.org Subject: NAPI for eepro100 Content-Type: multipart/mixed; boundary="------------070502030508090306010005" X-Mailing-List: linux-kernel@vger.kernel.org Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 25224 Lines: 958 This is a multi-part message in MIME format. --------------070502030508090306010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi,all Recently i've converted eepro100 driver to use napi,in order to improve network performance of my poor 150M mips machine. It does eliminate the interrupt live lock seen before,maintaining a peak throughput under heavy load. In case anybody are interested,i post the patches to the list. They are 3 incremental patchs: eepro100-napi.patch is against 2.5.20 eepro100.c and provide basic napi support eepro100-proc.patch is proc file system support adapted from intel's e100 driver. I am using it for debugging. eepro100-mips.patch is mips specific patch to make it work(well) for my mips platform. (i suppose people use: patch eepro100.c < x.patch to apply patch) Tests are mainly done on my mips machine for 2.4 kernel,though i think it should work for at least x86 on which minimal test is performed. Be careful. A little pitty is that to achieve good performance under heavy load, the /proc/sys/net/core/netdev_max_backlog value may need to be adjusted. Feedbacks are always welcome:). But i am not on linux-kernel list,so people there please CC me. --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-mips.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-mips.patch" --- eepro100-napi-proc.c Wed Jun 12 17:33:51 2002 +++ eepro100-mips.c Wed Jun 12 19:22:29 2002 @@ -45,7 +45,7 @@ /* Set the copy breakpoint for the copy-only-tiny-buffer Rx method. Lower values use more memory, but are faster. */ -#if defined(__alpha__) || defined(__sparc__) || defined(__mips__) || \ +#if defined(__alpha__) || defined(__sparc__) || /*defined(__mips__) ||*/ \ defined(__arm__) static int rx_copybreak = 1518; #else @@ -66,8 +66,8 @@ /* A few values that may be tweaked. */ /* The ring sizes should be a power of two for efficiency. */ -#define TX_RING_SIZE 64 -#define RX_RING_SIZE 64 +#define TX_RING_SIZE 32 +#define RX_RING_SIZE 32 /* How much slots multicast filter setup may take. Do not descrease without changing set_rx_mode() implementaion. */ #define TX_MULTICAST_SIZE 2 @@ -1298,7 +1298,14 @@ if (skb == NULL) break; /* OK. Just initially short of Rx bufs. */ skb->dev = dev; /* Mark as being used by this device. */ +#ifndef __mips__ rxf = (struct RxFD *)skb->tail; +#else + /* use uncached address,use pci_dma_sync_xx seems + * problematic in my mips platform + */ + rxf = (struct RxFD *)(KSEG1ADDR(skb->tail)); +#endif sp->rx_ringp[i] = rxf; sp->rx_ring_dma[i] = pci_map_single(sp->pdev, rxf, @@ -1306,8 +1313,10 @@ skb_reserve(skb, sizeof(struct RxFD)); if (last_rxf) { last_rxf->link = cpu_to_le32(sp->rx_ring_dma[i]); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, last_rxf_dma, sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif } last_rxf = rxf; last_rxf_dma = sp->rx_ring_dma[i]; @@ -1316,14 +1325,18 @@ /* This field unused by i82557. */ rxf->rx_buf_addr = 0xffffffff; rxf->count = cpu_to_le32(PKT_BUF_SZ << 16); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[i], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif } sp->dirty_rx = (unsigned int)(i - RX_RING_SIZE); /* Mark the last entry as end-of-list. */ last_rxf->status = cpu_to_le32(0xC0000002); /* '2' is flag value only. */ +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[RX_RING_SIZE-1], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif sp->last_rxf = last_rxf; sp->last_rxf_dma = last_rxf_dma; } @@ -1733,15 +1746,21 @@ #endif return NULL; } +#ifndef __mips__ rxf = sp->rx_ringp[entry] = (struct RxFD *)skb->tail; +#else + rxf = sp->rx_ringp[entry] = (struct RxFD *)(KSEG1ADDR(skb->tail)); +#endif sp->rx_ring_dma[entry] = pci_map_single(sp->pdev, rxf, PKT_BUF_SZ + sizeof(struct RxFD), PCI_DMA_FROMDEVICE); skb->dev = dev; skb_reserve(skb, sizeof(struct RxFD)); rxf->rx_buf_addr = 0xffffffff; +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[entry], sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif return rxf; } @@ -1754,8 +1773,10 @@ rxf->count = cpu_to_le32(PKT_BUF_SZ << 16); sp->last_rxf->link = cpu_to_le32(rxf_dma); sp->last_rxf->status &= cpu_to_le32(~0xC0000000); +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->last_rxf_dma, sizeof(struct RxFD), PCI_DMA_TODEVICE); +#endif sp->last_rxf = rxf; sp->last_rxf_dma = rxf_dma; } @@ -2274,8 +2295,10 @@ int status; int pkt_len; +#ifndef __mips__ pci_dma_sync_single(sp->pdev, sp->rx_ring_dma[entry], sizeof(struct RxFD), PCI_DMA_FROMDEVICE); +#endif status = le32_to_cpu(sp->rx_ringp[entry]->status); pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff; --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-napi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-napi.patch" --- eepro100.c.ori Wed Jun 12 17:25:28 2002 +++ eepro100-napi.c Wed Jun 12 17:11:38 2002 @@ -25,6 +25,8 @@ Disabled FC and ER, to avoid lockups when when we get FCP interrupts. 2000 Jul 17 Goutham Rao PCI DMA API fixes, adding pci_dma_sync_single calls where neccesary + 2002 Jun 12 Zhang Fuxin + add NAPI support */ static const char *version = @@ -115,6 +117,8 @@ #include #include +#define CONFIG_EEPRO100_NAPI + MODULE_AUTHOR("Maintainer: Andrey V. Savochkin "); MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver"); MODULE_LICENSE("GPL"); @@ -494,8 +498,34 @@ #ifdef CONFIG_PM u32 pm_state[16]; #endif + + /* added by zfx for NAPI*/ +#ifdef CONFIG_EEPRO100_NAPI + + /* used to pass rx_work_limit into speedo_rx,i don't want to + * change its prototype + */ + int curr_work_limit; + unsigned long poll_switch; + unsigned long failed_poll_switch; + unsigned long done_poll; + unsigned long notdone_poll; + unsigned long empty_poll; + unsigned long soft_reset_count; + unsigned long rx_resume_count; + unsigned long alloc_fail; + unsigned long long poll_cycles; + +#ifdef CONFIG_NET_FASTROUTE + unsigned long fastroute_hit; + unsigned long fastroute_success; + unsigned long fastroute_defer; +#endif + +#endif }; + /* The parameters for a CmdConfigure operation. There are so many options that it would be difficult to document each bit. We mostly use the default or recommended settings. */ @@ -546,6 +576,14 @@ static void set_rx_mode(struct net_device *dev); static void speedo_show_state(struct net_device *dev); +#ifdef CONFIG_EEPRO100_NAPI + +static int speedo_poll (struct net_device *dev, int *budget); +static void enable_rx_and_rxnobuf_ints(struct net_device *dev); +static void disable_rx_and_rxnobuf_ints(struct net_device *dev); + +#endif + #ifdef honor_default_port @@ -842,6 +880,10 @@ dev->set_multicast_list = &set_rx_mode; dev->do_ioctl = &speedo_ioctl; +#ifdef CONFIG_EEPRO100_NAPI + dev->poll = speedo_poll; + dev->quota = dev->weight = RX_RING_SIZE; +#endif return 0; } @@ -1517,6 +1559,9 @@ struct speedo_private *sp; long ioaddr, boguscnt = max_interrupt_work; unsigned short status; +#ifdef CONFIG_EEPRO100_NAPI + int first = 1; +#endif #ifndef final_version if (dev == NULL) { @@ -1543,16 +1588,21 @@ /* Acknowledge all of the current interrupt sources ASAP. */ /* Will change from 0xfc00 to 0xff00 when we start handling FCP and ER interrupts --Dragan */ +#ifndef CONFIG_EEPRO100_NAPI outw(status & 0xfc00, ioaddr + SCBStatus); +#else + /* Rx & RxNoBuf is acked in speedo_poll */ + outw(status & 0xac00, ioaddr + SCBStatus); +#endif if (speedo_debug > 4) printk(KERN_DEBUG "%s: interrupt status=%#4.4x.\n", dev->name, status); +#ifndef CONFIG_EEPRO100_NAPI if ((status & 0xfc00) == 0) break; - if ((status & 0x5000) || /* Packet received, or Rx error. */ (sp->rx_ring_state&(RrNoMem|RrPostponed)) == RrPostponed) /* Need to gather the postponed packet. */ @@ -1560,8 +1610,33 @@ /* Always check if all rx buffers are allocated. --SAW */ speedo_refill_rx_buffers(dev, 0); +#else + /* Packet received, or Rx error. */ + if (first && ((status & 0x5000) || (sp->rx_ring_state&(RrNoMem|RrPostponed)) == RrPostponed || (status & 0x3c) != 0x10 )) + /* Need to gather the postponed packet. */ + { + if (speedo_debug > 4) + printk("switching to poll,status=%x\n",status); + first = 0; + if (netif_rx_schedule_prep(dev)) { + sp->poll_switch++; + /* disable interrupts caused by arriving packets */ + disable_rx_and_rxnobuf_ints(dev); + /* tell system we have work to be done. */ + __netif_rx_schedule(dev); + }else { + sp->failed_poll_switch++; + } + + } + + if ((status & 0xac00) == 0) + break; +#endif spin_lock(&sp->lock); + +#ifndef CONFIG_EEPRO100_NAPI /* * The chip may have suspended reception for various reasons. * Check for that, and re-prime it should this be the case. @@ -1581,7 +1656,7 @@ /* these are all reserved values */ break; } - +#endif /* User interrupt, Command/Tx unit interrupt or CU not active. */ if (status & 0xA400) { @@ -1602,7 +1677,12 @@ /* Clear all interrupt sources. */ /* Will change from 0xfc00 to 0xff00 when we start handling FCP and ER interrupts --Dragan */ +#ifndef CONFIG_EEPRO100_NAPI outw(0xfc00, ioaddr + SCBStatus); +#else + outw(0xac00, ioaddr + SCBStatus); +#endif + break; } } while (1); @@ -1611,7 +1691,9 @@ printk(KERN_DEBUG "%s: exiting interrupt, status=%#4.4x.\n", dev->name, inw(ioaddr + SCBStatus)); +#ifndef final_version clear_bit(0, (void*)&sp->in_interrupt); +#endif return; } @@ -1625,6 +1707,9 @@ sp->rx_skbuff[entry] = skb; if (skb == NULL) { sp->rx_ringp[entry] = NULL; +#ifdef CONFIG_EEPRO100_NAPI + sp->alloc_fail++; +#endif return NULL; } rxf = sp->rx_ringp[entry] = (struct RxFD *)skb->tail; @@ -1705,12 +1790,112 @@ speedo_refill_rx_buf(dev, force) != -1); } +#ifdef CONFIG_EEPRO100_NAPI +static void enable_rx_and_rxnobuf_ints(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + outw(SCBMaskEarlyRx | SCBMaskFlowCtl, ioaddr + SCBCmd); + inw(ioaddr + SCBStatus); /* flushes last write, read-safe */ +}; + +static void disable_rx_and_rxnobuf_ints(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + outw(SCBMaskRxDone | SCBMaskRxSuspend | SCBMaskEarlyRx | SCBMaskFlowCtl, ioaddr + SCBCmd); + inw(ioaddr + SCBStatus); /* flushes last write, read-safe */ +}; + +static int speedo_poll (struct net_device *dev, int *budget) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + long ioaddr, received = 0; + unsigned short intr_status; + + ioaddr = dev->base_addr; + intr_status = inw(ioaddr + SCBStatus); + + if (speedo_debug > 4) + printk(KERN_DEBUG " In speedo_poll().\n"); + + sp->curr_work_limit = *budget; + if (sp->curr_work_limit > dev->quota) + sp->curr_work_limit = dev->quota; + + do { + /* ack Rx & RxNobuf intrs*/ + outw(intr_status & 0x5000, ioaddr + SCBStatus); + + received += speedo_rx(dev); + + if (sp->curr_work_limit < 0) /* out of quota */ + goto not_done; + + /* no packets on ring; but new ones can arrive since we last checked */ + intr_status = inw(ioaddr + SCBStatus); + + if ((intr_status & 0x5000) == 0) { + /* If something arrives in this narrow window,an interrupt + * will be generated + */ + goto done; + } + /* done! at least thats what it looks like ;-> + if new packets came in after our last check on status bits + they'll be caught by the while check and we go back and clear them + since we havent exceeded our quota + */ + } while (intr_status & 0x5000); + +done: + if (!received) { + if (speedo_debug > 4) printk("received==0\n"); + received = 1; + sp->empty_poll++; + } + dev->quota -= received; + *budget -= received; + + /* we are happy/done, no more packets on ring; put us back + * to where we can start processing interrupts again + */ + netif_rx_complete(dev); + enable_rx_and_rxnobuf_ints(dev); + + sp->done_poll++; + + if (speedo_debug > 3) + printk("done,received=%lu\n",received); + + return 0; /* done */ + +not_done: + if (!received) { + if (speedo_debug > 4) printk("received==0\n"); + received = 1; + sp->empty_poll++; + } + dev->quota -= received; + *budget -= received; + + sp->notdone_poll++; + + if (speedo_debug > 3) + printk("not done,received=%lu\n",received); + + return 1; /* not_done */ +} + +#endif /* NAPI */ + static int speedo_rx(struct net_device *dev) { struct speedo_private *sp = (struct speedo_private *)dev->priv; int entry = sp->cur_rx % RX_RING_SIZE; +#ifndef CONFIG_EEPRO100_NAPI int rx_work_limit = sp->dirty_rx + RX_RING_SIZE - sp->cur_rx; +#endif + int received = 0; int alloc_ok = 1; if (speedo_debug > 4) @@ -1725,11 +1910,42 @@ status = le32_to_cpu(sp->rx_ringp[entry]->status); pkt_len = le32_to_cpu(sp->rx_ringp[entry]->count) & 0x3fff; +#ifndef CONFIG_EEPRO100_NAPI if (!(status & RxComplete)) break; if (--rx_work_limit < 0) break; +#else + if (!(status & RxComplete)) { + int intr_status; + unsigned long ioaddr = dev->base_addr; + + intr_status = inw(ioaddr + SCBStatus); + /* We check receiver state here because if + * we have to do soft reset,sp->cur_rx should + * point to an empty entry or something + * unexpected will happen + */ + if (intr_status | 0x1000) { /* suspended */ + outw(0x5000,ioaddr + SCBStatus); + /* No resources */ + if ((intr_status & 0x3c) == 0x28) { + outw(RxResumeNoResources,ioaddr+SCBCmd); + sp->rx_resume_count++; + }else if ((intr_status & 0x3c) == 0x8) { + if (speedo_debug > 4) + printk("No resource,reset\n"); + speedo_rx_soft_reset(dev); + sp->soft_reset_count++; + } + } + break; + } + + if (--sp->curr_work_limit < 0) + break; +#endif /* Check for a rare out-of-memory case: the current buffer is the last buffer allocated in the RX ring. --SAW */ @@ -1793,7 +2009,12 @@ PKT_BUF_SZ + sizeof(struct RxFD), PCI_DMA_FROMDEVICE); } skb->protocol = eth_type_trans(skb, dev); +#ifndef CONFIG_EEPRO100_NAPI netif_rx(skb); +#else + netif_receive_skb(skb); + received ++; +#endif dev->last_rx = jiffies; sp->stats.rx_packets++; sp->stats.rx_bytes += pkt_len; @@ -1811,7 +2032,7 @@ sp->last_rx_time = jiffies; - return 0; + return received; } static int --------------070502030508090306010005 Content-Type: text/plain; name="eepro100-proc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eepro100-proc.patch" --- eepro100-napi.c Wed Jun 12 17:11:38 2002 +++ eepro100-napi-proc.c Wed Jun 12 17:33:51 2002 @@ -119,6 +119,10 @@ #define CONFIG_EEPRO100_NAPI +#ifdef CONFIG_PROC_FS +#include +#endif + MODULE_AUTHOR("Maintainer: Andrey V. Savochkin "); MODULE_DESCRIPTION("Intel i82557/i82558/i82559 PCI EtherExpressPro driver"); MODULE_LICENSE("GPL"); @@ -516,6 +520,10 @@ unsigned long alloc_fail; unsigned long long poll_cycles; +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *proc_parent; +#endif + #ifdef CONFIG_NET_FASTROUTE unsigned long fastroute_hit; unsigned long fastroute_success; @@ -582,6 +590,11 @@ static void enable_rx_and_rxnobuf_ints(struct net_device *dev); static void disable_rx_and_rxnobuf_ints(struct net_device *dev); +#ifdef CONFIG_PROC_FS +int __devinit speedo_create_proc_subdir(struct net_device *sp); +void speedo_remove_proc_subdir(struct net_device *sp); +#endif + #endif @@ -883,6 +896,14 @@ #ifdef CONFIG_EEPRO100_NAPI dev->poll = speedo_poll; dev->quota = dev->weight = RX_RING_SIZE; + +#ifdef CONFIG_PROC_FS + if (speedo_create_proc_subdir(dev) < 0) { + printk(KERN_ERR "Failed to create proc directory for %s\n", + dev->name); + } +#endif + #endif return 0; } @@ -1885,6 +1906,354 @@ return 1; /* not_done */ } +#ifdef CONFIG_PROC_FS +/* adapted from intel's e100 code */ +static struct proc_dir_entry *adapters_proc_dir = 0; + +static void speedo_proc_cleanup(void); +static unsigned char speedo_init_proc_dir(void); + +#define ADAPTERS_PROC_DIR "eepro100" +#define WRITE_BUF_MAX_LEN 20 +#define READ_BUF_MAX_LEN 256 +#define SPEEDO_PE_LEN 25 + +#define sp_off(off) (unsigned long)(offsetof(struct speedo_private, off)) + +typedef struct _speedo_proc_entry { + char *name; + read_proc_t *read_proc; + write_proc_t *write_proc; + unsigned long offset; /* offset into sp. ~0 means no value, pass NULL. */ +} speedo_proc_entry; + +static int +generic_read(char *page, char **start, off_t off, int count, int *eof, int len) +{ + if (len <= off + count) + *eof = 1; + + *start = page + off; + len -= off; + if (len > count) + len = count; + + if (len < 0) + len = 0; + + return len; +} + +static int +read_ulong(char *page, char **start, off_t off, + int count, int *eof, unsigned long l) +{ + int len; + + len = sprintf(page, "%lu\n", l); + + return generic_read(page, start, off, count, eof, len); +} + +static int +read_gen_ulong(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + unsigned long val = 0; + + if (data) + val = *((unsigned long *) data); + + return read_ulong(page, start, off, count, eof, val); +} + +static int +read_ulonglong(char *page, char **start, off_t off, + int count, int *eof, unsigned long long ll) +{ + int len; + + len = sprintf(page, "%llu\n", ll); + + return generic_read(page, start, off, count, eof, len); +} + +static int +read_gen_ulonglong(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + unsigned long val = 0; + + if (data) + val = *((unsigned long long *) data); + + return read_ulonglong(page, start, off, count, eof, val); +} + +static int +set_debug(struct file *file, const char *buffer, + unsigned long count, void *data) + +{ + if (speedo_debug == 1) + speedo_debug = 6; + else + speedo_debug = 1; + return count; +} + +static int +_speedo_show_state(struct file *file, const char *buffer, + unsigned long count, void *data) +{ + + struct net_device *dev = (struct net_device *)data; + + speedo_show_state(dev); + + return count; +} + +static speedo_proc_entry speedo_proc_list[] = { + {"set_debug", 0, set_debug, ~0}, + {"show_state", 0, _speedo_show_state, ~0}, + {"poll_switch",read_gen_ulong,0,sp_off(poll_switch)}, + {"failed_poll_switch",read_gen_ulong,0,sp_off(failed_poll_switch)}, + {"done_poll",read_gen_ulong,0,sp_off(done_poll)}, + {"notdone_poll",read_gen_ulong,0,sp_off(notdone_poll)}, + {"empty_poll",read_gen_ulong,0,sp_off(empty_poll)}, + {"soft_reset_count",read_gen_ulong,0,sp_off(soft_reset_count)}, + {"rx_resume_count",read_gen_ulong,0,sp_off(rx_resume_count)}, + {"alloc_fail",read_gen_ulong,0,sp_off(alloc_fail)}, + {"poll_cycles",read_gen_ulonglong,0,sp_off(poll_cycles)}, + {"fastroute_hit",read_gen_ulonglong,0,sp_off(fastroute_hit)}, + {"fastroute_success",read_gen_ulonglong,0,sp_off(fastroute_success)}, + {"fastroute_defer",read_gen_ulonglong,0,sp_off(fastroute_defer)}, + {"", 0, 0, 0} +}; + +static int +read_info(char *page, char **start, off_t off, int count, int *eof, void *data) +{ + struct speedo_private *sp = data; + speedo_proc_entry *pe; + int tmp; + void *val; + int len = 0; + + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') { + len += sprintf(page + len, "\n"); + continue; + } + + if (pe->read_proc) { + if ((len + READ_BUF_MAX_LEN + SPEEDO_PE_LEN + 1) >= + PAGE_SIZE) + break; + + if (pe->offset != ~0) + val = ((char *) sp) + pe->offset; + else + val = NULL; + + len += sprintf(page + len, "%-" + __MODULE_STRING(SPEEDO_PE_LEN) + "s ", pe->name); + len += pe->read_proc(page + len, start, 0, + READ_BUF_MAX_LEN + 1, &tmp, val); + } + } + + return generic_read(page, start, off, count, eof, len); +} + +static struct proc_dir_entry * __devinit +create_proc_rw(char *name, void *data, struct proc_dir_entry *parent, + read_proc_t * read_proc, write_proc_t * write_proc) +{ + struct proc_dir_entry *pdep; + mode_t mode = S_IFREG; + + if (write_proc) { + mode |= S_IWUSR; + if (read_proc) { + mode |= S_IRUSR; + } + + } else if (read_proc) { + mode |= S_IRUGO; + } + + if (!(pdep = create_proc_entry(name, mode, parent))) + return NULL; + + pdep->read_proc = read_proc; + pdep->write_proc = write_proc; + pdep->data = data; + return pdep; +} + +void +speedo_remove_proc_subdir(struct net_device *dev) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + speedo_proc_entry *pe; + char info[256]; + int len; + + /* If our root /proc dir was not created, there is nothing to remove */ + if (adapters_proc_dir == NULL) { + return; + } + + len = strlen(dev->name); + strncpy(info, dev->name, sizeof (info)); + strncat(info + len, ".info", sizeof (info) - len); + + if (sp->proc_parent) { + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') + continue; + + remove_proc_entry(pe->name, sp->proc_parent); + } + + remove_proc_entry(dev->name, adapters_proc_dir); + sp->proc_parent = NULL; + } + + remove_proc_entry(info, adapters_proc_dir); + + /* try to remove the main /proc dir, if it's empty */ + speedo_proc_cleanup(); +} + +int __devinit +speedo_create_proc_subdir(struct net_device *dev) +{ + struct speedo_private *sp = (struct speedo_private *)dev->priv; + struct proc_dir_entry *dev_dir; + speedo_proc_entry *pe; + char info[256]; + int len; + void *data; + + /* create the main /proc dir if needed */ + if (!adapters_proc_dir) { + if (!speedo_init_proc_dir()) + return -ENOMEM; + } + + strncpy(info, dev->name, sizeof (info)); + len = strlen(info); + strncat(info + len, ".info", sizeof (info) - len); + + /* info */ + if (!(create_proc_rw(info, sp, adapters_proc_dir, read_info, 0))) { + speedo_proc_cleanup(); + return -ENOMEM; + } + + dev_dir = create_proc_entry(dev->name, S_IFDIR, + adapters_proc_dir); + sp->proc_parent = dev_dir; + + if (!dev_dir) { + speedo_remove_proc_subdir(dev); + return -ENOMEM; + } + + for (pe = speedo_proc_list; pe->name[0]; pe++) { + if (pe->name[0] == '\n') + continue; + + if (pe->offset != ~0) + data = ((char *) sp) + pe->offset; + else + data = dev; + + if (!(create_proc_rw(pe->name, data, dev_dir, + pe->read_proc, pe->write_proc))) { + speedo_remove_proc_subdir(dev); + return -ENOMEM; + } + } + + return 0; +} + +/**************************************************************************** + * Name: speedo_init_proc_dir + * + * Description: This routine creates the top-level /proc directory for the + * driver in /proc/net + * + * Arguments: none + * + * Returns: true on success, false on fail + * + ***************************************************************************/ +static unsigned char +speedo_init_proc_dir(void) +{ + int len; + + /* first check if adapters_proc_dir already exists */ + len = strlen(ADAPTERS_PROC_DIR); + for (adapters_proc_dir = proc_net->subdir; + adapters_proc_dir; adapters_proc_dir = adapters_proc_dir->next) { + + if ((adapters_proc_dir->namelen == len) && + (!memcmp(adapters_proc_dir->name, ADAPTERS_PROC_DIR, len))) + break; + } + + if (!adapters_proc_dir) + adapters_proc_dir = + create_proc_entry(ADAPTERS_PROC_DIR, S_IFDIR, proc_net); + + if (!adapters_proc_dir) + return 0; + + return 1; +} + +/**************************************************************************** + * Name: speedo_proc_cleanup + * + * Description: This routine clears the top-level /proc directory, if empty. + * + * Arguments: none + * + * Returns: none + * + ***************************************************************************/ +static void +speedo_proc_cleanup(void) +{ + struct proc_dir_entry *de; + + if (adapters_proc_dir == NULL) { + return; + } + + /* check if subdir list is empty before removing adapters_proc_dir */ + for (de = adapters_proc_dir->subdir; de; de = de->next) { + /* ignore . and .. */ + if (*(de->name) != '.') + break; + } + + if (de) + return; + + remove_proc_entry(ADAPTERS_PROC_DIR, proc_net); + adapters_proc_dir = NULL; +} + +#endif /* CONFIG_PROC_FS */ + #endif /* NAPI */ static int @@ -2474,6 +2843,9 @@ unregister_netdev(dev); +#if defined(CONFIG_EEPRO100_NAPI) && defined(CONFIG_PROC_FS) + speedo_remove_proc_subdir(dev); +#endif release_region(pci_resource_start(pdev, 1), pci_resource_len(pdev, 1)); release_mem_region(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0)); --------------070502030508090306010005-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-mips@oss.sgi.com Thu Jun 13 12:06: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 g5DJ6FnC029901 for ; Thu, 13 Jun 2002 12:06:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DJ6FSu029900 for linux-mips-outgoing; Thu, 13 Jun 2002 12:06:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DJ4XnC029822 for ; Thu, 13 Jun 2002 12:04:34 -0700 Received: from tmrini by opus.bloom.county with local (Exim 3.35 #1 (Debian)) id 17IZvi-0006SD-00; Thu, 13 Jun 2002 12:06:46 -0700 Date: Thu, 13 Jun 2002 12:06:46 -0700 From: Tom Rini To: Roman Zippel , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: [RFC and PATCH] Move the m68k genrtc driver into 2.5 and use on PPC Message-ID: <20020613190646.GT13541@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 22313 Lines: 787 Hello all. A few months back yet another RTC thread was started. I've finally gotten around to trying to do something about the generic RTC issue. The following patch takes the m68k generic RTC driver (drivers/char/genrtc.c) and drops it into 2.5.21, along with include/asm-ppc/rtc.h with the needed inlines to get basic functionality going. My first question is to the MIPS people. What did you end up doing in the end about a 'generic' RTC driver? Did you do something quick-and-dirty ala drivers/macintosh/rtc.c or did you go and take the m68k one? If you did something other than take the m68k driver, did you find any problems with genrtc.c that stopped you from using it? Or was it the generic code changes (include/linux/rtc.h) Secondly to the m68k people, does anyone have an objection (or would like to do it themselves?) with me trying to get Linus to take the changes to include/linux/rtc.h? radeonfb.c currently conflicts with the 'pll_info' struct, but Ani Joshi is renaming it. Also, CONFIG_GEN_RTC used to be define_bool'ed to y on CONFIG_SUN3, but I'm not sure if that looks nice in a common file. Any idea on how to solve this nicely? (create arch/m68k/configs/*defconfig ala ppc or arch/m68k/defconfig-xxx ala mips or arch/m68k/def-configs/ ala arm?) And to everyone, while this patch is vs 2.5.21'ish, it should mostly apply to 2.4.x, so please test this on your favorite arch (or for MIPS, create and test :)) and get back to me. What I'd like to try and do in the end is perhaps replace drivers/char/rtc.c, but at a miniumum, I'd like to kill off drivers/macintosh/rtc.c. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ diff -Nru a/drivers/char/Config.help b/drivers/char/Config.help --- a/drivers/char/Config.help Thu Jun 13 12:03:49 2002 +++ b/drivers/char/Config.help Thu Jun 13 12:03:49 2002 @@ -1058,6 +1058,34 @@ The module is called rtc.o. If you want to compile it as a module, say M here and read . +Generic Real Time Clock Support +CONFIG_GEN_RTC + If you say Y here and create a character special file /dev/rtc with + major number 10 and minor number 135 using mknod ("man mknod"), you + will get access to the real time clock (or hardware clock) built + into your computer. + + In 2.4 and later kernels this is the only way to set and get rtc + time on m68k systems so it is highly recommended. + + It reports status information via the file /proc/driver/rtc and its + behaviour is set by various ioctls on /dev/rtc. If you enable the + "extended RTC operation" below it will also provide an emulation + for RTC_UIE which is required by some programs and may improve + precision in some cases. + + This driver is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called rtc.o. If you want to compile it as a module, + say M here and read . To load the + module automaticaly add 'alias char-major-10-135 genrtc' to your + /etc/modules.conf + +Extended RTC operation +CONFIG_GEN_RTC_X + Provides an emulation for RTC_UIE which is required by some programs + and may improve precision of the generic RTC support in some cases. + CONFIG_H8 The Hitachi H8/337 is a microcontroller used to deal with the power and thermal environment. If you say Y here, you will be able to diff -Nru a/drivers/char/Config.in b/drivers/char/Config.in --- a/drivers/char/Config.in Thu Jun 13 12:03:49 2002 +++ b/drivers/char/Config.in Thu Jun 13 12:03:49 2002 @@ -188,6 +188,14 @@ dep_tristate 'Intel i8x0 Random Number Generator support' CONFIG_INTEL_RNG $CONFIG_PCI tristate '/dev/nvram support' CONFIG_NVRAM tristate 'Enhanced Real Time Clock Support' CONFIG_RTC +# XXX: RTC drivers conflict. Only allow one. +if [ "$CONFIG_RTC" = "n" ]; then + # XXX: CONFIG_SUN3 used to define_bool this to y + tristate 'Generic /dev/rtc emulation' CONFIG_GEN_RTC + if [ "$CONFIG_GEN_RTC" != "n" ]; then + bool ' Extended RTC operation' CONFIG_GEN_RTC_X + fi +fi if [ "$CONFIG_IA64" = "y" ]; then bool 'EFI Real Time Clock Services' CONFIG_EFI_RTC fi diff -Nru a/drivers/char/Makefile b/drivers/char/Makefile --- a/drivers/char/Makefile Thu Jun 13 12:03:49 2002 +++ b/drivers/char/Makefile Thu Jun 13 12:03:49 2002 @@ -173,6 +173,7 @@ obj-$(CONFIG_ADBMOUSE) += adbmouse.o obj-$(CONFIG_PC110_PAD) += pc110pad.o obj-$(CONFIG_RTC) += rtc.o +obj-$(CONFIG_GEN_RTC) += genrtc.o obj-$(CONFIG_EFI_RTC) += efirtc.o ifeq ($(CONFIG_PPC),) obj-$(CONFIG_NVRAM) += nvram.o diff -Nru a/drivers/char/genrtc.c b/drivers/char/genrtc.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/drivers/char/genrtc.c Thu Jun 13 12:03:49 2002 @@ -0,0 +1,517 @@ +/* + * Real Time Clock interface for q40 and other m68k machines + * emulate some RTC irq capabilities in software + * + * Copyright (C) 1999 Richard Zidlicky + * + * based on Paul Gortmaker's rtc.c device and + * Sam Creasey Generic rtc driver + * + * This driver allows use of the real time clock (built into + * nearly all computers) from user space. It exports the /dev/rtc + * interface supporting various ioctl() and also the /proc/dev/rtc + * pseudo-file for status information. + * + * The ioctls can be used to set the interrupt behaviour where + * supported. + * + * The /dev/rtc interface will block on reads until an interrupt + * has been received. If a RTC interrupt has already happened, + * it will output an unsigned long and then block. The output value + * contains the interrupt status in the low byte and the number of + * interrupts since the last read in the remaining high bytes. The + * /dev/rtc interface can also be used with the select(2) call. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + + * 1.01 fix for 2.3.X rz@linux-m68k.org + * 1.02 merged with code from genrtc.c rz@linux-m68k.org + * 1.03 make it more portable zippel@linux-m68k.org + * 1.04 removed useless timer code rz@linux-m68k.org + * 1.05 portable RTC_UIE emulation rz@linux-m68k.org + */ + +#define RTC_VERSION "1.05" + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +/* + * We sponge a minor off of the misc major. No need slurping + * up another valuable major dev number for this. If you add + * an ioctl, make sure you don't conflict with SPARC's RTC + * ioctls. + */ + +static DECLARE_WAIT_QUEUE_HEAD(gen_rtc_wait); + +static int gen_rtc_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg); + +/* + * Bits in gen_rtc_status. + */ + +#define RTC_IS_OPEN 0x01 /* means /dev/rtc is in use */ + +unsigned char gen_rtc_status; /* bitmapped status byte. */ +unsigned long gen_rtc_irq_data; /* our output to the world */ + +/* months start at 0 now */ +unsigned char days_in_mo[] = +{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}; + +static int irq_active; + +#ifdef CONFIG_GEN_RTC_X +struct tq_struct genrtc_task; +static struct timer_list timer_task; + +static unsigned int oldsecs; +static int lostint; +static int tt_exp; + +void gen_rtc_timer(unsigned long data); + +static volatile int stask_active; /* schedule_task */ +static volatile int ttask_active; /* timer_task */ +static int stop_rtc_timers; /* don't requeue tasks */ +static spinlock_t gen_rtc_lock = SPIN_LOCK_UNLOCKED; + +/* + * Routine to poll RTC seconds field for change as often as posible, + * after first RTC_UIE use timer to reduce polling + */ +void genrtc_troutine(void *data) +{ + unsigned int tmp = get_rtc_ss(); + + if (stop_rtc_timers) { + stask_active = 0; + return; + } + + if (oldsecs != tmp){ + oldsecs = tmp; + + timer_task.function = gen_rtc_timer; + timer_task.expires = jiffies + HZ - (HZ/10); + tt_exp=timer_task.expires; + ttask_active=1; + stask_active=0; + add_timer(&timer_task); + + gen_rtc_interrupt(0); + } else if (schedule_task(&genrtc_task) == 0) + stask_active = 0; +} + +void gen_rtc_timer(unsigned long data) +{ + lostint = get_rtc_ss() - oldsecs ; + if (lostint<0) + lostint = 60 - lostint; + if (jiffies-tt_exp>1) + printk("genrtc: timer task delayed by %ld jiffies\n", + jiffies-tt_exp); + ttask_active=0; + stask_active=1; + if ((schedule_task(&genrtc_task) == 0)) + stask_active = 0; +} + +/* + * call gen_rtc_interrupt function to signal an RTC_UIE, + * arg is unused. + * Could be invoked either from a real interrupt handler or + * from some routine that periodically (eg 100HZ) monitors + * whether RTC_SECS changed + */ +void gen_rtc_interrupt(unsigned long arg) +{ + /* We store the status in the low byte and the number of + * interrupts received since the last read in the remainder + * of rtc_irq_data. */ + + gen_rtc_irq_data += 0x100; + gen_rtc_irq_data &= ~0xff; + gen_rtc_irq_data |= RTC_UIE; + + if (lostint){ + printk("genrtc: system delaying clock ticks?\n"); + /* increment count so that userspace knows something is wrong */ + gen_rtc_irq_data += ((lostint-1)<<8); + lostint = 0; + } + + wake_up_interruptible(&gen_rtc_wait); +} + +/* + * Now all the various file operations that we export. + */ +static ssize_t gen_rtc_read(struct file *file, char *buf, + size_t count, loff_t *ppos) +{ + DECLARE_WAITQUEUE(wait, current); + unsigned long data; + ssize_t retval; + + if (count < sizeof(unsigned long)) + return -EINVAL; + + if (file->f_flags & O_NONBLOCK && !gen_rtc_irq_data) + return -EAGAIN; + + add_wait_queue(&gen_rtc_wait, &wait); + retval = -ERESTARTSYS; + + while (1) { + set_current_state(TASK_INTERRUPTIBLE); + data = xchg(&gen_rtc_irq_data, 0); + if (data) + break; + if (signal_pending(current)) + goto out; + schedule(); + } + + retval = put_user(data, (unsigned long *)buf); + if (!retval) + retval = sizeof(unsigned long); + out: + current->state = TASK_RUNNING; + remove_wait_queue(&gen_rtc_wait, &wait); + + return retval; +} + +static unsigned int gen_rtc_poll(struct file *file, + struct poll_table_struct *wait) +{ + poll_wait(file, &gen_rtc_wait, wait); + if (gen_rtc_irq_data != 0) + return POLLIN | POLLRDNORM; + return 0; +} + +#endif + +/* + * Used to disable/enable interrupts, only RTC_UIE supported + * We also clear out any old irq data after an ioctl() that + * meddles with the interrupt enable/disable bits. + */ + +static inline void gen_clear_rtc_irq_bit(unsigned char bit) +{ +#ifdef CONFIG_GEN_RTC_X + stop_rtc_timers = 1; + if (ttask_active){ + del_timer_sync(&timer_task); + ttask_active = 0; + } + while (stask_active) + schedule(); + + spin_lock(&gen_rtc_lock); + irq_active = 0; + spin_unlock(&gen_rtc_lock); +#endif +} + +static inline int gen_set_rtc_irq_bit(unsigned char bit) +{ +#ifdef CONFIG_GEN_RTC_X + spin_lock(&gen_rtc_lock); + if ( !irq_active ) { + irq_active = 1; + stop_rtc_timers = 0; + lostint = 0; + genrtc_task.routine = genrtc_troutine; + oldsecs = get_rtc_ss(); + init_timer(&timer_task); + + stask_active = 1; + if (schedule_task(&genrtc_task) == 0){ + stask_active = 0; + } + } + spin_unlock(&gen_rtc_lock); + gen_rtc_irq_data = 0; + return 0; +#else + return -EINVAL; +#endif +} + +static int gen_rtc_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + struct rtc_time wtime; + struct pll_info pll; + + switch (cmd) { + + case RTC_PLL_GET: + if (get_rtc_pll(&pll)) + return -EINVAL; + else + return copy_to_user((void *)arg, &pll, sizeof pll) ? -EFAULT : 0; + + case RTC_PLL_SET: + if (!capable(CAP_SYS_TIME)) + return -EACCES; + if (copy_from_user(&pll, (struct pll_info*)arg, + sizeof(pll))) + return -EFAULT; + return set_rtc_pll(&pll); + + case RTC_UIE_OFF: /* disable ints from RTC updates. */ + gen_clear_rtc_irq_bit(RTC_UIE); + return 0; + + case RTC_UIE_ON: /* enable ints for RTC updates. */ + return gen_set_rtc_irq_bit(RTC_UIE); + + case RTC_RD_TIME: /* Read the time/date from RTC */ + /* this doesn't get week-day, who cares */ + memset(&wtime, 0, sizeof(wtime)); + get_rtc_time(&wtime); + + return copy_to_user((void *)arg, &wtime, sizeof(wtime)) ? -EFAULT : 0; + + case RTC_SET_TIME: /* Set the RTC */ + { + int year; + unsigned char leap_yr; + + if (!capable(CAP_SYS_TIME)) + return -EACCES; + + if (copy_from_user(&wtime, (struct rtc_time *)arg, + sizeof(wtime))) + return -EFAULT; + + year = wtime.tm_year + 1900; + leap_yr = ((!(year % 4) && (year % 100)) || + !(year % 400)); + + if ((wtime.tm_mon < 0 || wtime.tm_mon > 11) || (wtime.tm_mday < 1)) + return -EINVAL; + + if (wtime.tm_mday < 0 || wtime.tm_mday > + (days_in_mo[wtime.tm_mon] + ((wtime.tm_mon == 1) && leap_yr))) + return -EINVAL; + + if (wtime.tm_hour < 0 || wtime.tm_hour >= 24 || + wtime.tm_min < 0 || wtime.tm_min >= 60 || + wtime.tm_sec < 0 || wtime.tm_sec >= 60) + return -EINVAL; + + set_rtc_time(&wtime); + return 0; + } + } + + return -EINVAL; +} + +/* + * We enforce only one user at a time here with the open/close. + * Also clear the previous interrupt data on an open, and clean + * up things on a close. + */ + +static int gen_rtc_open(struct inode *inode, struct file *file) +{ + if (gen_rtc_status & RTC_IS_OPEN) + return -EBUSY; + + MOD_INC_USE_COUNT; + + gen_rtc_status |= RTC_IS_OPEN; + gen_rtc_irq_data = 0; + irq_active = 0; + + return 0; +} + +static int gen_rtc_release(struct inode *inode, struct file *file) +{ + /* + * Turn off all interrupts once the device is no longer + * in use and clear the data. + */ + + gen_clear_rtc_irq_bit(RTC_PIE|RTC_AIE|RTC_UIE); + + gen_rtc_status &= ~RTC_IS_OPEN; + MOD_DEC_USE_COUNT; + + return 0; +} + +static int gen_rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data); + + +/* + * The various file operations we support. + */ + +static struct file_operations gen_rtc_fops = { + owner: THIS_MODULE, +#ifdef CONFIG_GEN_RTC_X + read: gen_rtc_read, + poll: gen_rtc_poll, +#endif + ioctl: gen_rtc_ioctl, + open: gen_rtc_open, + release: gen_rtc_release +}; + +static struct miscdevice rtc_gen_dev = +{ + RTC_MINOR, + "rtc", + &gen_rtc_fops +}; + +int __init rtc_generic_init(void) +{ + + printk(KERN_INFO "Generic RTC Driver v%s\n", RTC_VERSION); + + misc_register(&rtc_gen_dev); + create_proc_read_entry ("driver/rtc", 0, 0, gen_rtc_read_proc, NULL); + + return 0; +} + +static void __exit rtc_generic_exit(void) +{ + remove_proc_entry ("driver/rtc", NULL); + misc_deregister(&rtc_gen_dev); +} + +module_init(rtc_generic_init); +module_exit(rtc_generic_exit); +EXPORT_NO_SYMBOLS; + + +/* + * Info exported via "/proc/rtc". + */ + +int gen_rtc_proc_output(char *buf) +{ + char *p; + struct rtc_time tm; + unsigned tmp; + struct pll_info pll; + + p = buf; + + get_rtc_time(&tm); + + p += sprintf(p, + "rtc_time\t: %02d:%02d:%02d\n" + "rtc_date\t: %04d-%02d-%02d\n" + "rtc_epoch\t: %04u\n", + tm.tm_hour, tm.tm_min, tm.tm_sec, + tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, 1900); + + tm.tm_hour=0;tm.tm_min=0;tm.tm_sec=0; + + p += sprintf(p, "alarm\t\t: "); + if (tm.tm_hour <= 24) + p += sprintf(p, "%02d:", tm.tm_hour); + else + p += sprintf(p, "**:"); + + if (tm.tm_min <= 59) + p += sprintf(p, "%02d:", tm.tm_min); + else + p += sprintf(p, "**:"); + + if (tm.tm_sec <= 59) + p += sprintf(p, "%02d\n", tm.tm_sec); + else + p += sprintf(p, "**\n"); + + tmp= RTC_24H ; + p += sprintf(p, + "DST_enable\t: %s\n" + "BCD\t\t: %s\n" + "24hr\t\t: %s\n" + "square_wave\t: %s\n" + "alarm_IRQ\t: %s\n" + "update_IRQ\t: %s\n" + "periodic_IRQ\t: %s\n" + "periodic_freq\t: %ld\n" + "batt_status\t: %s\n", + (tmp & RTC_DST_EN) ? "yes" : "no", + (tmp & RTC_DM_BINARY) ? "no" : "yes", + (tmp & RTC_24H) ? "yes" : "no", + (tmp & RTC_SQWE) ? "yes" : "no", + (tmp & RTC_AIE) ? "yes" : "no", + irq_active ? "yes" : "no", + (tmp & RTC_PIE) ? "yes" : "no", + 0L /* freq */, + "okay" ); + if (!get_rtc_pll(&pll)) + p += sprintf(p, + "PLL adjustment\t: %d\n" + "PLL max +ve adjustment\t: %d\n" + "PLL max -ve adjustment\t: %d\n" + "PLL +ve adjustment factor\t: %d\n" + "PLL -ve adjustment factor\t: %d\n" + "PLL frequency\t: %ld\n", + pll.pll_value, + pll.pll_max, + pll.pll_min, + pll.pll_posmult, + pll.pll_negmult, + pll.pll_clock); + return p - buf; +} + +static int gen_rtc_read_proc(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + int len = gen_rtc_proc_output (page); + if (len <= off+count) *eof = 1; + *start = page + off; + len -= off; + if (len>count) len = count; + if (len<0) len = 0; + return len; +} + + +MODULE_AUTHOR("Richard Zidlicky"); +MODULE_LICENSE("GPL"); + +/* + * Local variables: + * compile-command: "m68k-linux-gcc -D__KERNEL__ -I../../include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -ffixed-a2 -c -o genrtc.o genrtc.c" + * End: + */ + diff -Nru a/drivers/video/radeonfb.c b/drivers/video/radeonfb.c --- a/drivers/video/radeonfb.c Thu Jun 13 12:03:49 2002 +++ b/drivers/video/radeonfb.c Thu Jun 13 12:03:49 2002 @@ -190,7 +190,7 @@ } __attribute__ ((packed)) PLL_BLOCK; -struct pll_info { +struct radeon_pll_info { int ppll_max; int ppll_min; int xclk; @@ -304,7 +304,7 @@ u32 dp_gui_master_cntl; - struct pll_info pll; + struct radeon_pll_info pll; int pll_output_freq, post_div, fb_div; struct ram_info ram; diff -Nru a/include/asm-ppc/rtc.h b/include/asm-ppc/rtc.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/include/asm-ppc/rtc.h Thu Jun 13 12:03:49 2002 @@ -0,0 +1,94 @@ +/* + * inclue/asm-ppc/rtc.h + * + * Copyright 2002 MontaVista Software Inc. + * Author: Tom Rini + * + * Based on: + * include/asm-m68k/rtc.h + * + * Copyright Richard Zidlicky + * implementation details for genrtc/q40rtc driver + * + * And the old drivers/macintosh/rtc.c which was heavily based on: + * Linux/SPARC Real Time Clock Driver + * Copyright (C) 1996 Thomas K. Dyas (tdyas@eden.rutgers.edu) + * + * With additional work by Paul Mackerras and Franz Sirl. + */ +/* permission is hereby granted to copy, modify and redistribute this code + * in terms of the GNU Library General Public License, Version 2 or later, + * at your option. + */ + +#ifndef __ASM_RTC_H__ +#define __ASM_RTC_H__ + +#ifdef __KERNEL__ + +#include + +#include +#include + +#define RTC_PIE 0x40 /* periodic interrupt enable */ +#define RTC_AIE 0x20 /* alarm interrupt enable */ +#define RTC_UIE 0x10 /* update-finished interrupt enable */ + +extern void gen_rtc_interrupt(unsigned long); + +/* some dummy definitions */ +#define RTC_SQWE 0x08 /* enable square-wave output */ +#define RTC_DM_BINARY 0x04 /* all time/date values are BCD if clear */ +#define RTC_24H 0x02 /* 24 hour mode - else hours bit 7 means pm */ +#define RTC_DST_EN 0x01 /* auto switch DST - works f. USA only */ + +static inline void get_rtc_time(struct rtc_time *time) +{ + if (ppc_md.get_rtc_time) { + unsigned long nowtime; + + nowtime = (ppc_md.get_rtc_time)(); + + to_tm(nowtime, time); + + time->tm_year -= 1900; + time->tm_mon -= 1; /* Make sure userland has a 0-based month */ + } else + return -EINVAL; +} + +/* Set the current date and time in the real time clock. */ +static inline void set_rtc_time(struct rtc_time *time) +{ + if (ppc_md.get_rtc_time) { + unsigned long nowtime; + + nowtime = mktime(time->tm_year+1900, time->tm_mon+1, + time->tm_mday, time->tm_hour, time->tm_min, + time->tm_sec); + + (ppc_md.set_rtc_time)(nowtime); + } else + return -EINVAL; +} + +static inline unsigned int get_rtc_ss(void) +{ + struct rtc_time h; + + get_rtc_time(&h); + return h.tm_sec; +} + +static inline int get_rtc_pll(struct pll_info *pll) +{ + return -EINVAL; +} +static inline int set_rtc_pll(struct pll_info *pll) +{ + return -EINVAL; +} + +#endif /* __KERNEL__ */ +#endif /* __ASM_RTC_H__ */ diff -Nru a/include/linux/rtc.h b/include/linux/rtc.h --- a/include/linux/rtc.h Thu Jun 13 12:03:49 2002 +++ b/include/linux/rtc.h Thu Jun 13 12:03:49 2002 @@ -39,10 +39,32 @@ struct rtc_time time; /* time the alarm is set to */ }; +/* + * Data structure to control PLL correction some better RTC feature + * pll_value is used to get or set current value of correction, + * the rest of the struct is used to query HW capabilities. + * This is modeled after the RTC used in Q40/Q60 computers but + * should be sufficiently flexible for other devices + * + * +ve pll_value means clock will run faster by + * pll_value*pll_posmult/pll_clock + * -ve pll_value means clock will run slower by + * pll_value*pll_negmult/pll_clock + */ + +struct pll_info { + int pll_ctrl; /* placeholder for fancier control */ + int pll_value; /* get/set correction value */ + int pll_max; /* max +ve (faster) adjustment value */ + int pll_min; /* max -ve (slower) adjustment value */ + int pll_posmult; /* factor for +ve corection */ + int pll_negmult; /* factor for -ve corection */ + long pll_clock; /* base PLL frequency */ +}; /* * ioctl calls that are permitted to the /dev/rtc interface, if - * CONFIG_RTC/CONFIG_EFI_RTC was enabled. + * any of the RTC drivers are enabled. */ #define RTC_AIE_ON _IO('p', 0x01) /* Alarm int. enable on */ @@ -65,6 +87,9 @@ #define RTC_WKALM_SET _IOW('p', 0x0f, struct rtc_wkalrm)/* Set wakeup alarm*/ #define RTC_WKALM_RD _IOR('p', 0x10, struct rtc_wkalrm)/* Get wakeup alarm*/ +#define RTC_PLL_GET _IOR('p', 0x11, struct pll_info) /* Get PLL correction */ +#define RTC_PLL_SET _IOW('p', 0x12, struct pll_info) /* Set PLL correction */ +# #ifdef __KERNEL__ From owner-linux-mips@oss.sgi.com Thu Jun 13 13:13: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 g5DKDVnC005025 for ; Thu, 13 Jun 2002 13:13:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DKDVLm005024 for linux-mips-outgoing; Thu, 13 Jun 2002 13:13:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DKCLnC005021 for ; Thu, 13 Jun 2002 13:12:22 -0700 Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 16:05:27 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:40:32 -0400 Received: from sources.redhat.com ([209.249.29.67]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with SMTP id g5AKeWtH022654 for ; Mon, 10 Jun 2002 16:40:33 -0400 (EDT) Received: (qmail 17587 invoked by alias); 10 Jun 2002 20:36:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm List-Unsubscribe: List-Archive: List-Post: List-Help: Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 17475 invoked from network); 10 Jun 2002 20:36:56 -0000 Received: from unknown (HELO sccrmhc01.attbi.com) (204.127.202.61) by sources.redhat.com with SMTP; 10 Jun 2002 20:36:56 -0000 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 <20020610203655.ESMT1024.sccrmhc01.attbi.com@ocean.lucon.org>; Mon, 10 Jun 2002 20:36:55 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 735E2125C0; Mon, 10 Jun 2002 13:36:52 -0700 (PDT) Date: Mon, 10 Jun 2002 13:36:52 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.11 is released. Message-ID: <20020610133652.A27414@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 Content-Length: 15756 Lines: 571 This is the beta release of binutils 2.12.90.0.11 for Linux, which is based on binutils 2002 0608 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.11 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.9: 1. Update from binutils 2002 0608. 2. Fix an ELF/mips SHF_MERGE bug. 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.11.tar.gz. Source code. 2. binutils-2.12.90.0.9-2.12.90.0.11.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.11-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.11.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 06/10/2002 From owner-linux-mips@oss.sgi.com Thu Jun 13 15:46: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 g5DMkmnC007287 for ; Thu, 13 Jun 2002 15:46:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DMkmBL007286 for linux-mips-outgoing; Thu, 13 Jun 2002 15:46:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from faui02.informatik.uni-erlangen.de (root@faui02.informatik.uni-erlangen.de [131.188.30.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DMkenC007280 for ; Thu, 13 Jun 2002 15:46:41 -0700 Received: from rz.de (root@faui02b.informatik.uni-erlangen.de [131.188.30.151]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id AAA03684; Fri, 14 Jun 2002 00:48:53 +0200 (MEST) Received: (from rz@localhost) by rz.de (8.8.8/8.8.8) id AAA01325; Fri, 14 Jun 2002 00:31:43 +0200 Date: Fri, 14 Jun 2002 00:31:43 +0200 From: Richard Zidlicky To: Tom Rini Cc: Roman Zippel , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC and PATCH] Move the m68k genrtc driver into 2.5 and use on PPC Message-ID: <20020614003143.C1230@linux-m68k.org> References: <20020613190646.GT13541@opus.bloom.county> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020613190646.GT13541@opus.bloom.county>; from trini@kernel.crashing.org on Thu, Jun 13, 2002 at 12:06:46PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2050 Lines: 50 On Thu, Jun 13, 2002 at 12:06:46PM -0700, Tom Rini wrote: Hi, > Secondly to the m68k people, does anyone have an objection (or would > like to do it themselves?) with me trying to get Linus to take the > changes to include/linux/rtc.h? radeonfb.c currently conflicts with the > 'pll_info' struct, but Ani Joshi is renaming it. I will be happy whoever gets it in. The pll_info stuff could be renamed in genrtc.c as well. > Also, CONFIG_GEN_RTC > used to be define_bool'ed to y on CONFIG_SUN3, but I'm not sure if that > looks nice in a common file. Any idea on how to solve this nicely? m68k doesn't source drivers/chars/Config.in so just don't do anything about it? > diff -Nru a/drivers/char/Config.help b/drivers/char/Config.help > --- a/drivers/char/Config.help Thu Jun 13 12:03:49 2002 > +++ b/drivers/char/Config.help Thu Jun 13 12:03:49 2002 > @@ -1058,6 +1058,34 @@ > The module is called rtc.o. If you want to compile it as a module, > say M here and read . > > +Generic Real Time Clock Support > +CONFIG_GEN_RTC > + If you say Y here and create a character special file /dev/rtc with > + major number 10 and minor number 135 using mknod ("man mknod"), you > + will get access to the real time clock (or hardware clock) built > + into your computer. > + > + In 2.4 and later kernels this is the only way to set and get rtc > + time on m68k systems so it is highly recommended. > + > + It reports status information via the file /proc/driver/rtc and its > + behaviour is set by various ioctls on /dev/rtc. If you enable the > + "extended RTC operation" below it will also provide an emulation > + for RTC_UIE which is required by some programs and may improve > + precision in some cases. > + > + This driver is also available as a module ( = code which can be > + inserted in and removed from the running kernel whenever you want). > + The module is called rtc.o. If you want to compile it as a module, ^^^^^^^ genrtc.o ... I could swear I fixed it in m68k CVS ;) Richard From owner-linux-mips@oss.sgi.com Thu Jun 13 16:15: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 g5DNFOnC007836 for ; Thu, 13 Jun 2002 16:15:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DNFOJ9007835 for linux-mips-outgoing; Thu, 13 Jun 2002 16:15:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f 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 g5DNFInC007832 for ; Thu, 13 Jun 2002 16:15:18 -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 g5DNHiC13379; Fri, 14 Jun 2002 01:17:44 +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 g5DNHjTF018060; Fri, 14 Jun 2002 01:17:45 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.34 #1 (Debian)) id 17Idqa-00024a-00; Fri, 14 Jun 2002 01:17:44 +0200 Date: Fri, 14 Jun 2002 01:17:44 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: R10K speculative store on non-coherent systems workaround proposal In-Reply-To: <1023707152.18634.18.camel@dea.linux-mips.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1469 Lines: 39 On 10 Jun 2002, Ralf Baechle wrote: > Looks like a good start but unfortunately your concept is ignoring > userspace entirely. indeed ;) > You might have to deal with mmapped pages that are being written to > backing storage. True. > In such a case you'll have to trackdown all mappings and disable > access to them I don't think so. Before doing DMA, pages will be locked with lock_page (mm/filemap.c) and processes accessing this page will be forced to wait for I/O completion. Quote from include/asm/page.h: >> * During disk I/O, PG_locked is used. This bit is set before I/O >> * and reset when I/O completes. page->wait is a wait queue of all >> * tasks waiting for the I/O on this page to complete. Thus, no user process should be accessing the page during the I/O transfer (this would cause problems anyway, even on coherent architectures). However, now our problem is that the mappings may still be in the TLB, and thus speculative stores could be executed to the DMA buffer. However, this can be easily worked around by flushing the TLB entries for these mappings (we only have 64 to check, or we can do the bovine flush_tlb_all ;)). Thus mappings will be invalid for the CPU, causing an exception that will abort the speculative store. Does that sound ok? > Intially I guess you can simply avoid this hairy job by doing all DMA using > bounce buffers only. Expensive but doable ... I'd prefer to avoid those expensive memcpy if possible.. Vivien. From owner-linux-mips@oss.sgi.com Thu Jun 13 23:18: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 g5E6IrnC012521 for ; Thu, 13 Jun 2002 23:18:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5E6IrKt012520 for linux-mips-outgoing; Thu, 13 Jun 2002 23:18: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 g5E6IjnC012517 for ; Thu, 13 Jun 2002 23:18:45 -0700 Received: from opus.bloom.county (cpe-24-221-152-185.az.sprintbbd.net [24.221.152.185]) 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 RAA04933 for ; Thu, 13 Jun 2002 17:41:57 -0700 (PDT) mail_from (trini@kernel.crashing.org) Received: from tmrini by opus.bloom.county with local (Exim 3.35 #1 (Debian)) id 17Iew7-0006nu-00; Thu, 13 Jun 2002 17:27:31 -0700 Date: Thu, 13 Jun 2002 17:27:31 -0700 From: Tom Rini To: Richard Zidlicky Cc: Roman Zippel , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC and PATCH] Move the m68k genrtc driver into 2.5 and use on PPC Message-ID: <20020614002731.GC13541@opus.bloom.county> References: <20020613190646.GT13541@opus.bloom.county> <20020614003143.C1230@linux-m68k.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020614003143.C1230@linux-m68k.org> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2438 Lines: 57 On Fri, Jun 14, 2002 at 12:31:43AM +0200, Richard Zidlicky wrote: > On Thu, Jun 13, 2002 at 12:06:46PM -0700, Tom Rini wrote: > Hi, > > > Secondly to the m68k people, does anyone have an objection (or would > > like to do it themselves?) with me trying to get Linus to take the > > changes to include/linux/rtc.h? radeonfb.c currently conflicts with the > > 'pll_info' struct, but Ani Joshi is renaming it. > > I will be happy whoever gets it in. The pll_info stuff could be > renamed in genrtc.c as well. It could... But I imagine it'll be fun getting that in either way. :) > > Also, CONFIG_GEN_RTC > > used to be define_bool'ed to y on CONFIG_SUN3, but I'm not sure if that > > looks nice in a common file. Any idea on how to solve this nicely? > > m68k doesn't source drivers/chars/Config.in so just don't do > anything about it? Ah, it doesn't? I suppose that will work too.. :) > > diff -Nru a/drivers/char/Config.help b/drivers/char/Config.help > > --- a/drivers/char/Config.help Thu Jun 13 12:03:49 2002 > > +++ b/drivers/char/Config.help Thu Jun 13 12:03:49 2002 > > @@ -1058,6 +1058,34 @@ > > The module is called rtc.o. If you want to compile it as a module, > > say M here and read . > > > > +Generic Real Time Clock Support > > +CONFIG_GEN_RTC > > + If you say Y here and create a character special file /dev/rtc with > > + major number 10 and minor number 135 using mknod ("man mknod"), you > > + will get access to the real time clock (or hardware clock) built > > + into your computer. > > + > > + In 2.4 and later kernels this is the only way to set and get rtc > > + time on m68k systems so it is highly recommended. > > + > > + It reports status information via the file /proc/driver/rtc and its > > + behaviour is set by various ioctls on /dev/rtc. If you enable the > > + "extended RTC operation" below it will also provide an emulation > > + for RTC_UIE which is required by some programs and may improve > > + precision in some cases. > > + > > + This driver is also available as a module ( = code which can be > > + inserted in and removed from the running kernel whenever you want). > > + The module is called rtc.o. If you want to compile it as a module, > ^^^^^^^ > genrtc.o ... I could swear I fixed it in m68k CVS ;) I might have grabbed too old a version of that. Fixing it now. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ From owner-linux-mips@oss.sgi.com Fri Jun 14 01:01: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 g5E81gnC013520 for ; Fri, 14 Jun 2002 01:01:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5E81gPT013519 for linux-mips-outgoing; Fri, 14 Jun 2002 01:01:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.sonytel.be (mail2.sonytel.be [195.0.45.172]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5E81anC013510 for ; Fri, 14 Jun 2002 01:01:37 -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 KAA25408; Fri, 14 Jun 2002 10:03:15 +0200 (MET DST) Date: Fri, 14 Jun 2002 10:03:16 +0200 (MEST) From: Geert Uytterhoeven To: Tom Rini cc: Roman Zippel , Linux/MIPS Development , Linux/m68k , Linux/PPC Development Subject: Re: [RFC and PATCH] Move the m68k genrtc driver into 2.5 and use on PPC In-Reply-To: <20020613190646.GT13541@opus.bloom.county> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 590 Lines: 18 On Thu, 13 Jun 2002, Tom Rini wrote: > Secondly to the m68k people, does anyone have an objection (or would > like to do it themselves?) with me trying to get Linus to take the > changes to include/linux/rtc.h? radeonfb.c currently conflicts with the No objection at all :-) Thanks! 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 Fri Jun 14 04:48: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 g5EBmLnC003706 for ; Fri, 14 Jun 2002 04:48:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EBmLXQ003705 for linux-mips-outgoing; Fri, 14 Jun 2002 04:48:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-3.us4.outblaze.com (205-158-62-93.outblaze.com [205.158.62.93]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EBmInC003701 for ; Fri, 14 Jun 2002 04:48:18 -0700 Received: (qmail 16385 invoked by uid 1001); 14 Jun 2002 11:50:49 -0000 Message-ID: <20020614115049.16384.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-3.us4.outblaze.com with http for domca_psg@email.com; Fri, 14 Jun 2002 06:50:49 -0500 From: "Domcan Sami" To: linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, redhat-list@redhat.com Date: Fri, 14 Jun 2002 06:50:49 -0500 Subject: Kernel - arch support(mips) X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-3.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 19 Hi all, I am trying to compile a program using a MIPS-LINUX cross compiler(gcc). I've set up a connection between my i386 Linux machine and a MIPS(RM7000) processor. This is again connected to a WinNT Terminal where there should be an output from the MIPS processor. I have 2 kernels in my Linux machine under the directories: 1) /usr/src/linux - kernel version 2.2.14 2) /root/kernels/linux - kernel version 2.4.14 I am using a boot image generated from the older kernel for booting. The problem is the older kernel doesn't support MIPS architecture. What should I do to upgrade my kernel so that it supports MIPS architecture & that I'll be able to cross-compile my programs properly. Domcan -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Fri Jun 14 08:01: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 g5EF11nC009672 for ; Fri, 14 Jun 2002 08:01:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EF11lZ009671 for linux-mips-outgoing; Fri, 14 Jun 2002 08:01:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws1-3.us4.outblaze.com (205-158-62-55.outblaze.com [205.158.62.55]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EF0xnC009663 for ; Fri, 14 Jun 2002 08:00:59 -0700 Received: (qmail 22602 invoked by uid 1001); 14 Jun 2002 15:02:36 -0000 Message-ID: <20020614150236.22601.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [194.11.79.70] by ws1-3.us4.outblaze.com with http for yvar@mail.com; Fri, 14 Jun 2002 10:02:36 -0500 From: "Yvar Hoogland" To: linux-mips@oss.sgi.com Date: Fri, 14 Jun 2002 10:02:36 -0500 Subject: Need kernel for Origin200 X-Originating-Ip: 194.11.79.70 X-Originating-Server: ws1-3.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 329 Lines: 9 Anybody able to assist me in building a kernel for the Orgin200 -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Fri Jun 14 17: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 g5F0B0nC027825 for ; Fri, 14 Jun 2002 17:11:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0B0dg027824 for linux-mips-outgoing; Fri, 14 Jun 2002 17:11:00 -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 (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0AtnC027821 for ; Fri, 14 Jun 2002 17:10:56 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0BiC22473 for linux-mips@oss.sgi.com; Sat, 15 Jun 2002 02:11:44 +0200 Received: from msr.hinet.net (msr88.hinet.net [168.95.4.188]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5E7PrnC013213 for ; Fri, 14 Jun 2002 00:25:53 -0700 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id PAA04080; Fri, 14 Jun 2002 15:28:20 +0800 (CST) Message-ID: <004801c21375$09ff8fc0$780411ac@sam> From: "Sam+" To: "Sam" , Subject: # CrossCompiler (Big Endian) Date: Fri, 14 Jun 2002 15:28:10 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C213B8.170810F0" 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 Content-Length: 3349 Lines: 106 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C213B8.170810F0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, Could andbody give some suggestion? thanks --Sam ----- Original Message -----=20 From: Sam=20 To: linux-mips@oss.sgi.com=20 Sent: Thursday, June 13, 2002 5:50 PM Subject: # CrossCompiler (Big Endian) Hi everybody, I got some information to build Little Endian CrossCompiler for = mips even precompiled binary files, and work well..... However, I have to build a Big Endian's one Should I get the binutil and glibc for big endian firstly? Is there any homepage for reference on web? anybody know the flow?=20 gcc -BE is not work? thanks all! --Sam ------=_NextPart_000_0045_01C213B8.170810F0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
    Could andbody give some=20 suggestion?
    thanks
 
--Sam
----- Original = Message -----
From:=20 Sam=20
To: linux-mips@oss.sgi.com
Sent: = Thursday, June 13, 2002 5:50=20 PM
Subject: # = CrossCompiler (Big=20 Endian)

Hi everybody,
 
    I got some information to build = Little=20 Endian CrossCompiler for mips
    even precompiled binary files, = and work=20 well.....
 
    However, I have to build a Big = Endian's=20 one
    Should I get the binutil and = glibc for=20 big endian firstly?
 
    Is there any homepage for = reference on=20 web?
    anybody know the flow? =
    gcc -BE is not = work?
 
    thanks all!
 
--Sam
------=_NextPart_000_0045_01C213B8.170810F0-- From owner-linux-mips@oss.sgi.com Fri Jun 14 17:11: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 g5F0BVnC027860 for ; Fri, 14 Jun 2002 17:11:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0BVJG027859 for linux-mips-outgoing; Fri, 14 Jun 2002 17:11:31 -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 (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0BPnC027849 for ; Fri, 14 Jun 2002 17:11:26 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0CEc22491 for linux-mips@oss.sgi.com; Sat, 15 Jun 2002 02:12:14 +0200 Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EIClnC022138 for ; Fri, 14 Jun 2002 11:12:47 -0700 Received: (qmail 11332 invoked by uid 512); 14 Jun 2002 18:15:23 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.04974 secs); 14 Jun 2002 18:15:23 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 14 Jun 2002 18:15:23 -0000 Message-ID: <00a601c213cf$8bf56b30$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Domcan Sami" References: <20020614115049.16384.qmail@email.com> Subject: Re: Kernel - arch support(mips) Date: Fri, 14 Jun 2002 11:15:35 -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 Content-Length: 1101 Lines: 30 linux-mips@oss.sgi.com: Domcan Sami wrote: > I am trying to compile a program using a MIPS-LINUX cross compiler > (gcc). I've set up a connection between my i386 Linux machine and a > MIPS(RM7000) processor. This is again connected to a WinNT Terminal > where there should be an output from the MIPS processor. > > I have 2 kernels in my Linux machine under the directories: > 1) /usr/src/linux - kernel version 2.2.14 > 2) /root/kernels/linux - kernel version 2.4.14 > > I am using a boot image generated from the older kernel for booting. > The problem is the older kernel doesn't support MIPS architecture. > What should I do to upgrade my kernel so that it supports MIPS > architecture & that I'll be able to cross-compile my programs > properly. Please provide more information: 1. What is your target platform -- e.g. make of model of the board or computer that has the RM7000 processor on/in it? 2. Does the target support Linux, does it have a ROM monitor, or is it a raw embedded target (e.g. requires crt0)? David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Fri Jun 14 17:13: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 g5F0DmnC028294 for ; Fri, 14 Jun 2002 17:13:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F0Dm39028293 for linux-mips-outgoing; Fri, 14 Jun 2002 17:13: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 (c-180-196-6.ka.dial.de.ignite.net [62.180.196.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F0DjnC028251 for ; Fri, 14 Jun 2002 17:13:46 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5F0EYv22541 for linux-mips@oss.sgi.com; Sat, 15 Jun 2002 02:14:34 +0200 Received: from msr.hinet.net (msr4.hinet.net [168.95.4.104]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D9llnC026376 for ; Thu, 13 Jun 2002 02:47:47 -0700 Received: from sam (61-220-89-134.HINET-IP.hinet.net [61.220.89.134]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id RAA18744 for ; Thu, 13 Jun 2002 17:50:17 +0800 (CST) Message-ID: <01b701c212bf$b1394850$780411ac@sam> From: "Sam" To: Subject: # CrossCompiler (Big Endian) Date: Thu, 13 Jun 2002 17:50:02 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01C21302.BE4042E0" 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 Content-Length: 1818 Lines: 60 This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C21302.BE4042E0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi everybody, I got some information to build Little Endian CrossCompiler for mips even precompiled binary files, and work well..... However, I have to build a Big Endian's one Should I get the binutil and glibc for big endian firstly? Is there any homepage for reference on web? any sample? thanks all! --Sam ------=_NextPart_000_01B4_01C21302.BE4042E0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi everybody,
 
    I got some information to build = Little=20 Endian CrossCompiler for mips
    even precompiled binary files, = and work=20 well.....
 
    However, I have to build a Big = Endian's=20 one
    Should I get the binutil and = glibc for big=20 endian firstly?
 
    Is there any homepage for = reference on=20 web?
    any sample?
 
    thanks all!
 
--Sam
------=_NextPart_000_01B4_01C21302.BE4042E0-- From owner-linux-mips@oss.sgi.com Sat Jun 15 04:38: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 g5FBcBnC001589 for ; Sat, 15 Jun 2002 04:38:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FBcAPh001588 for linux-mips-outgoing; Sat, 15 Jun 2002 04:38:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FBc5nC001584 for ; Sat, 15 Jun 2002 04:38:06 -0700 Received: from vrazalla.corp.sgi.com (vrazalla.sgi.com [192.26.57.43]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA21967 for ; Sat, 15 Jun 2002 06:40:40 -0500 (CDT) Received: from mail6.triad.rr.com (fe6.southeast.rr.com [24.93.67.53]) by vrazalla.corp.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5FBdexW012551 for ; Sat, 15 Jun 2002 04:40:40 -0700 Received: from mail pickup service by mail6.triad.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:14:50 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.triad.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 16:56:09 -0400 Received: from oss.sgi.com (oss.SGI.COM [128.167.58.27]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKu9Ia002953 for ; Mon, 10 Jun 2002 16:56:09 -0400 (EDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AKrInC027617; Mon, 10 Jun 2002 13:53:18 -0700 Received: from localhost (mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) with SMTP id g5AKrHLV027616; Mon, 10 Jun 2002 13:53:17 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 10 Jun 2002 13:51:17 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AKpHnC027571 for ; Mon, 10 Jun 2002 13:51:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AKpHhN027570 for linux-mips-outgoing; Mon, 10 Jun 2002 13:51:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AKpEnC027567 for ; Mon, 10 Jun 2002 13:51:14 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5AKr6g5274302; Mon, 10 Jun 2002 16:53:08 -0400 Received: from d01ml076.pok.ibm.com (d01ml076.pok.ibm.com [9.117.250.6]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5AKr3m40312; Mon, 10 Jun 2002 16:53:04 -0400 Subject: MIPS RPM binaries now available for LTP. To: ltp-list@lists.sourceforge.net, linux-mips@oss.sgi.com Cc: Carsten Langgaard , Eric LEBOEUF X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Williamson" Date: Mon, 10 Jun 2002 15:52:33 -0500 X-MIMETrack: Serialize by Router on D01ML076/01/M/IBM(Release 5.0.10 |March 28, 2002) at 06/10/2002 04:53:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 437 Lines: 14 Thanks to Carsten Langgaard for volunteering to create the MIPS binary RPMS. Carsten doesn't have time right now to actually run and test the testsuite, so could some MIPS users please download the appropriate binary (big or little endian) and give us feedback. Thanks, - Robbie Robert V. Williamson Linux Test Project IBM Linux Technology Center Phone: (512) 838-9295 T/L: 638-9295 http://ltp.sourceforge.net From owner-linux-mips@oss.sgi.com Sat Jun 15 07:58: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 g5FEwCnC006911 for ; Sat, 15 Jun 2002 07:58:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FEwCcR006910 for linux-mips-outgoing; Sat, 15 Jun 2002 07:58:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail6.triad.rr.com (fe6.southeast.rr.com [24.93.67.53]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FEv3nC006869 for ; Sat, 15 Jun 2002 07:57:03 -0700 Received: from mail pickup service by mail6.triad.rr.com with Microsoft SMTPSVC; Fri, 14 Jun 2002 02:20:13 -0400 Received: from ncmx02.mgw.rr.com ([24.93.67.222]) by mail6.triad.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Jun 2002 17:21:54 -0400 Received: from oss.sgi.com (oss.SGI.COM [128.167.58.27]) by ncmx02.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5AKekIa009950 for ; Mon, 10 Jun 2002 16:40:47 -0400 (EDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AKbtnC027442; Mon, 10 Jun 2002 13:37:55 -0700 Received: from localhost (mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) with SMTP id g5AKbsxv027441; Mon, 10 Jun 2002 13:37:54 -0700 X-Authentication-Warning: oss.sgi.com: mail owned process doing -bs Received: by oss.sgi.com (bulk_mailer v1.13); Mon, 10 Jun 2002 13:35:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AKZnnC027397 for ; Mon, 10 Jun 2002 13:35:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AKZnGZ027396 for linux-mips-outgoing; Mon, 10 Jun 2002 13:35:49 -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 g5AKYenC027389 for ; Mon, 10 Jun 2002 13:34:41 -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 <20020610203655.ESMT1024.sccrmhc01.attbi.com@ocean.lucon.org>; Mon, 10 Jun 2002 20:36:55 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 735E2125C0; Mon, 10 Jun 2002 13:36:52 -0700 (PDT) Date: Mon, 10 Jun 2002 13:36:52 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.11 is released. Message-ID: <20020610133652.A27414@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 Content-Length: 15756 Lines: 571 This is the beta release of binutils 2.12.90.0.11 for Linux, which is based on binutils 2002 0608 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.11 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.9: 1. Update from binutils 2002 0608. 2. Fix an ELF/mips SHF_MERGE bug. 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.11.tar.gz. Source code. 2. binutils-2.12.90.0.9-2.12.90.0.11.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.11-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.11.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 06/10/2002 From owner-linux-mips@oss.sgi.com Sat Jun 15 12:58: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 g5FJwrnC009240 for ; Sat, 15 Jun 2002 12:58:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FJwrvJ009239 for linux-mips-outgoing; Sat, 15 Jun 2002 12:58:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FJwnnC009236 for ; Sat, 15 Jun 2002 12:58:50 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Sat, 15 Jun 2002 16:02:34 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id QAA09024 for ; Sat, 15 Jun 2002 16:01:25 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA25231 for ; Sat, 15 Jun 2002 13:01:24 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA27520 for ; Sat, 15 Jun 2002 13:01:24 -0700 (PDT) Message-ID: <3D0B9D14.BFE27F7E@analog.com> Date: Sat, 15 Jun 2002 13:01:24 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Debugging using GDB and gdbserver Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 413 Lines: 11 How does GDB work under MIPS Linux? I'm trying to do a bring-up of an embedded device, and it looks like the kernel is missing the code needed to handle software breakpoints. Are there patches that need to be applied to the kernel? -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 13:11: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 g5FKBjnC009442 for ; Sat, 15 Jun 2002 13:11:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FKBjl7009441 for linux-mips-outgoing; Sat, 15 Jun 2002 13:11:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FKBgnC009433 for ; Sat, 15 Jun 2002 13:11:42 -0700 Received: from drow by crack.them.org with local (Exim 3.12 #1 (Debian)) id 17JJw6-0004yp-00; Sat, 15 Jun 2002 15:14:14 -0500 Date: Sat, 15 Jun 2002 15:14:13 -0500 From: Daniel Jacobowitz To: Justin Wojdacki Cc: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver Message-ID: <20020615151413.A19123@crack.them.org> References: <3D0B9D14.BFE27F7E@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0B9D14.BFE27F7E@analog.com>; from justin.wojdacki@analog.com on Sat, Jun 15, 2002 at 01:01:24PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 626 Lines: 14 On Sat, Jun 15, 2002 at 01:01:24PM -0700, Justin Wojdacki wrote: > > How does GDB work under MIPS Linux? I'm trying to do a bring-up of an > embedded device, and it looks like the kernel is missing the code > needed to handle software breakpoints. Are there patches that need to > be applied to the kernel? No. If you use a current GDB (I recommend 5.2 or CVS) it should work just fine, if you are using a recent kernel (you didn't mention what version you were looking at). -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University From owner-linux-mips@oss.sgi.com Sat Jun 15 13:27: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 g5FKRQnC009575 for ; Sat, 15 Jun 2002 13:27:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FKRQcS009574 for linux-mips-outgoing; Sat, 15 Jun 2002 13:27:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FKRInC009570 for ; Sat, 15 Jun 2002 13:27:21 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Sat, 15 Jun 2002 16:31:04 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id QAA10191; Sat, 15 Jun 2002 16:29:57 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA25815; Sat, 15 Jun 2002 13:29:56 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA27579; Sat, 15 Jun 2002 13:29:56 -0700 (PDT) Message-ID: <3D0BA3C4.79ED2B5D@analog.com> Date: Sat, 15 Jun 2002 13:29:56 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1362 Lines: 31 Daniel Jacobowitz wrote: > > On Sat, Jun 15, 2002 at 01:01:24PM -0700, Justin Wojdacki wrote: > > > > How does GDB work under MIPS Linux? I'm trying to do a bring-up of an > > embedded device, and it looks like the kernel is missing the code > > needed to handle software breakpoints. Are there patches that need to > > be applied to the kernel? > > No. If you use a current GDB (I recommend 5.2 or CVS) it should work > just fine, if you are using a recent kernel (you didn't mention what > version you were looking at). > > -- > Daniel Jacobowitz Debian GNU/Linux Developer > MontaVista Software Carnegie Mellon University Sorry, I'm using the 2.4.10 kernel and GDB 5.2. What I see happening is the BREAK 5 instruction from a software breakpoint is hit, and the kernel loops continuously on that, as it appears to have no way to deal with that exception. I'm running gdbserver on the MIPS target and gdb as a cross-debugger on an x86 host (RedHat 7.1). To me, it looks like when the debugging breakpoint is hit, gdbserver should get scheduled to run and handle the breakpoint, but instead the child keep's getting scheduled. -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 13:35: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 g5FKZvnC009707 for ; Sat, 15 Jun 2002 13:35:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FKZvSh009706 for linux-mips-outgoing; Sat, 15 Jun 2002 13:35:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FKZpnC009693 for ; Sat, 15 Jun 2002 13:35:52 -0700 Received: from drow by crack.them.org with local (Exim 3.12 #1 (Debian)) id 17JKJc-0004zn-00; Sat, 15 Jun 2002 15:38:32 -0500 Date: Sat, 15 Jun 2002 15:38:31 -0500 From: Daniel Jacobowitz To: Justin Wojdacki Cc: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver Message-ID: <20020615153831.B19123@crack.them.org> References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0BA3C4.79ED2B5D@analog.com>; from justin.wojdacki@analog.com on Sat, Jun 15, 2002 at 01:29:56PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1588 Lines: 33 On Sat, Jun 15, 2002 at 01:29:56PM -0700, Justin Wojdacki wrote: > Daniel Jacobowitz wrote: > > > > On Sat, Jun 15, 2002 at 01:01:24PM -0700, Justin Wojdacki wrote: > > > > > > How does GDB work under MIPS Linux? I'm trying to do a bring-up of an > > > embedded device, and it looks like the kernel is missing the code > > > needed to handle software breakpoints. Are there patches that need to > > > be applied to the kernel? > > > > No. If you use a current GDB (I recommend 5.2 or CVS) it should work > > just fine, if you are using a recent kernel (you didn't mention what > > version you were looking at). > > > > -- > > Daniel Jacobowitz Debian GNU/Linux Developer > > MontaVista Software Carnegie Mellon University > > Sorry, I'm using the 2.4.10 kernel and GDB 5.2. What I see happening > is the BREAK 5 instruction from a software breakpoint is hit, and the > kernel loops continuously on that, as it appears to have no way to > deal with that exception. I'm running gdbserver on the MIPS target and > gdb as a cross-debugger on an x86 host (RedHat 7.1). To me, it looks > like when the debugging breakpoint is hit, gdbserver should get > scheduled to run and handle the breakpoint, but instead the child > keep's getting scheduled. Software breakpoints have worked at least as far back as 2.4.2. This most likely means that the exception handling for your board is broken. -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University From owner-linux-mips@oss.sgi.com Sat Jun 15 13:42: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 g5FKgcnC009910 for ; Sat, 15 Jun 2002 13:42:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FKgcK3009909 for linux-mips-outgoing; Sat, 15 Jun 2002 13:42:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FKgZnC009905 for ; Sat, 15 Jun 2002 13:42:35 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Sat, 15 Jun 2002 16:46:17 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id QAA10862; Sat, 15 Jun 2002 16:45:09 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA26121; Sat, 15 Jun 2002 13:45:08 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id NAA27611; Sat, 15 Jun 2002 13:45:07 -0700 (PDT) Message-ID: <3D0BA753.B0A51BCC@analog.com> Date: Sat, 15 Jun 2002 13:45:07 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 567 Lines: 16 Daniel Jacobowitz wrote: > > Software breakpoints have worked at least as far back as 2.4.2. This > most likely means that the exception handling for your board is broken. > > -- > Daniel Jacobowitz Debian GNU/Linux Developer > MontaVista Software Carnegie Mellon University What exception handling is the board expected to provide? -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 14:14: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 g5FLElnC012189 for ; Sat, 15 Jun 2002 14:14:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FLElJl012188 for linux-mips-outgoing; Sat, 15 Jun 2002 14:14:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FLEgnC012185 for ; Sat, 15 Jun 2002 14:14:42 -0700 Received: (qmail 24331 invoked by uid 512); 15 Jun 2002 21:17:23 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.056607 secs); 15 Jun 2002 21:17:23 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 15 Jun 2002 21:17:22 -0000 Message-ID: <006a01c214b2$22e59280$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Domcan Sami" References: <20020615091631.20470.qmail@email.com> Subject: Re: Kernel - arch support(mips) Date: Sat, 15 Jun 2002 14:16:13 -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 Content-Length: 1216 Lines: 37 linux-mips@oss.sgi.com: > 1)I'm using is a Galileo Board EV64120A. > 2)It is a raw embedded target & does not support Linux. I'm trying to > print a string by compiling code with RM7000 & directing the output > via Serial Port to a WinNT HyperTerminal. Searching on Google, it looks like you have a EV64120A-7000 made by Galileo Technology, Inc.. It is a PCI card that plugs into a PC, and includes the PMON ROM monitor in flash. Galileo appears to have been sold to Marvell (www.marvell.com). I don't see support or search links on the Marvell web site. I don't see Galileo or EV64120A on their product page. I suggest you send them an e-mail asking if and what support is available. I was going to recommend the SDE-MIPS toolkit by Algorithmics, but I don't see your board in their Programmer's Guide. Try asking them if they support it: http://www.algor-uk.com/ To be blunt, trying to make an older, slower, and unsupported board work is going to be difficult. It might not be possible. If you can, get a current, complete, and well-supported MIPS development system -- board, ICE/JTAG, ROM monitor/ embedded OS, development toolchain, etc.. David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Sat Jun 15 14: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 g5FLkxnC012501 for ; Sat, 15 Jun 2002 14:46:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FLkxNG012500 for linux-mips-outgoing; Sat, 15 Jun 2002 14:46:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FLksnC012497 for ; Sat, 15 Jun 2002 14:46:55 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5FLn2x01680; Sat, 15 Jun 2002 14:49:02 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: reenabling interrupts on return from function From: Justin Carlson To: linux-mips@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 Jun 2002 14:49:01 -0700 Message-Id: <1024177741.1549.4.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 806 Lines: 27 I'm obviously missing something basic here. Looking at stackframe.h, I see this code as a part of RESTORE_SOME mfc0 t0, CP0_STATUS; \ .set pop; \ ori t0, 0x1f; \ xori t0, 0x1f; \ mtc0 t0, CP0_STATUS; Here, we're explicitly clearing the IE bit (among others) in the status register, and we leave it cleared. The status register is not touched again until we do an eret. First, why do we explicitly clear the IE bit, when we're running with the EXL bit set? And where is the black magic that is re-enabling interrupts for the return to usermode? I must be missing something really fundamental here. Anyone care to point out my obvious gaps of knowledge? :) Thanks, Justin From owner-linux-mips@oss.sgi.com Sat Jun 15 15:13: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 g5FMDXnC012744 for ; Sat, 15 Jun 2002 15:13:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FMDXbW012743 for linux-mips-outgoing; Sat, 15 Jun 2002 15:13:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FMDTnC012740 for ; Sat, 15 Jun 2002 15:13:30 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Sat, 15 Jun 2002 18:17:15 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb1.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id SAA11501; Sat, 15 Jun 2002 18:16:06 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id PAA27663; Sat, 15 Jun 2002 15:16:05 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id PAA27809; Sat, 15 Jun 2002 15:16:05 -0700 (PDT) Message-ID: <3D0BBCA5.5A0D722A@analog.com> Date: Sat, 15 Jun 2002 15:16:05 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 952 Lines: 24 Daniel Jacobowitz wrote: > > Software breakpoints have worked at least as far back as 2.4.2. This > most likely means that the exception handling for your board is broken. > Sorry, originally misinterpretted your use of "board" as referring to the board itself, and perhaps PMON (I've found a number of references online to GDB talking to PMON, but not much else). So what I've found by looking at other board-specific code revolves around GDB talking to an in-kernel stub via the serial port. As the board I'm working with has an unreliable serial port (and some incarnations don't even have that), what about ethernet-based debugging? Is that do-able, say via putDebugChar() (although I suspect this poses an initialization problem)? Thanks for the info so far. -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 15:20: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 g5FMKQnC012843 for ; Sat, 15 Jun 2002 15:20:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FMKQXN012842 for linux-mips-outgoing; Sat, 15 Jun 2002 15:20:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FMKNnC012839 for ; Sat, 15 Jun 2002 15:20:23 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5FMMTM01743; Sat, 15 Jun 2002 15:22:29 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: reenabling interrupts on return from function From: Justin Carlson To: Justin Carlson Cc: linux-mips@oss.sgi.com In-Reply-To: <1024177741.1549.4.camel@localhost.localdomain> References: <1024177741.1549.4.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 Jun 2002 15:22:28 -0700 Message-Id: <1024179748.1549.12.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 721 Lines: 22 On Sat, 2002-06-15 at 14:49, Justin Carlson wrote: > I'm obviously missing something basic here. > > Looking at stackframe.h, I see this code as a part of RESTORE_SOME > > > mfc0 t0, CP0_STATUS; \ > .set pop; \ > ori t0, 0x1f; \ > xori t0, 0x1f; \ > mtc0 t0, CP0_STATUS; > OK, this was a stupid question; the answer was staring me in the face (the restoration of the status register from the stack), and I didn't see it. However, I still don't see the point of the above code. Why do we explicitly clear bits 4-0 of the status register just before reloading it from the system stack? -Justin From owner-linux-mips@oss.sgi.com Sat Jun 15 15:24: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 g5FMO9nC012929 for ; Sat, 15 Jun 2002 15:24:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FMO9Pa012928 for linux-mips-outgoing; Sat, 15 Jun 2002 15:24:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FMO4nC012923 for ; Sat, 15 Jun 2002 15:24:04 -0700 Received: from drow by crack.them.org with local (Exim 3.12 #1 (Debian)) id 17JM0L-00054O-00; Sat, 15 Jun 2002 17:26:45 -0500 Date: Sat, 15 Jun 2002 17:26:45 -0500 From: Daniel Jacobowitz To: Justin Wojdacki Cc: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver Message-ID: <20020615172645.A19472@crack.them.org> References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> <3D0BBCA5.5A0D722A@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0BBCA5.5A0D722A@analog.com>; from justin.wojdacki@analog.com on Sat, Jun 15, 2002 at 03:16:05PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1420 Lines: 32 On Sat, Jun 15, 2002 at 03:16:05PM -0700, Justin Wojdacki wrote: > Daniel Jacobowitz wrote: > > > > Software breakpoints have worked at least as far back as 2.4.2. This > > most likely means that the exception handling for your board is broken. > > > > Sorry, originally misinterpretted your use of "board" as referring to > the board itself, and perhaps PMON (I've found a number of references > online to GDB talking to PMON, but not much else). > > So what I've found by looking at other board-specific code revolves > around GDB talking to an in-kernel stub via the serial port. As the > board I'm working with has an unreliable serial port (and some > incarnations don't even have that), what about ethernet-based > debugging? Is that do-able, say via putDebugChar() (although I suspect > this poses an initialization problem)? > > Thanks for the info so far. Wait, wait. What are you trying to do? Originally you were talking about userspace debugging via gdbserver. Now you're talking about kernel debugging via kgdb. They're separate (and coexisting can cause problems if you are not careful with your exception handlers; I do not remember when my patches to make that work went into the tree, or if someone else did it). gdbserver can just use TCP. -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University From owner-linux-mips@oss.sgi.com Sat Jun 15 15:37: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 g5FMbdnC014187 for ; Sat, 15 Jun 2002 15:37:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FMbdiv014186 for linux-mips-outgoing; Sat, 15 Jun 2002 15:37:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FMbXnC014183 for ; Sat, 15 Jun 2002 15:37:34 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Sat, 15 Jun 2002 18:41:17 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id SAA15663; Sat, 15 Jun 2002 18:40:09 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id PAA28149; Sat, 15 Jun 2002 15:40:08 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id PAA27867; Sat, 15 Jun 2002 15:40:08 -0700 (PDT) Message-ID: <3D0BC248.16CB7EC2@analog.com> Date: Sat, 15 Jun 2002 15:40:08 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> <3D0BBCA5.5A0D722A@analog.com> <20020615172645.A19472@crack.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1652 Lines: 36 Daniel Jacobowitz wrote: > > Wait, wait. What are you trying to do? Originally you were talking > about userspace debugging via gdbserver. Now you're talking about > kernel debugging via kgdb. They're separate (and coexisting can cause > problems if you are not careful with your exception handlers; I do not > remember when my patches to make that work went into the tree, or if > someone else did it). > > gdbserver can just use TCP. > > -- > Daniel Jacobowitz Debian GNU/Linux Developer > MontaVista Software Carnegie Mellon University Sorry for the confusion. I've been discussing userspace debugging via gdbserver the entire time. However, I've noticed that gdbserver doesn't seem to be fully functional because the kernel doesn't seem to be handling the "BREAK 5" instruction correctly. You mentioned problems with board exception handling and I looked at the ddb series board support code. In there, I found handling for software breakpoints, and got the impression from the code that it was a general debugging interface, not just for kernel debugging. Again, sorry for the confusion. As it stands right now, when I get hit a "BREAK 5" instruction, gdbserver never get's a chance to handle it, as the kernel keeps scheduling the child process I'm trying to debug, and hitting the "BREAK 5" instruction over and over again. What I can't seem to find out is how gdbserver is supposed to get scheduled again. -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 16: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 g5FN0onC015890 for ; Sat, 15 Jun 2002 16:00:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FN0oNB015889 for linux-mips-outgoing; Sat, 15 Jun 2002 16:00:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (mail@crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FN0inC015886 for ; Sat, 15 Jun 2002 16:00:44 -0700 Received: from drow by crack.them.org with local (Exim 3.12 #1 (Debian)) id 17JMZp-00055q-00; Sat, 15 Jun 2002 18:03:25 -0500 Date: Sat, 15 Jun 2002 18:03:25 -0500 From: Daniel Jacobowitz To: Justin Wojdacki Cc: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver Message-ID: <20020615180325.B19472@crack.them.org> References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> <3D0BBCA5.5A0D722A@analog.com> <20020615172645.A19472@crack.them.org> <3D0BC248.16CB7EC2@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0BC248.16CB7EC2@analog.com>; from justin.wojdacki@analog.com on Sat, Jun 15, 2002 at 03:40:08PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2067 Lines: 41 On Sat, Jun 15, 2002 at 03:40:08PM -0700, Justin Wojdacki wrote: > Daniel Jacobowitz wrote: > > > > Wait, wait. What are you trying to do? Originally you were talking > > about userspace debugging via gdbserver. Now you're talking about > > kernel debugging via kgdb. They're separate (and coexisting can cause > > problems if you are not careful with your exception handlers; I do not > > remember when my patches to make that work went into the tree, or if > > someone else did it). > > > > gdbserver can just use TCP. > > > > -- > > Daniel Jacobowitz Debian GNU/Linux Developer > > MontaVista Software Carnegie Mellon University > > Sorry for the confusion. I've been discussing userspace debugging via > gdbserver the entire time. However, I've noticed that gdbserver > doesn't seem to be fully functional because the kernel doesn't seem to > be handling the "BREAK 5" instruction correctly. You mentioned > problems with board exception handling and I looked at the ddb series > board support code. In there, I found handling for software > breakpoints, and got the impression from the code that it was a > general debugging interface, not just for kernel debugging. Again, > sorry for the confusion. > > As it stands right now, when I get hit a "BREAK 5" instruction, > gdbserver never get's a chance to handle it, as the kernel keeps > scheduling the child process I'm trying to debug, and hitting the > "BREAK 5" instruction over and over again. What I can't seem to find > out is how gdbserver is supposed to get scheduled again. What should happen is that the child receives a signal (SIGTRAP) after the exception. Then it is scheduled again, drops into do_signal, and the kernel notices that the traced bit is set and wakes the tracer. I'd guess your board needs to do something different to deliver the SIGTRAP properly, if that isn't happening. -- Daniel Jacobowitz Debian GNU/Linux Developer MontaVista Software Carnegie Mellon University From owner-linux-mips@oss.sgi.com Sat Jun 15 16:03: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 g5FN35nC015961 for ; Sat, 15 Jun 2002 16:03:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FN35J8015960 for linux-mips-outgoing; Sat, 15 Jun 2002 16:03:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FN31nC015957 for ; Sat, 15 Jun 2002 16:03:01 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Sat, 15 Jun 2002 19:06:46 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb1.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id TAA13616; Sat, 15 Jun 2002 19:05:38 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id QAA28695; Sat, 15 Jun 2002 16:05:37 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id QAA27932; Sat, 15 Jun 2002 16:05:36 -0700 (PDT) Message-ID: <3D0BC840.669BEE96@analog.com> Date: Sat, 15 Jun 2002 16:05:36 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: linux-mips@oss.sgi.com Subject: Re: Debugging using GDB and gdbserver References: <3D0B9D14.BFE27F7E@analog.com> <20020615151413.A19123@crack.them.org> <3D0BA3C4.79ED2B5D@analog.com> <20020615153831.B19123@crack.them.org> <3D0BBCA5.5A0D722A@analog.com> <20020615172645.A19472@crack.them.org> <3D0BC248.16CB7EC2@analog.com> <20020615180325.B19472@crack.them.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 732 Lines: 19 Daniel Jacobowitz wrote: > > What should happen is that the child receives a signal (SIGTRAP) after > the exception. Then it is scheduled again, drops into do_signal, and > the kernel notices that the traced bit is set and wakes the tracer. I'd > guess your board needs to do something different to deliver the SIGTRAP > properly, if that isn't happening. > > -- > Daniel Jacobowitz Debian GNU/Linux Developer > MontaVista Software Carnegie Mellon University Okay, thanks for the clarification. :) -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Sat Jun 15 16:51: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 g5FNpEnC016237 for ; Sat, 15 Jun 2002 16:51:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FNpD6D016236 for linux-mips-outgoing; Sat, 15 Jun 2002 16:51:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FNp6nC016233 for ; Sat, 15 Jun 2002 16:51:06 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g5FNjA919900 for ; Sat, 15 Jun 2002 19:45:10 -0400 Received: from mx.hsv.redhat.com (IDENT:root@spot.hsv.redhat.com [172.16.16.7]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g5FNrmr21931; Sat, 15 Jun 2002 19:53:48 -0400 Received: from redhat.com (slurm.hsv.redhat.com [172.16.16.102]) by mx.hsv.redhat.com (8.11.6/8.11.0) with ESMTP id g5FNsag23222; Sat, 15 Jun 2002 18:54:36 -0500 Message-ID: <3D0BD42E.20602@redhat.com> Date: Sat, 15 Jun 2002 18:56:30 -0500 From: Louis Hamilton User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: sandcraft-elinux-project@redhat.com, hamilton@redhat.com Subject: Bug in Linux? fcr31 not being saved-restored Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1899 Lines: 56 We have a customer here testing a 2.4.16 mips kernel on an embedded Linux RM7000/SR71000 based system who has written a test that they believe has uncovered a bug in Linux. The FPU control register appears to not get saved and restored. I've reproduced the problem described below and find the results consistent with their description. The problem occurs on both the RM7000 and SR71000 cpus. It looks like save_fp_context and restore_fp_context are not being called since the kernel save-restore logic thinks the process is not using floating point math. If you do some fp math before calling the test routine below, it seems to works fine. Is this a known caveat? A true bug? Or a contorted corner case unlikely to be seen under typical end-user usage (see customer's last paragraph :-) ? If true bug, recommended remedy? TIA, Louis Louis Hamilton hamilton@redhat.com ------ customer reports the following: --------- We found a bug in Linux. A ^C (control-C) typed into a shell (or a running program, it doesn't matter), causes the FCR (floating-point control register) to be corrupted in another, unrelated process. This is repeatable behavior. This can be reproduced with the following short assembly language program that loops forever, waiting for the FCR to change. .align 2 .globl mips_float_debug_loop mips_float_debug_loop: li $9, 0xF000F02F ctc1 $9, $31 # set FCR to some non-zero value nop 1: cfc1 $8, $31 # get FCR beq $8, $9, 1b # spin, waiting for FCR to change nop or $2, $0, $8 jr $31 nop You can call this function from a short C program and the return value is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. Run the above loop in one window (connected to the board using telnet) and then in another window (connected to the same board) type ^C. I'm surprised this bug hasn't been encountered by other MIPS vendors. From owner-linux-mips@oss.sgi.com Sun Jun 16 23:17: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 g5H6HinC011971 for ; Sun, 16 Jun 2002 23:17:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5H6Hijl011970 for linux-mips-outgoing; Sun, 16 Jun 2002 23:17:44 -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 g5H6HZnC011962 for ; Sun, 16 Jun 2002 23:17:35 -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 XAA05457; Sun, 16 Jun 2002 23:20:07 -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 XAA10192; Sun, 16 Jun 2002 23:20:09 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5H6K9b13541; Mon, 17 Jun 2002 08:20:09 +0200 (MEST) Message-ID: <3D0D7F98.566B3176@mips.com> Date: Mon, 17 Jun 2002 08:20:09 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Louis Hamilton CC: linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2569 Lines: 70 This is one of the bugs, among others, we have fixed. I'm not sure, if Ralf have integrated the patches we send him yet. /Carsten Louis Hamilton wrote: > We have a customer here testing a 2.4.16 mips kernel on an embedded > Linux RM7000/SR71000 based system who has written a test that they > believe has uncovered a bug in Linux. The FPU control register appears > to not get saved and restored. I've reproduced the problem described > below and find the results consistent with their description. The > problem occurs on both the RM7000 and SR71000 cpus. > > It looks like save_fp_context and restore_fp_context are not being > called since the kernel save-restore logic thinks the process is not > using floating point math. If you do some fp math before calling the > test routine below, it seems to works fine. > > Is this a known caveat? A true bug? Or a contorted corner case > unlikely to be seen under typical end-user usage (see customer's > last paragraph :-) ? If true bug, recommended remedy? > > TIA, > Louis > > Louis Hamilton > hamilton@redhat.com > > ------ customer reports the following: --------- > We found a bug in Linux. A ^C (control-C) typed into a shell (or a > running program, it doesn't matter), causes the FCR (floating-point > control register) to be corrupted in another, unrelated process. This > is repeatable behavior. > > This can be reproduced with the following short assembly language > program that loops forever, waiting for the FCR to change. > > .align 2 > .globl mips_float_debug_loop > mips_float_debug_loop: > li $9, 0xF000F02F > ctc1 $9, $31 # set FCR to some non-zero value > nop > 1: cfc1 $8, $31 # get FCR > beq $8, $9, 1b # spin, waiting for FCR to change > nop > or $2, $0, $8 > jr $31 > nop > > You can call this function from a short C program and the return value > is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. > > Run the above loop in one window (connected to the board using telnet) > and then in another window (connected to the same board) type ^C. > > I'm surprised this bug hasn't been encountered by other MIPS vendors. > > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jun 17 01:35: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 g5H8ZhnC013800 for ; Mon, 17 Jun 2002 01:35:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5H8Zhbn013799 for linux-mips-outgoing; Mon, 17 Jun 2002 01:35:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from inetmg.sony.com.sg (inetmg.sony.com.sg [202.42.154.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5H8ZbnC013794 for ; Mon, 17 Jun 2002 01:35:39 -0700 Received: from seagw01.sony.com.sg (firewall-user@seagw [43.68.8.1]) by inetmg.sony.com.sg (8.10.2+Sun/8.10.2) with ESMTP id g5H8jXi25445 for ; Mon, 17 Jun 2002 16:45:38 +0800 (SGT) Received: from sapsgssdibh01.ap.sony.com (localhost [127.0.0.1]) by seagw01.sony.com.sg (8.11.6+Sun/8.11.6) with ESMTP id g5H8at228321 for ; Mon, 17 Jun 2002 16:36:55 +0800 (SGT) Received: from sapinsardexc01.sard.in.sony.com.sg (SAPINSARDEXC01 [43.88.102.8]) by sapsgssdibh01.ap.sony.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M4YKY3ZT; Mon, 17 Jun 2002 16:36:53 +0800 Received: from Aditya.ap.sony.com (43.88.102.16 [43.88.102.16]) by sapinsardexc01.sard.in.sony.com.sg with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JF0D3GDL; Mon, 17 Jun 2002 14:17:53 +0530 Message-Id: <4.3.2.7.0.20020617140608.00b9f640@43.88.102.8> X-Sender: apinsard/aditya/aditya.ps@43.88.102.8 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jun 2002 14:07:46 +0530 To: linux-mips@oss.sgi.com From: aditya Subject: regarding jal instruction in mips Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 321 Lines: 17 hello, I have a doubt w.r.t. Linux on mips. in mips there is a instruction jal which jumps across 256 MB boundry. but this is a restriction as shared text (libraries) and private text (program's text) should be located within 256 MB boundry. Is it true ?? how this problem is solved in linux ??? Thanks Aditya From owner-linux-mips@oss.sgi.com Mon Jun 17 02:46: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 g5H9kAnC014461 for ; Mon, 17 Jun 2002 02:46:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5H9kAZk014460 for linux-mips-outgoing; Mon, 17 Jun 2002 02:46:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-2.us4.outblaze.com (205-158-62-92.outblaze.com [205.158.62.92]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5H9k7nC014457 for ; Mon, 17 Jun 2002 02:46:07 -0700 Received: (qmail 30732 invoked by uid 1001); 17 Jun 2002 09:48:51 -0000 Message-ID: <20020617094851.30730.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-2.us4.outblaze.com with http for balakris_ananth@email.com; Mon, 17 Jun 2002 04:48:51 -0500 From: "Balakrishnan Ananthanarayanan" To: linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, redhat-list@redhat.com Date: Mon, 17 Jun 2002 04:48:51 -0500 Subject: Code error - why? X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-2.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 670 Lines: 23 I wrote a SAMPLE CODE - Hello.S to work for a cross-assembler mips-linux-as - but this is giving me an error message: ".data quest: .asciiz "Hello World!" .text _start: la $a0, quest li $v0, 4 syscall " The error messages are: " Hello.S line 5: illegal operands 'la' Hello.S line 6: illegal operands 'li'" Can anyone help? What is wrong? -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Mon Jun 17 03:54: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 g5HAsXnC015080 for ; Mon, 17 Jun 2002 03:54:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HAsXSn015079 for linux-mips-outgoing; Mon, 17 Jun 2002 03:54:33 -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 g5HAsTnC015076 for ; Mon, 17 Jun 2002 03:54:29 -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 DAA06148 for ; Mon, 17 Jun 2002 03:57:12 -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 DAA19991 for ; Mon, 17 Jun 2002 03:57:12 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5HAvBb08679 for ; Mon, 17 Jun 2002 12:57:11 +0200 (MEST) Message-ID: <3D0DC086.27BFAA1D@mips.com> Date: Mon, 17 Jun 2002 12:57:10 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: PCI DMA transfer Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1042 Lines: 25 I can see the 'dma_cache_inv_pc' routines (in the arch/mips/mm cache files), in almost every incarnation, is actually doing a write-back invalidation, why ? My first thought was, that this will never work for the PCI devices doing DMA, so I was wondering why it actually does work. And the answer is, that this routine isn't used by the PCI DMA functions, no matter what the DIRECTION of the DMA transfer is. Has anyone got an idea why the while PCI DMA stuff is implemented this way (only using write-back invalidations) ? I would expect that we did a write-back invalidation of the D-cache, when the direction was PCI_DMA_TODEVICE and only did invalidation of the D-cache, when the direction was PCI_DMA_FROMDEVICE. /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 Mon Jun 17 04:14: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 g5HBEPnC015722 for ; Mon, 17 Jun 2002 04:14:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HBEPHP015721 for linux-mips-outgoing; Mon, 17 Jun 2002 04:14:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from oval.algor.co.uk (root@oval.algor.co.uk [62.254.210.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HBEJnC015718 for ; Mon, 17 Jun 2002 04:14:20 -0700 Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g5HBH4Y02821; Mon, 17 Jun 2002 12:17:04 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id MAA17773; Mon, 17 Jun 2002 12:17:03 +0100 (BST) Date: Mon, 17 Jun 2002 12:17:03 +0100 (BST) Message-Id: <200206171117.MAA17773@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aditya Cc: linux-mips@oss.sgi.com Subject: Re: regarding jal instruction in mips In-Reply-To: <4.3.2.7.0.20020617140608.00b9f640@43.88.102.8> References: <4.3.2.7.0.20020617140608.00b9f640@43.88.102.8> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1058 Lines: 28 aditya (aditya.ps@ap.sony.com) writes: > I have a doubt w.r.t. Linux on mips. > > in mips there is a instruction jal which jumps across 256 MB > boundry. but this is a restriction as shared text (libraries) and > private text (program's text) should be located within 256 MB > boundry. Is it true ?? In the usual Linux address map it isn't true: library code might easily fail to be in the same 256Mbyte 'chunk' of virtual memory. Linux/MIPS applications implement calls between modules (and for relocatable libraries, calls inside modules too) with an indirection through a table of pointers - the "global access table" or GOT. We normally think of this as a way of providing suitably position-independent code... There's a fair description of this in my book "See MIPS Run" under the heading "Sharing Library Code in the MIPS ABI" - Chapter 10 or so. -- Dominic Sweetman, Algorithmics Ltd The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From owner-linux-mips@oss.sgi.com Mon Jun 17 04:32: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 g5HBWunC015886 for ; Mon, 17 Jun 2002 04:32:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HBWuIc015885 for linux-mips-outgoing; Mon, 17 Jun 2002 04:32:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from kopretinka (mail@p030.as-l025.contactel.cz [212.65.234.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HBWmnC015881 for ; Mon, 17 Jun 2002 04:32:50 -0700 Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian)) id 17Juky-0000EG-00 for ; Mon, 17 Jun 2002 13:33:12 +0200 Date: Mon, 17 Jun 2002 13:33:11 +0200 To: linux-mips@oss.sgi.com Subject: DBE/IBE handling incompatibility Message-ID: <20020617113311.GA839@kopretinka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Ladislav Michl Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 971 Lines: 19 hi, i'd like to release GIO64 bus support. Before doing so DBE/IBE handling should be done in the same fashion for both mips and mips64 (*). Currently mips is using handler in handler via dbe_board_handler and ibe_board_handler which are not used anywhere while mips64 is using BUILD_HANDLER macro defined in include/asm-mips64/exception.h (see arch/mips64/sgi-ip27/ip27-dbe-glue.S) Unfortunately I have nearly zero knowledge of MIPS assembler, so I'm unable to code mips way same as mips64 is... Help from someone more experienced will be greatly appreciated :-) (*) How GIO device detection works? each IP22 machine contains three GIO bus slots. GIO device provides information about itself in first (three) word(s) of address space it occupies. The only way how to detect GIO card is trying to read word from it's base address. If DBE exception is generated then there is definitely no card present, otherwise read value encodes information about device. ladis From owner-linux-mips@oss.sgi.com Mon Jun 17 04:51: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 g5HBpKnC016074 for ; Mon, 17 Jun 2002 04:51:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HBpKJJ016073 for linux-mips-outgoing; Mon, 17 Jun 2002 04:51:20 -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 g5HBp6nC016069 for ; Mon, 17 Jun 2002 04:51:06 -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 EAA06248 for ; Mon, 17 Jun 2002 04:53:48 -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 EAA21993 for ; Mon, 17 Jun 2002 04:53:49 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5HBrmb14619 for ; Mon, 17 Jun 2002 13:53:48 +0200 (MEST) Message-ID: <3D0DCDCB.252F5565@mips.com> Date: Mon, 17 Jun 2002 13:53:47 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: __access_ok Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3467 Lines: 110 The __access_ok macro in include/asm-mips64/uaccess.h need to be changed in order to work correctly, it's a copy from the 32-bit kernel. It's not good enough to simply check for the "sign bit" of the address. The area between USEG (XUSEG) and KSEG0 will in 64-bit addressing mode generate an address error, if accessed. The size of the area depend on the number of virtual addressing bits, implemented in the CPU. I have tried to come up with a patch, please see below. Any thought ? I also changed the macro in arch/mips64/kernel/unaligned.c /Carsten Index: include/asm-mips64//uaccess.h =================================================================== RCS file: /home/repository/sw/linux-2.4.18/include/asm-mips64/uaccess.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 uaccess.h --- include/asm-mips64//uaccess.h 4 Mar 2002 11:13:26 -0000 1.1.1.1 +++ include/asm-mips64//uaccess.h 17 Jun 2002 11:35:32 -0000 @@ -12,6 +12,8 @@ #include #include +#include + #define STR(x) __STR(x) #define __STR(x) #x @@ -40,16 +42,23 @@ * than tests. * * Address valid if: - * - "addr" doesn't have any high-bits set - * - AND "size" doesn't have any high-bits set - * - AND "addr+size" doesn't have any high-bits set - * - OR we are in kernel mode. + * - In user mode and "addr" and "addr+size" in USEG (or XUSEG). + * - OR we are in kernel mode and "addr" and "addr+size" isn't in the + * area between USEG (XUSEG) and KSEG0. */ #define __ua_size(size) \ (__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : (size)) -#define __access_ok(addr,size,mask) \ - (((signed long)((mask)&(addr | (addr + size) | __ua_size(size)))) >= 0) +static inline int +__access_ok(unsigned long addr, unsigned long size, long mask) +{ + if (((mask) && ((addr | (addr+size)) >= KUSIZE)) || + (((addr | (addr+size)) < K0BASE) && + ((addr | (addr+size)) >= KUSIZE))) + return 0; + else + return 1; +} #define __access_mask ((long)(get_fs().seg)) Index: arch/mips64/kernel/unaligned.c =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips64/kernel/unaligned.c,v retrieving revision 1.2 diff -u -r1.2 unaligned.c --- arch/mips64/kernel/unaligned.c 23 May 2002 11:11:45 -0000 1.2 +++ arch/mips64/kernel/unaligned.c 17 Jun 2002 11:51:30 -0000 @@ -89,11 +89,14 @@ #define __STR(x) #x /* - * User code may only access USEG; kernel code may access the - * entire address space. + * User code may only access USEG; + * Kernel code may access the entire address space, except the area between + * USEG (XUSEG) and KSEG0. */ -#define check_axs(pc,a,s) \ - if ((long)(~(pc) & ((a) | ((a)+(s)))) < 0) \ +#define check_axs(pc,a,s) \ + if (((pc < KUSIZE) && (((a) | ((a)+(s))) >= KUSIZE)) || \ + ((((a) | ((a)+(s))) < K0BASE) && \ + (((a) | ((a)+(s))) >= KUSIZE))) \ goto sigbus; -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jun 17 09: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 g5HGMinC025295 for ; Mon, 17 Jun 2002 09:22:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HGMi6x025294 for linux-mips-outgoing; Mon, 17 Jun 2002 09:22:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HGMfnC025291 for ; Mon, 17 Jun 2002 09:22:41 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HGOxT01910; Mon, 17 Jun 2002 09:24:59 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: __access_ok From: Justin Carlson To: Carsten Langgaard Cc: linux-mips@oss.sgi.com In-Reply-To: <3D0DCDCB.252F5565@mips.com> References: <3D0DCDCB.252F5565@mips.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 17 Jun 2002 09:24:58 -0700 Message-Id: <1024331098.1463.3.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 718 Lines: 18 On Mon, 2002-06-17 at 04:53, Carsten Langgaard wrote: > * Address valid if: > - * - "addr" doesn't have any high-bits set > - * - AND "size" doesn't have any high-bits set > - * - AND "addr+size" doesn't have any high-bits set > - * - OR we are in kernel mode. > + * - In user mode and "addr" and "addr+size" in USEG (or XUSEG). > + * - OR we are in kernel mode and "addr" and "addr+size" isn't in the > + * area between USEG (XUSEG) and KSEG0. You also need to test for high bit set in size. Otherwise, for example, if a process was ok to access range 0x40000000-0x40003fff, access_ok(0x40001000, 0xfffff100) would return 1. The addition will wrap around, leading to all sorts of fun havoc. -Justin From owner-linux-mips@oss.sgi.com Mon Jun 17 09:26: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 g5HGQtnC025418 for ; Mon, 17 Jun 2002 09:26:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HGQtxU025417 for linux-mips-outgoing; Mon, 17 Jun 2002 09:26:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HGQonC025414 for ; Mon, 17 Jun 2002 09:26:51 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Mon, 17 Jun 2002 12:30:26 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb1.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id MAA06968; Mon, 17 Jun 2002 12:29:17 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id JAA02224; Mon, 17 Jun 2002 09:29:15 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id JAA02742; Mon, 17 Jun 2002 09:29:15 -0700 (PDT) Message-ID: <3D0E0E5B.C41AC2DF@analog.com> Date: Mon, 17 Jun 2002 09:29:15 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Balakrishnan Ananthanarayanan CC: linux-mips@oss.sgi.com Subject: Re: Code error - why? References: <20020617094851.30730.qmail@email.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 887 Lines: 30 Balakrishnan Ananthanarayanan wrote: > > I wrote a SAMPLE CODE - Hello.S to work for a cross-assembler mips-linux-as - but this is giving me an error message: > ".data > quest: .asciiz "Hello World!" > .text > _start: > la $a0, quest > li $v0, 4 > syscall " > > The error messages are: > " Hello.S line 5: illegal operands 'la' > Hello.S line 6: illegal operands 'li'" > > Can anyone help? What is wrong? > $a0 and $v0 are what's probably giving you grief. Are you relying on the assembler to know these symbols or are you including a file that defines them. Just to be sure, try replacing $a0 with $4 and $v0 with $2 and see if the code builds. -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Mon Jun 17 09:52: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 g5HGqYnC026022 for ; Mon, 17 Jun 2002 09:52:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HGqYY2026021 for linux-mips-outgoing; Mon, 17 Jun 2002 09:52:34 -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 g5HGqUnC026018 for ; Mon, 17 Jun 2002 09:52:31 -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 17Jzky-000aPg-00 for linux-mips@oss.sgi.com; Mon, 17 Jun 2002 18:53:32 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17Jzmc-0004pJ-00 for ; Mon, 17 Jun 2002 18:55:14 +0200 Date: Mon, 17 Jun 2002 18:55:14 +0200 To: linux-mips@oss.sgi.com Subject: Re: Code error - why? Message-ID: <20020617165514.GF8626@rembrandt.csv.ica.uni-stuttgart.de> References: <20020617094851.30730.qmail@email.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617094851.30730.qmail@email.com> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 457 Lines: 18 Balakrishnan Ananthanarayanan wrote: [snip] > la $a0, quest > li $v0, 4 > syscall " > > The error messages are: > " Hello.S line 5: illegal operands 'la' > Hello.S line 6: illegal operands 'li'" > > Can anyone help? What is wrong? The register names are wrong. The software names, if defined in some assembler header, are 'a0' and 'v0', while the assembler recognized hardware names are '$4' and '$2'. Thiemo From owner-linux-mips@oss.sgi.com Mon Jun 17 10:17: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 g5HHHgnC026326 for ; Mon, 17 Jun 2002 10:17:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HHHgMg026325 for linux-mips-outgoing; Mon, 17 Jun 2002 10:17: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-141.ayrnetworks.com [64.166.72.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HHHXnC026322 for ; Mon, 17 Jun 2002 10:17:33 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g5HHH8828454; Mon, 17 Jun 2002 10:17:08 -0700 Date: Mon, 17 Jun 2002 10:17:08 -0700 From: William Jhun To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: PCI DMA transfer Message-ID: <20020617101708.A28405@ayrnetworks.com> References: <3D0DC086.27BFAA1D@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: <3D0DC086.27BFAA1D@mips.com>; from carstenl@mips.com on Mon, Jun 17, 2002 at 12:57:10PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3070 Lines: 62 On Mon, Jun 17, 2002 at 12:57:10PM +0200, Carsten Langgaard wrote: > I can see the 'dma_cache_inv_pc' routines (in the arch/mips/mm cache > files), in almost every incarnation, is actually doing a write-back > invalidation, why ? > My first thought was, that this will never work for the PCI devices > doing DMA, so I was wondering why it actually does work. It ought to work, though it's just not as efficient. One clear problem is that there is no wback/inv on pci_unmap_{single,sg}(). This will cause a problem when a driver: - calls pci_map_single() - DMAs into the buffer - calls pci_dma_sync_single() [eg, a buffer smaller than rx_copybreak in tulip] - copies the buffer - returns the buffer to the device - does another DMA transfer - this time calls pci_unmap_single() [eg, buffer > rx_copybreak] Clearly, stale cache lines will remain after the first buffer copy. For the time being, we can just put the flush in the pci_unmap_* calls. This is also pretty lame as we are always needlessly flushing the cache one extra time (in the map *and* in the unmap. Or in the map and in the dma_sync). I've proposed some API changes to Dave Miller that should solve this problem. Hopefully they'll be integrated in some way and we can enjoy both correctness and optimal performance. :o) (BTW, we've found that the performance implications of getting this stuff right *IS* significant, and there is indeed a noticeable difference between doing an invalidate and a writeback-invalidate, even if there is nothing to write back.) > And the answer is, that this routine isn't used by the > PCI DMA functions, no matter what the DIRECTION of the DMA transfer is. > Has anyone got an idea why the while PCI DMA stuff is implemented this > way (only using write-back invalidations) ? Broken cache routines? Apathy? :o) Most likely that this hasn't hit a lot of people yet... (see below) > I would expect that we did a write-back invalidation of the D-cache, > when the direction was PCI_DMA_TODEVICE and only did invalidation of the > D-cache, when the direction was PCI_DMA_FROMDEVICE. I sent out a patch to change this a while ago, but it got dropped since most implementations of dma_cache_wback() just call BUG(). I've been meaning to get a patch ready for this as well, but haven't had the time. Well, it's a slow Monday morning, so maybe I'll do it now. :o) For architectures that can only do a wback/inv and not an inv or wback by itself, it should be suitable to do a wback/inv in place. In effect, an invalidate or writeback should only be requested as a performance enhancement, and should not differ in correctness when replaced with a writeback-invalidate. As such, code should not write something to cache, do an invalidate some measured amount of time later and expect the write to be completely invalidated. Is it reasonable to expect that code will not do this? And doing a wback/inv in place of a wback does not seem harmful to me... At least, I can't think of a case where it would be. Agree? Disagree? I'll put together some patches shortly... Will From owner-linux-mips@oss.sgi.com Mon Jun 17 11:18: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 g5HIIWnC028003 for ; Mon, 17 Jun 2002 11:18:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HIIWmj028002 for linux-mips-outgoing; Mon, 17 Jun 2002 11:18:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HIINnC027998; Mon, 17 Jun 2002 11:18:23 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HIKh802005; Mon, 17 Jun 2002 11:20:43 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: system.h asm fixes From: Justin Carlson To: linux-mips@oss.sgi.com Cc: ralf@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 17 Jun 2002 11:20:42 -0700 Message-Id: <1024338042.1463.21.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 802 Lines: 43 Looks to me like we're missing some proper asm clobber markers: diff -u -r1.13 system.h --- system.h 4 Feb 2002 17:35:51 -0000 1.13 +++ system.h 17 Jun 2002 18:18:56 -0000 @@ -41,7 +41,8 @@ "__sti" : /* no outputs */ : /* no inputs */ - : "memory"); + : "$1","memory" + ); } /* @@ -73,7 +74,7 @@ "__cli" : /* no outputs */ : /* no inputs */ - : "memory"); + : "$1","memory"); } __asm__ ( @@ -110,7 +111,7 @@ "__save_and_cli\t%0" \ : "=r" (x) \ : /* no inputs */ \ - : "memory") + : "$1","memory") __asm__(".macro\t__restore_flags flags\n\t" ".set\tpush\n\t" @@ -136,7 +137,7 @@ "__restore_flags\t%0" \ : "=r" (__tmp1) \ : "0" (flags) \ - : "memory"); \ + : "$1","memory"); \ } while(0) #ifdef CONFIG_SMP From owner-linux-mips@oss.sgi.com Mon Jun 17 12:33: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 g5HJXJnC029098 for ; Mon, 17 Jun 2002 12:33:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HJXJlR029097 for linux-mips-outgoing; Mon, 17 Jun 2002 12:33:19 -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 g5HJX7nC029094 for ; Mon, 17 Jun 2002 12:33:07 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA05594; Mon, 17 Jun 2002 12:33:18 -0700 Message-ID: <3D0E38E8.10804@mvista.com> Date: Mon, 17 Jun 2002 12:30:48 -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: Carsten Langgaard CC: Louis Hamilton , linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> <3D0D7F98.566B3176@mips.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2906 Lines: 90 Carsten Langgaard wrote: > This is one of the bugs, among others, we have fixed. > I'm not sure, if Ralf have integrated the patches we send him yet. > Carsten, Do you remember the cause and the fix? It appears to me the first ctc1 instruction should trap into kernel and mark current process as fpu owner, and should not cause fcr31 corruption. Or somehow the ctc1 does not trap into kernel? Jun > /Carsten > > Louis Hamilton wrote: > > >>We have a customer here testing a 2.4.16 mips kernel on an embedded >>Linux RM7000/SR71000 based system who has written a test that they >>believe has uncovered a bug in Linux. The FPU control register appears >>to not get saved and restored. I've reproduced the problem described >>below and find the results consistent with their description. The >>problem occurs on both the RM7000 and SR71000 cpus. >> >>It looks like save_fp_context and restore_fp_context are not being >>called since the kernel save-restore logic thinks the process is not >>using floating point math. If you do some fp math before calling the >>test routine below, it seems to works fine. >> >>Is this a known caveat? A true bug? Or a contorted corner case >>unlikely to be seen under typical end-user usage (see customer's >>last paragraph :-) ? If true bug, recommended remedy? >> >>TIA, >>Louis >> >>Louis Hamilton >>hamilton@redhat.com >> >>------ customer reports the following: --------- >>We found a bug in Linux. A ^C (control-C) typed into a shell (or a >>running program, it doesn't matter), causes the FCR (floating-point >>control register) to be corrupted in another, unrelated process. This >>is repeatable behavior. >> >>This can be reproduced with the following short assembly language >>program that loops forever, waiting for the FCR to change. >> >> .align 2 >> .globl mips_float_debug_loop >>mips_float_debug_loop: >> li $9, 0xF000F02F >> ctc1 $9, $31 # set FCR to some non-zero value >> nop >>1: cfc1 $8, $31 # get FCR >> beq $8, $9, 1b # spin, waiting for FCR to change >> nop >> or $2, $0, $8 >> jr $31 >> nop >> >>You can call this function from a short C program and the return value >>is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. >> >>Run the above loop in one window (connected to the board using telnet) >>and then in another window (connected to the same board) type ^C. >> >>I'm surprised this bug hasn't been encountered by other MIPS vendors. >> >> >> > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > > From owner-linux-mips@oss.sgi.com Mon Jun 17 12: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 g5HJeYnC029225 for ; Mon, 17 Jun 2002 12:40:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HJeY3L029224 for linux-mips-outgoing; Mon, 17 Jun 2002 12:40:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nevyn.them.org (01-042.118.popsite.net [66.19.120.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HJeRnC029221; Mon, 17 Jun 2002 12:40:28 -0700 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17K2PB-0003m4-00; Mon, 17 Jun 2002 15:43:13 -0400 Date: Mon, 17 Jun 2002 15:43:12 -0400 From: Daniel Jacobowitz To: Justin Carlson Cc: linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: system.h asm fixes Message-ID: <20020617194312.GA14489@nevyn.them.org> References: <1024338042.1463.21.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1024338042.1463.21.camel@localhost.localdomain> User-Agent: Mutt/1.5.1i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 522 Lines: 11 On Mon, Jun 17, 2002 at 11:20:42AM -0700, Justin Carlson wrote: > Looks to me like we're missing some proper asm clobber markers: Not really, I think those actually caused a problem at some point but that might be my imagination. They certainly aren't necessary. The compiler can not use $1 for anything, because it doesn't know what the assembler might be doing with it. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Jun 17 13:02: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 g5HK24nC029666 for ; Mon, 17 Jun 2002 13:02:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HK24la029665 for linux-mips-outgoing; Mon, 17 Jun 2002 13:02:04 -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 g5HK22nC029662 for ; Mon, 17 Jun 2002 13:02:02 -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 g5HK4djf007898; Mon, 17 Jun 2002 13:04:39 -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 g5HK4dan007893; Mon, 17 Jun 2002 13:04:39 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 17 Jun 2002 13:04:39 -0700 (PDT) From: James Simmons To: Pavel Machek cc: Linux Fbdev development list , Linux Kernel Mailing List , , Subject: Re: tx3912 Re: [PATCH] fbdev updates. In-Reply-To: <20020606211252.GA1112@elf.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 424 Lines: 12 > Hi! > > > This patch includes the latest in the fbdev BK repository. I have > > modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the > > new api. Please test these changes out before I submit them to linus. > > Thank you. It is against the latest BK tree and 2.5.20. > > Does the code even boot on any machine having tx3912fb? Yes :-) Also a few other types of MIPS devices use this framebuffer. From owner-linux-mips@oss.sgi.com Mon Jun 17 13:44: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 g5HKiQnC030155 for ; Mon, 17 Jun 2002 13:44:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HKiQ8O030154 for linux-mips-outgoing; Mon, 17 Jun 2002 13:44:26 -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 (c-180-196-76.ka.dial.de.ignite.net [62.180.196.76]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HKiLnC030148 for ; Mon, 17 Jun 2002 13:44:23 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5HKiqJ27026; Mon, 17 Jun 2002 22:44:52 +0200 Date: Mon, 17 Jun 2002 22:44:52 +0200 From: Ralf Baechle To: Justin Carlson Cc: linux-mips@oss.sgi.com Subject: Re: system.h asm fixes Message-ID: <20020617224452.C27009@dea.linux-mips.net> References: <1024338042.1463.21.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1024338042.1463.21.camel@localhost.localdomain>; from justin@cs.cmu.edu on Mon, Jun 17, 2002 at 11:20:42AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 506 Lines: 13 In-Reply-To: <1024338042.1463.21.camel@localhost.localdomain>; from justin@cs.cmu.edu on Mon, Jun 17, 2002 at 11:20:42AM -0700 You may consider configuring a hostname for your machine :) On Mon, Jun 17, 2002 at 11:20:42AM -0700, Justin Carlson wrote: > Looks to me like we're missing some proper asm clobber markers: No, as per convention $1 is never used by the compiler per convention, so clobbering not necessary. I recently removed all "$1" clobbers to make the code a bit easier to read. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 17 13:44: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 g5HKimnC030182 for ; Mon, 17 Jun 2002 13:44:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HKimco030180 for linux-mips-outgoing; Mon, 17 Jun 2002 13:44: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 g5HKiinC030175; Mon, 17 Jun 2002 13:44:44 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) 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 NAA02332; Mon, 17 Jun 2002 13:47:22 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) 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 17K2bz-000b8W-00; Mon, 17 Jun 2002 21:56:27 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17K2df-0005PH-00; Mon, 17 Jun 2002 21:58:11 +0200 Date: Mon, 17 Jun 2002 21:58:11 +0200 To: Daniel Jacobowitz Cc: Justin Carlson , linux-mips@oss.sgi.com, ralf@oss.sgi.com Subject: Re: system.h asm fixes Message-ID: <20020617195811.GA20335@rembrandt.csv.ica.uni-stuttgart.de> References: <1024338042.1463.21.camel@localhost.localdomain> <20020617194312.GA14489@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617194312.GA14489@nevyn.them.org> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 487 Lines: 13 Daniel Jacobowitz wrote: > On Mon, Jun 17, 2002 at 11:20:42AM -0700, Justin Carlson wrote: > > Looks to me like we're missing some proper asm clobber markers: > > Not really, I think those actually caused a problem at some point but > that might be my imagination. They certainly aren't necessary. The > compiler can not use $1 for anything, because it doesn't know what the > assembler might be doing with it. But other assembler routines which run in the meantime may do. Thiemo From owner-linux-mips@oss.sgi.com Mon Jun 17 13:55: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 g5HKtJnC030514 for ; Mon, 17 Jun 2002 13:55:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HKtJIW030513 for linux-mips-outgoing; Mon, 17 Jun 2002 13:55:19 -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] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HKt2nC030508 for ; Mon, 17 Jun 2002 13:55:03 -0700 Received: from av.mvista.com (gateway-1237.mvista.com [12.44.186.158]) 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 ESMTP id NAA05660 for ; Mon, 17 Jun 2002 13:57:49 -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 MAA06259; Mon, 17 Jun 2002 12:57:38 -0700 Message-ID: <3D0E3E9C.4070702@mvista.com> Date: Mon, 17 Jun 2002 12:55:08 -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: Carsten Langgaard CC: linux-mips@oss.sgi.com Subject: Re: __access_ok References: <3D0DCDCB.252F5565@mips.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3791 Lines: 119 Just to be nit-picking, the end point should be (addr + size - 1). Jun Carsten Langgaard wrote: > The __access_ok macro in include/asm-mips64/uaccess.h need to be changed > in order to work correctly, it's a copy from the 32-bit kernel. > It's not good enough to simply check for the "sign bit" of the address. > The area between USEG (XUSEG) and KSEG0 will in 64-bit addressing mode > generate an address error, if > accessed. The size of the area depend on the number of virtual > addressing bits, implemented in the CPU. > > I have tried to come up with a patch, please see below. Any thought ? > I also changed the macro in arch/mips64/kernel/unaligned.c > > /Carsten > > > Index: include/asm-mips64//uaccess.h > =================================================================== > RCS file: > /home/repository/sw/linux-2.4.18/include/asm-mips64/uaccess.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 uaccess.h > --- include/asm-mips64//uaccess.h 4 Mar 2002 11:13:26 -0000 > 1.1.1.1 > +++ include/asm-mips64//uaccess.h 17 Jun 2002 11:35:32 -0000 > @@ -12,6 +12,8 @@ > #include > #include > > +#include > + > #define STR(x) __STR(x) > #define __STR(x) #x > > @@ -40,16 +42,23 @@ > * than tests. > * > * Address valid if: > - * - "addr" doesn't have any high-bits set > - * - AND "size" doesn't have any high-bits set > - * - AND "addr+size" doesn't have any high-bits set > - * - OR we are in kernel mode. > + * - In user mode and "addr" and "addr+size" in USEG (or XUSEG). > + * - OR we are in kernel mode and "addr" and "addr+size" isn't in the > + * area between USEG (XUSEG) and KSEG0. > */ > #define > __ua_size(size) \ > (__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : > (size)) > > -#define __access_ok(addr,size,mask) > \ > - (((signed long)((mask)&(addr | (addr + size) | > __ua_size(size)))) >= 0) > +static inline int > +__access_ok(unsigned long addr, unsigned long size, long mask) > +{ > + if (((mask) && ((addr | (addr+size)) >= KUSIZE)) || > + (((addr | (addr+size)) < K0BASE) && > + ((addr | (addr+size)) >= KUSIZE))) > + return 0; > + else > + return 1; > +} > > #define __access_mask ((long)(get_fs().seg)) > > > Index: arch/mips64/kernel/unaligned.c > =================================================================== > RCS file: > /home/repository/sw/linux-2.4.18/arch/mips64/kernel/unaligned.c,v > retrieving revision 1.2 > diff -u -r1.2 unaligned.c > --- arch/mips64/kernel/unaligned.c 23 May 2002 11:11:45 -0000 > 1.2 > +++ arch/mips64/kernel/unaligned.c 17 Jun 2002 11:51:30 -0000 > @@ -89,11 +89,14 @@ > #define __STR(x) #x > > /* > - * User code may only access USEG; kernel code may access the > - * entire address space. > + * User code may only access USEG; > + * Kernel code may access the entire address space, except the area > between > + * USEG (XUSEG) and KSEG0. > */ > -#define check_axs(pc,a,s) \ > - if ((long)(~(pc) & ((a) | ((a)+(s)))) < 0) \ > +#define check_axs(pc,a,s) > \ > + if (((pc < KUSIZE) && (((a) | ((a)+(s))) >= KUSIZE)) > || \ > + ((((a) | ((a)+(s))) < K0BASE) && > \ > + (((a) | ((a)+(s))) >= KUSIZE))) > \ > goto sigbus; > > > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > > From owner-linux-mips@oss.sgi.com Mon Jun 17 15:34: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 g5HMYAnC031402 for ; Mon, 17 Jun 2002 15:34:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HMYAem031401 for linux-mips-outgoing; Mon, 17 Jun 2002 15:34:10 -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 g5HMY4nC031397; Mon, 17 Jun 2002 15:34:05 -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 17K55X-000axA-00; Tue, 18 Jun 2002 00:35:07 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17K57C-0005rW-00; Tue, 18 Jun 2002 00:36:50 +0200 Date: Tue, 18 Jun 2002 00:36:50 +0200 To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: system.h asm fixes Message-ID: <20020617223650.GD20335@rembrandt.csv.ica.uni-stuttgart.de> References: <1024338042.1463.21.camel@localhost.localdomain> <20020617224452.C27009@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617224452.C27009@dea.linux-mips.net> User-Agent: Mutt/1.3.28i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 401 Lines: 13 Ralf Baechle wrote: [snip] > > Looks to me like we're missing some proper asm clobber markers: > > No, as per convention $1 is never used by the compiler per convention, > so clobbering not necessary. I recently removed all "$1" clobbers to > make the code a bit easier to read. How can this work? A grep shows many instances of $1 usage, I don't think all of this code is interrupt safe. Thiemo From owner-linux-mips@oss.sgi.com Mon Jun 17 15:55: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 g5HMtVnC031625 for ; Mon, 17 Jun 2002 15:55:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HMtVmW031624 for linux-mips-outgoing; Mon, 17 Jun 2002 15:55:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HMtQnC031620 for ; Mon, 17 Jun 2002 15:55:26 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5HMv9u03463; Mon, 17 Jun 2002 15:57:09 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: system.h asm fixes From: Justin Carlson To: Thiemo Seufer Cc: linux-mips@oss.sgi.com In-Reply-To: <20020617223650.GD20335@rembrandt.csv.ica.uni-stuttgart.de> References: <1024338042.1463.21.camel@localhost.localdomain> <20020617224452.C27009@dea.linux-mips.net> <20020617223650.GD20335@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 17 Jun 2002 15:57:08 -0700 Message-Id: <1024354629.3160.8.camel@xyzzy.rlson.org> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1364 Lines: 37 On Mon, 2002-06-17 at 15:36, Thiemo Seufer wrote: > Ralf Baechle wrote: > [snip] > > > Looks to me like we're missing some proper asm clobber markers: > > > > No, as per convention $1 is never used by the compiler per convention, > > so clobbering not necessary. I recently removed all "$1" clobbers to > > make the code a bit easier to read. > > How can this work? A grep shows many instances of $1 usage, > I don't think all of this code is interrupt safe. > The "$x" clobber markers exist so that the *compiler* won't expect values in those registers to be preserved across the asm call. It has nothing to do with safety across interrupts. In other words, it's there to prevent something like this: foo = 2; // Compiler sticks foo a register, say, $2 asm ( " lw $2, baz\n" " sw $2, (%0)\n" ::"r" (sna)); // Assembly code uses $2 as a temp reg (*bar) = foo; // Compiler erroneously does (*bar) = baz; In terms of interrupt safety, there is no issue with $1; any interrupt would save the register before mucking with it, and restore it before returning. The only registers for which this is not true are k0 and k1. As others have rightly pointed out, the compiler isn't allowed to muck with $1 anyways, as it is defined to be a temporary register for the assembler. So the clobber notation isn't necessary. Make sense? -Justin From owner-linux-mips@oss.sgi.com Mon Jun 17 17:51: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 g5I0pWnC032761 for ; Mon, 17 Jun 2002 17:51:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I0pWXf032760 for linux-mips-outgoing; Mon, 17 Jun 2002 17:51: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 (c-180-196-76.ka.dial.de.ignite.net [62.180.196.76]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I0pRnC032757 for ; Mon, 17 Jun 2002 17:51:28 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5I0q4228292; Tue, 18 Jun 2002 02:52:04 +0200 Date: Tue, 18 Jun 2002 02:52:04 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: system.h asm fixes Message-ID: <20020618025204.A28165@dea.linux-mips.net> References: <1024338042.1463.21.camel@localhost.localdomain> <20020617224452.C27009@dea.linux-mips.net> <20020617223650.GD20335@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020617223650.GD20335@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jun 18, 2002 at 12:36:50AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 694 Lines: 21 On Tue, Jun 18, 2002 at 12:36:50AM +0200, Thiemo Seufer wrote: > Ralf Baechle wrote: > [snip] > > > Looks to me like we're missing some proper asm clobber markers: > > > > No, as per convention $1 is never used by the compiler per convention, > > so clobbering not necessary. I recently removed all "$1" clobbers to > > make the code a bit easier to read. > > How can this work? A grep shows many instances of $1 usage, Uses by assembler code only, not gcc. Therefoe we don't need to protect C code against use of $at. > I don't think all of this code is interrupt safe. How this should relate to interrupts is beyond me. Exception handlers do their own register saving thing. Ralf From owner-linux-mips@oss.sgi.com Tue Jun 18 00:35: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 g5I7ZxnC009248 for ; Tue, 18 Jun 2002 00:35:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I7ZxTn009247 for linux-mips-outgoing; Tue, 18 Jun 2002 00:35: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 g5I7ZgnC009242 for ; Tue, 18 Jun 2002 00:35:42 -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 AAA10979; Tue, 18 Jun 2002 00:38:24 -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 AAA00007; Tue, 18 Jun 2002 00:38:26 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5I7cQb05227; Tue, 18 Jun 2002 09:38:26 +0200 (MEST) Message-ID: <3D0EE371.8C6D85FD@mips.com> Date: Tue, 18 Jun 2002 09:38:25 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@oss.sgi.com Subject: Re: __access_ok References: <3D0DCDCB.252F5565@mips.com> <3D0E3E9C.4070702@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4380 Lines: 134 That's true, lets do it right, thanks. /Carsten Jun Sun wrote: > Just to be nit-picking, the end point should be (addr + size - 1). > > Jun > > Carsten Langgaard wrote: > > > The __access_ok macro in include/asm-mips64/uaccess.h need to be changed > > in order to work correctly, it's a copy from the 32-bit kernel. > > It's not good enough to simply check for the "sign bit" of the address. > > The area between USEG (XUSEG) and KSEG0 will in 64-bit addressing mode > > generate an address error, if > > accessed. The size of the area depend on the number of virtual > > addressing bits, implemented in the CPU. > > > > I have tried to come up with a patch, please see below. Any thought ? > > I also changed the macro in arch/mips64/kernel/unaligned.c > > > > /Carsten > > > > > > Index: include/asm-mips64//uaccess.h > > =================================================================== > > RCS file: > > /home/repository/sw/linux-2.4.18/include/asm-mips64/uaccess.h,v > > retrieving revision 1.1.1.1 > > diff -u -r1.1.1.1 uaccess.h > > --- include/asm-mips64//uaccess.h 4 Mar 2002 11:13:26 -0000 > > 1.1.1.1 > > +++ include/asm-mips64//uaccess.h 17 Jun 2002 11:35:32 -0000 > > @@ -12,6 +12,8 @@ > > #include > > #include > > > > +#include > > + > > #define STR(x) __STR(x) > > #define __STR(x) #x > > > > @@ -40,16 +42,23 @@ > > * than tests. > > * > > * Address valid if: > > - * - "addr" doesn't have any high-bits set > > - * - AND "size" doesn't have any high-bits set > > - * - AND "addr+size" doesn't have any high-bits set > > - * - OR we are in kernel mode. > > + * - In user mode and "addr" and "addr+size" in USEG (or XUSEG). > > + * - OR we are in kernel mode and "addr" and "addr+size" isn't in the > > + * area between USEG (XUSEG) and KSEG0. > > */ > > #define > > __ua_size(size) \ > > (__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : > > (size)) > > > > -#define __access_ok(addr,size,mask) > > \ > > - (((signed long)((mask)&(addr | (addr + size) | > > __ua_size(size)))) >= 0) > > +static inline int > > +__access_ok(unsigned long addr, unsigned long size, long mask) > > +{ > > + if (((mask) && ((addr | (addr+size)) >= KUSIZE)) || > > + (((addr | (addr+size)) < K0BASE) && > > + ((addr | (addr+size)) >= KUSIZE))) > > + return 0; > > + else > > + return 1; > > +} > > > > #define __access_mask ((long)(get_fs().seg)) > > > > > > Index: arch/mips64/kernel/unaligned.c > > =================================================================== > > RCS file: > > /home/repository/sw/linux-2.4.18/arch/mips64/kernel/unaligned.c,v > > retrieving revision 1.2 > > diff -u -r1.2 unaligned.c > > --- arch/mips64/kernel/unaligned.c 23 May 2002 11:11:45 -0000 > > 1.2 > > +++ arch/mips64/kernel/unaligned.c 17 Jun 2002 11:51:30 -0000 > > @@ -89,11 +89,14 @@ > > #define __STR(x) #x > > > > /* > > - * User code may only access USEG; kernel code may access the > > - * entire address space. > > + * User code may only access USEG; > > + * Kernel code may access the entire address space, except the area > > between > > + * USEG (XUSEG) and KSEG0. > > */ > > -#define check_axs(pc,a,s) \ > > - if ((long)(~(pc) & ((a) | ((a)+(s)))) < 0) \ > > +#define check_axs(pc,a,s) > > \ > > + if (((pc < KUSIZE) && (((a) | ((a)+(s))) >= KUSIZE)) > > || \ > > + ((((a) | ((a)+(s))) < K0BASE) && > > \ > > + (((a) | ((a)+(s))) >= KUSIZE))) > > \ > > goto sigbus; > > > > > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com > > > > > > > > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jun 18 00:41: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 g5I7fRnC009476 for ; Tue, 18 Jun 2002 00:41:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I7fR6Z009475 for linux-mips-outgoing; Tue, 18 Jun 2002 00:41: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 g5I7fMnC009472 for ; Tue, 18 Jun 2002 00:41:22 -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 AAA10991; Tue, 18 Jun 2002 00:44:03 -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 AAA00107; Tue, 18 Jun 2002 00:44:05 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5I7i5b05666; Tue, 18 Jun 2002 09:44:05 +0200 (MEST) Message-ID: <3D0EE4C5.99F67A43@mips.com> Date: Tue, 18 Jun 2002 09:44:05 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Justin Carlson CC: linux-mips@oss.sgi.com Subject: Re: __access_ok References: <3D0DCDCB.252F5565@mips.com> <1024331098.1463.3.camel@localhost.localdomain> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1212 Lines: 34 Note, that this is in the 64-bit kernel, a size there the high bit is set, will be astronomical and not a true value. /Carsten Justin Carlson wrote: > On Mon, 2002-06-17 at 04:53, Carsten Langgaard wrote: > > > * Address valid if: > > - * - "addr" doesn't have any high-bits set > > - * - AND "size" doesn't have any high-bits set > > - * - AND "addr+size" doesn't have any high-bits set > > - * - OR we are in kernel mode. > > + * - In user mode and "addr" and "addr+size" in USEG (or XUSEG). > > + * - OR we are in kernel mode and "addr" and "addr+size" isn't in the > > + * area between USEG (XUSEG) and KSEG0. > > You also need to test for high bit set in size. Otherwise, for example, > if a process was ok to access range 0x40000000-0x40003fff, > access_ok(0x40001000, 0xfffff100) would return 1. The addition will > wrap around, leading to all sorts of fun havoc. > > -Justin -- _ _ ____ ___ 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 Jun 18 01:05: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 g5I85fnC009822 for ; Tue, 18 Jun 2002 01:05:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I85fGw009821 for linux-mips-outgoing; Tue, 18 Jun 2002 01:05:41 -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 g5I85LnC009799 for ; Tue, 18 Jun 2002 01:05:21 -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 BAA11108; Tue, 18 Jun 2002 01:07:54 -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 BAA00705; Tue, 18 Jun 2002 01:07:55 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5I87sb08097; Tue, 18 Jun 2002 10:07:55 +0200 (MEST) Message-ID: <3D0EEA5A.1B5DAA23@mips.com> Date: Tue, 18 Jun 2002 10:07:54 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: Louis Hamilton , linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> <3D0D7F98.566B3176@mips.com> <3D0E38E8.10804@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5145 Lines: 141 I believe this is the patch that solve the problem. The lazy fpu stuff has cause so many problems, that we have decided (together with Ralf) to get rid of it, and do the FPU context save and restore a little bit differently. We now have a solution here locally and we are testing it at the moment. /Carsten Index: arch/mips/kernel/traps.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/traps.c,v retrieving revision 1.99.2.14 diff -u -r1.99.2.14 traps.c --- arch/mips/kernel/traps.c 2002/05/28 06:33:13 1.99.2.14 +++ arch/mips/kernel/traps.c 2002/06/18 07:53:47 + { + __enable_fpu(); save_fp(last_task_used_math); + /* last_task_used_math loose fpu */ + ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - + sizeof(struct pt_regs)))-> + cp0_status &= ~ST0_CU1; + } Index: include/asm-mips/processor.h =================================================================== RCS file: /cvs/linux/include/asm-mips/processor.h,v retrieving revision 1.43.2.2 diff -u -r1.43.2.2 processor.h --- include/asm-mips/processor.h 2002/05/28 06:11:56 1.43.2.2 +++ include/asm-mips/processor.h 2002/06/18 07:56:58 @@ -215,6 +215,7 @@ regs->cp0_epc = new_pc; \ regs->regs[29] = new_sp; \ current->thread.current_ds = USER_DS; \ + current->used_math = 0; \ } while (0) unsigned long get_wchan(struct task_struct *p); Jun Sun wrote: > Carsten Langgaard wrote: > > > This is one of the bugs, among others, we have fixed. > > I'm not sure, if Ralf have integrated the patches we send him yet. > > > > Carsten, > > Do you remember the cause and the fix? It appears to me the first ctc1 > instruction should trap into kernel and mark current process as fpu owner, and > should not cause fcr31 corruption. > > Or somehow the ctc1 does not trap into kernel? > > Jun > > > /Carsten > > > > Louis Hamilton wrote: > > > > > >>We have a customer here testing a 2.4.16 mips kernel on an embedded > >>Linux RM7000/SR71000 based system who has written a test that they > >>believe has uncovered a bug in Linux. The FPU control register appears > >>to not get saved and restored. I've reproduced the problem described > >>below and find the results consistent with their description. The > >>problem occurs on both the RM7000 and SR71000 cpus. > >> > >>It looks like save_fp_context and restore_fp_context are not being > >>called since the kernel save-restore logic thinks the process is not > >>using floating point math. If you do some fp math before calling the > >>test routine below, it seems to works fine. > >> > >>Is this a known caveat? A true bug? Or a contorted corner case > >>unlikely to be seen under typical end-user usage (see customer's > >>last paragraph :-) ? If true bug, recommended remedy? > >> > >>TIA, > >>Louis > >> > >>Louis Hamilton > >>hamilton@redhat.com > >> > >>------ customer reports the following: --------- > >>We found a bug in Linux. A ^C (control-C) typed into a shell (or a > >>running program, it doesn't matter), causes the FCR (floating-point > >>control register) to be corrupted in another, unrelated process. This > >>is repeatable behavior. > >> > >>This can be reproduced with the following short assembly language > >>program that loops forever, waiting for the FCR to change. > >> > >> .align 2 > >> .globl mips_float_debug_loop > >>mips_float_debug_loop: > >> li $9, 0xF000F02F > >> ctc1 $9, $31 # set FCR to some non-zero value > >> nop > >>1: cfc1 $8, $31 # get FCR > >> beq $8, $9, 1b # spin, waiting for FCR to change > >> nop > >> or $2, $0, $8 > >> jr $31 > >> nop > >> > >>You can call this function from a short C program and the return value > >>is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. > >> > >>Run the above loop in one window (connected to the board using telnet) > >>and then in another window (connected to the same board) type ^C. > >> > >>I'm surprised this bug hasn't been encountered by other MIPS vendors. > >> > >> > >> > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com > > > > > > > > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jun 18 04:48: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 g5IBm3nC012704 for ; Tue, 18 Jun 2002 04:48:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IBm3f0012703 for linux-mips-outgoing; Tue, 18 Jun 2002 04:48: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 (c-180-196-27.ka.dial.de.ignite.net [62.180.196.27]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IBlsnC012699 for ; Tue, 18 Jun 2002 04:47:55 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5IBmZo29507 for linux-mips@oss.sgi.com; Tue, 18 Jun 2002 13:48:35 +0200 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 g5HGtDnC026125 for ; Mon, 17 Jun 2002 09:55:16 -0700 Received: from prefect.mshome.net ([192.168.0.76] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17Jyui-0005nP-00; Mon, 17 Jun 2002 11:59:32 -0400 Message-ID: <00bd01c21618$4e714ef0$4c00a8c0@prefect> From: "Bradley D. LaRonde" To: "Balakrishnan Ananthanarayanan" , References: <20020617094851.30730.qmail@email.com> Subject: Re: Code error - why? Date: Mon, 17 Jun 2002 12:01:56 -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 Content-Length: 713 Lines: 28 Drop the $ on the registers? Regards, Brad ----- Original Message ----- From: "Balakrishnan Ananthanarayanan" To: ; ; Sent: Monday, June 17, 2002 5:48 AM Subject: Code error - why? > I wrote a SAMPLE CODE - Hello.S to work for a cross-assembler mips-linux-as - but this is giving me an error message: > ".data > quest: .asciiz "Hello World!" > .text > _start: > la $a0, quest > li $v0, 4 > syscall " > > The error messages are: > " Hello.S line 5: illegal operands 'la' > Hello.S line 6: illegal operands 'li'" > > Can anyone help? What is wrong? From owner-linux-mips@oss.sgi.com Tue Jun 18 05:31: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 g5ICVAnC014305 for ; Tue, 18 Jun 2002 05:31:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ICVAwi014304 for linux-mips-outgoing; Tue, 18 Jun 2002 05:31:10 -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 g5ICV4nC014300 for ; Tue, 18 Jun 2002 05:31:04 -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 FAA11827 for ; Tue, 18 Jun 2002 05:33:50 -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 FAA05736 for ; Tue, 18 Jun 2002 05:33:51 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5ICXpb11613 for ; Tue, 18 Jun 2002 14:33:51 +0200 (MEST) Message-ID: <3D0F28AE.7B0D822B@mips.com> Date: Tue, 18 Jun 2002 14:33:50 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: 64-bit kernel Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1158 Lines: 38 I don't know if anymore has a interest in the 64-bit kernel, but I just found this bug (see patch below). It would be nice to know, how many are interested in the 64-bit kernel and who actually got something running. So please rise you voice. /Carsten Index: include/asm-mips64/exception.h =================================================================== RCS file: /home/repository/sw/linux-2.4.18/include/asm-mips64/exception.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 exception.h --- include/asm-mips64/exception.h 4 Mar 2002 11:13:25 -0000 1.1.1.1 +++ include/asm-mips64/exception.h 18 Jun 2002 12:18:40 -0000 @@ -28,7 +28,7 @@ .macro __build_clear_fpe cfc1 a1, fcr31 - li a2, ~(0x3f << 13) + li a2, ~(0x3f << 12) and a2, a1 ctc1 a2, fcr31 STI -- _ _ ____ ___ 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 Jun 18 06:50: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 g5IDoPnC015277 for ; Tue, 18 Jun 2002 06:50:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IDoPQH015276 for linux-mips-outgoing; Tue, 18 Jun 2002 06:50:25 -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 g5IDoJnC015273 for ; Tue, 18 Jun 2002 06:50: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 GAA12118; Tue, 18 Jun 2002 06:53:06 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA07442; Tue, 18 Jun 2002 06:53:04 -0700 (PDT) Message-ID: <007601c216d0$6f7f0840$10eca8c0@grendel> From: "Kevin D. Kissell" To: , Subject: Linux and the Sony Playstation 2 Date: Tue, 18 Jun 2002 15:59: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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1600 Lines: 41 The Sony PS2 Linux kit has been shipping for nearly a month now, and I'm frankly astonished at how little I've seen on this mailing list about it. For better or for worse, this changes everything for MIPS/Linux. The number of MIPS/Linux users worldwide has just gone up by at least an order of magnitude, and they are on a platform running a 2.2.1-derived kernel and using gcc 2.95.2. It's a perfectly usable platform out of the box, but Carsten has thrown "crashme" at it, and it goes down relatively quickly. People trying to port kaffe and other programs that do double-precision float are blocked because there's no double precision on the R5900, and the Sony kernel lacks the Algorithmics emulator. It's not clear what Sony is going to put into further development, and what they are going to expect the user community to take over from here. There is a group of people trying to take the kernel up to 2.2.20, but I'm not yet sure whether they know what they are doing, and anyway, that box needs to get to 2.4.x ASAP. I respectfully submit that, within a year, any MIPS/Linux source tree that does not support the PS2 will be considered obsolete. And that quite specifically includes the one at oss.sgi.com. I personally would want to approach this in terms of merging the necessary PS2 code into something that could be expressed as a patch over kernel.org's 2.4.19_or_better, and which would be provded as the default MIPS kernel technology by MIPS and SGI servers, and ultimately by kernel.org. Is no one else here working on this? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jun 18 08:16: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 g5IFGcnC017304 for ; Tue, 18 Jun 2002 08:16:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IFGcZ4017303 for linux-mips-outgoing; Tue, 18 Jun 2002 08:16:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IFGYnC017300 for ; Tue, 18 Jun 2002 08:16:34 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020618151923.CPT20219.sccrmhc03.attbi.com@ocean.lucon.org>; Tue, 18 Jun 2002 15:19:23 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id D195A125C1; Tue, 18 Jun 2002 08:19:18 -0700 (PDT) Date: Tue, 18 Jun 2002 08:19:18 -0700 From: "H . J . Lu" To: "Kevin D. Kissell" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Linux and the Sony Playstation 2 Message-ID: <20020618081918.A3774@lucon.org> References: <007601c216d0$6f7f0840$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: <007601c216d0$6f7f0840$10eca8c0@grendel>; from kevink@mips.com on Tue, Jun 18, 2002 at 03:59:57PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 971 Lines: 25 On Tue, Jun 18, 2002 at 03:59:57PM +0200, Kevin D. Kissell wrote: > The Sony PS2 Linux kit has been shipping for nearly > a month now, and I'm frankly astonished at how little > I've seen on this mailing list about it. For better or > for worse, this changes everything for MIPS/Linux. > The number of MIPS/Linux users worldwide has > just gone up by at least an order of magnitude, > and they are on a platform running a 2.2.1-derived > kernel and using gcc 2.95.2. > > It's a perfectly usable platform out of the box, but > Carsten has thrown "crashme" at it, and it goes down > relatively quickly. People trying to port kaffe and > other programs that do double-precision float are > blocked because there's no double precision on the > R5900, and the Sony kernel lacks the Algorithmics > emulator. > I looked at PS2 when I was looking for a mips platform for my Linux/mips work. Unfortunately, PS2 doesn't have ll/sc, which makes many things complicated. H.J. From owner-linux-mips@oss.sgi.com Tue Jun 18 09:00: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 g5IG0xnC022125 for ; Tue, 18 Jun 2002 09:00:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IG0x3X022124 for linux-mips-outgoing; Tue, 18 Jun 2002 09:00:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IG0unC022121 for ; Tue, 18 Jun 2002 09:00:56 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5IG3I201203; Tue, 18 Jun 2002 09:03:18 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: 64-bit kernel From: Justin Carlson To: Carsten Langgaard Cc: linux-mips@oss.sgi.com In-Reply-To: <3D0F28AE.7B0D822B@mips.com> References: <3D0F28AE.7B0D822B@mips.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 09:03:18 -0700 Message-Id: <1024416198.1166.1.camel@xyzzy.rlson.org> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 446 Lines: 14 On Tue, 2002-06-18 at 05:33, Carsten Langgaard wrote: > I don't know if anymore has a interest in the 64-bit kernel, but I just > found this bug (see patch below). > It would be nice to know, how many are interested in the 64-bit kernel > and who actually got something running. > So please rise you voice. > Been running 64-bit stuff here, but nothing even remotely fpu intensive. It's quite possible we'd never run into this case. -Justin From owner-linux-mips@oss.sgi.com Tue Jun 18 10:04: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 g5IH4onC024075 for ; Tue, 18 Jun 2002 10:04:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IH4oww024074 for linux-mips-outgoing; Tue, 18 Jun 2002 10:04:50 -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-141.ayrnetworks.com [64.166.72.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IH4BnC024069 for ; Tue, 18 Jun 2002 10:04:11 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g5IH3l601409 for "linux-mips@oss.sgi.com"; Tue, 18 Jun 2002 10:03:47 -0700 Date: Tue, 18 Jun 2002 10:03:47 -0700 From: William Jhun To: "linux-mips@oss.sgi.com"@ayrnetworks.com Subject: [PATCH] dma_cache_wback, pci DMA cache coherency changes Message-ID: <20020618100347.A1361@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 Content-Length: 10085 Lines: 322 This is a re-hash of patches I sent out a while ago which do a more optimal cache-flushing for pci_map_*() and pci_dma_sync_*(). It basically does an invalidate for PCI_DMA_FROMDEVICE operations and a writeback for PCI_DMA_TODEVICE pci_map_* (or writeback/invalidate if PCI_DMA_BIDIRECTIONAL). This is similar to the ARM implementation. Additionally, I filled in the _dma_cache_wback calls in the arch/mips/c-*.c to call *_dma_cache_wback_inv* instead of calling panic(). Some architectures could probably do a real writeback instead of just wback_inv, but this will at least allow code that can use writeback-only if available. Note: I'm not familiar with a lot of these CPUs, but the change should be innocuous. Could someone validate/improve these? Thanks, William Index: include/asm/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/pci.h 2002/02/26 06:00:25 1.24.2.1 +++ include/asm/pci.h 2002/06/18 16:51:30 @@ -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 } @@ -246,8 +279,9 @@ /* 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); + sync_buffer(sg->address, sg->length, direction); #endif + } /* Return whether the given PCI device DMA address mask can Index: arch/mips/mm/c-mips32.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-mips32.c,v retrieving revision 1.3.2.4 diff -u -r1.3.2.4 c-mips32.c --- arch/mips/mm/c-mips32.c 2002/05/29 03:03:17 1.3.2.4 +++ arch/mips/mm/c-mips32.c 2002/06/18 16:52:21 @@ -393,12 +393,6 @@ } } -static void -mips32_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("mips32_dma_cache called - should not happen."); -} - /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -603,7 +597,7 @@ _flush_icache_page = mips32_flush_icache_page; _dma_cache_wback_inv = mips32_dma_cache_wback_inv_pc; - _dma_cache_wback = mips32_dma_cache_wback; + _dma_cache_wback = mips32_dma_cache_wback_inv_pc; _dma_cache_inv = mips32_dma_cache_inv_pc; } @@ -621,7 +615,7 @@ _flush_icache_page = mips32_flush_icache_page_s; _dma_cache_wback_inv = mips32_dma_cache_wback_inv_sc; - _dma_cache_wback = mips32_dma_cache_wback; + _dma_cache_wback = mips32_dma_cache_wback_inv_sc; _dma_cache_inv = mips32_dma_cache_inv_sc; } Index: arch/mips/mm/c-r3k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-r3k.c,v retrieving revision 1.4.2.1 diff -u -r1.4.2.1 c-r3k.c --- arch/mips/mm/c-r3k.c 2002/02/18 15:22:30 1.4.2.1 +++ arch/mips/mm/c-r3k.c 2002/06/18 16:52:21 @@ -337,7 +337,9 @@ _flush_icache_page = r3k_flush_icache_page; _flush_icache_range = r3k_flush_icache_range; + _dma_cache_inv = r3k_dma_cache_wback_inv; _dma_cache_wback_inv = r3k_dma_cache_wback_inv; + _dma_cache_wback = r3k_dma_cache_wback_inv; printk("Primary instruction cache %dkb, linesize %d bytes\n", (int) (icache_size >> 10), (int) icache_lsize); Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.3.2.3 diff -u -r1.3.2.3 c-r4k.c --- arch/mips/mm/c-r4k.c 2002/05/29 03:03:17 1.3.2.3 +++ arch/mips/mm/c-r4k.c 2002/06/18 16:52:21 @@ -1150,12 +1150,6 @@ } } -static void -r4k_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("r4k_dma_cache called - should not happen."); -} - /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -1358,7 +1352,7 @@ _flush_icache_page = r4k_flush_icache_page_p; _dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc; - _dma_cache_wback = r4k_dma_cache_wback; + _dma_cache_wback = r4k_dma_cache_wback_inv_pc; _dma_cache_inv = r4k_dma_cache_inv_pc; } @@ -1441,7 +1435,7 @@ ___flush_cache_all = _flush_cache_all; _flush_icache_page = r4k_flush_icache_page_s; _dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc; - _dma_cache_wback = r4k_dma_cache_wback; + _dma_cache_wback = r4k_dma_cache_wback_inv_sc; _dma_cache_inv = r4k_dma_cache_inv_sc; } Index: arch/mips/mm/c-r5432.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-r5432.c,v retrieving revision 1.4 diff -u -r1.4 c-r5432.c --- arch/mips/mm/c-r5432.c 2001/11/30 13:28:06 1.4 +++ arch/mips/mm/c-r5432.c 2002/06/18 16:52:21 @@ -414,12 +414,6 @@ bc_inv(addr, size); } -static void -r5432_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("r5432_dma_cache called - should not happen."); -} - /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -470,7 +464,7 @@ _flush_cache_page = r5432_flush_cache_page_d32i32; _flush_icache_page = r5432_flush_icache_page_i32; _dma_cache_wback_inv = r5432_dma_cache_wback_inv_pc; - _dma_cache_wback = r5432_dma_cache_wback; + _dma_cache_wback = r5432_dma_cache_wback_inv_pc; _dma_cache_inv = r5432_dma_cache_inv_pc; _flush_cache_sigtramp = r5432_flush_cache_sigtramp; Index: arch/mips/mm/c-rm7k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-rm7k.c,v retrieving revision 1.4.2.2 diff -u -r1.4.2.2 c-rm7k.c --- arch/mips/mm/c-rm7k.c 2002/05/29 03:03:17 1.4.2.2 +++ arch/mips/mm/c-rm7k.c 2002/06/18 16:52:21 @@ -177,12 +177,6 @@ } } -static void -rm7k_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("rm7k_dma_cache_wback called - should not happen."); -} - /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -342,7 +336,7 @@ _flush_icache_page = rm7k_flush_icache_page; _dma_cache_wback_inv = rm7k_dma_cache_wback_inv; - _dma_cache_wback = rm7k_dma_cache_wback; + _dma_cache_wback = rm7k_dma_cache_wback_inv; _dma_cache_inv = rm7k_dma_cache_inv; __flush_cache_all_d32i32(); Index: arch/mips/mm/c-tx39.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-tx39.c,v retrieving revision 1.4 diff -u -r1.4 c-tx39.c --- arch/mips/mm/c-tx39.c 2001/11/30 13:28:06 1.4 +++ arch/mips/mm/c-tx39.c 2002/06/18 16:52:21 @@ -225,11 +225,6 @@ } } -static void tx39_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("tx39_dma_cache called - should not happen."); -} - static void tx39_flush_cache_sigtramp(unsigned long addr) { unsigned long config; @@ -317,7 +312,7 @@ _flush_icache_range = tx39_flush_icache_range; _dma_cache_wback_inv = tx39_dma_cache_wback_inv; - _dma_cache_wback = tx39_dma_cache_wback; + _dma_cache_wback = tx39_dma_cache_wback_inv; _dma_cache_inv = tx39_dma_cache_inv; break; Index: arch/mips/mm/c-tx49.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-tx49.c,v retrieving revision 1.3.2.1 diff -u -r1.3.2.1 c-tx49.c --- arch/mips/mm/c-tx49.c 2002/05/29 03:03:17 1.3.2.1 +++ arch/mips/mm/c-tx49.c 2002/06/18 16:52:21 @@ -343,12 +343,6 @@ } } -static void -r4k_dma_cache_wback(unsigned long addr, unsigned long size) -{ - panic("r4k_dma_cache called - should not happen."); -} - /* * While we're protected against bad userland addresses we don't care * very much about what happens in that case. Usually a segmentation @@ -429,7 +423,7 @@ _flush_icache_page = r4k_flush_icache_page; _dma_cache_wback_inv = r4k_dma_cache_wback_inv; - _dma_cache_wback = r4k_dma_cache_wback; + _dma_cache_wback = r4k_dma_cache_wback_inv; _dma_cache_inv = r4k_dma_cache_inv; _flush_cache_sigtramp = r4k_flush_cache_sigtramp; From owner-linux-mips@oss.sgi.com Tue Jun 18 10:49: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 g5IHninC025577 for ; Tue, 18 Jun 2002 10:49:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IHni1p025576 for linux-mips-outgoing; Tue, 18 Jun 2002 10:49: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 g5IHnNnC025572 for ; Tue, 18 Jun 2002 10:49:23 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA02555; Tue, 18 Jun 2002 10:52:02 -0700 Message-ID: <3D0F7213.6000002@mvista.com> Date: Tue, 18 Jun 2002 10:46:59 -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: Carsten Langgaard CC: Louis Hamilton , linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> <3D0D7F98.566B3176@mips.com> <3D0E38E8.10804@mvista.com> <3D0EEA5A.1B5DAA23@mips.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6133 Lines: 172 Your first chunk is not clear as to where it applies. Maybe you are using a different code base. The second chunck is not necessary. Although the FPU values in thread struct for the new thread are stale, the new program cannot assume the fpu register values and cannot use them without initialization anyway. I don't see such a code in x86's code. Current call to start_thread() is ok with or without this change. I am afraid future use of start_thread() may give undesired effect after we make this change. As for the new fpu context switch code, I wrote a experiemental patch after much discussion with Ralf and Kevin. It is at http://linux.junsun.net/patches/oss.sgi.com/experimental/020304-half-fpu-context-switch I also did some performance study of this patch. Did not get much feedbacks when I asked last time. :-( Jun Carsten Langgaard wrote: > I believe this is the patch that solve the problem. > The lazy fpu stuff has cause so many problems, that we have decided (together > with Ralf) to get rid of it, and do the FPU context save and restore a little bit > differently. > We now have a solution here locally and we are testing it at the moment. > > /Carsten > > > Index: arch/mips/kernel/traps.c > =================================================================== > RCS file: /cvs/linux/arch/mips/kernel/traps.c,v > retrieving revision 1.99.2.14 > diff -u -r1.99.2.14 traps.c > --- arch/mips/kernel/traps.c 2002/05/28 06:33:13 1.99.2.14 > +++ arch/mips/kernel/traps.c 2002/06/18 07:53:47 > + { > + __enable_fpu(); > save_fp(last_task_used_math); > + /* last_task_used_math loose fpu */ > + ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - > + sizeof(struct pt_regs)))-> > + cp0_status &= ~ST0_CU1; > + } > > Index: include/asm-mips/processor.h > =================================================================== > RCS file: /cvs/linux/include/asm-mips/processor.h,v > retrieving revision 1.43.2.2 > diff -u -r1.43.2.2 processor.h > --- include/asm-mips/processor.h 2002/05/28 06:11:56 1.43.2.2 > +++ include/asm-mips/processor.h 2002/06/18 07:56:58 > @@ -215,6 +215,7 @@ > regs->cp0_epc = new_pc; \ > regs->regs[29] = new_sp; \ > current->thread.current_ds = USER_DS; \ > + current->used_math = 0; \ > } while (0) > > unsigned long get_wchan(struct task_struct *p); > > > > Jun Sun wrote: > > >>Carsten Langgaard wrote: >> >> >>>This is one of the bugs, among others, we have fixed. >>>I'm not sure, if Ralf have integrated the patches we send him yet. >>> >>> >>Carsten, >> >>Do you remember the cause and the fix? It appears to me the first ctc1 >>instruction should trap into kernel and mark current process as fpu owner, and >>should not cause fcr31 corruption. >> >>Or somehow the ctc1 does not trap into kernel? >> >>Jun >> >> >>>/Carsten >>> >>>Louis Hamilton wrote: >>> >>> >>> >>>>We have a customer here testing a 2.4.16 mips kernel on an embedded >>>>Linux RM7000/SR71000 based system who has written a test that they >>>>believe has uncovered a bug in Linux. The FPU control register appears >>>>to not get saved and restored. I've reproduced the problem described >>>>below and find the results consistent with their description. The >>>>problem occurs on both the RM7000 and SR71000 cpus. >>>> >>>>It looks like save_fp_context and restore_fp_context are not being >>>>called since the kernel save-restore logic thinks the process is not >>>>using floating point math. If you do some fp math before calling the >>>>test routine below, it seems to works fine. >>>> >>>>Is this a known caveat? A true bug? Or a contorted corner case >>>>unlikely to be seen under typical end-user usage (see customer's >>>>last paragraph :-) ? If true bug, recommended remedy? >>>> >>>>TIA, >>>>Louis >>>> >>>>Louis Hamilton >>>>hamilton@redhat.com >>>> >>>>------ customer reports the following: --------- >>>>We found a bug in Linux. A ^C (control-C) typed into a shell (or a >>>>running program, it doesn't matter), causes the FCR (floating-point >>>>control register) to be corrupted in another, unrelated process. This >>>>is repeatable behavior. >>>> >>>>This can be reproduced with the following short assembly language >>>>program that loops forever, waiting for the FCR to change. >>>> >>>> .align 2 >>>> .globl mips_float_debug_loop >>>>mips_float_debug_loop: >>>> li $9, 0xF000F02F >>>> ctc1 $9, $31 # set FCR to some non-zero value >>>> nop >>>>1: cfc1 $8, $31 # get FCR >>>> beq $8, $9, 1b # spin, waiting for FCR to change >>>> nop >>>> or $2, $0, $8 >>>> jr $31 >>>> nop >>>> >>>>You can call this function from a short C program and the return value >>>>is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. >>>> >>>>Run the above loop in one window (connected to the board using telnet) >>>>and then in another window (connected to the same board) type ^C. >>>> >>>>I'm surprised this bug hasn't been encountered by other MIPS vendors. >>>> >>>> >>>> >>>-- >>>_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com >>>|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 >>>| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 >>> TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 >>> Denmark http://www.mips.com >>> >>> >>> >>> >>> > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com > > > > From owner-linux-mips@oss.sgi.com Tue Jun 18 10:54: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 g5IHsenC025904 for ; Tue, 18 Jun 2002 10:54:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IHseUk025903 for linux-mips-outgoing; Tue, 18 Jun 2002 10:54:40 -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 g5IHsXnC025900 for ; Tue, 18 Jun 2002 10:54:33 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA02786; Tue, 18 Jun 2002 10:57:22 -0700 Message-ID: <3D0F7353.20107@mvista.com> Date: Tue, 18 Jun 2002 10:52: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: Carsten Langgaard CC: linux-mips@oss.sgi.com Subject: Re: 64-bit kernel References: <3D0F28AE.7B0D822B@mips.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1551 Lines: 56 Carsten Langgaard wrote: > I don't know if anymore has a interest in the 64-bit kernel, but I just > found this bug (see patch below). > It would be nice to know, how many are interested in the 64-bit kernel > and who actually got something running. > So please rise you voice. > Actually I think there is an increased interestes to 64bit kernel with the recent introduction of RM7K and bcm1250 CPUs. If 64bit kernel gets mature, I think two years down the road we will see mid-range CPUs edging into that domain as well. (Jun is raising his voice....) Jun > /Carsten > > Index: include/asm-mips64/exception.h > =================================================================== > RCS file: > /home/repository/sw/linux-2.4.18/include/asm-mips64/exception.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 exception.h > --- include/asm-mips64/exception.h 4 Mar 2002 11:13:25 -0000 > 1.1.1.1 > +++ include/asm-mips64/exception.h 18 Jun 2002 12:18:40 -0000 > @@ -28,7 +28,7 @@ > > .macro __build_clear_fpe > cfc1 a1, fcr31 > - li a2, ~(0x3f << 13) > + li a2, ~(0x3f << 12) > and a2, a1 > ctc1 a2, fcr31 > STI > > > > -- > _ _ ____ ___ 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 Jun 18 11:29: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 g5IITAnC029496 for ; Tue, 18 Jun 2002 11:29:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IITAPv029495 for linux-mips-outgoing; Tue, 18 Jun 2002 11:29:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IIT4nC029491 for ; Tue, 18 Jun 2002 11:29:04 -0700 Received: (qmail 21656 invoked by uid 512); 18 Jun 2002 18:31:58 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.070934 secs); 18 Jun 2002 18:31:58 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 18 Jun 2002 18:31:58 -0000 Message-ID: <00e001c216f6$86594b40$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: , References: <007601c216d0$6f7f0840$10eca8c0@grendel> Subject: Re: Linux and the Sony Playstation 2 Date: Tue, 18 Jun 2002 11:31:34 -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 Content-Length: 1363 Lines: 41 Kevin: Kevin D. Kissell wrote on linux-mips@oss.sgi.com: > The Sony PS2 Linux kit has been shipping for nearly... If the PS2 is an open source platform, I would like to know that. However, I do not see Sony on the OSI approved license list: http://www.opensource.org/licenses/index.php So, let me get out my soap box... When people say "Open Source", the first thing that comes to mind is software. But, this is only one half of the equation. The hardware must also be "open", or the concept doesn't work. First, because attempting to write systems software without complete and accurate hardware documentation is an exercise in reverse engineering. The community can better spend its time on documented hardware. Second, and more importantly, because any intellectual property (IP) encumbrance will make the results pointless in the marketplace. Closed hardware breaks the community development model. Vendors who provide a Linux distribution but keep their hardware proprietary cannot honestly claim "Open Source". Vendors who fully disclose and freely license both their hardware and software have embraced "Open Source". As consumers, we vote with our dollars. As engineers, we further one cause or the other by our education, employment, and personal project choices. David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Tue Jun 18 15:11: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 g5IMBhnC002288 for ; Tue, 18 Jun 2002 15:11:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IMBhtD002287 for linux-mips-outgoing; Tue, 18 Jun 2002 15:11:43 -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 (c-180-196-59.ka.dial.de.ignite.net [62.180.196.59]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IMBbnC002284 for ; Tue, 18 Jun 2002 15:11:39 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5IMCI604644 for linux-mips@oss.sgi.com; Wed, 19 Jun 2002 00:12:18 +0200 Received: from localhost.localdomain (ip68-6-25-170.hu.sd.cox.net [68.6.25.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IGBqnC022306 for ; Tue, 18 Jun 2002 09:11:52 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g5IGE9r01526; Tue, 18 Jun 2002 09:14:09 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justin@cs.cmu.edu using -f Subject: Re: Code error - why? From: Justin Carlson To: "Bradley D. LaRonde" Cc: Balakrishnan Ananthanarayanan , linux-mips@oss.sgi.com In-Reply-To: <00bd01c21618$4e714ef0$4c00a8c0@prefect> References: <20020617094851.30730.qmail@email.com> <00bd01c21618$4e714ef0$4c00a8c0@prefect> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 09:14:09 -0700 Message-Id: <1024416849.1182.10.camel@xyzzy.rlson.org> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1026 Lines: 45 After preprocessing, the assembler needs to see $ as register specifiers, so typically your choices are to do either: #define a0 $4 // See include/asm-mips/regdef.h for these #define v0 $2 ... la a0, quest li v0, 4 Or to just use the register numbers, e.g. la $4, quest li $2, 4 -Justin > ----- Original Message ----- > From: "Balakrishnan Ananthanarayanan" > To: ; ; > > Sent: Monday, June 17, 2002 5:48 AM > Subject: Code error - why? > > > > I wrote a SAMPLE CODE - Hello.S to work for a cross-assembler > mips-linux-as - but this is giving me an error message: > > ".data > > quest: .asciiz "Hello World!" > > .text > > _start: > > la $a0, quest > > li $v0, 4 > > syscall " > > > > The error messages are: > > " Hello.S line 5: illegal operands 'la' > > Hello.S line 6: illegal operands 'li'" > > > > Can anyone help? What is wrong? From owner-linux-mips@oss.sgi.com Tue Jun 18 23:53: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 g5J6rNnC008947 for ; Tue, 18 Jun 2002 23:53:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J6rNqN008946 for linux-mips-outgoing; Tue, 18 Jun 2002 23:53:23 -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 g5J6qonC008933 for ; Tue, 18 Jun 2002 23:52: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 XAA19374; Tue, 18 Jun 2002 23:55:31 -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 XAA20785; Tue, 18 Jun 2002 23:55:26 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5J6tQb25482; Wed, 19 Jun 2002 08:55:27 +0200 (MEST) Message-ID: <3D102ADD.71178636@mips.com> Date: Wed, 19 Jun 2002 08:55:26 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: Louis Hamilton , linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> <3D0D7F98.566B3176@mips.com> <3D0E38E8.10804@mvista.com> <3D0EEA5A.1B5DAA23@mips.com> <3D0F7213.6000002@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9323 Lines: 266 Jun Sun wrote: > Your first chunk is not clear as to where it applies. Maybe you are using a > different code base. Here is my do_cpu handler: asmlinkage void do_cpu(struct pt_regs *regs) { unsigned int cpid; extern void lazy_fpu_switch(void *); extern void save_fp(struct task_struct *); extern void init_fpu(void); void fpu_emulator_init_fpu(void); int sig; cpid = (regs->cp0_cause >> CAUSEB_CE) & 3; if (cpid != 1) goto bad_cid; if (!(mips_cpu.options & MIPS_CPU_FPU)) goto fp_emul; regs->cp0_status |= ST0_CU1; if (last_task_used_math == current) return; if (current->used_math) { /* Using the FPU again. */ lazy_fpu_switch(last_task_used_math); } else { /* First time FPU user. */ if (last_task_used_math != NULL) { __enable_fpu(); save_fp(last_task_used_math); /* last_task_used_math loose fpu */ ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - sizeof(struct pt_regs)))-> cp0_status &= ~ST0_CU1; } init_fpu(); current->used_math = 1; } last_task_used_math = current; return; fp_emul: if (last_task_used_math != current) { if (!current->used_math) { fpu_emulator_init_fpu(); current->used_math = 1; } } sig = fpu_emulator_cop1Handler(0, regs, ¤t->thread.fpu.soft); last_task_used_math = current; if (sig) { /* * Return EPC is not calculated in the FPU emulator, if * a signal is being send. So we calculate it here. */ compute_return_epc(regs); force_sig(sig, current); } return; bad_cid: #ifndef CONFIG_CPU_HAS_LLSC switch (mips_cpu.cputype) { case CPU_TX3927: case CPU_TX39XX: do_ri(regs); return; } #endif compute_return_epc(regs); force_sig(SIGILL, current); } > > The second chunck is not necessary. Although the FPU values in thread struct > for the new thread are stale, the new program cannot assume the fpu register > values and cannot use them without initialization anyway. At least with the do_cpu handler above, you need this. I'm not sure which tests failed without this, but I think it was some of the gcc selftests and I think the problem was, that a thread inherited the previous thread's fsr (floating point status register). > > I don't see such a code in x86's code. Current call to start_thread() is ok > with or without this change. I am afraid future use of start_thread() may > give undesired effect after we make this change. Why ? > > As for the new fpu context switch code, I wrote a experiemental patch after > much discussion with Ralf and Kevin. It is at > > http://linux.junsun.net/patches/oss.sgi.com/experimental/020304-half-fpu-context-switch > > I also did some performance study of this patch. Did not get much feedbacks > when I asked last time. :-( > > Jun > > Carsten Langgaard wrote: > > > I believe this is the patch that solve the problem. > > The lazy fpu stuff has cause so many problems, that we have decided (together > > with Ralf) to get rid of it, and do the FPU context save and restore a little bit > > differently. > > We now have a solution here locally and we are testing it at the moment. > > > > /Carsten > > > > > > Index: arch/mips/kernel/traps.c > > =================================================================== > > RCS file: /cvs/linux/arch/mips/kernel/traps.c,v > > retrieving revision 1.99.2.14 > > diff -u -r1.99.2.14 traps.c > > --- arch/mips/kernel/traps.c 2002/05/28 06:33:13 1.99.2.14 > > +++ arch/mips/kernel/traps.c 2002/06/18 07:53:47 > > + { > > + __enable_fpu(); > > save_fp(last_task_used_math); > > + /* last_task_used_math loose fpu */ > > + ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - > > + sizeof(struct pt_regs)))-> > > + cp0_status &= ~ST0_CU1; > > + } > > > > Index: include/asm-mips/processor.h > > =================================================================== > > RCS file: /cvs/linux/include/asm-mips/processor.h,v > > retrieving revision 1.43.2.2 > > diff -u -r1.43.2.2 processor.h > > --- include/asm-mips/processor.h 2002/05/28 06:11:56 1.43.2.2 > > +++ include/asm-mips/processor.h 2002/06/18 07:56:58 > > @@ -215,6 +215,7 @@ > > regs->cp0_epc = new_pc; \ > > regs->regs[29] = new_sp; \ > > current->thread.current_ds = USER_DS; \ > > + current->used_math = 0; \ > > } while (0) > > > > unsigned long get_wchan(struct task_struct *p); > > > > > > > > Jun Sun wrote: > > > > > >>Carsten Langgaard wrote: > >> > >> > >>>This is one of the bugs, among others, we have fixed. > >>>I'm not sure, if Ralf have integrated the patches we send him yet. > >>> > >>> > >>Carsten, > >> > >>Do you remember the cause and the fix? It appears to me the first ctc1 > >>instruction should trap into kernel and mark current process as fpu owner, and > >>should not cause fcr31 corruption. > >> > >>Or somehow the ctc1 does not trap into kernel? > >> > >>Jun > >> > >> > >>>/Carsten > >>> > >>>Louis Hamilton wrote: > >>> > >>> > >>> > >>>>We have a customer here testing a 2.4.16 mips kernel on an embedded > >>>>Linux RM7000/SR71000 based system who has written a test that they > >>>>believe has uncovered a bug in Linux. The FPU control register appears > >>>>to not get saved and restored. I've reproduced the problem described > >>>>below and find the results consistent with their description. The > >>>>problem occurs on both the RM7000 and SR71000 cpus. > >>>> > >>>>It looks like save_fp_context and restore_fp_context are not being > >>>>called since the kernel save-restore logic thinks the process is not > >>>>using floating point math. If you do some fp math before calling the > >>>>test routine below, it seems to works fine. > >>>> > >>>>Is this a known caveat? A true bug? Or a contorted corner case > >>>>unlikely to be seen under typical end-user usage (see customer's > >>>>last paragraph :-) ? If true bug, recommended remedy? > >>>> > >>>>TIA, > >>>>Louis > >>>> > >>>>Louis Hamilton > >>>>hamilton@redhat.com > >>>> > >>>>------ customer reports the following: --------- > >>>>We found a bug in Linux. A ^C (control-C) typed into a shell (or a > >>>>running program, it doesn't matter), causes the FCR (floating-point > >>>>control register) to be corrupted in another, unrelated process. This > >>>>is repeatable behavior. > >>>> > >>>>This can be reproduced with the following short assembly language > >>>>program that loops forever, waiting for the FCR to change. > >>>> > >>>> .align 2 > >>>> .globl mips_float_debug_loop > >>>>mips_float_debug_loop: > >>>> li $9, 0xF000F02F > >>>> ctc1 $9, $31 # set FCR to some non-zero value > >>>> nop > >>>>1: cfc1 $8, $31 # get FCR > >>>> beq $8, $9, 1b # spin, waiting for FCR to change > >>>> nop > >>>> or $2, $0, $8 > >>>> jr $31 > >>>> nop > >>>> > >>>>You can call this function from a short C program and the return value > >>>>is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. > >>>> > >>>>Run the above loop in one window (connected to the board using telnet) > >>>>and then in another window (connected to the same board) type ^C. > >>>> > >>>>I'm surprised this bug hasn't been encountered by other MIPS vendors. > >>>> > >>>> > >>>> > >>>-- > >>>_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > >>>|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > >>>| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > >>> TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > >>> Denmark http://www.mips.com > >>> > >>> > >>> > >>> > >>> > > > > -- > > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > > Denmark http://www.mips.com > > > > > > > > -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jun 19 00:15: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 g5J7F8nC009197 for ; Wed, 19 Jun 2002 00:15:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J7F87P009196 for linux-mips-outgoing; Wed, 19 Jun 2002 00:15:08 -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 g5J7ExnC009189 for ; Wed, 19 Jun 2002 00:14:59 -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 AAA19440 for ; Wed, 19 Jun 2002 00:17:47 -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 AAA21644 for ; Wed, 19 Jun 2002 00:17:48 -0700 (PDT) Received: (from hartvige@localhost) by copfs01.mips.com (8.11.4/8.9.0) id g5J7Hnc27328 for linux-mips@oss.sgi.com; Wed, 19 Jun 2002 09:17:49 +0200 (MEST) From: Hartvig Ekner Message-Id: <200206190717.g5J7Hnc27328@copfs01.mips.com> Subject: Re: Linux and the Sony Playstation To: linux-mips@oss.sgi.com (user alias) Date: Wed, 19 Jun 2002 09:17:49 +0200 (MEST) 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 Content-Length: 3069 Lines: 68 Forwarded message: > From: "Kevin D. Kissell" > To: , > Subject: Linux and the Sony Playstation 2 > Date: Tue, 18 Jun 2002 15:59:57 +0200 > > The Sony PS2 Linux kit has been shipping for nearly > a month now, and I'm frankly astonished at how little > I've seen on this mailing list about it. For better or > for worse, this changes everything for MIPS/Linux. > The number of MIPS/Linux users worldwide has > just gone up by at least an order of magnitude, > and they are on a platform running a 2.2.1-derived > kernel and using gcc 2.95.2. > > It's a perfectly usable platform out of the box, but > Carsten has thrown "crashme" at it, and it goes down > relatively quickly. People trying to port kaffe and > other programs that do double-precision float are > blocked because there's no double precision on the > R5900, and the Sony kernel lacks the Algorithmics > emulator. The few simple double-precision programs (ala hello world) I ran worked, and the compiler substitutes integer code (softfloat) for any double precision operation. What are the things known not to work? > It's not clear what Sony is going to put into further > development, and what they are going to expect the > user community to take over from here. There is a > group of people trying to take the kernel up to > 2.2.20, but I'm not yet sure whether they know > what they are doing, and anyway, that box needs > to get to 2.4.x ASAP. It would be great to get 2.4.x on PS/2, and if one doesn't run into glibc/kernel dependencies in the upgrade, it should be a reasonable amount of work. The biggest benefit I see is that a 2.4.x upgrade with the emulator would allow binary portability of userland using double prec floats. But one thing which I really admire on the Sony release is the thoroughness and completeness of their offering. The kernel has full support for the additional T5900 SIMD state, all new instructions and state is supported fully in toolchain: binutils, gdb, you name it. Everything in the kit works (at least what I have tested). Getting the kernel upgraded would be nice, but there is probably even more work getting the toolchain, glibc and userland up to speed. There are about 600 binary userland RPMs provided, which is also a ton of work to keep updated. One needs to be very careful that the individual "upgrade" pieces people do doesn't break the overall nice picture of "everything works out of the box". What is really needed is that somebody puts together a productized PS/2 Linux kit version 2.0, which has the kernel/glibc/toolchain/userland RPMs upgraded to recent versions. If somebody else volunteers for the rest, I'll do the kernel :-) (One of us here here might do it anyway). /Hartvig -- _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com |\ /| | |____)(____ Direct: +45 4486 5503 | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 From owner-linux-mips@oss.sgi.com Wed Jun 19 02:12: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 g5J9CrnC012839 for ; Wed, 19 Jun 2002 02:12:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9CrSg012838 for linux-mips-outgoing; Wed, 19 Jun 2002 02:12:53 -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 (c-180-196-131.ka.dial.de.ignite.net [62.180.196.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9CanC012835 for ; Wed, 19 Jun 2002 02:12:47 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5J91xk21715; Wed, 19 Jun 2002 11:01:59 +0200 Date: Wed, 19 Jun 2002 11:01:59 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: 64-bit kernel Message-ID: <20020619110159.A21533@dea.linux-mips.net> References: <3D0F28AE.7B0D822B@mips.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: <3D0F28AE.7B0D822B@mips.com>; from carstenl@mips.com on Tue, Jun 18, 2002 at 02:33:50PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 477 Lines: 13 On Tue, Jun 18, 2002 at 02:33:50PM +0200, Carsten Langgaard wrote: > I don't know if anymore has a interest in the 64-bit kernel, but I just > found this bug (see patch below). > It would be nice to know, how many are interested in the 64-bit kernel > and who actually got something running. > So please rise you voice. More and more systems run into the limits of system memory so once it's practically unavoidable. Take the existence of highmem as a proof for it. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 02:16: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 g5J9GRnC012941 for ; Wed, 19 Jun 2002 02:16:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9GRgN012940 for linux-mips-outgoing; Wed, 19 Jun 2002 02:16: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 g5J9GLnC012937 for ; Wed, 19 Jun 2002 02:16:21 -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 CAA19851; Wed, 19 Jun 2002 02:15:22 -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 CAA26087; Wed, 19 Jun 2002 02:15:17 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5J9FHb17914; Wed, 19 Jun 2002 11:15:18 +0200 (MEST) Message-ID: <3D104BA4.BEEAAB6C@mips.com> Date: Wed, 19 Jun 2002 11:15:16 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Christensen CC: linux-mips@oss.sgi.com, license-discuss@opensource.org, kevink@mips.com Subject: Re: Linux and the Sony Playstation 2 References: <007601c216d0$6f7f0840$10eca8c0@grendel> <00e001c216f6$86594b40$0b01a8c0@w2k30g> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1842 Lines: 49 The DVDs you get with the linux kit, contain all necessary hardware documentation. /Carsten David Christensen wrote: > Kevin: > > Kevin D. Kissell wrote on linux-mips@oss.sgi.com: > > The Sony PS2 Linux kit has been shipping for nearly... > > If the PS2 is an open source platform, I would like to know that. > However, I do not see Sony on the OSI approved license list: > > http://www.opensource.org/licenses/index.php > > So, let me get out my soap box... > > When people say "Open Source", the first thing that comes to mind is > software. But, this is only one half of the equation. The hardware > must also be "open", or the concept doesn't work. First, because > attempting to write systems software without complete and accurate > hardware documentation is an exercise in reverse engineering. The > community can better spend its time on documented hardware. Second, and > more importantly, because any intellectual property (IP) encumbrance > will make the results pointless in the marketplace. > > Closed hardware breaks the community development model. Vendors who > provide a Linux distribution but keep their hardware proprietary cannot > honestly claim "Open Source". Vendors who fully disclose and freely > license both their hardware and software have embraced "Open Source". > As consumers, we vote with our dollars. As engineers, we further one > cause or the other by our education, employment, and personal project > choices. > > David Christensen > dpchrist@holgerdanske.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 Wed Jun 19 02:17: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 g5J9H9nC012982 for ; Wed, 19 Jun 2002 02:17:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9H9jR012981 for linux-mips-outgoing; Wed, 19 Jun 2002 02:17: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 (c-180-196-131.ka.dial.de.ignite.net [62.180.196.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9H5nC012978 for ; Wed, 19 Jun 2002 02:17:07 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5J9Hbl21969; Wed, 19 Jun 2002 11:17:37 +0200 Date: Wed, 19 Jun 2002 11:17:37 +0200 From: Ralf Baechle To: Jun Sun Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: __access_ok Message-ID: <20020619111737.B21533@dea.linux-mips.net> References: <3D0DCDCB.252F5565@mips.com> <3D0E3E9C.4070702@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: <3D0E3E9C.4070702@mvista.com>; from jsun@mvista.com on Mon, Jun 17, 2002 at 12:55:08PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 251 Lines: 8 On Mon, Jun 17, 2002 at 12:55:08PM -0700, Jun Sun wrote: > Just to be nit-picking, the end point should be (addr + size - 1). You better don't use the last bit of userspace and make that (addr + size). Saves several kB on the entire kernel. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 02:28: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 g5J9SJnC013310 for ; Wed, 19 Jun 2002 02:28:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9SJ4t013309 for linux-mips-outgoing; Wed, 19 Jun 2002 02:28: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 (c-180-196-131.ka.dial.de.ignite.net [62.180.196.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9SEnC013304 for ; Wed, 19 Jun 2002 02:28:16 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5J9Sqw22130; Wed, 19 Jun 2002 11:28:52 +0200 Date: Wed, 19 Jun 2002 11:28:52 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: 64-bit kernel Message-ID: <20020619112852.A22048@dea.linux-mips.net> References: <3D0F28AE.7B0D822B@mips.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: <3D0F28AE.7B0D822B@mips.com>; from carstenl@mips.com on Tue, Jun 18, 2002 at 02:33:50PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 537 Lines: 15 On Tue, Jun 18, 2002 at 02:33:50PM +0200, Carsten Langgaard wrote: > X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) > > I don't know if anymore has a interest in the 64-bit kernel, but I just > found this bug (see patch below). > It would be nice to know, how many are interested in the 64-bit kernel > and who actually got something running. > So please rise you voice. The patch is ok but please do not send inline patches with Mozilla - it does bad things like converting tabs to spaces and wordwrapping to patches. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 02:32: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 g5J9WGnC013576 for ; Wed, 19 Jun 2002 02:32:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9WGQg013575 for linux-mips-outgoing; Wed, 19 Jun 2002 02:32:16 -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 (c-180-196-131.ka.dial.de.ignite.net [62.180.196.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9WBnC013572 for ; Wed, 19 Jun 2002 02:32:12 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5J9Wii22209; Wed, 19 Jun 2002 11:32:44 +0200 Date: Wed, 19 Jun 2002 11:32:44 +0200 From: Ralf Baechle To: Justin Carlson Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: 64-bit kernel Message-ID: <20020619113244.B22048@dea.linux-mips.net> References: <3D0F28AE.7B0D822B@mips.com> <1024416198.1166.1.camel@xyzzy.rlson.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: <1024416198.1166.1.camel@xyzzy.rlson.org>; from justin@cs.cmu.edu on Tue, Jun 18, 2002 at 09:03:18AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 662 Lines: 16 On Tue, Jun 18, 2002 at 09:03:18AM -0700, Justin Carlson wrote: > On Tue, 2002-06-18 at 05:33, Carsten Langgaard wrote: > > I don't know if anymore has a interest in the 64-bit kernel, but I just > > found this bug (see patch below). > > It would be nice to know, how many are interested in the 64-bit kernel > > and who actually got something running. > > So please rise you voice. > > Been running 64-bit stuff here, but nothing even remotely fpu intensive. > It's quite possible we'd never run into this case. At this time probably most 64-bit kernels are running on a certain 64-bit CPU with it's hardware fp disabled so nobody ever saw this one. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 02:37: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 g5J9b8nC013678 for ; Wed, 19 Jun 2002 02:37:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9b8XV013677 for linux-mips-outgoing; Wed, 19 Jun 2002 02:37:08 -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 g5J9b0nC013672 for ; Wed, 19 Jun 2002 02:37:00 -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 CAA19938 for ; Wed, 19 Jun 2002 02:39:51 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA27110; Wed, 19 Jun 2002 02:39:46 -0700 (PDT) Message-ID: <002901c21775$45209190$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Hartvig Ekner" , "user alias" References: <200206190717.g5J7Hnc27328@copfs01.mips.com> Subject: Re: Linux and the Sony Playstation Date: Wed, 19 Jun 2002 11:39:41 +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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2484 Lines: 57 From: "Hartvig Ekner" To: "user alias" > > From: "Kevin D. Kissell" > > To: , > > Subject: Linux and the Sony Playstation 2 > > Date: Tue, 18 Jun 2002 15:59:57 +0200 > > > > The Sony PS2 Linux kit has been shipping for nearly > > a month now, and I'm frankly astonished at how little > > I've seen on this mailing list about it. For better or > > for worse, this changes everything for MIPS/Linux. > > The number of MIPS/Linux users worldwide has > > just gone up by at least an order of magnitude, > > and they are on a platform running a 2.2.1-derived > > kernel and using gcc 2.95.2. > > > > It's a perfectly usable platform out of the box, but > > Carsten has thrown "crashme" at it, and it goes down > > relatively quickly. People trying to port kaffe and > > other programs that do double-precision float are > > blocked because there's no double precision on the > > R5900, and the Sony kernel lacks the Algorithmics > > emulator. > > The few simple double-precision programs (ala hello world) I ran worked, > and the compiler substitutes integer code (softfloat) for any double > precision operation. What are the things known not to work? You didn't disassemble the code. The Sony gcc distribution is hard-wired to generate soft-float code, even if you specify -mhard-float on the command line. Since most embedded/multimedia FP is single precision, one could imagine why Sony and Toshiba could have decided to leave out floating doubles. The real problem is the accursed C stipulation that all FP arguments be promoted to doubles. Having every damned passed argument converted by the kernel would be a bit of a hit, but I would expect that, in any (single precision) floating point computation intensive application, that would be more than made up for by the time gained in executing the loops native. And, as always, we have the correctness issue. We need to get the PS2 to 2.4.x (and 2.5) fairly quickly, and we want to be able to have interoperability of MIPS32 binaries across PS2 and non-PS2 platforms, including those who habitually use their FPUs. I've started hacking the current (2.4.18+) MIPS/Algorithmics emulator code into the Sony 2.2.1 kernel as a stopgap, but it's a little tricky to test, given that the Sony tools go out of their way to stop me generating any real FP instructions. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Jun 19 02:40: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 g5J9eNnC013782 for ; Wed, 19 Jun 2002 02:40:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9eN7N013781 for linux-mips-outgoing; Wed, 19 Jun 2002 02:40: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 (c-180-196-131.ka.dial.de.ignite.net [62.180.196.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J9eGnC013775 for ; Wed, 19 Jun 2002 02:40:17 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5J9evC22344 for linux-mips@oss.sgi.com; Wed, 19 Jun 2002 11:40:57 +0200 Date: Wed, 19 Jun 2002 11:39:33 +0200 From: Ralf Baechle To: William Jhun Cc: "linux-mips@oss.sgi.com"@ayrnetworks.com Subject: Re: [PATCH] dma_cache_wback, pci DMA cache coherency changes Message-ID: <20020619113933.C22048@dea.linux-mips.net> References: <20020618100347.A1361@ayrnetworks.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: <20020618100347.A1361@ayrnetworks.com>; from wjhun@ayrnetworks.com on Tue, Jun 18, 2002 at 10:03:47AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1421 Lines: 32 On Tue, Jun 18, 2002 at 10:03:47AM -0700, William Jhun wrote: > To: "linux-mips@oss.sgi.com"@ayrnetworks.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Your mail software is smoking funny stuff ;-) > This is a re-hash of patches I sent out a while ago which do a more > optimal cache-flushing for pci_map_*() and pci_dma_sync_*(). It > basically does an invalidate for PCI_DMA_FROMDEVICE operations and a > writeback for PCI_DMA_TODEVICE pci_map_* (or writeback/invalidate if > PCI_DMA_BIDIRECTIONAL). This is similar to the ARM implementation. > > Additionally, I filled in the _dma_cache_wback calls in the > arch/mips/c-*.c to call *_dma_cache_wback_inv* instead of calling > panic(). Some architectures could probably do a real writeback instead > of just wback_inv, but this will at least allow code that can use > writeback-only if available. > > Note: I'm not familiar with a lot of these CPUs, but the change should > be innocuous. Could someone validate/improve these? Can you try to get rid of all these #ifdef CONFIG_NONCOHERENT_IO things? We already had too many of them and you're adding even more ... Basically if dma_cache_wback_inv, dma_cache_wback and dma_cache_inv are just empty macros as they are if CONFIG_NONCOHERENT_IO is undefined gcc should be able to optimize most of the #ifdef'd code away. Please always cc patches you want to submit to me or I might miss them on the list. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 02:49: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 g5J9nHnC014035 for ; Wed, 19 Jun 2002 02:49:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9nG8w014034 for linux-mips-outgoing; Wed, 19 Jun 2002 02:49:16 -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 g5J9n5nC014023 for ; Wed, 19 Jun 2002 02:49:05 -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 CAA19975 for ; Wed, 19 Jun 2002 02:51:56 -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 CAA27558; Wed, 19 Jun 2002 02:51:54 -0700 (PDT) Received: (from hartvige@localhost) by copfs01.mips.com (8.11.4/8.9.0) id g5J9pt620966; Wed, 19 Jun 2002 11:51:55 +0200 (MEST) From: Hartvig Ekner Message-Id: <200206190951.g5J9pt620966@copfs01.mips.com> Subject: Re: Linux and the Sony Playstation To: kevink@mips.com (Kevin D. Kissell) Date: Wed, 19 Jun 2002 11:51:55 +0200 (MEST) Cc: hartvige@mips.com (Hartvig Ekner), linux-mips@oss.sgi.com (user alias) In-Reply-To: <002901c21775$45209190$10eca8c0@grendel> from "Kevin D. Kissell" at Jun 19, 2002 11:39:41 AM 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 Content-Length: 3536 Lines: 89 Kevin D. Kissell writes: > > From: "Hartvig Ekner" > To: "user alias" > > > From: "Kevin D. Kissell" > > > To: , > > > Subject: Linux and the Sony Playstation 2 > > > Date: Tue, 18 Jun 2002 15:59:57 +0200 > > > > > > The Sony PS2 Linux kit has been shipping for nearly > > > a month now, and I'm frankly astonished at how little > > > I've seen on this mailing list about it. For better or > > > for worse, this changes everything for MIPS/Linux. > > > The number of MIPS/Linux users worldwide has > > > just gone up by at least an order of magnitude, > > > and they are on a platform running a 2.2.1-derived > > > kernel and using gcc 2.95.2. > > > > > > It's a perfectly usable platform out of the box, but > > > Carsten has thrown "crashme" at it, and it goes down > > > relatively quickly. People trying to port kaffe and > > > other programs that do double-precision float are > > > blocked because there's no double precision on the > > > R5900, and the Sony kernel lacks the Algorithmics > > > emulator. > > > > The few simple double-precision programs (ala hello world) I ran worked, > > and the compiler substitutes integer code (softfloat) for any double > > precision operation. What are the things known not to work? > > You didn't disassemble the code. The Sony gcc distribution > is hard-wired to generate soft-float code, even if you > specify -mhard-float on the command line. I did disassemble the code. It generates true FPU code for floats, and soft-float for double. See the example below: [hartvige@copps01 test]$ more hellof.c int main() { float a,b; a = 3.0f; b = a + 2.0f; printf("hello world %f\n",b); } gcc hellof.c, and disassembling: 0000000000400a70
: 400a70: 3c1c0fc0 lui $gp,0xfc0 400a74: 279c75c0 addiu $gp,$gp,30144 400a78: 0399e021 addu $gp,$gp,$t9 400a7c: 27bdffc0 addiu $sp,$sp,-64 400a80: afbc0010 sw $gp,16($sp) 400a84: afbf0038 sw $ra,56($sp) 400a88: afbe0034 sw $s8,52($sp) 400a8c: afbc0030 sw $gp,48($sp) 400a90: 03a0f021 move $s8,$sp 400a94: 3c014040 lui $at,0x4040 400a98: 44810000 mtc1 $at,$f0 400a9c: 00000000 nop 400aa0: e7c00020 swc1 $f0,32($s8) 400aa4: c7c00020 lwc1 $f0,32($s8) 400aa8: 3c014000 lui $at,0x4000 400aac: 44810800 mtc1 $at,$f1 400ab0: 00000000 nop 400ab4: 46010000 add.s $f0,$f0,$f1 400ab8: e7c00024 swc1 $f0,36($s8) 400abc: c7cc0024 lwc1 $f12,36($s8) 400ac0: 8f998054 lw $t9,-32684($gp) 400ac4: 0320f809 jalr $t9 400ac8: 00000000 nop 400acc: 8fdc0010 lw $gp,16($s8) 400ad0: 8f848018 lw $a0,-32744($gp) 400ad4: 24841040 addiu $a0,$a0,4160 400ad8: 00403021 move $a2,$v0 400adc: 00603821 move $a3,$v1 400ae0: 8f998064 lw $t9,-32668($gp) 400ae4: 0320f809 jalr $t9 400ae8: 00000000 nop 400aec: 8fdc0010 lw $gp,16($s8) 400af0: 03c0e821 move $sp,$s8 Were you talking about double-precision only, or is there something different in the kits? /Hartvig From owner-linux-mips@oss.sgi.com Wed Jun 19 03:12: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 g5JACxnC014378 for ; Wed, 19 Jun 2002 03:12:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JACx7H014377 for linux-mips-outgoing; Wed, 19 Jun 2002 03:12: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 g5JACunC014374 for ; Wed, 19 Jun 2002 03:12:56 -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 DAA20054 for ; Wed, 19 Jun 2002 03:15:46 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA28487; Wed, 19 Jun 2002 03:15:44 -0700 (PDT) Message-ID: <005501c2177a$4a1ba590$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Hartvig Ekner" Cc: "user alias" References: <200206190951.g5J9pt620966@copfs01.mips.com> Subject: Re: Linux and the Sony Playstation Date: Wed, 19 Jun 2002 12:15:37 +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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 861 Lines: 22 > > You didn't disassemble the code. The Sony gcc distribution > > is hard-wired to generate soft-float code, even if you > > specify -mhard-float on the command line. > > I did disassemble the code. It generates true FPU code for floats, and > soft-float for double. See the example below: I tested both double and single variants last night, and I *thought* that I had seen soft-float code generated for both cases. By the light of day, I can see that that the single case disassembly does indeed use the FPU - I must have gotten the disassembly files confused last night. In any case, as I said, even if you specify "hard-float", you'll get soft doubles from the Sony gcc. While various users have complained about both the speed and the accuracy of the Sony soft float implementation, it does pass paranoia with flying colors. Kevin K. From owner-linux-mips@oss.sgi.com Wed Jun 19 04:05: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 g5JB56nC015209 for ; Wed, 19 Jun 2002 04:05:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JB56mV015208 for linux-mips-outgoing; Wed, 19 Jun 2002 04:05:06 -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 g5JB4unC015193; Wed, 19 Jun 2002 04:04:57 -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 EAA20211; Wed, 19 Jun 2002 04:07:48 -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 EAA00374; Wed, 19 Jun 2002 04:07:47 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5JB7kb03497; Wed, 19 Jun 2002 13:07:46 +0200 (MEST) Message-ID: <3D106601.2347EECC@mips.com> Date: Wed, 19 Jun 2002 13:07:46 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: 64-bit kernel References: <3D0F28AE.7B0D822B@mips.com> <1024416198.1166.1.camel@xyzzy.rlson.org> <20020619113244.B22048@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 Content-Length: 1434 Lines: 43 I'm trying to compile glibc natively using my 64-bit kernel, but it fails with the following message: Out of Memory: Killed process 641 (qmgr). Out of Memory: Killed process 642 (tlsmgr). Out of Memory: Killed process 378 (portmap). Out of Memory: Killed process 9363 (cc1). Out of Memory: Killed process 9363 (cc1). So there may be a memory leak problem in 64-bit kernel. Has anyone seen this ? /Carsten Ralf Baechle wrote: > On Tue, Jun 18, 2002 at 09:03:18AM -0700, Justin Carlson wrote: > > > On Tue, 2002-06-18 at 05:33, Carsten Langgaard wrote: > > > I don't know if anymore has a interest in the 64-bit kernel, but I just > > > found this bug (see patch below). > > > It would be nice to know, how many are interested in the 64-bit kernel > > > and who actually got something running. > > > So please rise you voice. > > > > Been running 64-bit stuff here, but nothing even remotely fpu intensive. > > It's quite possible we'd never run into this case. > > At this time probably most 64-bit kernels are running on a certain 64-bit > CPU with it's hardware fp disabled so nobody ever saw this one. > > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jun 19 04:13: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 g5JBDKnC015384 for ; Wed, 19 Jun 2002 04:13:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JBDKE8015383 for linux-mips-outgoing; Wed, 19 Jun 2002 04:13:20 -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 (c-180-196-69.ka.dial.de.ignite.net [62.180.196.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JBDEnC015380 for ; Wed, 19 Jun 2002 04:13:16 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5JBDlW23563; Wed, 19 Jun 2002 13:13:47 +0200 Date: Wed, 19 Jun 2002 13:13:47 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: Justin Carlson , linux-mips@oss.sgi.com Subject: Re: 64-bit kernel Message-ID: <20020619131347.A23495@dea.linux-mips.net> References: <3D0F28AE.7B0D822B@mips.com> <1024416198.1166.1.camel@xyzzy.rlson.org> <20020619113244.B22048@dea.linux-mips.net> <3D106601.2347EECC@mips.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: <3D106601.2347EECC@mips.com>; from carstenl@mips.com on Wed, Jun 19, 2002 at 01:07:46PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 19 On Wed, Jun 19, 2002 at 01:07:46PM +0200, Carsten Langgaard wrote: > I'm trying to compile glibc natively using my 64-bit kernel, but it fails with > the following message: > > Out of Memory: Killed process 641 (qmgr). > Out of Memory: Killed process 642 (tlsmgr). > Out of Memory: Killed process 378 (portmap). > Out of Memory: Killed process 9363 (cc1). > Out of Memory: Killed process 9363 (cc1). > > So there may be a memory leak problem in 64-bit kernel. > Has anyone seen this ? No. The entire Redhat 7.0 stuff I built was done exclusivly on a 64-bit kernel (with 2GB RAM however ...) and no such problem ever, even after long uptimes. Ralf From owner-linux-mips@oss.sgi.com Wed Jun 19 05:01: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 g5JC1OnC023593 for ; Wed, 19 Jun 2002 05:01:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JC1O7u023592 for linux-mips-outgoing; Wed, 19 Jun 2002 05:01:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-3.us4.outblaze.com (205-158-62-93.outblaze.com [205.158.62.93]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JC1LnC023584 for ; Wed, 19 Jun 2002 05:01:21 -0700 Received: (qmail 8474 invoked by uid 1001); 19 Jun 2002 12:04:14 -0000 Message-ID: <20020619120414.8473.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-3.us4.outblaze.com with http for balakris_ananth@email.com; Wed, 19 Jun 2002 07:04:14 -0500 From: "Balakrishnan Ananthanarayanan" To: linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, redhat-list@redhat.com Date: Wed, 19 Jun 2002 07:04:14 -0500 Subject: MIPS - Serial port X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-3.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 500 Lines: 14 Hi all, Is there anyone who has accessed the serial port of an RM7000 MIPS processor? If u can provide me the code please - or atleast the Serial PORT number of an RM7000 proc. mounted on an EV64120A Galileo Board? Balakrishnan -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Wed Jun 19 08:13: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 g5JFDHnC026556 for ; Wed, 19 Jun 2002 08:13:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFDHV9026555 for linux-mips-outgoing; Wed, 19 Jun 2002 08:13:17 -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 g5JFDDnC026551 for ; Wed, 19 Jun 2002 08:13:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22879; Wed, 19 Jun 2002 17:16:37 +0200 (MET DST) Date: Wed, 19 Jun 2002 17:16:37 +0200 (MET DST) From: "Maciej W. Rozycki" To: Justin Carlson cc: linux-mips@oss.sgi.com Subject: Re: reenabling interrupts on return from function In-Reply-To: <1024179748.1549.12.camel@localhost.localdomain> 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 Content-Length: 481 Lines: 13 On 15 Jun 2002, Justin Carlson wrote: > However, I still don't see the point of the above code. Why do we > explicitly clear bits 4-0 of the status register just before reloading > it from the system stack? Not to receive an interrupt in the middle of register restoration. -- + 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 Jun 19 09:15: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 g5JGFCnC029939 for ; Wed, 19 Jun 2002 09:15:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JGFC92029938 for linux-mips-outgoing; Wed, 19 Jun 2002 09:15:12 -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 g5JGF6nC029935 for ; Wed, 19 Jun 2002 09:15:07 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24293; Wed, 19 Jun 2002 18:18:05 +0200 (MET DST) Date: Wed, 19 Jun 2002 18:18:03 +0200 (MET DST) From: "Maciej W. Rozycki" To: Justin Carlson cc: "Bradley D. LaRonde" , Balakrishnan Ananthanarayanan , linux-mips@oss.sgi.com Subject: Re: Code error - why? In-Reply-To: <1024416849.1182.10.camel@xyzzy.rlson.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 Content-Length: 583 Lines: 21 On 18 Jun 2002, Justin Carlson wrote: > After preprocessing, the assembler needs to see $ as > register specifiers, so typically your choices are to do either: > > #define a0 $4 // See include/asm-mips/regdef.h for these > #define v0 $2 > > ... > > la a0, quest > li v0, 4 Well, the usual choice is to put "#include " instead of copying definitions. -- + 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 Jun 19 09:43: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 g5JGhunC031113 for ; Wed, 19 Jun 2002 09:43:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JGhuE0031112 for linux-mips-outgoing; Wed, 19 Jun 2002 09:43: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 g5JGhnnC031108 for ; Wed, 19 Jun 2002 09:43:50 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA25063; Wed, 19 Jun 2002 18:47:05 +0200 (MET DST) Date: Wed, 19 Jun 2002 18:47:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ladislav Michl cc: linux-mips@oss.sgi.com Subject: Re: DBE/IBE handling incompatibility In-Reply-To: <20020617113311.GA839@kopretinka> 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 Content-Length: 2108 Lines: 40 On Mon, 17 Jun 2002, Ladislav Michl wrote: > i'd like to release GIO64 bus support. Before doing so DBE/IBE handling > should be done in the same fashion for both mips and mips64 (*). Currently > mips is using handler in handler via dbe_board_handler and ibe_board_handler > which are not used anywhere while mips64 is using BUILD_HANDLER macro defined > in include/asm-mips64/exception.h (see arch/mips64/sgi-ip27/ip27-dbe-glue.S) > Unfortunately I have nearly zero knowledge of MIPS assembler, so I'm > unable to code mips way same as mips64 is... Help from someone more > experienced will be greatly appreciated :-) I'm going to work on unifying and extending the code a bit once I have my 64-bit world running, so don't worry about the divergence between the ports. Don't rely in dbe_board_handler and ibe_board_handler -- they are system-specific backends that shouldn't be touched unless you want to handle the exceptions in a system-specific way (e.g. to report ECC errors from a memory controller). Also expect the handlers to get rewritten so that search_dbe_table() gets invoked unconditionally, before a system-specific backend. > (*) How GIO device detection works? each IP22 machine contains three GIO bus > slots. GIO device provides information about itself in first (three) word(s) > of address space it occupies. The only way how to detect GIO card is > trying to read word from it's base address. If DBE exception is generated > then there is definitely no card present, otherwise read value encodes > information about device. Use get_dbe() from for reading data with an additional DBE status. For a simple example see drivers/mtd/devices/ms02-nv.c. The macro is used in a somewhat more complex way in drivers/tc/tc.c as well -- this bit of code fits your situation quite closely (here probing TURBOchannel bus slots). The macro works in modules 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 Wed Jun 19 10:13: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 g5JHDXnC031682 for ; Wed, 19 Jun 2002 10:13:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JHDXEO031681 for linux-mips-outgoing; Wed, 19 Jun 2002 10:13:33 -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 g5JHDQnC031678; Wed, 19 Jun 2002 10:13:27 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA25860; Wed, 19 Jun 2002 19:16:42 +0200 (MET DST) Date: Wed, 19 Jun 2002 19:16:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: system.h asm fixes In-Reply-To: <20020618025204.A28165@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 Content-Length: 565 Lines: 16 On Tue, 18 Jun 2002, Ralf Baechle wrote: > > How can this work? A grep shows many instances of $1 usage, > > Uses by assembler code only, not gcc. Therefoe we don't need to protect > C code against use of $at. Moreover, gcc assumes ".set at" is always in effect and includes macros in its output that are known to clobber $1 and don't work with ".set noat". -- + 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 Jun 19 11:22: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 g5JIMqnC016604 for ; Wed, 19 Jun 2002 11:22:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JIMqD5016603 for linux-mips-outgoing; Wed, 19 Jun 2002 11:22: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-141.ayrnetworks.com [64.166.72.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JIMWnC016579; Wed, 19 Jun 2002 11:22:32 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g5JIM7v08690; Wed, 19 Jun 2002 11:22:07 -0700 Date: Wed, 19 Jun 2002 11:22:07 -0700 From: William Jhun To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: [PATCH] include/asm-mips/pci.h Message-ID: <20020619112207.B6057@ayrnetworks.com> References: <20020618100347.A1361@ayrnetworks.com> <20020619113933.C22048@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: <20020619113933.C22048@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Jun 19, 2002 at 11:39:33AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4420 Lines: 136 On Wed, Jun 19, 2002 at 11:39:33AM +0200, Ralf Baechle wrote: > On Tue, Jun 18, 2002 at 10:03:47AM -0700, William Jhun wrote: > > > To: "linux-mips@oss.sgi.com"@ayrnetworks.com > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Your mail software is smoking funny stuff ;-) Well! I'll just have to give it a strict spanking and send it off to rehab. No wonder the office window is always wide open when I arrive in the morning! > Can you try to get rid of all these #ifdef CONFIG_NONCOHERENT_IO things? > We already had too many of them and you're adding even more ... > Basically if dma_cache_wback_inv, dma_cache_wback and dma_cache_inv are > just empty macros as they are if CONFIG_NONCOHERENT_IO is undefined > gcc should be able to optimize most of the #ifdef'd code away. Ok, so I got rid of most except the ones in the *_sg() functions; gcc won't optimize the loop out, even with -O2. It just creates a tight loop that increments sg.. Note that without the #ifdefs, you may get warnings like: ../../../ayr/linux/include/asm/pci.h: In function `prep_buffer': ../../../ayr/linux/include/asm/pci.h:89: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:89: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:92: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:92: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:95: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:95: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h: In function `sync_buffer': ../../../ayr/linux/include/asm/pci.h:108: warning: statement with no effect ../../../ayr/linux/include/asm/pci.h:108: warning: statement with no effect So are we still sure we want to leave them out? 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/06/19 18:20:51 @@ -80,6 +80,37 @@ void *vaddr, dma_addr_t dma_handle); /* + * 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; + } +} + +/* * Map a single buffer of the indicated size for DMA in streaming mode. * The 32-bit bus address to use is returned. * @@ -92,9 +123,7 @@ if (direction == PCI_DMA_NONE) BUG(); -#ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)ptr, size); -#endif + prep_buffer(ptr, size, direction); return virt_to_bus(ptr); } @@ -131,9 +160,7 @@ addr = (unsigned long) page_address(page); addr += offset; -#ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv(addr, size); -#endif + prep_buffer((void*)addr, size, direction); return virt_to_bus((void *)addr); } @@ -183,7 +210,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; @@ -220,9 +247,7 @@ if (direction == PCI_DMA_NONE) BUG(); -#ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)bus_to_virt(dma_handle), size); -#endif + sync_buffer(bus_to_virt(dma_handle), size, direction); } /* @@ -246,7 +271,7 @@ /* 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); + sync_buffer(sg->address, sg->length, direction); #endif } From owner-linux-mips@oss.sgi.com Wed Jun 19 12:03: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 g5JJ3unC017287 for ; Wed, 19 Jun 2002 12:03:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JJ3uoS017286 for linux-mips-outgoing; Wed, 19 Jun 2002 12:03:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JJ3nnC017282 for ; Wed, 19 Jun 2002 12:03:49 -0700 Received: (qmail 17771 invoked by uid 512); 19 Jun 2002 19:06:47 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.127071 secs); 19 Jun 2002 19:06:47 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 19 Jun 2002 19:06:47 -0000 Message-ID: <011601c217c4$8df07490$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: "Dave J Woolley" References: Subject: Re: Linux and the Sony Playstation 2 Date: Wed, 19 Jun 2002 12:06:13 -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 Content-Length: 2189 Lines: 55 linux-mips@oss.sgi.com: "Dave J Woolley" wrote to "David Christensen" : > You are off topic on license discuss - it has a rather narrow charter > of discussing proposed Open Source licence documents. OK > There are two levels of open-ness in hardware. I'm not sure that > there is any electronic computing hardware that is completely open to > the level that open source software is++, but there is basically > hardware for which the design documentation is published and there is > hardware for which a programming model is published. Open source > drivers require the latter, Open source development may require both. for example, let's say I want to buy a PS2, open it up, add some goodies, and then sell, release under GPL, gift to the public domain, etc., my derivative work. > or reverse engineering - which may be illegal (even in Europe as I > think publishing the driver source code exceeds the limited > permissions given to reverse engineer without the vendors permission - > black box reverse engineering is OK, I believe, but not anything that > looks at mechanism rather than behaviour##). > > I'm not sure if you meant open programming models (which in software > terms mean open interface specifications) or open design information. > > ++ I doubt that the photo-lithography masks for even simple > transistors re published. I want open programming models and open design information down to the schematic, board layout, and parts list level. The insides of integrated circuits can remain secret so long as their operation and interfaces are completely documented and there are no IP entanglements when I want to design, publish, build, sell, give away, etc., circuits, software, and products which use them. > ## My understanding is that the EEC law requires refusal of the > supplier to provide the information on reasonable (not necessarily > cost free) terms; the information not to be used to create a competing > product; the information only being sufficient to interface; the > information not to be published to third parties. IANAL. Interesting. David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Wed Jun 19 12:03: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 g5JJ3xnC017304 for ; Wed, 19 Jun 2002 12:03:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JJ3xi7017303 for linux-mips-outgoing; Wed, 19 Jun 2002 12:03:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JJ3mnC017279 for ; Wed, 19 Jun 2002 12:03:48 -0700 Received: (qmail 17756 invoked by uid 512); 19 Jun 2002 19:06:46 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.04988 secs); 19 Jun 2002 19:06:46 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 19 Jun 2002 19:06:46 -0000 Message-ID: <011501c217c4$8daeb0a0$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: References: <007601c216d0$6f7f0840$10eca8c0@grendel> <00e001c216f6$86594b40$0b01a8c0@w2k30g> <3D104BA4.BEEAAB6C@mips.com> Subject: Re: Linux and the Sony Playstation 2 Date: Wed, 19 Jun 2002 11:18:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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 Content-Length: 420 Lines: 23 Everyone: "Carsten Langgaard" wrote on linux-mips@oss.sgi.com: > The DVDs you get with the linux kit, contain all necessary hardware > documentation. OK I assume the license is also on the DVD's. 1. Are the documents and license available online? If so, what is/are the URL(s)? 2. Has Sony submitted their license to OSI for approval? David Christensen dpchrist@holgerdanske.com From owner-linux-mips@oss.sgi.com Wed Jun 19 12:05: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 g5JJ52nC017364 for ; Wed, 19 Jun 2002 12:05:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JJ52P8017363 for linux-mips-outgoing; Wed, 19 Jun 2002 12:05:02 -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 g5JJ4unC017325 for ; Wed, 19 Jun 2002 12:04:56 -0700 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g5JJ7p626662; Wed, 19 Jun 2002 12:07:51 -0700 From: "Matthew Dharm" To: "Balakrishnan Ananthanarayanan" , , , Subject: RE: MIPS - Serial port Date: Wed, 19 Jun 2002 12:07:51 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20020619120414.8473.qmail@email.com> Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1199 Lines: 39 The RM7000 does not have an on-chip serial port. The EV board has it's own UART. 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 Balakrishnan > Ananthanarayanan > Sent: Wednesday, June 19, 2002 5:04 AM > To: linux-mips@oss.sgi.com; linux-kernel@vger.kernel.org; > redhat-list@redhat.com > Subject: MIPS - Serial port > > > Hi all, > > Is there anyone who has accessed the serial port of an > RM7000 MIPS processor? If u can provide me the code please > - or atleast the Serial PORT number of an RM7000 proc. > mounted on an EV64120A Galileo Board? > > Balakrishnan > > -- > __________________________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > Save up to $160 by signing up for NetZero Platinum Internet service. > http://www.netzero.net/?refcd=N2P0602NEP8 > From owner-linux-mips@oss.sgi.com Wed Jun 19 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 g5JK9hnC020537 for ; Wed, 19 Jun 2002 13:09:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JK9hop020536 for linux-mips-outgoing; Wed, 19 Jun 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 mail2.camcare.com ([206.193.125.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JK9WnC020524 for ; Wed, 19 Jun 2002 13:09:33 -0700 Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAXGJAR6; Wed, 19 Jun 2002 16:22:57 -0400 Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jun 2002 16:10:58 -0400 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568B84@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@oss.sgi.com'" Subject: RE: Linux and the Sony Playstation 2 Date: Wed, 19 Jun 2002 16:10:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2309 Lines: 63 Hello Kevin, This list is been pretty quiet lately so I don't really know what is happening on the Linux/MIPS front. I am hoping that work is still slowly proceeding on the DECstation that I have, but I don't really know. I agree with you that PS2 offer enormous power to the developer and as a cheap source of computing power to other countries. I don't know a great deal about it, but I am least willing to discuss it if it will create some additional interest. Todd Smith -----Original Message----- From: Kevin D. Kissell [mailto:kevink@mips.com] Sent: Tuesday, June 18, 2002 10:00 AM To: linux-mips@fnet.fr; linux-mips@oss.sgi.com Subject: Linux and the Sony Playstation 2 The Sony PS2 Linux kit has been shipping for nearly a month now, and I'm frankly astonished at how little I've seen on this mailing list about it. For better or for worse, this changes everything for MIPS/Linux. The number of MIPS/Linux users worldwide has just gone up by at least an order of magnitude, and they are on a platform running a 2.2.1-derived kernel and using gcc 2.95.2. It's a perfectly usable platform out of the box, but Carsten has thrown "crashme" at it, and it goes down relatively quickly. People trying to port kaffe and other programs that do double-precision float are blocked because there's no double precision on the R5900, and the Sony kernel lacks the Algorithmics emulator. It's not clear what Sony is going to put into further development, and what they are going to expect the user community to take over from here. There is a group of people trying to take the kernel up to 2.2.20, but I'm not yet sure whether they know what they are doing, and anyway, that box needs to get to 2.4.x ASAP. I respectfully submit that, within a year, any MIPS/Linux source tree that does not support the PS2 will be considered obsolete. And that quite specifically includes the one at oss.sgi.com. I personally would want to approach this in terms of merging the necessary PS2 code into something that could be expressed as a patch over kernel.org's 2.4.19_or_better, and which would be provded as the default MIPS kernel technology by MIPS and SGI servers, and ultimately by kernel.org. Is no one else here working on this? Regards, Kevin K. From owner-linux-mips@oss.sgi.com Wed Jun 19 13:37: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 g5JKbKnC021553 for ; Wed, 19 Jun 2002 13:37:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JKbKJt021552 for linux-mips-outgoing; Wed, 19 Jun 2002 13:37:20 -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] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JKbBnC021549; Wed, 19 Jun 2002 13:37:11 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 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 ESMTP id NAA07751; Wed, 19 Jun 2002 13:40:09 -0700 (PDT) mail_from (pj@engr.sgi.com) Received: from turbo-linux.engr.sgi.com (turbo-linux.engr.sgi.com [163.154.6.103]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA96108; Wed, 19 Jun 2002 13:38:52 -0700 (PDT) Received: by turbo-linux.engr.sgi.com (Postfix, from userid 2324) id 95A461014E10; Wed, 19 Jun 2002 13:38:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turbo-linux.engr.sgi.com (Postfix) with ESMTP id 905B81C000AA; Wed, 19 Jun 2002 13:38:52 -0700 (PDT) Date: Wed, 19 Jun 2002 13:38:52 -0700 (PDT) From: Paul Jackson To: William Jhun Cc: Ralf Baechle , Subject: Re: [PATCH] include/asm-mips/pci.h In-Reply-To: <20020619112207.B6057@ayrnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1149 Lines: 40 On Wed, 19 Jun 2002, William Jhun wrote: > Note that without the #ifdefs, you may get warnings like: > > ../../../ayr/linux/include/asm/pci.h: In function `prep_buffer': > ../../../ayr/linux/include/asm/pci.h:89: warning: statement with no effect > ... > > So are we still sure we want to leave them out? Yes - leave them out (speaking out of context here - hopefully still useful). Remove the warnings instead. I've gotten in the habit of having the following form to optional code logic: In some header file foobar.h: #if CONFIG_FOOBAR #define init_foobar(x) do { \ int f = 2 * (x); \ foobar_initialize(f); \ | while (0) #else #define init_foobar(x) do {} while (0) #endif I don't see any warnings from this, and it provides just the right sort of syntax wrapper on the macro init_foobar(), forcing it to be a single statement, regardless of context, while providing a nested block context for any local variables. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From owner-linux-mips@oss.sgi.com Thu Jun 20 03:25:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KAP7nC003612 for ; Thu, 20 Jun 2002 03:25:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KAP7ca003611 for linux-mips-outgoing; Thu, 20 Jun 2002 03:25:07 -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 (c-180-196-7.ka.dial.de.ignite.net [62.180.196.7]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KAOwnC003581 for ; Thu, 20 Jun 2002 03:25:00 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5KAPQp05042; Thu, 20 Jun 2002 12:25:26 +0200 Date: Thu, 20 Jun 2002 12:25:26 +0200 From: Ralf Baechle To: Paul Jackson Cc: William Jhun , linux-mips@oss.sgi.com Subject: Re: [PATCH] include/asm-mips/pci.h Message-ID: <20020620122525.B4835@dea.linux-mips.net> References: <20020619112207.B6057@ayrnetworks.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 pj@engr.sgi.com on Wed, Jun 19, 2002 at 01:38:52PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1405 Lines: 48 On Wed, Jun 19, 2002 at 01:38:52PM -0700, Paul Jackson wrote: > Yes - leave them out (speaking out of context here - hopefully still > useful). > > Remove the warnings instead. > > I've gotten in the habit of having the following form to > optional code logic: > > In some header file foobar.h: > > #if CONFIG_FOOBAR > #define init_foobar(x) do { \ > int f = 2 * (x); \ > foobar_initialize(f); \ > | while (0) > #else > #define init_foobar(x) do {} while (0) > #endif > > I don't see any warnings from this, and it provides just > the right sort of syntax wrapper on the macro init_foobar(), > forcing it to be a single statement, regardless of context, > while providing a nested block context for any local variables. Note your variant doesn't deal with side effects of the argument expression x (basically none of the equivalent constructions in the kernels do!) which is why our code in question does something like this: #if CONFIG_FOOBAR #define init_foobar(x) do { \ int f = 2 * (x); \ foobar_initialize(f); \ | while (0) #else #define init_foobar(x) do { (x); } while (0) #endif This can potencially expand into something like: do { 42; } while(0) which will result in warnings. The solution is: #define init_foobar(x) do { (void) (x); } while (0) Ralf From owner-linux-mips@oss.sgi.com Thu Jun 20 05:26: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 g5KCQ6nC010964 for ; Thu, 20 Jun 2002 05:26:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KCQ6LJ010963 for linux-mips-outgoing; Thu, 20 Jun 2002 05:26:06 -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 g5KCQ1nC010960 for ; Thu, 20 Jun 2002 05:26:02 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA20187; Thu, 20 Jun 2002 14:29:27 +0200 (MET DST) Date: Thu, 20 Jun 2002 14:29:26 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Smith, Todd" cc: "'linux-mips@oss.sgi.com'" Subject: RE: Linux and the Sony Playstation 2 In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568B84@KES.camcare.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 Content-Length: 970 Lines: 21 On Wed, 19 Jun 2002, Smith, Todd wrote: > This list is been pretty quiet lately so I don't really know what is > happening on the Linux/MIPS front. I am hoping that work is still slowly > proceeding on the DECstation that I have, but I don't really know. I agree > with you that PS2 offer enormous power to the developer and as a cheap > source of computing power to other countries. I'm doing some development on the DECstation -- changes get applied to the CVS as they are ready (e.g. I fixed a few bugs in declance yesterday). The last large change was the IRQ handling rewrite (small parts of which are still pending awaiting approval of generic bits they depend on). I'm planning another big change soon. If you have any problems, just report them here. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jun 20 10:44: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 g5KHiHnC032495 for ; Thu, 20 Jun 2002 10:44:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHiHR8032494 for linux-mips-outgoing; Thu, 20 Jun 2002 10:44:17 -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 g5KHiCnC032491 for ; Thu, 20 Jun 2002 10:44:14 -0700 Received: from excalibur.cologne.de (p50850B0C.dip.t-dialin.net [80.133.11.12]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA09085; Thu, 20 Jun 2002 19:47:13 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17L5ip-00007X-00; Thu, 20 Jun 2002 19:27:51 +0200 Date: Thu, 20 Jun 2002 19:27:51 +0200 From: Karsten Merker To: "Smith, Todd" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: Linux and the Sony Playstation 2 Message-ID: <20020620192751.B253@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , "Smith, Todd" , "'linux-mips@oss.sgi.com'" References: <490E0430C3C72046ACF7F18B7CD76A2A568B84@KES.camcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568B84@KES.camcare.com>; from Todd.Smith@camc.org on Wed, Jun 19, 2002 at 04:10:52PM -0400 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 671 Lines: 17 On Wed, Jun 19, 2002 at 04:10:52PM -0400, Smith, Todd wrote: > This list is been pretty quiet lately so I don't really know what is > happening on the Linux/MIPS front. I am hoping that work is still slowly > proceeding on the DECstation that I have, but I don't really know. I agree Which model Du you have? I am actively using Linux/MIPS on a DECstation 5000/150 (although not with a bleeding-edge kernel), and it works rather well for me. 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 Thu Jun 20 10:48: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 g5KHm3nC032601 for ; Thu, 20 Jun 2002 10:48:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHm2YU032600 for linux-mips-outgoing; Thu, 20 Jun 2002 10:48:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.camcare.com ([206.193.125.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KHm1nC032597 for ; Thu, 20 Jun 2002 10:48:01 -0700 Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAXGJMPZ; Thu, 20 Jun 2002 14:02:45 -0400 Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jun 2002 13:50:47 -0400 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568B90@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@oss.sgi.com'" Subject: DECstation Date: Thu, 20 Jun 2002 13:50:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 113 Lines: 4 Thanks for the update. Has there been any work on the website updating what works and what doesn't? Todd Smith From owner-linux-mips@oss.sgi.com Thu Jun 20 11:22: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 g5KIMlnC003598 for ; Thu, 20 Jun 2002 11:22:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KIMl5t003597 for linux-mips-outgoing; Thu, 20 Jun 2002 11:22:47 -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 g5KIMAnC003535 for ; Thu, 20 Jun 2002 11:22:10 -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 LAA06911 for ; Thu, 20 Jun 2002 11:25:28 -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 LAA25699; Thu, 20 Jun 2002 11:09:05 -0700 Message-ID: <3D12190A.9030607@mvista.com> Date: Thu, 20 Jun 2002 11:03:54 -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: Carsten Langgaard CC: Louis Hamilton , linux-mips@oss.sgi.com, sandcraft-elinux-project@redhat.com Subject: Re: Bug in Linux? fcr31 not being saved-restored References: <3D0BD42E.20602@redhat.com> <3D0D7F98.566B3176@mips.com> <3D0E38E8.10804@mvista.com> <3D0EEA5A.1B5DAA23@mips.com> <3D0F7213.6000002@mvista.com> <3D102ADD.71178636@mips.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10304 Lines: 300 I think this patch is OK. Whatever your gcc test is, it seems like it should fail on all other archs too, because a new program would always inherit the old fpu registers. It would be interesting to do a test on those platforms. I can see that having old values for general FPU registers is not a problem, but having the old value in FPU status register might. So an alternative is to clear fcr31 only in start_thread(). Note that without your patch, the secondary if (last_task_used_math != NULL) branch is never taken. This is because init process will be the only process that does not have used_math flag set and in that case last_task_use_math is indeed NULL. All other processes will inherit the used_math flag from its parent. Jun Carsten Langgaard wrote: > Jun Sun wrote: > > >>Your first chunk is not clear as to where it applies. Maybe you are using a >>different code base. >> > > Here is my do_cpu handler: > > asmlinkage void do_cpu(struct pt_regs *regs) > { > unsigned int cpid; > extern void lazy_fpu_switch(void *); > extern void save_fp(struct task_struct *); > extern void init_fpu(void); > void fpu_emulator_init_fpu(void); > int sig; > > cpid = (regs->cp0_cause >> CAUSEB_CE) & 3; > if (cpid != 1) > goto bad_cid; > > if (!(mips_cpu.options & MIPS_CPU_FPU)) > goto fp_emul; > > regs->cp0_status |= ST0_CU1; > if (last_task_used_math == current) > return; > > if (current->used_math) { /* Using the FPU again. */ > lazy_fpu_switch(last_task_used_math); > } else { /* First time FPU user. */ > if (last_task_used_math != NULL) > { > __enable_fpu(); > save_fp(last_task_used_math); > /* last_task_used_math loose fpu */ > ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - > sizeof(struct pt_regs)))-> > cp0_status &= ~ST0_CU1; > } > init_fpu(); > current->used_math = 1; > } > last_task_used_math = current; > > return; > > fp_emul: > if (last_task_used_math != current) { > if (!current->used_math) { > fpu_emulator_init_fpu(); > current->used_math = 1; > } > } > sig = fpu_emulator_cop1Handler(0, regs, ¤t->thread.fpu.soft); > last_task_used_math = current; > if (sig) > { > /* > * Return EPC is not calculated in the FPU emulator, if > * a signal is being send. So we calculate it here. > */ > compute_return_epc(regs); > force_sig(sig, current); > } > return; > > bad_cid: > #ifndef CONFIG_CPU_HAS_LLSC > switch (mips_cpu.cputype) { > case CPU_TX3927: > case CPU_TX39XX: > do_ri(regs); > return; > } > #endif > compute_return_epc(regs); > force_sig(SIGILL, current); > } > > > >>The second chunck is not necessary. Although the FPU values in thread struct >>for the new thread are stale, the new program cannot assume the fpu register >>values and cannot use them without initialization anyway. >> > > At least with the do_cpu handler above, you need this. > I'm not sure which tests failed without this, but I think it was some of the gcc selftests > and I think the problem was, that a thread inherited the previous thread's fsr (floating > point status register). > > >>I don't see such a code in x86's code. Current call to start_thread() is ok >>with or without this change. I am afraid future use of start_thread() may >>give undesired effect after we make this change. >> > > Why ? > > >>As for the new fpu context switch code, I wrote a experiemental patch after >>much discussion with Ralf and Kevin. It is at >> >>http://linux.junsun.net/patches/oss.sgi.com/experimental/020304-half-fpu-context-switch >> >>I also did some performance study of this patch. Did not get much feedbacks >>when I asked last time. :-( >> >>Jun >> >>Carsten Langgaard wrote: >> >> >>>I believe this is the patch that solve the problem. >>>The lazy fpu stuff has cause so many problems, that we have decided (together >>>with Ralf) to get rid of it, and do the FPU context save and restore a little bit >>>differently. >>>We now have a solution here locally and we are testing it at the moment. >>> >>>/Carsten >>> >>> >>>Index: arch/mips/kernel/traps.c >>>=================================================================== >>>RCS file: /cvs/linux/arch/mips/kernel/traps.c,v >>>retrieving revision 1.99.2.14 >>>diff -u -r1.99.2.14 traps.c >>>--- arch/mips/kernel/traps.c 2002/05/28 06:33:13 1.99.2.14 >>>+++ arch/mips/kernel/traps.c 2002/06/18 07:53:47 >>>+ { >>>+ __enable_fpu(); >>> save_fp(last_task_used_math); >>>+ /* last_task_used_math loose fpu */ >>>+ ((struct pt_regs *)(__KSTK_TOS(last_task_used_math) - >>>+ sizeof(struct pt_regs)))-> >>>+ cp0_status &= ~ST0_CU1; >>>+ } >>> >>>Index: include/asm-mips/processor.h >>>=================================================================== >>>RCS file: /cvs/linux/include/asm-mips/processor.h,v >>>retrieving revision 1.43.2.2 >>>diff -u -r1.43.2.2 processor.h >>>--- include/asm-mips/processor.h 2002/05/28 06:11:56 1.43.2.2 >>>+++ include/asm-mips/processor.h 2002/06/18 07:56:58 >>>@@ -215,6 +215,7 @@ >>> regs->cp0_epc = new_pc; \ >>> regs->regs[29] = new_sp; \ >>> current->thread.current_ds = USER_DS; \ >>>+ current->used_math = 0; \ >>> } while (0) >>> >>> unsigned long get_wchan(struct task_struct *p); >>> >>> >>> >>>Jun Sun wrote: >>> >>> >>> >>>>Carsten Langgaard wrote: >>>> >>>> >>>> >>>>>This is one of the bugs, among others, we have fixed. >>>>>I'm not sure, if Ralf have integrated the patches we send him yet. >>>>> >>>>> >>>>> >>>>Carsten, >>>> >>>>Do you remember the cause and the fix? It appears to me the first ctc1 >>>>instruction should trap into kernel and mark current process as fpu owner, and >>>>should not cause fcr31 corruption. >>>> >>>>Or somehow the ctc1 does not trap into kernel? >>>> >>>>Jun >>>> >>>> >>>> >>>>>/Carsten >>>>> >>>>>Louis Hamilton wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>We have a customer here testing a 2.4.16 mips kernel on an embedded >>>>>>Linux RM7000/SR71000 based system who has written a test that they >>>>>>believe has uncovered a bug in Linux. The FPU control register appears >>>>>>to not get saved and restored. I've reproduced the problem described >>>>>>below and find the results consistent with their description. The >>>>>>problem occurs on both the RM7000 and SR71000 cpus. >>>>>> >>>>>>It looks like save_fp_context and restore_fp_context are not being >>>>>>called since the kernel save-restore logic thinks the process is not >>>>>>using floating point math. If you do some fp math before calling the >>>>>>test routine below, it seems to works fine. >>>>>> >>>>>>Is this a known caveat? A true bug? Or a contorted corner case >>>>>>unlikely to be seen under typical end-user usage (see customer's >>>>>>last paragraph :-) ? If true bug, recommended remedy? >>>>>> >>>>>>TIA, >>>>>>Louis >>>>>> >>>>>>Louis Hamilton >>>>>>hamilton@redhat.com >>>>>> >>>>>>------ customer reports the following: --------- >>>>>>We found a bug in Linux. A ^C (control-C) typed into a shell (or a >>>>>>running program, it doesn't matter), causes the FCR (floating-point >>>>>>control register) to be corrupted in another, unrelated process. This >>>>>>is repeatable behavior. >>>>>> >>>>>>This can be reproduced with the following short assembly language >>>>>>program that loops forever, waiting for the FCR to change. >>>>>> >>>>>> .align 2 >>>>>> .globl mips_float_debug_loop >>>>>>mips_float_debug_loop: >>>>>> li $9, 0xF000F02F >>>>>> ctc1 $9, $31 # set FCR to some non-zero value >>>>>> nop >>>>>>1: cfc1 $8, $31 # get FCR >>>>>> beq $8, $9, 1b # spin, waiting for FCR to change >>>>>> nop >>>>>> or $2, $0, $8 >>>>>> jr $31 >>>>>> nop >>>>>> >>>>>>You can call this function from a short C program and the return value >>>>>>is the (corrupted) FCR, which turns out to alwyas be: 0x00000002. >>>>>> >>>>>>Run the above loop in one window (connected to the board using telnet) >>>>>>and then in another window (connected to the same board) type ^C. >>>>>> >>>>>>I'm surprised this bug hasn't been encountered by other MIPS vendors. >>>>>> >>>>>> >>>>>> >>>>>-- >>>>>_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com >>>>>|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 >>>>>| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 >>>>> TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 >>>>> Denmark http://www.mips.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>-- >>>_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com >>>|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 >>>| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 >>> TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 >>> Denmark http://www.mips.com >>> >>> >>> >>> >>> > > -- > _ _ ____ ___ 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 Jun 20 12:21: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 g5KJL6nC007766 for ; Thu, 20 Jun 2002 12:21:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KJL6hM007765 for linux-mips-outgoing; Thu, 20 Jun 2002 12:21:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KJJunC007750 for ; Thu, 20 Jun 2002 12:19:57 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020620192254.FSQ20219.sccrmhc03.attbi.com@ocean.lucon.org>; Thu, 20 Jun 2002 19:22:54 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 49FAA125C1; Thu, 20 Jun 2002 12:22:49 -0700 (PDT) Date: Thu, 20 Jun 2002 12:22:49 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.12.90.0.12 is released Message-ID: <20020620122249.A17654@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 Content-Length: 15776 Lines: 572 This is the beta release of binutils 2.12.90.0.12 for Linux, which is based on binutils 2002 0618 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 Please report any bugs related to binutils 2.12.90.0.12 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.12.90.0.11: 1. Update from binutils 2002 0618. 2. Fix an mips assembler bug. Changes from binutils 2.12.90.0.9: 1. Update from binutils 2002 0608. 2. Fix an ELF/mips SHF_MERGE bug. 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.12.tar.gz. Source code. 2. binutils-2.12.90.0.11-2.12.90.0.12.diff.gz. Patch against the previous beta source code. 3. binutils-2.12.90.0.12-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.12.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 06/19/2002 From owner-linux-mips@oss.sgi.com Thu Jun 20 16:56: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 g5KNuOnC013605 for ; Thu, 20 Jun 2002 16:56:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KNuOfN013604 for linux-mips-outgoing; Thu, 20 Jun 2002 16:56:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from smtp.inreach.com (smtp.inreach.com [209.142.2.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KNuInC013588 for ; Thu, 20 Jun 2002 16:56:18 -0700 Received: (qmail 5672 invoked by uid 512); 20 Jun 2002 23:59:21 -0000 Received: from dpchrist@holgerdanske.com by smtp.inreach.com by uid 509 with qmail-scanner-1.11 (perlscanner 1.11: clear; processed in 0.049461 secs); 20 Jun 2002 23:59:21 -0000 Received: from unknown (HELO w2k30g) (209.142.39.228) by smtp.inreach.com with SMTP; 20 Jun 2002 23:59:21 -0000 Message-ID: <001601c218b6$97984b10$0b01a8c0@w2k30g> From: "David Christensen" To: Cc: References: <007601c216d0$6f7f0840$10eca8c0@grendel> <3D104BA4.BEEAAB6C@mips.com> <011501c217c4$8daeb0a0$0b01a8c0@w2k30g> Subject: Re: Linux and the Sony Playstation 2 Date: Thu, 20 Jun 2002 16:59:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" 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 Content-Length: 870 Lines: 43 Luke: "OSI" is the Open Source Initiative: http://www.opensource.org/ David ----- Original Message ----- From: "Luke A. Guest" To: "David Christensen" Sent: Wednesday, June 19, 2002 3:08 PM Subject: Re: Linux and the Sony Playstation 2 On Wednesday 19 Jun 2002 7:18 pm, you wrote: > Everyone: > > "Carsten Langgaard" wrote on > linux-mips@oss.sgi.com: > > The DVDs you get with the linux kit, contain all necessary hardware > > documentation. Not all, but most of them. Basically you get the black/blue books in PDF form. > OK I assume the license is also on the DVD's. > > 1. Are the documents and license available online? If so, what > is/are the URL(s)? Not unless you're a PS2 developer. > 2. Has Sony submitted their license to OSI for approval? OSI? Luke. From owner-linux-mips@oss.sgi.com Fri Jun 21 00:43: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 g5L7hJnC003588 for ; Fri, 21 Jun 2002 00:43:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L7hJEL003587 for linux-mips-outgoing; Fri, 21 Jun 2002 00:43:19 -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 g5L7hFnC003584 for ; Fri, 21 Jun 2002 00:43:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA18588; Fri, 21 Jun 2002 09:46:48 +0200 (MET DST) Date: Fri, 21 Jun 2002 09:46:48 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Smith, Todd" cc: "'linux-mips@oss.sgi.com'" Subject: Re: DECstation In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568B90@KES.camcare.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 Content-Length: 580 Lines: 15 On Thu, 20 Jun 2002, Smith, Todd wrote: > Thanks for the update. Has there been any work on the website updating what > works and what doesn't? What website do you specifically refer to? If you mean 'http://decstation.unix-ag.org/', then that's notoriously out of date. But Karel does a pretty good job maintaining his site -- see 'http://www.xs4all.nl/~vhouten/mipsel/'. -- + 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 Fri Jun 21 06:53: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 g5LDrQnC007086 for ; Fri, 21 Jun 2002 06:53:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LDrQGb007085 for linux-mips-outgoing; Fri, 21 Jun 2002 06:53:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.camcare.com ([206.193.125.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LDrKnC007082 for ; Fri, 21 Jun 2002 06:53:21 -0700 Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAXGJW6F; Fri, 21 Jun 2002 10:08:10 -0400 Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jun 2002 09:56:11 -0400 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568B98@KES.camcare.com> From: "Smith, Todd" To: "''linux-mips@oss.sgi.com' '" Subject: DECstation Date: Fri, 21 Jun 2002 09:56:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 925 Lines: 34 Hello, I was curious about the DECstation 5000/133 and a graphical console. Todd Smith -----Original Message----- From: Karsten Merker To: Smith, Todd Cc: 'linux-mips@oss.sgi.com' Sent: 6/20/2002 1:27 PM Subject: Re: Linux and the Sony Playstation 2 On Wed, Jun 19, 2002 at 04:10:52PM -0400, Smith, Todd wrote: > This list is been pretty quiet lately so I don't really know what is > happening on the Linux/MIPS front. I am hoping that work is still slowly > proceeding on the DECstation that I have, but I don't really know. I agree Which model Du you have? I am actively using Linux/MIPS on a DECstation 5000/150 (although not with a bleeding-edge kernel), and it works rather well for me. 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 Fri Jun 21 06:55: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 g5LDtcnC007160 for ; Fri, 21 Jun 2002 06:55:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LDtcgN007159 for linux-mips-outgoing; Fri, 21 Jun 2002 06:55:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.camcare.com ([206.193.125.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LDtXnC007156 for ; Fri, 21 Jun 2002 06:55:34 -0700 Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAXGJW7G; Fri, 21 Jun 2002 10:10:24 -0400 Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jun 2002 09:58:25 -0400 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568B99@KES.camcare.com> From: "Smith, Todd" To: "''linux-mips@oss.sgi.com' '" Subject: RE: DECstation Date: Fri, 21 Jun 2002 09:58:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 915 Lines: 31 Hello, The http://decstation.unix-ag.org is the site that I was refering to. The sother site that you mentioned, I get a 404 on it. Thanks for your time Todd Smith -----Original Message----- From: Maciej W. Rozycki To: Smith, Todd Cc: 'linux-mips@oss.sgi.com' Sent: 6/21/2002 3:46 AM Subject: Re: DECstation On Thu, 20 Jun 2002, Smith, Todd wrote: > Thanks for the update. Has there been any work on the website updating what > works and what doesn't? What website do you specifically refer to? If you mean 'http://decstation.unix-ag.org/', then that's notoriously out of date. But Karel does a pretty good job maintaining his site -- see 'http://www.xs4all.nl/~vhouten/mipsel/'. -- + 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 Fri Jun 21 09:20: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 g5LGKtnC010734 for ; Fri, 21 Jun 2002 09:20:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LGKtvV010733 for linux-mips-outgoing; Fri, 21 Jun 2002 09:20:55 -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 g5LGKpnC010729 for ; Fri, 21 Jun 2002 09:20:51 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id <26NPRAQL>; Fri, 21 Jun 2002 11:23:24 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA379B78@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: File permission handling Date: Fri, 21 Jun 2002 11:22:05 -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 Content-Length: 811 Lines: 20 I am attempting to bunzip and untar a file in an embedded system. The application invokes a system() call to launch bzcat piped to tar. tar is reporting the filenames, but refuses to untar complaining about permissions violations. How do I get the files to untar successfully? Script invocation is "bzcat -xk %s | tar xf -" and a filename is supplied to the string argument through sprintf(). What am I doing wrong here? BTW, for those who would throw up security warning flags, this is an enclosed box where I don't have much worry about security issues revolviing around forking a shell script. 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 Fri Jun 21 14: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 g5LL2onC014417 for ; Fri, 21 Jun 2002 14:02:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LL2oHU014416 for linux-mips-outgoing; Fri, 21 Jun 2002 14:02:50 -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 g5LL2knC014407 for ; Fri, 21 Jun 2002 14:02:47 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA04577; Fri, 21 Jun 2002 23:06:19 +0200 (MET DST) Date: Fri, 21 Jun 2002 23:06:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Smith, Todd" cc: "''linux-mips@oss.sgi.com' '" Subject: Re: DECstation In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568B98@KES.camcare.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 Content-Length: 685 Lines: 17 On Fri, 21 Jun 2002, Smith, Todd wrote: > I was curious about the DECstation 5000/133 and a graphical console. The system should be fine -- basically all I/O ASIC based systems should work, though not all devices have been supplied with drivers yet. You should be able to use X11 with an XF86_FBDev Xserver on a PMAG-B (CX) or a PMAGB-B (HX) display adapter (I wasn't able to try myself so far though). For other display adapters, the answer is either "not yet" or "no way". -- + 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 Fri Jun 21 14:14: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 g5LLEUnC014610 for ; Fri, 21 Jun 2002 14:14:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LLEUAQ014609 for linux-mips-outgoing; Fri, 21 Jun 2002 14:14:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LLEOnC014605 for ; Fri, 21 Jun 2002 14:14:24 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E270313405; Fri, 21 Jun 2002 23:17:30 +0200 (CEST) Date: Fri, 21 Jun 2002 23:17:30 +0200 From: Jan-Benedict Glaw To: "''linux-mips@oss.sgi.com' '" Subject: Re: DECstation Message-ID: <20020621211730.GO24903@lug-owl.de> Mail-Followup-To: "''linux-mips@oss.sgi.com' '" References: <490E0430C3C72046ACF7F18B7CD76A2A568B98@KES.camcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gh4H09KImyIEQ1se" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: Linux mail 2.4.18 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1394 Lines: 44 --gh4H09KImyIEQ1se Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2002-06-21 23:06:19 +0200, Maciej W. Rozycki wrote in message : > On Fri, 21 Jun 2002, Smith, Todd wrote: > You should be able to use X11 with an XF86_FBDev Xserver on a PMAG-B (CX= )=20 > or a PMAGB-B (HX) display adapter (I wasn't able to try myself so far > though). For other display adapters, the answer is either "not yet" or > "no way".=20 I had X4 with framebuffer running on my DECstation with a PMAGB-B framebuffer. However, seems there were some threading problems (which might exist because the lack of ll/sc...). However, graphic was functional, but I haven't switched on that box for three months or so. I'm currently moving to an other city (well, quite a smallish town)... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --gh4H09KImyIEQ1se Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9E5fqHb1edYOZ4bsRAnlCAJ9UgbCLAa31jUSEq73PeT6vuBzgBACgkWE2 B8ZN6siTWlhHwWPnK2TsY6A= =6V33 -----END PGP SIGNATURE----- --gh4H09KImyIEQ1se-- From owner-linux-mips@oss.sgi.com Fri Jun 21 14:15: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 g5LLFZnC014670 for ; Fri, 21 Jun 2002 14:15:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LLFZsm014669 for linux-mips-outgoing; Fri, 21 Jun 2002 14:15:35 -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 g5LLFWnC014641 for ; Fri, 21 Jun 2002 14:15:33 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA04786; Fri, 21 Jun 2002 23:18:48 +0200 (MET DST) Date: Fri, 21 Jun 2002 23:18:48 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Smith, Todd" cc: "''linux-mips@oss.sgi.com' '" Subject: RE: DECstation In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568B99@KES.camcare.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 Content-Length: 517 Lines: 13 On Fri, 21 Jun 2002, Smith, Todd wrote: > The http://decstation.unix-ag.org is the site that I was refering to. The > sother site that you mentioned, I get a 404 on it. Well, I've copied and pasted the URL as is from my web client. You may get to the page from 'http://decstation.unix-ag.org/people/' 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 Fri Jun 21 14: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 g5LLqknC030069 for ; Fri, 21 Jun 2002 14:52:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LLqkSI030068 for linux-mips-outgoing; Fri, 21 Jun 2002 14:52:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail2.camcare.com ([206.193.125.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LLqgnC030065 for ; Fri, 21 Jun 2002 14:52:42 -0700 Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAXGJ8WD; Fri, 21 Jun 2002 18:07:33 -0400 Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jun 2002 17:55:34 -0400 Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568B9E@KES.camcare.com> From: "Smith, Todd" To: "'linux-mips@oss.sgi.com'" Subject: RE: DECstation Date: Fri, 21 Jun 2002 17:55:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 17 Thank you for your information. I was unsure since the website that I was reading for information was very much out of date. Keep up the good work! Todd Smith -----Original Message----- From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] The system should be fine -- basically all I/O ASIC based systems should work, though not all devices have been supplied with drivers yet. You should be able to use X11 with an XF86_FBDev Xserver on a PMAG-B (CX) or a PMAGB-B (HX) display adapter (I wasn't able to try myself so far though). For other display adapters, the answer is either "not yet" or "no way". From owner-linux-mips@oss.sgi.com Fri Jun 21 15:42: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 g5LMgWnC003169 for ; Fri, 21 Jun 2002 15:42:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LMgWU7003168 for linux-mips-outgoing; Fri, 21 Jun 2002 15:42: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 g5LMgRnC003162 for ; Fri, 21 Jun 2002 15:42:28 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA06135; Sat, 22 Jun 2002 00:46:05 +0200 (MET DST) Date: Sat, 22 Jun 2002 00:46:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: "''linux-mips@oss.sgi.com' '" Subject: Re: DECstation In-Reply-To: <20020621211730.GO24903@lug-owl.de> 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 Content-Length: 804 Lines: 21 On Fri, 21 Jun 2002, Jan-Benedict Glaw wrote: > I had X4 with framebuffer running on my DECstation with a PMAGB-B > framebuffer. However, seems there were some threading problems (which > might exist because the lack of ll/sc...). Either sysmips (ouch) or the emulation should handle them. There may be bugs, however... > However, graphic was functional, but I haven't switched on that box for > three months or so. I'm currently moving to an other city (well, quite a > smallish town)... I'm on the way to getting appropriate monitor adapter cables, so I may finally be able to access consoles. -- + 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 Fri Jun 21 19:31: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 g5M2VEnC013997 for ; Fri, 21 Jun 2002 19:31:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M2VElw013996 for linux-mips-outgoing; Fri, 21 Jun 2002 19:31:14 -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 g5M2V8nC013993 for ; Fri, 21 Jun 2002 19:31:09 -0700 Received: from excalibur.cologne.de (p50850F61.dip.t-dialin.net [80.133.15.97]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id EAA09456; Sat, 22 Jun 2002 04:34:08 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 17Lall-0003Oh-00; Sat, 22 Jun 2002 04:36:57 +0200 Date: Sat, 22 Jun 2002 04:36:57 +0200 From: Karsten Merker To: "Smith, Todd" Cc: linux-mips@oss.sgi.com Subject: Re: DECstation Message-ID: <20020622043657.B253@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , "Smith, Todd" , linux-mips@oss.sgi.com References: <490E0430C3C72046ACF7F18B7CD76A2A568B98@KES.camcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Jun 21, 2002 at 11:06:19PM +0200 X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1023 Lines: 26 On Fri, Jun 21, 2002 at 11:06:19PM +0200, Maciej W. Rozycki wrote: > On Fri, 21 Jun 2002, Smith, Todd wrote: > > > I was curious about the DECstation 5000/133 and a graphical console. > > The system should be fine -- basically all I/O ASIC based systems should > work, though not all devices have been supplied with drivers yet. > > You should be able to use X11 with an XF86_FBDev Xserver on a PMAG-B (CX) > or a PMAGB-B (HX) display adapter (I wasn't able to try myself so far > though). For other display adapters, the answer is either "not yet" or > "no way". Graphical console on PMAG-B and PMAGB-B works fine. X works in principle, too, i.e. you get graphical output and you can use the mouse (with the help of gpm's repeater mode), but the keyboard support within X is broken. 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 Sat Jun 22 00:38: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 g5M7cJnC016483 for ; Sat, 22 Jun 2002 00:38:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M7cJWu016482 for linux-mips-outgoing; Sat, 22 Jun 2002 00:38:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M7cCnC016479 for ; Sat, 22 Jun 2002 00:38:13 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0A54C13375; Sat, 22 Jun 2002 09:41:21 +0200 (CEST) Date: Sat, 22 Jun 2002 09:41:21 +0200 From: Jan-Benedict Glaw To: "''linux-mips@oss.sgi.com' '" Subject: Re: DECstation Message-ID: <20020622074121.GS24903@lug-owl.de> Mail-Followup-To: "''linux-mips@oss.sgi.com' '" References: <20020621211730.GO24903@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A3RWl4qWgABmkY4K" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Operating-System: Linux mail 2.4.18 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1152 Lines: 39 --A3RWl4qWgABmkY4K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2002-06-22 00:46:04 +0200, Maciej W. Rozycki wrote in message : > On Fri, 21 Jun 2002, Jan-Benedict Glaw wrote: > I'm on the way to getting appropriate monitor adapter cables, so I may > finally be able to access consoles. I've only got one DEC monitor cable (and I can't find it currently, I'm moving...), but maybe I can ask around in a university nearby if there are DECstations going their last way out, then I'll send you an original cable... MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --A3RWl4qWgABmkY4K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9FCohHb1edYOZ4bsRArx1AJkBGtJYb1Ul46BgTly+0zkgP8//8ACePzTS aewZyu7bU4j0w80krenMOms= =0TAx -----END PGP SIGNATURE----- --A3RWl4qWgABmkY4K-- From owner-linux-mips@oss.sgi.com Sat Jun 22 00:57: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 g5M7vinC016653 for ; Sat, 22 Jun 2002 00:57:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M7vhDt016652 for linux-mips-outgoing; Sat, 22 Jun 2002 00:57:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dvmwest.gt.owl.de (dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M7vbnC016649 for ; Sat, 22 Jun 2002 00:57:37 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 1C06B13387; Sat, 22 Jun 2002 10:00:46 +0200 (CEST) Date: Sat, 22 Jun 2002 10:00:46 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: DECstation Message-ID: <20020622080045.GT24903@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <490E0430C3C72046ACF7F18B7CD76A2A568B98@KES.camcare.com> <20020622043657.B253@excalibur.cologne.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZXzThk3vFZecBD04" Content-Disposition: inline In-Reply-To: <20020622043657.B253@excalibur.cologne.de> User-Agent: Mutt/1.3.28i X-Operating-System: Linux mail 2.4.18 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1349 Lines: 42 --ZXzThk3vFZecBD04 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2002-06-22 04:36:57 +0200, Karsten Merker wrote in message <20020622043657.B253@excalibur.cologne.de>: > On Fri, Jun 21, 2002 at 11:06:19PM +0200, Maciej W. Rozycki wrote: > > On Fri, 21 Jun 2002, Smith, Todd wrote: > > > I was curious about the DECstation 5000/133 and a graphical console. > X works in principle, too, i.e. you get graphical output and you can=20 > use the mouse (with the help of gpm's repeater mode), but the keyboard=20 > support within X is broken. Well... Some keys are functional, some are not, and some are better to never press... I've tried to understand how X handles the keyboard one evening, but I badly failed to understand all those mappings and layouts and so on:-( MfG, JBG --=20 Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --ZXzThk3vFZecBD04 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9FC6tHb1edYOZ4bsRAqbXAJ9JcmUYOYGN1aZcuDhxDBe99TOUJgCfbLcb DD6MAu5zlRg8b5O+UC1KJYs= =8q1p -----END PGP SIGNATURE----- --ZXzThk3vFZecBD04-- From owner-linux-mips@oss.sgi.com Sat Jun 22 02: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 g5M9UInC017305 for ; Sat, 22 Jun 2002 02:30:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M9UIa5017304 for linux-mips-outgoing; Sat, 22 Jun 2002 02:30:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ws3-3.us4.outblaze.com (205-158-62-93.outblaze.com [205.158.62.93]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M9UGnC017301 for ; Sat, 22 Jun 2002 02:30:16 -0700 Received: (qmail 25584 invoked by uid 1001); 22 Jun 2002 09:33:21 -0000 Message-ID: <20020622093321.25583.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [202.140.142.131] by ws3-3.us4.outblaze.com with http for domca_psg@email.com; Sat, 22 Jun 2002 04:33:21 -0500 From: "Domcan Sami" To: , linux-kernel@vger.kernel.org Cc: redhat-list@redhat.com Date: Sat, 22 Jun 2002 04:33:21 -0500 Subject: Linux Boot sequence on MIPS?? X-Originating-Ip: 202.140.142.131 X-Originating-Server: ws3-3.us4.outblaze.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 445 Lines: 12 Hello everybody I m trying to develop a Linux boot-loader for MIPS processor, can anybody help me sending the Linux boot sequence on MIPS. Any sites for reference? Thanks Domcan -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Save up to $160 by signing up for NetZero Platinum Internet service. http://www.netzero.net/?refcd=N2P0602NEP8 From owner-linux-mips@oss.sgi.com Sun Jun 23 05:57: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 g5NCvOnC008255 for ; Sun, 23 Jun 2002 05:57:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5NCvNBP008254 for linux-mips-outgoing; Sun, 23 Jun 2002 05:57:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5NCvFnC008244 for ; Sun, 23 Jun 2002 05:57:16 -0700 Received: (qmail 5284 invoked by uid 0); 23 Jun 2002 13:00:24 -0000 Received: from pd9e41335.dip.t-dialin.net (HELO bogon.ms20.nix) (217.228.19.53) by mail.gmx.net (mp011-rz3) with SMTP; 23 Jun 2002 13:00:24 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 0161E36562; Sun, 23 Jun 2002 14:58:11 +0200 (CEST) Date: Sun, 23 Jun 2002 14:58:11 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: 2.4.18: pgtable.h compile fix Message-ID: <20020623125811.GA24851@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1539 Lines: 51 Hi, I need the following to make head.S compile again for IP22 on the current linux_2_4 branch: Index: include/asm-mips/pgtable.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pgtable.h,v retrieving revision 1.63.2.12 diff -u -r1.63.2.12 pgtable.h --- include/asm-mips/pgtable.h 2002/05/28 09:49:40 1.63.2.12 +++ include/asm-mips/pgtable.h 2002/06/23 12:48:50 @@ -13,6 +13,8 @@ #include #include +#ifndef _LANGUAGE_ASSEMBLY + #include #include #include @@ -78,6 +80,7 @@ extern int add_temporary_entry(unsigned long entrylo0, unsigned long entrylo1, unsigned long entryhi, unsigned long pagemask); +#endif /* !defined (_LANGUAGE_ASSEMBLY) */ /* Basically we have the same two-level (which is the logical three level * Linux page table layout folded) page tables as the i386. Some day @@ -167,6 +170,8 @@ #define __S110 PAGE_SHARED #define __S111 PAGE_SHARED +#if !defined (_LANGUAGE_ASSEMBLY) + #ifdef CONFIG_64BIT_PHYS_ADDR #define pte_ERROR(e) \ printk("%s:%d: bad pte %016Lx.\n", __FILE__, __LINE__, pte_val(e)) @@ -472,6 +477,8 @@ #define kern_addr_valid(addr) (1) #include + +#endif /* !defined (_LANGUAGE_ASSEMBLY) */ /* * We provide our own get_unmapped area to cope with the virtual aliasing Is there a reason why the "_LANGUAGE_ASSEMBLY" ifdefs were removed? Mips64 still has these #ifdefs though. Regards, -- Guido From owner-linux-mips@oss.sgi.com Mon Jun 24 00:15: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 g5O7FZnC020328 for ; Mon, 24 Jun 2002 00:15:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O7FZ1c020327 for linux-mips-outgoing; Mon, 24 Jun 2002 00:15:35 -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 g5O7FTnC020323 for ; Mon, 24 Jun 2002 00:15:30 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA22700; Mon, 24 Jun 2002 09:19:16 +0200 (MET DST) Date: Mon, 24 Jun 2002 09:19:15 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: DECstation In-Reply-To: <20020622080045.GT24903@lug-owl.de> 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 Content-Length: 833 Lines: 18 On Sat, 22 Jun 2002, Jan-Benedict Glaw wrote: > Well... Some keys are functional, some are not, and some are better to > never press... I've tried to understand how X handles the keyboard one > evening, but I badly failed to understand all those mappings and layouts > and so on:-( A fix is on my to-do list -- hopefully to be done just after the current task. There is a long-standing bug in the generic keyboard handling code. After fixing it and then the LK driver (which cannot be fixed now because of the bug), you'll be able to use LK mappings included in the X11 distribution. It was discussed here earlier this year. -- + 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 Jun 24 01:11: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 g5O8B6nC021673 for ; Mon, 24 Jun 2002 01:11:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O8B576021672 for linux-mips-outgoing; Mon, 24 Jun 2002 01:11:05 -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 (c-180-196-16.ka.dial.de.ignite.net [62.180.196.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O8B0nC021669 for ; Mon, 24 Jun 2002 01:11:02 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5O8BNQ23375; Mon, 24 Jun 2002 10:11:23 +0200 Date: Mon, 24 Jun 2002 10:11:23 +0200 From: Ralf Baechle To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: 2.4.18: pgtable.h compile fix Message-ID: <20020624101123.A15988@dea.linux-mips.net> References: <20020623125811.GA24851@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020623125811.GA24851@bogon.ms20.nix>; from agx@sigxcpu.org on Sun, Jun 23, 2002 at 02:58:11PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 400 Lines: 13 On Sun, Jun 23, 2002 at 02:58:11PM +0200, Guido Guenther wrote: > Hi, > I need the following to make head.S compile again for IP22 on the > current linux_2_4 branch: > Is there a reason why the "_LANGUAGE_ASSEMBLY" ifdefs were removed? > Mips64 still has these #ifdefs though. The necessity for these was believed to be removed. What are you trying to do when you run into this problem? Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 01:26: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 g5O8QjnC021942 for ; Mon, 24 Jun 2002 01:26:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O8Qjen021941 for linux-mips-outgoing; Mon, 24 Jun 2002 01:26:45 -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 g5O8QfnC021938 for ; Mon, 24 Jun 2002 01:26:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA23941; Mon, 24 Jun 2002 10:30:23 +0200 (MET DST) Date: Mon, 24 Jun 2002 10:30:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: 2.4.18: pgtable.h compile fix In-Reply-To: <20020623125811.GA24851@bogon.ms20.nix> 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 Content-Length: 497 Lines: 13 On Sun, 23 Jun 2002, Guido Guenther wrote: > Is there a reason why the "_LANGUAGE_ASSEMBLY" ifdefs were removed? > Mips64 still has these #ifdefs though. MIPS64 lags behind a bit due to less interest/testing. Note that you should use "__ASSEMBLY__" to guard assembly-unsafe parts of headers. -- + 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 Jun 24 02:04: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 g5O94knC022902 for ; Mon, 24 Jun 2002 02:04:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O94k2e022901 for linux-mips-outgoing; Mon, 24 Jun 2002 02:04: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 g5O94DnC022864; Mon, 24 Jun 2002 02:04:13 -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 CAA10894; Mon, 24 Jun 2002 02:07:26 -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 CAA28316; Mon, 24 Jun 2002 02:07:24 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5O97Pb15419; Mon, 24 Jun 2002 11:07:25 +0200 (MEST) Message-ID: <3D16E14C.5C8D2FAD@mips.com> Date: Mon, 24 Jun 2002 11:07:24 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@oss.sgi.com Subject: sys_syscall patch. Content-Type: multipart/mixed; boundary="------------58C8EEAD283815526023212C" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6626 Lines: 241 This is a multi-part message in MIME format. --------------58C8EEAD283815526023212C Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The 'sys_syscall' syscall isn't properly implemented in the 64-bit kernel (for o32 as well as n64). Below is a patch, it seems to work for in the o32 case, but I haven't tested the n64 version (obviously). /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 --------------58C8EEAD283815526023212C Content-Type: text/plain; charset=iso-8859-15; name="sys_syscall.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sys_syscall.patch" Index: arch/mips64/kernel//linux32.c =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips64/kernel/linux32.c,v retrieving revision 1.3 diff -u -r1.3 linux32.c --- arch/mips64/kernel//linux32.c 13 Jun 2002 09:08:02 -0000 1.3 +++ arch/mips64/kernel//linux32.c 24 Jun 2002 08:56:02 -0000 @@ -32,6 +32,7 @@ #include #include #include +#include #define A(__x) ((unsigned long)(__x)) @@ -872,6 +873,82 @@ oldalarm++; return oldalarm; +} + +typedef asmlinkage long (*syscall_t)(void *a0,...); +extern syscall_t sys32_call_table[]; +extern unsigned char sys32_narg_table[]; + +/* + * Do the indirect syscall syscall. + * Don't care about kernel locking; the actual syscall will do it. + * + * XXX This is broken. + */ +asmlinkage int sys32_syscall(abi64_no_regargs, struct pt_regs regs) +{ + syscall_t syscall; + unsigned long syscallnr = regs.regs[4]; + unsigned long a0, a1, a2, a3, a4, a5, a6; + int nargs, errno; + + if ((syscallnr < __NR_Linux32) || + (syscallnr > __NR_Linux32 + __NR_Linux32_syscalls)) + return -ENOSYS; + + syscall = sys32_call_table[syscallnr-__NR_Linux32]; + nargs = sys32_narg_table[syscallnr-__NR_Linux32]; + + /* + * Prevent stack overflow by recursive + * syscall(__NR_syscall, __NR_syscall,...); + */ + if (syscall == (syscall_t) sys32_syscall) { + return -EINVAL; + } + + if (syscall == NULL) { + return -ENOSYS; + } + + if(nargs > 3) { + unsigned long usp = regs.regs[29]; + unsigned long *sp = (unsigned long *) usp; + if(usp & 3) { + printk("unaligned usp -EFAULT\n"); + force_sig(SIGSEGV, current); + return -EFAULT; + } + errno = verify_area(VERIFY_READ, (void *) (usp + 16), + (nargs - 3) * sizeof(unsigned long)); + if(errno) { + return -EFAULT; + } + switch(nargs) { + case 7: + a3 = sp[4]; a4 = sp[5]; a5 = sp[6]; a6 = sp[7]; + break; + case 6: + a3 = sp[4]; a4 = sp[5]; a5 = sp[6]; a6 = 0; + break; + case 5: + a3 = sp[4]; a4 = sp[5]; a5 = a6 = 0; + break; + case 4: + a3 = sp[4]; a4 = a5 = a6 = 0; + break; + + default: + a3 = a4 = a5 = a6 = 0; + break; + } + } else { + a3 = a4 = a5 = a6 = 0; + } + a0 = regs.regs[5]; a1 = regs.regs[6]; a2 = regs.regs[7]; + if(nargs == 0) + a0 = (unsigned long) ®s; + return syscall((void *)a0, a1, a2, a3, a4, a5, a6); } /* Translations due to time_t size differences. Which affects all Index: arch/mips64/kernel//scall_64.S =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips64/kernel/scall_64.S,v retrieving revision 1.3 diff -u -r1.3 scall_64.S --- arch/mips64/kernel//scall_64.S 19 Jun 2002 07:04:08 -0000 1.3 +++ arch/mips64/kernel//scall_64.S 24 Jun 2002 08:10:23 -0000 @@ -132,7 +132,7 @@ j ret_from_sys_call END(handle_sys64) -sys_call_table: +EXPORT(sys_call_table) PTR sys_syscall /* 5000 */ PTR sys_exit PTR sys_fork Index: arch/mips64/kernel//scall_o32.S =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips64/kernel/scall_o32.S,v retrieving revision 1.3 diff -u -r1.3 scall_o32.S --- arch/mips64/kernel//scall_o32.S 19 Jun 2002 07:04:08 -0000 1.3 +++ arch/mips64/kernel//scall_o32.S 24 Jun 2002 08:53:48 -0000 @@ -52,8 +52,8 @@ /* XXX Put both in one cacheline, should save a bit. */ dsll t0, v0, 3 # offset into table - ld t2, (sys_call_table - (__NR_Linux32 * 8))(t0) # syscall routine - lbu t3, (sys_narg_table - __NR_Linux32)(v0) # number of arguments + ld t2, (sys32_call_table - (__NR_Linux32 * 8))(t0) # syscall routine + lbu t3, (sys32_narg_table - __NR_Linux32)(v0) # number of arguments subu t0, t3, 5 # 5 or more arguments? sd a3, PT_R26(sp) # save a3 for syscall restarting @@ -246,7 +246,7 @@ END(sys_sysmips) .macro syscalltable - sys sys_syscall 0 /* 4000 */ + sys sys32_syscall 0 /* 4000 */ sys sys_exit 1 sys sys_fork 0 sys sys_read 3 @@ -489,12 +489,12 @@ PTR \function .endm -sys_call_table: +EXPORT(sys32_call_table) syscalltable .macro sys function, nargs .byte \nargs .endm - -sys_narg_table: + +EXPORT(sys32_narg_table) syscalltable Index: arch/mips64/kernel//syscall.c =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips64/kernel/syscall.c,v retrieving revision 1.2 diff -u -r1.2 syscall.c --- arch/mips64/kernel//syscall.c 13 Jun 2002 09:08:02 -0000 1.2 +++ arch/mips64/kernel//syscall.c 24 Jun 2002 08:38:55 -0000 @@ -123,14 +123,41 @@ return error; } +typedef asmlinkage long (*syscall_t)(void *a0,...); +extern syscall_t sys_call_table[]; + /* * Do the indirect syscall syscall. - * - * XXX This is borken. + * Don't care about kernel locking; the actual syscall will do it. */ asmlinkage int sys_syscall(abi64_no_regargs, struct pt_regs regs) { - return -ENOSYS; + syscall_t syscall; + unsigned long syscallnr = regs.regs[4]; + unsigned long a0, a1, a2, a3, a4, a5, a6; + + if ((syscallnr < __NR_Linux) || + (syscallnr > __NR_Linux + __NR_Linux_syscalls)) + return -ENOSYS; + + syscall = sys_call_table[syscallnr-__NR_Linux]; + + /* + * Prevent stack overflow by recursive + * syscall(__NR_syscall, __NR_syscall,...); + */ + if (syscall == (syscall_t) sys_syscall) { + return -EINVAL; + } + + if (syscall == NULL) { + return -ENOSYS; + } + + a0 = regs.regs[5]; a1 = regs.regs[6]; a2 = regs.regs[7]; + a3 = regs.regs[8]; a4 = regs.regs[9]; a5 = regs.regs[10]; + a6 = regs.regs[11]; + return syscall((void *)a0, a1, a2, a3, a4, a5, a6); } asmlinkage int --------------58C8EEAD283815526023212C-- From owner-linux-mips@oss.sgi.com Mon Jun 24 02:54: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 g5O9sZnC023430 for ; Mon, 24 Jun 2002 02:54:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O9sZHO023429 for linux-mips-outgoing; Mon, 24 Jun 2002 02:54: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 (c-180-196-49.ka.dial.de.ignite.net [62.180.196.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O9sUnC023423 for ; Mon, 24 Jun 2002 02:54:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5O9sqj25187; Mon, 24 Jun 2002 11:54:52 +0200 Date: Mon, 24 Jun 2002 11:54:52 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. Message-ID: <20020624115452.A25138@dea.linux-mips.net> References: <3D16E14C.5C8D2FAD@mips.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: <3D16E14C.5C8D2FAD@mips.com>; from carstenl@mips.com on Mon, Jun 24, 2002 at 11:07:24AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 678 Lines: 20 On Mon, Jun 24, 2002 at 11:07:24AM +0200, Carsten Langgaard wrote: > The 'sys_syscall' syscall isn't properly implemented in the 64-bit > kernel (for o32 as well as n64). > Below is a patch, it seems to work for in the o32 case, but I haven't > tested the n64 version (obviously). > +/* > + * Do the indirect syscall syscall. > + * Don't care about kernel locking; the actual syscall will do it. > + * > + * XXX This is broken. > + */ As the comment says - it's broken. This implementation just like it's 32-bit predecessor don't handle the error return value correctly. Worse, there's unprotected accesses to userspace which allow any user crashing the system ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 03:03: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 g5OA3nnC023723 for ; Mon, 24 Jun 2002 03:03:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OA3m1A023721 for linux-mips-outgoing; Mon, 24 Jun 2002 03:03:48 -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 g5OA3fnC023715; Mon, 24 Jun 2002 03:03:41 -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 DAA11070; Mon, 24 Jun 2002 03:06:54 -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 DAA29277; Mon, 24 Jun 2002 03:06:52 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5OA6rb18664; Mon, 24 Jun 2002 12:06:53 +0200 (MEST) Message-ID: <3D16EF3C.BCCB020@mips.com> Date: Mon, 24 Jun 2002 12:06:52 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. References: <3D16E14C.5C8D2FAD@mips.com> <20020624115452.A25138@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 Content-Length: 1109 Lines: 35 Ralf Baechle wrote: > On Mon, Jun 24, 2002 at 11:07:24AM +0200, Carsten Langgaard wrote: > > > The 'sys_syscall' syscall isn't properly implemented in the 64-bit > > kernel (for o32 as well as n64). > > Below is a patch, it seems to work for in the o32 case, but I haven't > > tested the n64 version (obviously). > > > +/* > > + * Do the indirect syscall syscall. > > + * Don't care about kernel locking; the actual syscall will do it. > > + * > > + * XXX This is broken. > > + */ > > As the comment says - it's broken. This implementation just like it's > 32-bit predecessor don't handle the error return value correctly. Worse, > there's unprotected accesses to userspace which allow any user crashing > the system ... > At least it makes my system work as well as for the 32-bit kernel. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jun 24 03:24: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 g5OAOOnC024031 for ; Mon, 24 Jun 2002 03:24:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OAOO0L024030 for linux-mips-outgoing; Mon, 24 Jun 2002 03:24:24 -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 (c-180-196-49.ka.dial.de.ignite.net [62.180.196.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OAOJnC024027 for ; Mon, 24 Jun 2002 03:24:20 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OAOoW25677; Mon, 24 Jun 2002 12:24:50 +0200 Date: Mon, 24 Jun 2002 12:24:50 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. Message-ID: <20020624122450.A25659@dea.linux-mips.net> References: <3D16E14C.5C8D2FAD@mips.com> <20020624115452.A25138@dea.linux-mips.net> <3D16EF3C.BCCB020@mips.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: <3D16EF3C.BCCB020@mips.com>; from carstenl@mips.com on Mon, Jun 24, 2002 at 12:06:52PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 539 Lines: 14 On Mon, Jun 24, 2002 at 12:06:52PM +0200, Carsten Langgaard wrote: > > At least it makes my system work as well as for the 32-bit kernel. What programs btw are using syscall()? To be honest I don't recall one ... Looking more into it I found a nice showstopper - a few functions like _sys_sigsuspend() expect a struct pt_regs on the stack. That's only working if we call those functions directly from the exception handler. It won't work if we have another function's stackframe - in this case sys_syscall()'s there also ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 03:43: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 g5OAhcnC024335 for ; Mon, 24 Jun 2002 03:43:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OAhc2E024333 for linux-mips-outgoing; Mon, 24 Jun 2002 03:43:38 -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 g5OAhVnC024303; Mon, 24 Jun 2002 03:43:31 -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 DAA11194; Mon, 24 Jun 2002 03:46:44 -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 DAA00068; Mon, 24 Jun 2002 03:46:43 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5OAkgb21113; Mon, 24 Jun 2002 12:46:42 +0200 (MEST) Message-ID: <3D16F891.78A333BA@mips.com> Date: Mon, 24 Jun 2002 12:46:41 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. References: <3D16E14C.5C8D2FAD@mips.com> <20020624115452.A25138@dea.linux-mips.net> <3D16EF3C.BCCB020@mips.com> <20020624122450.A25659@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 Content-Length: 1035 Lines: 32 Ralf Baechle wrote: > On Mon, Jun 24, 2002 at 12:06:52PM +0200, Carsten Langgaard wrote: > > > > > At least it makes my system work as well as for the 32-bit kernel. > > What programs btw are using syscall()? To be honest I don't recall one ... /sbin/rpc.lockd. It use syscall() to indirectly call the 'sys_nfsservctl' syscall, why it doesn't do the syscall directly is beyond me. > > Looking more into it I found a nice showstopper - a few functions like > _sys_sigsuspend() expect a struct pt_regs on the stack. That's only > working if we call those functions directly from the exception handler. > It won't work if we have another function's stackframe - in this case > sys_syscall()'s there also ... > > Ralf -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jun 24 04:34: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 g5OBYmnC025884 for ; Mon, 24 Jun 2002 04:34:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OBYmk4025883 for linux-mips-outgoing; Mon, 24 Jun 2002 04:34:48 -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 g5OBYfnC025880; Mon, 24 Jun 2002 04:34:41 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA27692; Mon, 24 Jun 2002 13:38:27 +0200 (MET DST) Date: Mon, 24 Jun 2002 13:38:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. In-Reply-To: <3D16F891.78A333BA@mips.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 Content-Length: 562 Lines: 16 On Mon, 24 Jun 2002, Carsten Langgaard wrote: > > What programs btw are using syscall()? To be honest I don't recall one ... > > /sbin/rpc.lockd. > It use syscall() to indirectly call the 'sys_nfsservctl' syscall, why it > doesn't do the syscall directly is beyond me. Hmm, shouldn't syscall() be a library wrapper? I think we should kill sys_syscall(). -- + 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 Jun 24 04:45: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 g5OBjWnC026213 for ; Mon, 24 Jun 2002 04:45:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OBjWQG026212 for linux-mips-outgoing; Mon, 24 Jun 2002 04:45: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 (c-180-196-145.ka.dial.de.ignite.net [62.180.196.145]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OBjQnC026209 for ; Mon, 24 Jun 2002 04:45:27 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OBjnU27930; Mon, 24 Jun 2002 13:45:49 +0200 Date: Mon, 24 Jun 2002 13:45:49 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. Message-ID: <20020624134549.B27807@dea.linux-mips.net> References: <3D16F891.78A333BA@mips.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 Mon, Jun 24, 2002 at 01:38:27PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 606 Lines: 16 On Mon, Jun 24, 2002 at 01:38:27PM +0200, Maciej W. Rozycki wrote: > > > What programs btw are using syscall()? To be honest I don't recall one ... > > > > /sbin/rpc.lockd. > > It use syscall() to indirectly call the 'sys_nfsservctl' syscall, why it > > doesn't do the syscall directly is beyond me. > > Hmm, shouldn't syscall() be a library wrapper? I think we should kill > sys_syscall(). It's in the kernel for no better reason than Risc/OS and IRIX having this syscall. Also the glibc syscall implementation was historically broken wrt. syscall restarting and a few other subtilities. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 04:59: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 g5OBxinC026692 for ; Mon, 24 Jun 2002 04:59:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OBxiEM026691 for linux-mips-outgoing; Mon, 24 Jun 2002 04:59:44 -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 g5OBxcnC026682; Mon, 24 Jun 2002 04:59:38 -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 FAA11415; Mon, 24 Jun 2002 05:02:49 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA01432; Mon, 24 Jun 2002 05:02:49 -0700 (PDT) Message-ID: <00ee01c21b77$18522510$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Carsten Langgaard" Cc: "Ralf Baechle" , References: Subject: Re: sys_syscall patch. Date: Mon, 24 Jun 2002 14:02:49 +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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 838 Lines: 21 From: "Maciej W. Rozycki" > On Mon, 24 Jun 2002, Carsten Langgaard wrote: > > > > What programs btw are using syscall()? To be honest I don't recall one ... > > > > /sbin/rpc.lockd. > > It use syscall() to indirectly call the 'sys_nfsservctl' syscall, why it > > doesn't do the syscall directly is beyond me. I can only speculate that at the time it was written, there was not a universally respected library binding to get to the direct syscall. > Hmm, shouldn't syscall() be a library wrapper? I think we should kill > sys_syscall(). While I agree that rpc.lockd should directly invoke the desired system call if possible, having an indirect system call mechanism is something that has proved useful to me in the past on other Unices, and I would rather see it fixed than discarded. Kevin K. From owner-linux-mips@oss.sgi.com Mon Jun 24 05:01: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 g5OC1hnC026793 for ; Mon, 24 Jun 2002 05:01:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OC1hEO026792 for linux-mips-outgoing; Mon, 24 Jun 2002 05:01:43 -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 (c-180-196-145.ka.dial.de.ignite.net [62.180.196.145]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OC1cnC026789 for ; Mon, 24 Jun 2002 05:01:40 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OC2AP28173; Mon, 24 Jun 2002 14:02:10 +0200 Date: Mon, 24 Jun 2002 14:02:10 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. Message-ID: <20020624140210.A28145@dea.linux-mips.net> References: <3D16E14C.5C8D2FAD@mips.com> <20020624115452.A25138@dea.linux-mips.net> <3D16EF3C.BCCB020@mips.com> <20020624122450.A25659@dea.linux-mips.net> <3D16F891.78A333BA@mips.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: <3D16F891.78A333BA@mips.com>; from carstenl@mips.com on Mon, Jun 24, 2002 at 12:46:41PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 483 Lines: 14 On Mon, Jun 24, 2002 at 12:46:41PM +0200, Carsten Langgaard wrote: > > > At least it makes my system work as well as for the 32-bit kernel. > > > > What programs btw are using syscall()? To be honest I don't recall one ... > > /sbin/rpc.lockd. > It use syscall() to indirectly call the 'sys_nfsservctl' syscall, why it > doesn't do the syscall directly is beyond me. More historic garbage - the kernel NFS server for a long time didn't have it's own, registered syscall. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 05:03: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 g5OC3inC026885 for ; Mon, 24 Jun 2002 05:03:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OC3i4h026884 for linux-mips-outgoing; Mon, 24 Jun 2002 05:03: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 (c-180-196-145.ka.dial.de.ignite.net [62.180.196.145]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OC3dnC026881 for ; Mon, 24 Jun 2002 05:03:41 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OC43J28193; Mon, 24 Jun 2002 14:04:03 +0200 Date: Mon, 24 Jun 2002 14:04:03 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "Maciej W. Rozycki" , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. Message-ID: <20020624140403.B28145@dea.linux-mips.net> References: <00ee01c21b77$18522510$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: <00ee01c21b77$18522510$10eca8c0@grendel>; from kevink@mips.com on Mon, Jun 24, 2002 at 02:02:49PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 504 Lines: 12 On Mon, Jun 24, 2002 at 02:02:49PM +0200, Kevin D. Kissell wrote: > While I agree that rpc.lockd should directly invoke the desired > system call if possible, having an indirect system call mechanism > is something that has proved useful to me in the past on other > Unices, and I would rather see it fixed than discarded. The question is not wheather to drop this mechnism - we can't anyway for compatibility reasons - but if a kernel or userspace implementation is preferable for the future. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 06:00: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 g5OD0inC028090 for ; Mon, 24 Jun 2002 06:00:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OD0hV6028089 for linux-mips-outgoing; Mon, 24 Jun 2002 06:00:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dprn03.deltartp.com (mail.deltartp.com [216.166.210.181]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OD0cnC028085 for ; Mon, 24 Jun 2002 06:00:39 -0700 Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 08:54:01 -0400 Message-ID: From: Chien-Lung Wu To: "'linux-mips@oss.sgi.com'" Cc: Chien-Lung Wu Subject: cross-compiler Date: Mon, 24 Jun 2002 08:54:00 -0400 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 Content-Length: 894 Lines: 28 Hi, I try to buils a cross-comipler in my linux box (build=i386-mips) with host=windowNT, and target=linux-mips. But it is not successful. I use the following tar-ball as base: (The newest one) a. binutils (2.11.2) b. gcc 3.1 c. glibc 2.2.5 As a newbie in linux embedded system, could anyone kindly show me "HOWTO" build up a cross-compiler in general and specifically for MIPS (IDT R32334/32332)? If you know any good stuffs in building cross-compiler and porting Linux to MIPS, please send me the web-side or pointers. Thanks in advance. Regards, Chien-Lung *********************************************************************** Chien-Lung Wu TEL: 919-767-3903 Sr. Software Engineer FAX: 919-767-2458 DataCom Lab of Delta Network Inc.. e-mail: cwu@deltartp.com *********************************************************** From owner-linux-mips@oss.sgi.com Mon Jun 24 06: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 g5ODKenC028256 for ; Mon, 24 Jun 2002 06:20:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ODKeSt028255 for linux-mips-outgoing; Mon, 24 Jun 2002 06:20:40 -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 g5ODKYnC028251 for ; Mon, 24 Jun 2002 06:20:35 -0700 Message-Id: <200206241320.g5ODKYnC028251@oss.sgi.com> Received: (qmail 12679 invoked from network); 24 Jun 2002 13:09:27 -0000 Received: from unknown (HELO foxsen) (159.226.40.150) by 159.226.39.4 with SMTP; 24 Jun 2002 13:09:27 -0000 Date: Mon, 24 Jun 2002 21:22:15 +0800 From: "Zhang Fuxin" To: Ralf Baechle CC: "linux-mips@oss.sgi.com" Subject: Re: Re: sys_syscall patch. 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 g5ODKZnC028252 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 934 Lines: 36 hi, ======= 2002-06-24 12:24:00 you wrote£º======= >On Mon, Jun 24, 2002 at 12:06:52PM +0200, Carsten Langgaard wrote: > >> >> At least it makes my system work as well as for the 32-bit kernel. > >What programs btw are using syscall()? To be honest I don't recall one ... I used it in a userland checkpoint program to intercept syscalls. > >Looking more into it I found a nice showstopper - a few functions like >_sys_sigsuspend() expect a struct pt_regs on the stack. That's only >working if we call those functions directly from the exception handler. >It won't work if we have another function's stackframe - in this case >sys_syscall()'s there also ... > > Ralf = = = = = = = = = = = = = = = = = = = = Best Regards --------------------------------------- Zhang Fuxin System Architecture Lab Institute of Computing Technology Chinese Academy of Sciences,China http://www.ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-06-24 From owner-linux-mips@oss.sgi.com Mon Jun 24 06:26: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 g5ODQunC028394 for ; Mon, 24 Jun 2002 06:26:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ODQub3028393 for linux-mips-outgoing; Mon, 24 Jun 2002 06:26:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtwse201.detewe.de ([195.50.171.201]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ODQlnC028384 for ; Mon, 24 Jun 2002 06:26:48 -0700 Received: from zinse043.detewe.de (unverified) by dtwse201.detewe.de (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Jun 2002 15:32:58 +0200 Received: from detewe.de ([172.30.201.153]) by zinse043.detewe.de (Netscape Messaging Server 3.6) with ESMTP id AAA5A27; Mon, 24 Jun 2002 15:29:00 +0200 Message-ID: <3D171ECB.28F566C1@detewe.de> Date: Mon, 24 Jun 2002 15:29:47 +0200 From: Carsten Lange X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "'linux-mips@oss.sgi.com'" Subject: mipsel-linux-gdb(5.2): DW_FORM_strp pointing outside of .debug_str section Content-Type: multipart/mixed; boundary="------------5CF768D46FA92DC52A37C165" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1226 Lines: 51 This is a multi-part message in MIME format. --------------5CF768D46FA92DC52A37C165 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I get the above error from gdb 5.2 when using the command. ... (gdb) file iprbs file iprbs Reading symbols from iprbs...DW_FORM_strp pointing outside of .debug_str section (gdb) ... My mipsel-linux- toolchain consist of the following packages: binutils-2.12.1 gcc-3.1 glibc-2.2.5 gdb-5.2 I have no idea what the problem might be. Any hints (solutions/workaround) are welcome. Best regards, Carsten --------------5CF768D46FA92DC52A37C165 Content-Type: text/x-vcard; charset=us-ascii; name="Carsten.Lange.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Carsten Lange Content-Disposition: attachment; filename="Carsten.Lange.vcf" begin:vcard n:Lange;Carsten tel;fax:+49 6104 4234 tel;work:+49 30 6104 4228 x-mozilla-html:FALSE url:http://www.detewe.de org:Cordless Technology A/S Berlin adr:;;Koepenicker Str. 180;10997 Berlin;;; version:2.1 email;internet:Carsten.Lange@detewe.de x-mozilla-cpt:;0 fn:Carsten Lange end:vcard --------------5CF768D46FA92DC52A37C165-- From owner-linux-mips@oss.sgi.com Mon Jun 24 07:14: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 g5OEEOnC031036 for ; Mon, 24 Jun 2002 07:14:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OEEObN031035 for linux-mips-outgoing; Mon, 24 Jun 2002 07:14:24 -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 g5OEECnC031032; Mon, 24 Jun 2002 07:14:12 -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 HAA11862; Mon, 24 Jun 2002 07:17:24 -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 HAA04198; Mon, 24 Jun 2002 07:17:25 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5OEHOb08148; Mon, 24 Jun 2002 16:17:24 +0200 (MEST) Message-ID: <3D1729F3.7241A74A@mips.com> Date: Mon, 24 Jun 2002 16:17:23 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "linux-mips@oss.sgi.com" Subject: Bug in __copy_user Content-Type: multipart/mixed; boundary="------------4EBBDD03DDAA4619AEF963D7" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2094 Lines: 64 This is a multi-part message in MIME format. --------------4EBBDD03DDAA4619AEF963D7 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit I have started to look a little bit at the LTP tests. And one of the testcases that fails (actually it doesn't fail as it supposed to do) is the syscall getsockopt. I think the failure is due to the copy_to_user(0, from, 4) call returns 0, which I wouldn't expect when the destination pointer is NULL. I think the problem is in the __copy_user function in arch/mips/lib/memcpy. It tries to handle the exception, which we get because the destination pointer is NULL, by returning the number of uncopied bytes in $a2 to the caller. But in this case the length is only 4 bytes, and the copying is done by a single 'sw'. The problem is the length ($a2) is decreased by 4 before the 'sw' is executed. The 'sw' fails and __copy_user terminates, but returns with $a2 = 0 (instead 4). I thing the following patch will solve the problem. /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 --------------4EBBDD03DDAA4619AEF963D7 Content-Type: text/plain; charset=iso-8859-15; name="memcpy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="memcpy.patch" Index: arch/mips/lib/memcpy.S =================================================================== RCS file: /home/repository/sw/linux-2.4.18/arch/mips/lib/memcpy.S,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 memcpy.S --- arch/mips/lib/memcpy.S 4 Mar 2002 11:12:21 -0000 1.1.1.1 +++ arch/mips/lib/memcpy.S 24 Jun 2002 13:46:07 -0000 @@ -248,8 +248,8 @@ 1: EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES - SUB len, len, NBYTES EXC( STORE t0, 0(dst), s_exc) + SUB len, len, NBYTES bne rem, len, 1b ADD dst, dst, NBYTES --------------4EBBDD03DDAA4619AEF963D7-- From owner-linux-mips@oss.sgi.com Mon Jun 24 07:25: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 g5OEPMnC031599 for ; Mon, 24 Jun 2002 07:25:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OEPMn5031598 for linux-mips-outgoing; Mon, 24 Jun 2002 07:25:22 -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 g5OEPHnC031595 for ; Mon, 24 Jun 2002 07:25:18 -0700 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17MUpR-00013H-00; Mon, 24 Jun 2002 16:28:29 +0200 Date: Mon, 24 Jun 2002 16:28:29 +0200 From: Johannes Stezenbach To: Chien-Lung Wu Cc: linux-mips@oss.sgi.com Subject: Re: cross-compiler Message-ID: <20020624142829.GA4015@convergence.de> Mail-Followup-To: Johannes Stezenbach , Chien-Lung Wu , linux-mips@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 543 Lines: 18 Chien-Lung Wu wrote: > I use the following tar-ball as base: (The newest one) > a. binutils (2.11.2) > b. gcc 3.1 > c. glibc 2.2.5 > > As a newbie in linux embedded system, could anyone kindly show me "HOWTO" > build up a cross-compiler in general and specifically for MIPS (IDT > R32334/32332)? > > If you know any good stuffs in building cross-compiler and porting Linux to > MIPS, please send me the web-side or pointers. Thanks in advance. http://linux-mips.sourceforge.net/ http://www.junsun.net/linux/porting-howto/ HTH, Johannes From owner-linux-mips@oss.sgi.com Mon Jun 24 07:45: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 g5OEjLnC032048 for ; Mon, 24 Jun 2002 07:45:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OEjLJ1032047 for linux-mips-outgoing; Mon, 24 Jun 2002 07:45:21 -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 g5OEjDnC032044; Mon, 24 Jun 2002 07:45:14 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA01609; Mon, 24 Jun 2002 16:49:02 +0200 (MET DST) Date: Mon, 24 Jun 2002 16:49:00 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: sys_syscall patch. In-Reply-To: <20020624134549.B27807@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 Content-Length: 1038 Lines: 23 On Mon, 24 Jun 2002, Ralf Baechle wrote: > It's in the kernel for no better reason than Risc/OS and IRIX having this > syscall. Also the glibc syscall implementation was historically broken > wrt. syscall restarting and a few other subtilities. Well, userland implementations for other archs seem quite straightforward. So should be ours -- we only have to shuffle arguments appropriately. Restarting is easy -- we just have to make sure to reload v0 just before "syscall" reliably (we can use a static register or an automatic variable to preserve it). What are the few other subtleties? Also I can't see an implementation of syscall() for MIPS/Linux anywhere in glibc. What implementation do you refer to? The Mach one? The win is we don't have to mess with user accesses specially -- the final syscall will handle them. -- + 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 Jun 24 07:57: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 g5OEvPnC032234 for ; Mon, 24 Jun 2002 07:57:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OEvPxh032233 for linux-mips-outgoing; Mon, 24 Jun 2002 07:57:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from crack.them.org (crack.them.org [65.125.64.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OEvKnC032230 for ; Mon, 24 Jun 2002 07:57:20 -0700 Received: from cs2876-108.austin.rr.com ([24.28.76.108] helo=branoic) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17MVKR-0007sX-00; Mon, 24 Jun 2002 10:00:31 -0500 Received: from drow by branoic with local (Exim 3.35 #1 (Debian)) id 17MVJx-0001P2-00; Mon, 24 Jun 2002 11:00:01 -0400 Date: Mon, 24 Jun 2002 11:00:01 -0400 From: Daniel Jacobowitz To: Carsten Lange Cc: "'linux-mips@oss.sgi.com'" Subject: Re: mipsel-linux-gdb(5.2): DW_FORM_strp pointing outside of .debug_str section Message-ID: <20020624150001.GA5373@branoic.them.org> References: <3D171ECB.28F566C1@detewe.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D171ECB.28F566C1@detewe.de> User-Agent: Mutt/1.3.28i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 829 Lines: 27 On Mon, Jun 24, 2002 at 03:29:47PM +0200, Carsten Lange wrote: > Hi, > > I get the above error from gdb 5.2 when using the command. > ... > (gdb) file iprbs > file iprbs > Reading symbols from iprbs...DW_FORM_strp pointing outside of .debug_str section > (gdb) > ... > > My mipsel-linux- toolchain consist of the following packages: > binutils-2.12.1 > gcc-3.1 > glibc-2.2.5 > gdb-5.2 > > I have no idea what the problem might be. > > Any hints (solutions/workaround) are welcome. Can you produce a testcase? These versions of the tools should not show the problem, assuming you rebuilt everything using them. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Mon Jun 24 08:09:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OF97nC032434 for ; Mon, 24 Jun 2002 08:09:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OF97IL032433 for linux-mips-outgoing; Mon, 24 Jun 2002 08:09:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ocean.lucon.org (12-234-143-38.client.attbi.com [12.234.143.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OF92nC032430 for ; Mon, 24 Jun 2002 08:09:02 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id E1D4D125D1; Mon, 24 Jun 2002 08:12:21 -0700 (PDT) Date: Mon, 24 Jun 2002 08:12:21 -0700 From: "H. J. Lu" To: Daniel Jacobowitz Cc: Carsten Lange , "'linux-mips@oss.sgi.com'" Subject: Re: mipsel-linux-gdb(5.2): DW_FORM_strp pointing outside of .debug_str section Message-ID: <20020624081221.C30482@lucon.org> References: <3D171ECB.28F566C1@detewe.de> <20020624150001.GA5373@branoic.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: <20020624150001.GA5373@branoic.them.org>; from dan@debian.org on Mon, Jun 24, 2002 at 11:00:01AM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 891 Lines: 31 On Mon, Jun 24, 2002 at 11:00:01AM -0400, Daniel Jacobowitz wrote: > On Mon, Jun 24, 2002 at 03:29:47PM +0200, Carsten Lange wrote: > > Hi, > > > > I get the above error from gdb 5.2 when using the command. > > ... > > (gdb) file iprbs > > file iprbs > > Reading symbols from iprbs...DW_FORM_strp pointing outside of .debug_str section > > (gdb) > > ... > > > > My mipsel-linux- toolchain consist of the following packages: > > binutils-2.12.1 > > gcc-3.1 > > glibc-2.2.5 > > gdb-5.2 > > > > I have no idea what the problem might be. > > > > Any hints (solutions/workaround) are welcome. > > Can you produce a testcase? These versions of the tools should not > show the problem, assuming you rebuilt everything using them. > Please get the Linux binutils 2.12.90.0.12. You need that for gcc 3.1 on Linux/mips. H.J. From owner-linux-mips@oss.sgi.com Mon Jun 24 08:29: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 g5OFTvnC032722 for ; Mon, 24 Jun 2002 08:29:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OFTuXG032721 for linux-mips-outgoing; Mon, 24 Jun 2002 08:29:56 -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 (c-180-196-18.ka.dial.de.ignite.net [62.180.196.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OFTqnC032713 for ; Mon, 24 Jun 2002 08:29:54 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5ODXUZ00436; Mon, 24 Jun 2002 15:33:30 +0200 Date: Mon, 24 Jun 2002 15:33:30 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: 2.4.18: pgtable.h compile fix Message-ID: <20020624153330.C28145@dea.linux-mips.net> References: <20020623125811.GA24851@bogon.ms20.nix> 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, Jun 24, 2002 at 10:30:22AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 310 Lines: 9 On Mon, Jun 24, 2002 at 10:30:22AM +0200, Maciej W. Rozycki wrote: > MIPS64 lags behind a bit due to less interest/testing. Note that you > should use "__ASSEMBLY__" to guard assembly-unsafe parts of headers. _LANGUAGE_ASSEMBLY is the traditional MIPS cpp symbol to indicate assembler source code. Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 08:35: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 g5OFZPnC000398 for ; Mon, 24 Jun 2002 08:35:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OFZPe5000397 for linux-mips-outgoing; Mon, 24 Jun 2002 08:35:25 -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 g5OFZCnC000394; Mon, 24 Jun 2002 08:35:14 -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 TAA27667; Mon, 24 Jun 2002 19:13:48 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id TAA26730; Mon, 24 Jun 2002 19:06:02 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id TAA28785; Mon, 24 Jun 2002 19:09:00 +0400 (MSK) Message-ID: <3D17376B.59333E27@niisi.msk.ru> Date: Mon, 24 Jun 2002 19:14:51 +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: Carsten Langgaard CC: Ralf Baechle , "linux-mips@oss.sgi.com" Subject: Re: Bug in __copy_user References: <3D1729F3.7241A74A@mips.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1590 Lines: 45 Carsten Langgaard wrote: > > I have started to look a little bit at the LTP tests. > And one of the testcases that fails (actually it doesn't fail as it > supposed to do) is the syscall getsockopt. > I think the failure is due to the copy_to_user(0, from, 4) call returns > 0, which I wouldn't expect when the destination pointer is NULL. > > I think the problem is in the __copy_user function in > arch/mips/lib/memcpy. > It tries to handle the exception, which we get because the destination > pointer is NULL, by returning the number of uncopied bytes in $a2 to the > caller. > But in this case the length is only 4 bytes, and the copying is done by > a single 'sw'. The problem is the length ($a2) is decreased by 4 before > the 'sw' is executed. > The 'sw' fails and __copy_user terminates, but returns with $a2 = 0 > (instead 4). > > I thing the following patch will solve the problem. Been here, done that. In fact, I posted the following patch few days ago to the list: less_than_4units: /* * rem = len % NBYTES */ beq rem, len, copy_bytes nop 1: EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES -EXC( STORE t0, 0(dst), s_exc) +EXC( STORE t0, 0(dst), s_exc_p1u) bne rem, len, 1b ADD dst, dst, NBYTES This patch also solves the problem for mips in 2.4/2.5 kernel. My question was about the patch for mips64 and mips in 2.2 kernel. Shall memcpy.S from 2.4/2.5 be backported to 2.2 and mips64? Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Jun 24 08:40: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 g5OFeqnC001179 for ; Mon, 24 Jun 2002 08:40:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OFeqEa001178 for linux-mips-outgoing; Mon, 24 Jun 2002 08:40:52 -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 (c-180-196-18.ka.dial.de.ignite.net [62.180.196.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OFelnC001175 for ; Mon, 24 Jun 2002 08:40:49 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OFdtV01135; Mon, 24 Jun 2002 17:39:55 +0200 Date: Mon, 24 Jun 2002 17:39:55 +0200 From: Ralf Baechle To: "Gleb O. Raiko" Cc: Carsten Langgaard , "linux-mips@oss.sgi.com" Subject: Re: Bug in __copy_user Message-ID: <20020624173954.A1109@dea.linux-mips.net> References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D17376B.59333E27@niisi.msk.ru>; from raiko@niisi.msk.ru on Mon, Jun 24, 2002 at 07:14:51PM +0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 452 Lines: 15 Gleb, On Mon, Jun 24, 2002 at 07:14:51PM +0400, Gleb O. Raiko wrote: > This patch also solves the problem for mips in 2.4/2.5 kernel. My > question was about the patch for mips64 and mips in 2.2 kernel. > > Shall memcpy.S from 2.4/2.5 be backported to 2.2 and mips64? I think that would be the prefered solution as it'll be easier to maintain. I've not received any 2.2 patches in a very long, long time - anybody actually still using it? Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 08:50: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 g5OFomnC001360 for ; Mon, 24 Jun 2002 08:50:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OFomha001359 for linux-mips-outgoing; Mon, 24 Jun 2002 08:50:48 -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 g5OFodnC001355; Mon, 24 Jun 2002 08:50:40 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA02953; Mon, 24 Jun 2002 17:54:29 +0200 (MET DST) Date: Mon, 24 Jun 2002 17:54:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: 2.4.18: pgtable.h compile fix In-Reply-To: <20020624153330.C28145@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 Content-Length: 877 Lines: 25 On Mon, 24 Jun 2002, Ralf Baechle wrote: > > MIPS64 lags behind a bit due to less interest/testing. Note that you > > should use "__ASSEMBLY__" to guard assembly-unsafe parts of headers. > > _LANGUAGE_ASSEMBLY is the traditional MIPS cpp symbol to indicate assembler > source code. Well, but the rest of the kernel uses "__ASSEMBLY__", that's defined in the top-level Makefile. What's the point in being different? Also it doesn't seem to work for me -- the rules in specs look broken: $ mipsel-linux-gcc -E -dM -xassembler-with-cpp /dev/null | grep LANGUAGE #define __LANGUAGE_C 1 #define _LANGUAGE_C 1 #define LANGUAGE_C 1 thus it cannot be considered reliable. -- + 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 Jun 24 09:00: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 g5OG0SnC002119 for ; Mon, 24 Jun 2002 09:00:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OG0SZM002118 for linux-mips-outgoing; Mon, 24 Jun 2002 09:00:28 -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 g5OG0InC002115; Mon, 24 Jun 2002 09:00:22 -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 UAA28048; Mon, 24 Jun 2002 20:03:48 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id TAA26858; Mon, 24 Jun 2002 19:56:55 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id TAA29978; Mon, 24 Jun 2002 19:59:33 +0400 (MSK) Message-ID: <3D174330.BAEBC56@niisi.msk.ru> Date: Mon, 24 Jun 2002 20:05:04 +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: Ralf Baechle CC: Carsten Langgaard , "linux-mips@oss.sgi.com" Subject: Re: Bug in __copy_user References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> <20020624173954.A1109@dea.linux-mips.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 776 Lines: 23 Ralf Baechle wrote: > > Gleb, > > On Mon, Jun 24, 2002 at 07:14:51PM +0400, Gleb O. Raiko wrote: > > > This patch also solves the problem for mips in 2.4/2.5 kernel. My > > question was about the patch for mips64 and mips in 2.2 kernel. > > > > Shall memcpy.S from 2.4/2.5 be backported to 2.2 and mips64? > > I think that would be the prefered solution as it'll be easier to maintain. > > I've not received any 2.2 patches in a very long, long time - anybody > actually still using it? Yes, I am still using 2.2. Considering pathes, I've got patches for r3k, which doesn't work with a standard 2.2 kernel. But those patches are backports from 2.4. So, I don't think they shall be applied. From other hand, I don't plan develop 'normal' patches for 2.2. Regards, Gleb. From owner-linux-mips@oss.sgi.com Mon Jun 24 09:04: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 g5OG40nC002234 for ; Mon, 24 Jun 2002 09:04:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OG403N002233 for linux-mips-outgoing; Mon, 24 Jun 2002 09:04:00 -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 g5OG3snC002230; Mon, 24 Jun 2002 09:03: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 JAA12383; Mon, 24 Jun 2002 09:07:08 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA07155; Mon, 24 Jun 2002 09:07:06 -0700 (PDT) Message-ID: <019401c21b99$387ce290$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Gleb O. Raiko" Cc: "Carsten Langgaard" , References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> <20020624173954.A1109@dea.linux-mips.net> Subject: Re: Bug in __copy_user Date: Mon, 24 Jun 2002 18:07:18 +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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 20 From: "Ralf Baechle" > On Mon, Jun 24, 2002 at 07:14:51PM +0400, Gleb O. Raiko wrote: > > > This patch also solves the problem for mips in 2.4/2.5 kernel. My > > question was about the patch for mips64 and mips in 2.2 kernel. > > > > Shall memcpy.S from 2.4/2.5 be backported to 2.2 and mips64? > > I think that would be the prefered solution as it'll be easier to maintain. > > I've not received any 2.2 patches in a very long, long time - anybody > actually still using it? Only a few thousand (or tens of thousands) of Sony Playstation 2 users. ;-) Most of them are running the wierd 2.2.1.?? Sony branch, but there are a few poor deluded souls tryng to update to 2.2.20... Kevin K. From owner-linux-mips@oss.sgi.com Mon Jun 24 09:22: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 g5OGMCnC002482 for ; Mon, 24 Jun 2002 09:22:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OGMCaR002481 for linux-mips-outgoing; Mon, 24 Jun 2002 09:22: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 (c-180-196-18.ka.dial.de.ignite.net [62.180.196.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OGM7nC002477 for ; Mon, 24 Jun 2002 09:22:09 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5OGMZW05311; Mon, 24 Jun 2002 18:22:35 +0200 Date: Mon, 24 Jun 2002 18:22:35 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: "Gleb O. Raiko" , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: Bug in __copy_user Message-ID: <20020624182235.A1345@dea.linux-mips.net> References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> <20020624173954.A1109@dea.linux-mips.net> <019401c21b99$387ce290$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: <019401c21b99$387ce290$10eca8c0@grendel>; from kevink@mips.com on Mon, Jun 24, 2002 at 06:07:18PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 358 Lines: 10 On Mon, Jun 24, 2002 at 06:07:18PM +0200, Kevin D. Kissell wrote: > Only a few thousand (or tens of thousands) of Sony Playstation 2 > users. ;-) Most of them are running the wierd 2.2.1.?? Sony > branch, but there are a few poor deluded souls tryng to update > to 2.2.20... Just in time when the Linux world has already mostly abandoned 2.2 ... Ralf From owner-linux-mips@oss.sgi.com Mon Jun 24 09:35: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 g5OGZcnC002636 for ; Mon, 24 Jun 2002 09:35:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OGZcvS002635 for linux-mips-outgoing; Mon, 24 Jun 2002 09:35:38 -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 g5OGZXnC002632; Mon, 24 Jun 2002 09:35: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 JAA12535; Mon, 24 Jun 2002 09:38:42 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA08306; Mon, 24 Jun 2002 09:38:41 -0700 (PDT) Message-ID: <004101c21b9d$a2181d60$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: "Gleb O. Raiko" , "Carsten Langgaard" , References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> <20020624173954.A1109@dea.linux-mips.net> <019401c21b99$387ce290$10eca8c0@grendel> <20020624182235.A1345@dea.linux-mips.net> Subject: Re: Bug in __copy_user Date: Mon, 24 Jun 2002 18:38:53 +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.4910.0300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 528 Lines: 14 From: "Ralf Baechle" > On Mon, Jun 24, 2002 at 06:07:18PM +0200, Kevin D. Kissell wrote: > > > Only a few thousand (or tens of thousands) of Sony Playstation 2 > > users. ;-) Most of them are running the wierd 2.2.1.?? Sony > > branch, but there are a few poor deluded souls tryng to update > > to 2.2.20... > > Just in time when the Linux world has already mostly abandoned 2.2 ... Well, like I said last week, we need to get the PS2 onto 2.4 ASAP, for a whole bunch of reasons... Kevin K. From owner-linux-mips@oss.sgi.com Mon Jun 24 10:28: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 g5OHSDnC003080 for ; Mon, 24 Jun 2002 10:28:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OHSDaR003079 for linux-mips-outgoing; Mon, 24 Jun 2002 10:28:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from nwd2mime2.analog.com (nwd2mime2.analog.com [137.71.25.114]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OHS7nC003076 for ; Mon, 24 Jun 2002 10:28:07 -0700 Received: from nwd2gtw1 (unverified) by nwd2mime2.analog.com (Content Technologies SMTPRS 4.2.5) with SMTP id ; Mon, 24 Jun 2002 13:31:24 -0400 Received: from golf.cpgdesign.analog.com ([137.71.139.100]) by nwd2mhb2.analog.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id NAA11916; Mon, 24 Jun 2002 13:31:18 -0400 (EDT) Received: from ws4.cpgdesign.analog.com (ws4 [137.71.139.26]) by golf.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id KAA17700; Mon, 24 Jun 2002 10:31:16 -0700 (PDT) Received: from analog.com (localhost [127.0.0.1]) by ws4.cpgdesign.analog.com (8.9.1/8.9.1) with ESMTP id KAA24572; Mon, 24 Jun 2002 10:31:16 -0700 (PDT) Message-ID: <3D175764.48E562F7@analog.com> Date: Mon, 24 Jun 2002 10:31:16 -0700 From: Justin Wojdacki Reply-To: justin.wojdacki@analog.com Organization: Analog Devices, Communications Processors Group X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Domcan Sami CC: linux-mips@oss.sgi.com, linux-kernel@vger.kernel.org, redhat-list@redhat.com Subject: Re: Linux Boot sequence on MIPS?? References: <20020622093321.25583.qmail@email.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 737 Lines: 22 Domcan Sami wrote: > > Hello everybody > I m trying to develop a Linux boot-loader for MIPS processor, can > anybody help me sending the Linux boot sequence on MIPS. Any sites for > reference? Thanks > Where do you expect to load the kernel from? And what CPU/Board? The basic process is to POST the board, load the kernel into SDRAM, and run the kernel. Where you want to load the kernel from determines the other initialization work you need to do. Alternately, have you looked at PMON? It may provide everything you need for a MIPS-based system. -- ------------------------------------------------- Justin Wojdacki justin.wojdacki@analog.com (408) 350-5032 Communications Processors Group -- Analog Devices From owner-linux-mips@oss.sgi.com Mon Jun 24 12:48:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OJm7nC005390 for ; Mon, 24 Jun 2002 12:48:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OJm7CP005389 for linux-mips-outgoing; Mon, 24 Jun 2002 12:48:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from alphaflight.d6.dnsalias.org (mke-24-209-142-145.wi.rr.com [24.209.142.145]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OJlbnC005383; Mon, 24 Jun 2002 12:47:45 -0700 Received: by alphaflight.d6.dnsalias.org (Postfix, from userid 1000) id D0BD84192; Mon, 24 Jun 2002 14:49:22 -0500 (CDT) Date: Mon, 24 Jun 2002 14:49:22 -0500 From: "M. R. Brown" To: "Kevin D. Kissell" Cc: Ralf Baechle , "Gleb O. Raiko" , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: Bug in __copy_user Message-ID: <20020624194922.GB12960@0xd6.org> References: <3D1729F3.7241A74A@mips.com> <3D17376B.59333E27@niisi.msk.ru> <20020624173954.A1109@dea.linux-mips.net> <019401c21b99$387ce290$10eca8c0@grendel> <20020624182235.A1345@dea.linux-mips.net> <004101c21b9d$a2181d60$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: <004101c21b9d$a2181d60$10eca8c0@grendel> User-Agent: Mutt/1.3.28i X-Sender: mrbrown@0xd6.org Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1127 Lines: 40 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kevin D. Kissell on Mon, Jun 24, 2002: > From: "Ralf Baechle" > > On Mon, Jun 24, 2002 at 06:07:18PM +0200, Kevin D. Kissell wrote: > >=20 > > > Only a few thousand (or tens of thousands) of Sony Playstation 2 > > > users. ;-) Most of them are running the wierd 2.2.1.?? Sony > > > branch, but there are a few poor deluded souls tryng to update > > > to 2.2.20... > >=20 > > Just in time when the Linux world has already mostly abandoned 2.2 ... >=20 > Well, like I said last week, we need to get the PS2 onto 2.4 ASAP, > for a whole bunch of reasons... >=20 ps2hacking.sourceforge.net - broken port of Sony's 2.2.1 kernel to 2.4.8 (or so). M. R. --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE9F3fCaK6pP/GNw0URApmmAKC9TbFc987AzdRR3S2bJYtubVehuQCfXUQl e6WuIG5SgtVm2JDe5XduZt4= =50NJ -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From owner-linux-mips@oss.sgi.com Mon Jun 24 17:38: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 g5P0c2nC014108 for ; Mon, 24 Jun 2002 17:38:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P0c1OQ014107 for linux-mips-outgoing; Mon, 24 Jun 2002 17:38:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from kopretinka (p055.as-l025.contactel.cz [212.65.234.55]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P0bFnC014102 for ; Mon, 24 Jun 2002 17:37:40 -0700 Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian)) id 17MeKW-0000VP-00; Tue, 25 Jun 2002 02:37:12 +0200 Date: Tue, 25 Jun 2002 02:36:34 +0200 To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: DBE/IBE handling incompatibility Message-ID: <20020625003634.GA1917@kopretinka> References: <20020617113311.GA839@kopretinka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Ladislav Michl Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1791 Lines: 46 On Wed, Jun 19, 2002 at 06:47:05PM +0200, Maciej W. Rozycki wrote: > Don't rely in dbe_board_handler and ibe_board_handler -- they are > system-specific backends that shouldn't be touched unless you want to > handle the exceptions in a system-specific way (e.g. to report ECC errors > from a memory controller). MC sends an interrupt whenever bus or parity errors occur. In addition, if the error happened during a CPU read, it also asserts the bus error pin on the R4K. so once one access nonexistent memory on Indy first DBE is generated followed by Bus Error interupt (IRQ 6). When GIO status register is cleared inside DBE handler, irq is not delivered. > Also expect the handlers to get rewritten so that search_dbe_table() gets > invoked unconditionally, before a system-specific backend. i don't want to use these handlers, i'd like to write it mips64 way. > Use get_dbe() from for reading data with an additional > DBE status. For a simple example see drivers/mtd/devices/ms02-nv.c. The > macro is used in a somewhat more complex way in drivers/tc/tc.c as well -- > this bit of code fits your situation quite closely (here probing > TURBOchannel bus slots). The macro works in modules as well. that does't work. i used folowing pseudocode: my_get_dbe() nofault = 1; ret = get_dbe(*val, (unsigned int *) addr); __asm__ __volatile__("nop;nop;nop;nop"); nofault = 0; my_do_buserr() save_and_clear_buserr(); if (nofault) { nofault = 0; return; } panic(); when calling my_get_dbe for nonexistent address it enters my_do_buserr and returns "somewhere" causing machine to freeze. calling save_and_clear_buserr() from board specific DBE handler works as expected. is there better solution or i missed anything important? thanks, ladis From owner-linux-mips@oss.sgi.com Tue Jun 25 00:12: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 g5P7CXnC031062 for ; Tue, 25 Jun 2002 00:12:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P7CXKq031061 for linux-mips-outgoing; Tue, 25 Jun 2002 00:12:33 -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 g5P7CLnC031054; Tue, 25 Jun 2002 00:12:22 -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 AAA15932; Tue, 25 Jun 2002 00:15:35 -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 AAA06911; Tue, 25 Jun 2002 00:15: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 g5P7Fbb13213; Tue, 25 Jun 2002 09:15:37 +0200 (MEST) Message-ID: <3D181898.837E864A@mips.com> Date: Tue, 25 Jun 2002 09:15:36 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "linux-mips@oss.sgi.com" Subject: LTP testing Content-Type: multipart/mixed; boundary="------------AFB792D746638736CFC1E76F" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1658 Lines: 60 This is a multi-part message in MIME format. --------------AFB792D746638736CFC1E76F Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The next LTP failure is: mprotect01 1 FAIL : unexpected error - 14 : Bad address - expected 12 This has been fixed in the 2.4.19-pre4 patch. But here is a local patch that solve the above problem, so we can have this fixed before we have merged with kernel.org. /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 --------------AFB792D746638736CFC1E76F Content-Type: text/plain; charset=iso-8859-15; name="mprotect.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mprotect.patch" Index: mm/mprotect.c =================================================================== RCS file: /home/repository/sw/linux-2.4.18/mm/mprotect.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 mprotect.c --- mm/mprotect.c 4 Mar 2002 11:13:35 -0000 1.1.1.1 +++ mm/mprotect.c 25 Jun 2002 07:00:55 -0000 @@ -284,7 +284,7 @@ down_write(¤t->mm->mmap_sem); vma = find_vma_prev(current->mm, start, &prev); - error = -EFAULT; + error = -ENOMEM; if (!vma || vma->vm_start > start) goto out; @@ -317,7 +317,7 @@ nstart = tmp; vma = next; if (!vma || vma->vm_start != nstart) { - error = -EFAULT; + error = -ENOMEM; goto out; } } --------------AFB792D746638736CFC1E76F-- From owner-linux-mips@oss.sgi.com Tue Jun 25 01:54: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 g5P8sVnC003118 for ; Tue, 25 Jun 2002 01:54:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P8sVFH003117 for linux-mips-outgoing; Tue, 25 Jun 2002 01:54:31 -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 (c-180-196-20.ka.dial.de.ignite.net [62.180.196.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P8sMnC003112 for ; Tue, 25 Jun 2002 01:54:24 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g5P8saR16545; Tue, 25 Jun 2002 10:54:36 +0200 Date: Tue, 25 Jun 2002 10:54:36 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: 2.4.18: pgtable.h compile fix Message-ID: <20020625105436.A16439@dea.linux-mips.net> References: <20020624153330.C28145@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, Jun 24, 2002 at 05:54:28PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1177 Lines: 35 On Mon, Jun 24, 2002 at 05:54:28PM +0200, Maciej W. Rozycki wrote: > > > MIPS64 lags behind a bit due to less interest/testing. Note that you > > > should use "__ASSEMBLY__" to guard assembly-unsafe parts of headers. > > > > _LANGUAGE_ASSEMBLY is the traditional MIPS cpp symbol to indicate assembler > > source code. > > Well, but the rest of the kernel uses "__ASSEMBLY__", that's defined in > the top-level Makefile. What's the point in being different? > > Also it doesn't seem to work for me -- the rules in specs look broken: > > $ mipsel-linux-gcc -E -dM -xassembler-with-cpp /dev/null | grep LANGUAGE > #define __LANGUAGE_C 1 > #define _LANGUAGE_C 1 > #define LANGUAGE_C 1 > > thus it cannot be considered reliable. The machanism guesses the language based on the source file name extension: [ralf@dea tmp]$ echo -n > c.c && mips-linux-gcc -E -dM -xassembler-with-cpp c.c | grep LANG #define __LANGUAGE_C 1 #define _LANGUAGE_C 1 #define LANGUAGE_C 1 [ralf@dea tmp]$ echo -n > c.S && mips-linux-gcc -E -dM c.S | grep LANG #define LANGUAGE_ASSEMBLY 1 #define _LANGUAGE_ASSEMBLY 1 #define __LANGUAGE_ASSEMBLY 1 [ralf@dea tmp]$ Buggy? Yes ... Ralf From owner-linux-mips@oss.sgi.com Tue Jun 25 02:56: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 g5P9uDnC019740 for ; Tue, 25 Jun 2002 02:56:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P9uDaV019739 for linux-mips-outgoing; Tue, 25 Jun 2002 02:56:13 -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 g5P9twnC019736; Tue, 25 Jun 2002 02:55:59 -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 CAA16402; Tue, 25 Jun 2002 02:59:13 -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 CAA11541; Tue, 25 Jun 2002 02:59: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 g5P9xEb23912; Tue, 25 Jun 2002 11:59:14 +0200 (MEST) Message-ID: <3D183EF2.FB26BA59@mips.com> Date: Tue, 25 Jun 2002 11:59:14 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "linux-mips@oss.sgi.com" Subject: LTP testing Content-Type: multipart/mixed; boundary="------------A57255ACE7E444374521FB17" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2617 Lines: 80 This is a multi-part message in MIME format. --------------A57255ACE7E444374521FB17 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The LTP test fails with: msgctl01 1 FAIL : qs_buf.msg_qbytes did not change msgctl02 1 FAIL : qs_buf.msg_qbytes value is not expected msgsnd01 1 FAIL : queue bytes != MSGSIZE msgsnd01 2 FAIL : queue message != 1 All the above failures is fixed by the attached patch. The msgbuf.h file is now a copy from i386, instead of alpha. I guess the fix goes for 64-bit kernel as well. /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 --------------A57255ACE7E444374521FB17 Content-Type: text/plain; charset=iso-8859-15; name="msgbuf.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msgbuf.patch" Index: include/asm-mips/msgbuf.h =================================================================== RCS file: /home/repository/sw/linux-2.4.18/include/asm-mips/msgbuf.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 msgbuf.h --- include/asm-mips/msgbuf.h 4 Mar 2002 11:13:24 -0000 1.1.1.1 +++ include/asm-mips/msgbuf.h 25 Jun 2002 09:30:03 -0000 @@ -2,26 +2,30 @@ #define _ASM_MSGBUF_H /* - * The msqid64_ds structure for alpha architecture. + * The msqid64_ds structure for i386 architecture. * Note extra padding because this structure is passed back and forth * between kernel and user space. * * Pad space is left for: - * - 2 miscellaneous 64-bit values + * - 64-bit time_t to solve y2038 problem + * - 2 miscellaneous 32-bit values */ struct msqid64_ds { struct ipc64_perm msg_perm; __kernel_time_t msg_stime; /* last msgsnd time */ + unsigned long __unused1; __kernel_time_t msg_rtime; /* last msgrcv time */ + unsigned long __unused2; __kernel_time_t msg_ctime; /* last change time */ + unsigned long __unused3; unsigned long msg_cbytes; /* current number of bytes on queue */ unsigned long msg_qnum; /* number of messages in queue */ unsigned long msg_qbytes; /* max number of bytes on queue */ __kernel_pid_t msg_lspid; /* pid of last msgsnd */ __kernel_pid_t msg_lrpid; /* last receive pid */ - unsigned long __unused1; - unsigned long __unused2; + unsigned long __unused4; + unsigned long __unused5; }; #endif /* _ASM_MSGBUF_H */ --------------A57255ACE7E444374521FB17-- From owner-linux-mips@oss.sgi.com Tue Jun 25 03:44: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 g5PAitnC007396 for ; Tue, 25 Jun 2002 03:44:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PAitpJ007395 for linux-mips-outgoing; Tue, 25 Jun 2002 03:44:55 -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 g5PAicnC007392; Tue, 25 Jun 2002 03:44:39 -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 DAA16508; Tue, 25 Jun 2002 03:47:55 -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 DAA12708; Tue, 25 Jun 2002 03:47:55 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g5PAlsb27260; Tue, 25 Jun 2002 12:47:55 +0200 (MEST) Message-ID: <3D184A59.E755154B@mips.com> Date: Tue, 25 Jun 2002 12:47:54 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "linux-mips@oss.sgi.com" Subject: LTP testing Content-Type: multipart/mixed; boundary="------------B685E88831FE5634C4CE0DD0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1813 Lines: 64 This is a multi-part message in MIME format. --------------B685E88831FE5634C4CE0DD0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The next LTP failure is: msync05 1 FAIL : msync() fails, unexpected errno:14, expected: ENOMEM This has also been fixed in the 2.4.19-pre4 patch. See the attached patch below. /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 --------------B685E88831FE5634C4CE0DD0 Content-Type: text/plain; charset=iso-8859-15; name="filemap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="filemap.patch" Index: mm/filemap.c =================================================================== RCS file: /home/repository/sw/linux-2.4.18/mm/filemap.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 filemap.c --- mm/filemap.c 4 Mar 2002 11:13:34 -0000 1.1.1.1 +++ mm/filemap.c 25 Jun 2002 10:36:12 -0000 @@ -2179,18 +2179,18 @@ goto out; /* * If the interval [start,end) covers some unmapped address ranges, - * just ignore them, but return -EFAULT at the end. + * just ignore them, but return -ENOMEM at the end. */ vma = find_vma(current->mm, start); unmapped_error = 0; for (;;) { /* Still start < end. */ - error = -EFAULT; + error = -ENOMEM; if (!vma) goto out; /* Here start < vma->vm_end. */ if (start < vma->vm_start) { - unmapped_error = -EFAULT; + unmapped_error = -ENOMEM; start = vma->vm_start; } /* Here vma->vm_start <= start < vma->vm_end. */ --------------B685E88831FE5634C4CE0DD0-- From owner-linux-mips@oss.sgi.com Tue Jun 25 04:04: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 g5PB4snC007948 for ; Tue, 25 Jun 2002 04:04:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PB4sW9007947 for linux-mips-outgoing; Tue, 25 Jun 2002 04:04:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dtwse201.detewe.de ([195.50.171.201]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PB3mnC007942 for ; Tue, 25 Jun 2002 04:03:59 -0700 Received: from zinse043.detewe.de (unverified) by dtwse201.detewe.de (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Jun 2002 13:09:33 +0200 Received: from detewe.de ([172.30.201.153]) by zinse043.detewe.de (Netscape Messaging Server 3.6) with ESMTP id AAA1348; Tue, 25 Jun 2002 13:05:36 +0200 Message-ID: <3D184EAC.D8C8CBA6@detewe.de> Date: Tue, 25 Jun 2002 13:06:20 +0200 From: Carsten Lange X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" CC: Daniel Jacobowitz , "'linux-mips@oss.sgi.com'" Subject: Re: mipsel-linux-gdb(5.2): DW_FORM_strp pointing outside of .debug_str section References: <3D171ECB.28F566C1@detewe.de> <20020624150001.GA5373@branoic.them.org> <20020624081221.C30482@lucon.org> Content-Type: multipart/mixed; boundary="------------4E8576234784E74CD2CBC2A8" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8215 Lines: 338 This is a multi-part message in MIME format. --------------4E8576234784E74CD2CBC2A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, when I use binutils 2.12.90.0.12 gcc 3.1 will not compile anymore. The error is: ... mkdir libgcc if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /opt/cross/production/build/gcc/gcc/xgcc -B/opt/cross/production/build/gcc/gcc/ -B/opt/cross/mipsel-linux/mipsel-linux/bin/ -B/opt/cross/mipsel-linux/mipsel-linux/lib/ -isystem /opt/cross/mipsel-linux/mipsel-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/opt/cross/production/src/gcc-3.1/gcc -I/opt/cross/production/src/gcc-3.1/gcc/. -I/opt/cross/production/src/gcc-3.1/gcc/config -I/opt/cross/production/src/gcc-3.1/gcc/../include -DL_muldi3 -c /opt/cross/production/src/gcc-3.1/gcc/libgcc2.c -o libgcc/./_muldi3.o /tmp/ccPEIznf.s: Assembler messages: /tmp/ccPEIznf.s:5: Error: file number 1 already allocated make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/opt/cross/production/build/gcc/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/opt/cross/production/build/gcc/gcc' make: *** [all-gcc] Error 2 ... Building the toolchain works fine with binutils-2.12.1. I attach 2 files (the build_mips_toolchain and mipsel-linux.source) which I use to build the tools from scratch on my linux i586 box. Any program build with this toolchain cannot be opened with gdb. What are the recommended versions of gcc, glibc and gdb? Many thanks Carsten "H. J. Lu" wrote: > > On Mon, Jun 24, 2002 at 11:00:01AM -0400, Daniel Jacobowitz wrote: > > On Mon, Jun 24, 2002 at 03:29:47PM +0200, Carsten Lange wrote: > > > Hi, > > > > > > I get the above error from gdb 5.2 when using the command. > > > ... > > > (gdb) file iprbs > > > file iprbs > > > Reading symbols from iprbs...DW_FORM_strp pointing outside of .debug_str section > > > (gdb) > > > ... > > > > > > My mipsel-linux- toolchain consist of the following packages: > > > binutils-2.12.1 > > > gcc-3.1 > > > glibc-2.2.5 > > > gdb-5.2 > > > > > > I have no idea what the problem might be. > > > > > > Any hints (solutions/workaround) are welcome. > > > > Can you produce a testcase? These versions of the tools should not > > show the problem, assuming you rebuilt everything using them. > > > > Please get the Linux binutils 2.12.90.0.12. You need that for gcc 3.1 > on Linux/mips. > > H.J. --------------4E8576234784E74CD2CBC2A8 Content-Type: text/plain; charset=us-ascii; name="build_mips_toolschain" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="build_mips_toolschain" #!/bin/sh if [ "x$1" == "x" ] then echo "usage: $0 " exit 1 fi if [ -f ${1}.source ] then . ${1}.source else echo "usage: $0 " exit 1 fi execute() { echo "+++++++++++++++++++++++++++ $@ " echo "+++++++++++++++++++++++++++ $@ " >> $LOGFILE 2>&1 $@ >> $LOGFILE 2>&1 if [ ! $? = 0 ] then echo "$@ FAILED!" exit 1 fi } execute_patch() { echo "+ patch $1 -s < $2" if [ -f $2 ] then pkgpatch $1 -s < $2 if [ ! $? = 0 ] then echo "patch $1 -s < $2 FAILED!" exit 1 fi else echo "Patchfile $2 not found!" exit 1 fi } #cleanup execute rm -rf $BUILD execute mkdir -p $BUILD execute rm -rf $SRC execute mkdir -p $SRC # # # BINUTILS if [ ! -f ${PREFIX}/binutils-${BINUTILS_V} ] ; then execute cd $SRC #execute tar xzf $PKG/binutils-${BINUTILS_V}.tar.gz execute tar xjf $PKG/binutils-${BINUTILS_V}.tar.bz2 execute cd $BUILD execute mkdir binutils execute cd binutils execute $SRC/binutils-${BINUTILS_V}/configure \ --target=${TARGET} \ --prefix=${PREFIX} execute make execute make install execute rm -rf $SRC/binutils-${BINUTILS_V} execute rm -rf $BUILD/binutils execute touch ${PREFIX}/binutils-${BINUTILS_V} fi # # # INCLUDE FILES #execute rm -rf ${PREFIX}/target #execute mkdir -p ${PREFIX}/target/include #execute cd /opt/cross/devel/ip_rbs/linux/include #execute tar cf /tmp/${TARGET}_include . #execute cd ${PREFIX}/target/usr/include #execute tar xf /tmp/${TARGET}_include #execute ln -sf /opt/cross/devel/ip_rbs/linux/include/asm ${PREFIX}/target/include/asm #execute ln -sf /opt/cross/devel/ip_rbs/linux/include/linux ${PREFIX}/target/include/linux # GCC if [ ! -f ${PREFIX}/gcc-${GCC_V}_step1 ] ; then execute cd $SRC execute tar xzf $PKG/gcc-${GCC_V}.tar.gz execute cd $BUILD execute mkdir gcc execute cd gcc execute $SRC/gcc-${GCC_V}/configure \ --target=${TARGET} \ --prefix=${PREFIX} \ --enable-languages=c \ --disable-shared \ --with-newlib \ --with-headers=${HEADERS} execute make execute make install execute touch ${PREFIX}/gcc-${GCC_V}_step1 fi # # # GLIBC if [ ! -f ${PREFIX}/glibc-${GLIBC_V} ] ; then execute cd $SRC execute tar xzf $PKG/glibc-${GLIBC_V}.tar.gz execute cd glibc-${GLIBC_V} execute tar xzf $PKG/glibc-linuxthreads-${GLIBC_V}.tar.gz execute cd $BUILD execute mkdir glibc execute cd glibc execute $SRC/glibc-${GLIBC_V}/configure \ --build=i686-linux \ --host=${TARGET} \ --enable-add-ons \ --disable-sanity-checks \ --prefix=${PREFIX}/${TARGTET} execute make execute make install execute touch ${PREFIX}/glibc-${GLIBC_V} fi # # # GCC again if [ ! -f ${PREFIX}/gcc-${GCC_V} ] ; then execute cd $BUILD execute cd gcc execute $SRC/gcc-${GCC_V}/configure \ --target=${TARGET} \ --prefix=${PREFIX} \ --enable-languages=c,c++ \ --with-libs=${PREFIX}/${TARGTET}/lib \ --with-headers=${HEADERS} execute make execute make install execute touch ${PREFIX}/gcc-${GCC_V} fi # # # GDB if [ ! -f ${PREFIX}/gdb-${GDB_V} ] ; then execute cd $SRC execute execute tar xzf $PKG/gdb-${GDB_V}.tar.gz execute cd $BUILD execute mkdir -p gdb execute cd gdb execute $SRC/gdb-${GDB_V}/configure \ --target=${TARGET} \ --prefix=${PREFIX} execute make execute make install execute touch ${PREFIX}/gdb-${GDB_V} fi # # # GDB SERVER if [ ! -f ${PREFIX}/gdbserver-${GDB_V} ] ; then execute mkdir -p $BUILD/gdbserver execute cd $BUILD execute cd gdbserver execute chmod u+x $SRC/gdb-${GDB_V}/gdb/gdbserver/configure export CC=mipsel-linux-gcc execute $SRC/gdb-${GDB_V}/gdb/gdbserver/configure \ --target=${TARGET} \ --prefix=${PREFIX} execute make execute make install execute touch ${PREFIX}/gdbserver-${GDB_V} fi execute echo "############ DONE ############" --------------4E8576234784E74CD2CBC2A8 Content-Type: text/plain; charset=us-ascii; name="mipsel-linux.source" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mipsel-linux.source" # TARGET TARGET=mipsel-linux HEADERS=/opt/cross/devel/ip_rbs/linux/include # VERSIONS #BINUTILS_V="2.12.90.0.12" BINUTILS_V="2.12.1" GCC_V="3.1" GLIBC_V="2.2.5" INSIGHT_V="5.1.1" GDB_V="5.2" DDD_V="3.3.1" # CONFIGURATION CROSSROOT=/opt/cross BASEDIR=$CROSSROOT/production PREFIX=$CROSSROOT/${TARGET} BUILD=$BASEDIR/build SRC=$BASEDIR/src PKG=$BASEDIR/pkg LOGDIR=$BASEDIR/log LOGFILE=$LOGDIR/${0}_`date +%d%m%Y`_`date +%H%M`.log # PATH PATH="$PREFIX/bin:$HOSTPREFIX/bin:$PATH" export PATH echo "LOGFILE is ${LOGFILE}" --------------4E8576234784E74CD2CBC2A8 Content-Type: text/x-vcard; charset=us-ascii; name="Carsten.Lange.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Carsten Lange Content-Disposition: attachment; filename="Carsten.Lange.vcf" begin:vcard n:Lange;Carsten tel;fax:+49 6104 4234 tel;work:+49 30 6104 4228 x-mozilla-html:FALSE url:http://www.detewe.de org:Cordless Technology A/S Berlin adr:;;Koepenicker Str. 180;10997 Berlin;;; version:2.1 email;internet:Carsten.Lange@detewe.de x-mozilla-cpt:;0 fn:Carsten Lange end:vcard --------------4E8576234784E74CD2CBC2A8-- From owner-linux-mips@oss.sgi.com Tue Jun 25 04: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 g5PBptnC013598 for ; Tue, 25 Jun 2002 04:51:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PBptqo013597 for linux-mips-outgoing; Tue, 25 Jun 2002 04:51:55 -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 g5PBpfnC013593 for ; Tue, 25 Jun 2002 04:51:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA00751; Tue, 25 Jun 2002 13:55:23 +0200 (MET DST) Date: Tue, 25 Jun 2002 13:55:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ladislav Michl , Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: DBE/IBE handling incompatibility In-Reply-To: <20020625003634.GA1917@kopretinka> 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 Content-Length: 3861 Lines: 105 On Tue, 25 Jun 2002, Ladislav Michl wrote: > > Don't rely in dbe_board_handler and ibe_board_handler -- they are > > system-specific backends that shouldn't be touched unless you want to > > handle the exceptions in a system-specific way (e.g. to report ECC errors > > from a memory controller). > > MC sends an interrupt whenever bus or parity errors occur. In addition, if the > error happened during a CPU read, it also asserts the bus error pin on the R4K. > so once one access nonexistent memory on Indy first DBE is generated followed > by Bus Error interupt (IRQ 6). When GIO status register is cleared inside DBE > handler, irq is not delivered. So you want both a system-specific DBE handler and a DBE detection in a driver, right? > > Also expect the handlers to get rewritten so that search_dbe_table() gets > > invoked unconditionally, before a system-specific backend. > > i don't want to use these handlers, i'd like to write it mips64 way. The MIPS way is the right one and I'll fix MIPS64 as soon as I get it fixed much enough to boot into the single-user mode on my system. They have to be identical, because there are drivers that work both on MIPS and MIPS64 and expect consistent semantics. A cleanup hook will be provided to let system-specific code do whatever is needed to discard saved DBE state regardless -- I didn't add it so far as I haven't managed to get at it yet. > > Use get_dbe() from for reading data with an additional > > DBE status. For a simple example see drivers/mtd/devices/ms02-nv.c. The > > macro is used in a somewhat more complex way in drivers/tc/tc.c as well -- > > this bit of code fits your situation quite closely (here probing > > TURBOchannel bus slots). The macro works in modules as well. > > that does't work. i used folowing pseudocode: > > my_get_dbe() > nofault = 1; > ret = get_dbe(*val, (unsigned int *) addr); > __asm__ __volatile__("nop;nop;nop;nop"); > nofault = 0; > > my_do_buserr() > save_and_clear_buserr(); > if (nofault) { > nofault = 0; > return; > } > panic(); > > when calling my_get_dbe for nonexistent address it enters my_do_buserr > and returns "somewhere" causing machine to freeze. calling > save_and_clear_buserr() from board specific DBE handler works as > expected. is there better solution or i missed anything important? Well, that's not the right approach -- you are trying to work around the current MIPS64 brokenness. The handler for DBE and IBE in arch/mips*/kernel/traps.c is intended to look more or less as follows: asmlinkage void do_be(struct pt_regs *regs) { unsigned long new_epc; unsigned long fixup = 0; int data = regs->cp0_cause & 4; if (data && !user_mode(regs)) fixup = search_dbe_table(regs->cp0_epc); if (be_board_handler) fixup = be_board_handler(regs, fixup); if (fixup) { new_epc = fix