From owner-linux-mips@oss.sgi.com Thu Aug 1 01:47:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g718lFRw022238 for ; Thu, 1 Aug 2002 01:47:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g718lF23022237 for linux-mips-outgoing; Thu, 1 Aug 2002 01:47:15 -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.5/8.12.5) with SMTP id g718kFRw022213 for ; Thu, 1 Aug 2002 01:46:16 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g718VsXb025297; Thu, 1 Aug 2002 01:31: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 BAA24811; Thu, 1 Aug 2002 01:31: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 g718Vkb27218; Thu, 1 Aug 2002 10:31:46 +0200 (MEST) Message-ID: <3D48F1EA.EBA1CC00@mips.com> Date: Thu, 01 Aug 2002 10:31: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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk What happen with this patch. I think it's ok to apply and no one has made any objection. /Carsten "Maciej W. Rozycki" wrote: > Hello, > > The following patch fixes all the places the default caching policy is > used but various local hacks are coded. Also the sc coherency algorithm > is configured for R4k processors which was previously left as set (or not) > by the firmware. A side effect is is created > and all conditional CPU options are set somehow. Tested on an R4400SC > (for both MIPS and MIPS64) and on an R3400. > > Admittedly, CONF_CM_DEFAULT is defined in a bit weird way, but I couldn't > figure any better one that wouldn't result in a serious but unnecessary > header bloat. If anyone has a better idea, please share any suggestions > here. > > OK to apply? > > Maciej > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > patch-mips-2.4.19-rc1-20020726-cache-coherency-5 > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/config-shared.in linux-mips-2.4.19-rc1-20020726/arch/mips/config-shared.in > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/config-shared.in 2002-07-25 20:11:36.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/config-shared.in 2002-07-27 22:14:21.000000000 +0000 > @@ -403,6 +403,10 @@ fi > if [ "$CONFIG_MIPS_AU1000" != "y" ]; then > define_bool CONFIG_MIPS_AU1000 n > fi > + > +if [ "$CONFIG_SMP" != "y" ]; then > + define_bool CONFIG_SMP n > +fi > endmenu > > mainmenu_option next_comment > @@ -492,6 +496,17 @@ if [ "$CONFIG_CPU_R3000" = "y" ]; then > else > define_bool CONFIG_CPU_HAS_SYNC y > fi > +if [ "$CONFIG_CPU_R4X00" = "y" -o "$CONFIG_CPU_SB1" = "y" ]; then > + define_bool CONFIG_CPU_CACHE_COHERENCY $CONFIG_SMP > +else > + define_bool CONFIG_CPU_CACHE_COHERENCY n > +fi > +if [ "$CONFIG_VTAG_ICACHE" != "y" ]; then > + define_bool CONFIG_VTAG_ICACHE n > +fi > +if [ "$CONFIG_CPU_HAS_PREFETCH" != "y" ]; then > + define_bool CONFIG_CPU_HAS_PREFETCH n > +fi > endmenu > > mainmenu_option next_comment > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-mips32.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-mips32.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-mips32.c 2002-05-30 02:57:43.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-mips32.c 2002-07-27 22:59:42.000000000 +0000 > @@ -657,11 +657,7 @@ void __init ld_mmu_mips32(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 > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-r4k.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-r4k.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-r4k.c 2002-07-15 02:57:47.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-r4k.c 2002-07-27 22:59:22.000000000 +0000 > @@ -1480,11 +1480,7 @@ void __init ld_mmu_r4xx0(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 > + change_cp0_config(CONF_CM_CMASK | CONF_CU, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-r5432.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-r5432.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-r5432.c 2001-12-01 05:26:01.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-r5432.c 2002-07-27 23:01:23.000000000 +0000 > @@ -455,7 +455,7 @@ void __init ld_mmu_r5432(void) > { > unsigned long config = read_32bit_cp0_register(CP0_CONFIG); > > - change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-rm7k.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-rm7k.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-rm7k.c 2002-05-30 02:57:46.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-rm7k.c 2002-07-27 23:02:21.000000000 +0000 > @@ -319,9 +319,7 @@ void __init ld_mmu_rm7k(void) > : "r" (addr), "i" (Index_Store_Tag_I), "i" (Fill)); > } > > -#ifndef CONFIG_MIPS_UNCACHED > - change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_NONCOHERENT); > -#endif > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-sb1.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-sb1.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-sb1.c 2002-05-30 02:57:46.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-sb1.c 2002-07-27 23:04:17.000000000 +0000 > @@ -519,6 +519,6 @@ void ld_mmu_sb1(void) > _flush_cache_sigtramp = sb1_flush_cache_sigtramp; > _flush_icache_all = sb1_flush_icache_all; > > - change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_COW); > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > flush_cache_all(); > } > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-tx49.c linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-tx49.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips/mm/c-tx49.c 2002-05-30 02:57:46.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips/mm/c-tx49.c 2002-07-27 23:05:01.000000000 +0000 > @@ -387,11 +387,7 @@ void __init ld_mmu_tx49(void) > if (mips_configk0 != -1) > change_cp0_config(CONF_CM_CMASK, mips_configk0); > else > -#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 > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/c-mips64.c linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/c-mips64.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/c-mips64.c 2002-07-24 16:12:11.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/c-mips64.c 2002-07-27 23:07:05.000000000 +0000 > @@ -654,11 +654,7 @@ 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 > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/c-sb1.c linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/c-sb1.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/c-sb1.c 2002-05-30 02:57:51.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/c-sb1.c 2002-07-27 23:07:42.000000000 +0000 > @@ -518,6 +518,6 @@ void ld_mmu_sb1(void) > _flush_cache_sigtramp = sb1_flush_cache_sigtramp; > _flush_icache_all = sb1_flush_icache_all; > > - change_cp0_config(CONF_CM_CMASK, CONF_CM_CACHABLE_COW); > + change_cp0_config(CONF_CM_CMASK, CONF_CM_DEFAULT); > flush_cache_all(); > } > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/r4xx0.c linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/r4xx0.c > --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/r4xx0.c 2002-06-20 02:57:39.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/r4xx0.c 2002-07-27 23:09:09.000000000 +0000 > @@ -2268,11 +2268,7 @@ void __init ld_mmu_r4xx0(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 /* UNCACHED */ > + change_cp0_config(CONF_CM_CMASK | CONF_CU, CONF_CM_DEFAULT); > > probe_icache(config); > probe_dcache(config); > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips/mipsregs.h linux-mips-2.4.19-rc1-20020726/include/asm-mips/mipsregs.h > --- linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips/mipsregs.h 2002-07-21 19:21:19.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/include/asm-mips/mipsregs.h 2002-07-27 22:57:03.000000000 +0000 > @@ -374,6 +374,7 @@ > #define CONF_CM_CACHABLE_CUW 6 > #define CONF_CM_CACHABLE_ACCELERATED 7 > #define CONF_CM_CMASK 7 > +#define CONF_CU (1 << 3) > #define CONF_DB (1 << 4) > #define CONF_IB (1 << 5) > #define CONF_SC (1 << 17) > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips/pgtable-bits.h linux-mips-2.4.19-rc1-20020726/include/asm-mips/pgtable-bits.h > --- linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips/pgtable-bits.h 2002-06-30 17:18:30.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/include/asm-mips/pgtable-bits.h 2002-07-27 23:00:05.000000000 +0000 > @@ -12,7 +12,8 @@ > > #include > > -/* Note that we shift the lower 32bits of each EntryLo[01] entry > +/* > + * Note that we shift the lower 32bits of each EntryLo[01] entry > * 6 bits to the left. That way we can convert the PFN into the > * physical address by a single 'and' operation and gain 6 additional > * bits for storing information which isn't present in a normal > @@ -74,9 +75,9 @@ > #define _CACHE_CACHABLE_WA (1<<9) /* R4600 only */ > #define _CACHE_UNCACHED (2<<9) /* R4[0246]00 */ > #define _CACHE_CACHABLE_NONCOHERENT (3<<9) /* R4[0246]00 */ > -#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00 only */ > -#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00 only */ > -#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00 only */ > +#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00MC only */ > +#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00MC only */ > +#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00MC only */ > #define _CACHE_UNCACHED_ACCELERATED (7<<9) /* R10000 only */ > > #endif > @@ -87,12 +88,21 @@ > > #define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_MODIFIED | _CACHE_MASK) > > -#ifdef CONFIG_MIPS_UNCACHED > + > +#if defined(CONFIG_MIPS_UNCACHED) > + > #define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED > -#elif CONFIG_CPU_SB1 > + > +#elif defined(CONFIG_CPU_CACHE_COHERENCY) > + > #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW > + > #else > + > #define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT > + > #endif > > +#define CONF_CM_DEFAULT (PAGE_CACHABLE_DEFAULT >> 9) > + > #endif /* _ASM_CACHINGMODES_H */ > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/mipsregs.h linux-mips-2.4.19-rc1-20020726/include/asm-mips64/mipsregs.h > --- linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/mipsregs.h 2002-06-29 03:02:05.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/include/asm-mips64/mipsregs.h 2002-07-27 22:57:22.000000000 +0000 > @@ -374,6 +374,7 @@ > #define CONF_CM_CACHABLE_CUW 6 > #define CONF_CM_CACHABLE_ACCELERATED 7 > #define CONF_CM_CMASK 7 > +#define CONF_CU (1 << 3) > #define CONF_DB (1 << 4) > #define CONF_IB (1 << 5) > #define CONF_SC (1 << 17) > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/pgtable-bits.h linux-mips-2.4.19-rc1-20020726/include/asm-mips64/pgtable-bits.h > --- linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/pgtable-bits.h 1970-01-01 00:00:00.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/include/asm-mips64/pgtable-bits.h 2002-07-27 23:00:24.000000000 +0000 > @@ -0,0 +1,79 @@ > +/* > + * 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) 1994 - 2001 by Ralf Baechle at alii > + * Copyright (C) 1999, 2000, 2001 Silicon Graphics, Inc. > + * Copyright (C) 2002 Maciej W. Rozycki > + */ > +#ifndef __ASM_MIPS64_PGTABLE_BITS_H > +#define __ASM_MIPS64_PGTABLE_BITS_H > + > +#include > + > +/* > + * Note that we shift the lower 32bits of each EntryLo[01] entry > + * 6 bits to the left. That way we can convert the PFN into the > + * physical address by a single 'and' operation and gain 6 additional > + * bits for storing information which isn't present in a normal > + * MIPS page table. > + * > + * Similar to the Alpha port, we need to keep track of the ref > + * and mod bits in software. We have a software "yeah you can read > + * from this page" bit, and a hardware one which actually lets the > + * process read from the page. On the same token we have a software > + * writable bit and the real hardware one which actually lets the > + * process write to the page, this keeps a mod bit via the hardware > + * dirty bit. > + * > + * Certain revisions of the R4000 and R5000 have a bug where if a > + * certain sequence occurs in the last 3 instructions of an executable > + * page, and the following page is not mapped, the cpu can do > + * unpredictable things. The code (when it is written) to deal with > + * this problem will be in the update_mmu_cache() code for the r4k. > + */ > +#define _PAGE_PRESENT (1<<0) /* implemented in software */ > +#define _PAGE_READ (1<<1) /* implemented in software */ > +#define _PAGE_WRITE (1<<2) /* implemented in software */ > +#define _PAGE_ACCESSED (1<<3) /* implemented in software */ > +#define _PAGE_MODIFIED (1<<4) /* implemented in software */ > +#define _PAGE_R4KBUG (1<<5) /* workaround for r4k bug */ > +#define _PAGE_GLOBAL (1<<6) > +#define _PAGE_VALID (1<<7) > +#define _PAGE_SILENT_READ (1<<7) /* synonym */ > +#define _PAGE_DIRTY (1<<8) /* The MIPS dirty bit */ > +#define _PAGE_SILENT_WRITE (1<<8) > +#define _CACHE_CACHABLE_NO_WA (0<<9) /* R4600 only */ > +#define _CACHE_CACHABLE_WA (1<<9) /* R4600 only */ > +#define _CACHE_UNCACHED (2<<9) /* R4[0246]00 */ > +#define _CACHE_CACHABLE_NONCOHERENT (3<<9) /* R4[0246]00 */ > +#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00MC only */ > +#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00MC only */ > +#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00MC only */ > +#define _CACHE_UNCACHED_ACCELERATED (7<<9) /* R10000 only */ > +#define _CACHE_MASK (7<<9) > + > +#define __READABLE (_PAGE_READ | _PAGE_SILENT_READ | _PAGE_ACCESSED) > +#define __WRITEABLE (_PAGE_WRITE | _PAGE_SILENT_WRITE | _PAGE_MODIFIED) > + > +#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_MODIFIED | _CACHE_MASK) > + > + > +#if defined(CONFIG_MIPS_UNCACHED) > + > +#define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED > + > +#elif defined(CONFIG_CPU_CACHE_COHERENCY) > + > +#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW > + > +#else > + > +#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT > + > +#endif > + > +#define CONF_CM_DEFAULT (PAGE_CACHABLE_DEFAULT >> 9) > + > +#endif /* __ASM_MIPS64_PGTABLE_BITS_H */ > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/pgtable.h linux-mips-2.4.19-rc1-20020726/include/asm-mips64/pgtable.h > --- linux-mips-2.4.19-rc1-20020726.macro/include/asm-mips64/pgtable.h 2002-07-08 16:46:37.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020726/include/asm-mips64/pgtable.h 2002-07-27 23:31:48.000000000 +0000 > @@ -155,64 +155,9 @@ extern void (*_flush_icache_page)(struct > #define VMALLOC_END \ > (VMALLOC_START + ((1 << PGD_ORDER) * PTRS_PER_PTE * PAGE_SIZE)) > > -/* > - * Note that we shift the lower 32bits of each EntryLo[01] entry > - * 6 bits to the left. That way we can convert the PFN into the > - * physical address by a single 'and' operation and gain 6 additional > - * bits for storing information which isn't present in a normal > - * MIPS page table. > - * > - * Similar to the Alpha port, we need to keep track of the ref > - * and mod bits in software. We have a software "yeah you can read > - * from this page" bit, and a hardware one which actually lets the > - * process read from the page. On the same token we have a software > - * writable bit and the real hardware one which actually lets the > - * process write to the page, this keeps a mod bit via the hardware > - * dirty bit. > - * > - * Certain revisions of the R4000 and R5000 have a bug where if a > - * certain sequence occurs in the last 3 instructions of an executable > - * page, and the following page is not mapped, the cpu can do > - * unpredictable things. The code (when it is written) to deal with > - * this problem will be in the update_mmu_cache() code for the r4k. > - */ > -#define _PAGE_PRESENT (1<<0) /* implemented in software */ > -#define _PAGE_READ (1<<1) /* implemented in software */ > -#define _PAGE_WRITE (1<<2) /* implemented in software */ > -#define _PAGE_ACCESSED (1<<3) /* implemented in software */ > -#define _PAGE_MODIFIED (1<<4) /* implemented in software */ > -#define _PAGE_R4KBUG (1<<5) /* workaround for r4k bug */ > -#define _PAGE_GLOBAL (1<<6) > -#define _PAGE_VALID (1<<7) > -#define _PAGE_SILENT_READ (1<<7) /* synonym */ > -#define _PAGE_DIRTY (1<<8) /* The MIPS dirty bit */ > -#define _PAGE_SILENT_WRITE (1<<8) > -#define _CACHE_CACHABLE_NO_WA (0<<9) /* R4600 only */ > -#define _CACHE_CACHABLE_WA (1<<9) /* R4600 only */ > -#define _CACHE_UNCACHED (2<<9) /* R4[0246]00 */ > -#define _CACHE_CACHABLE_NONCOHERENT (3<<9) /* R4[0246]00 */ > -#define _CACHE_CACHABLE_CE (4<<9) /* R4[04]00 only */ > -#define _CACHE_CACHABLE_COW (5<<9) /* R4[04]00 only */ > -#define _CACHE_CACHABLE_CUW (6<<9) /* R4[04]00 only */ > -#define _CACHE_UNCACHED_ACCELERATED (7<<9) /* R10000 only */ > -#define _CACHE_MASK (7<<9) > - > -#define __READABLE (_PAGE_READ | _PAGE_SILENT_READ | _PAGE_ACCESSED) > -#define __WRITEABLE (_PAGE_WRITE | _PAGE_SILENT_WRITE | _PAGE_MODIFIED) > - > -#define _PAGE_CHG_MASK (PAGE_MASK | _PAGE_ACCESSED | _PAGE_MODIFIED | _CACHE_MASK) > - > -#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 */ > -#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW > -#endif /* IP22 */ > -#endif /* UNCACHED */ > +#include > > -#define PAGE_NONE __pgprot(_PAGE_PRESENT | PAGE_CACHABLE_DEFAULT) > +#define PAGE_NONE __pgprot(_PAGE_PRESENT | _CACHE_CACHABLE_NONCOHERENT) > #define PAGE_SHARED __pgprot(_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \ > PAGE_CACHABLE_DEFAULT) > #define PAGE_COPY __pgprot(_PAGE_PRESENT | _PAGE_READ | \ > @@ -222,7 +167,7 @@ extern void (*_flush_icache_page)(struct > #define PAGE_KERNEL __pgprot(_PAGE_PRESENT | __READABLE | __WRITEABLE | \ > _PAGE_GLOBAL | PAGE_CACHABLE_DEFAULT) > #define PAGE_USERIO __pgprot(_PAGE_PRESENT | _PAGE_READ | _PAGE_WRITE | \ > - _CACHE_UNCACHED) > + PAGE_CACHABLE_DEFAULT) > #define PAGE_KERNEL_UNCACHED __pgprot(_PAGE_PRESENT | __READABLE | \ > __WRITEABLE | _PAGE_GLOBAL | _CACHE_UNCACHED) > -- _ _ ____ ___ 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 Aug 1 06:23:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71DNkRw032564 for ; Thu, 1 Aug 2002 06:23:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71DNkxB032563 for linux-mips-outgoing; Thu, 1 Aug 2002 06:23:46 -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 (shaft17-f3.dialo.tiscali.de [62.246.17.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g71DNaRw032554 for ; Thu, 1 Aug 2002 06:23:38 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g71DP0129522; Thu, 1 Aug 2002 15:25:00 +0200 Date: Thu, 1 Aug 2002 15:25:00 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020801152500.A31808@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Jul 29, 2002 at 04:29:35PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Mon, Jul 29, 2002 at 04:29:35PM +0200, Maciej W. Rozycki wrote: > The following patch fixes all the places the default caching policy is > used but various local hacks are coded. Also the sc coherency algorithm > is configured for R4k processors which was previously left as set (or not) > by the firmware. A side effect is is created > and all conditional CPU options are set somehow. Tested on an R4400SC > (for both MIPS and MIPS64) and on an R3400. > > Admittedly, CONF_CM_DEFAULT is defined in a bit weird way, but I couldn't > figure any better one that wouldn't result in a serious but unnecessary > header bloat. If anyone has a better idea, please share any suggestions > here. > > OK to apply? Looks mostly right except that the code in config-shared.in which deciedes if a system is coherent is wrong. Basically it assumes every R10000 or every uniprocessor system is non-coherent and that's wrong. As coherency between CPUs and for DMA I/O is basically the same thing I've changed your code from the use of CONFIG_CPU_CACHE_COHERENCY to CONFIG_NONCOHERENT_IO which did already exist; I don't think we need another config symbol to handle this. Will apply once I did a few test builds and patches the whole thing into 2.5 ... Ralf From owner-linux-mips@oss.sgi.com Thu Aug 1 08:23:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71FNIRw005213 for ; Thu, 1 Aug 2002 08:23:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71FNIXE005212 for linux-mips-outgoing; Thu, 1 Aug 2002 08:23:18 -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.5/8.12.5) with SMTP id g71FMcRw005199; Thu, 1 Aug 2002 08:22:40 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA08910; Thu, 1 Aug 2002 17:24:43 +0200 (MET DST) Date: Thu, 1 Aug 2002 17:24:43 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Carsten Langgaard , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards In-Reply-To: <20020731223158.A6394@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Wed, 31 Jul 2002, Ralf Baechle wrote: > I doublechecked the docs for the R4700 as well - just one cycle needed > between a tlbw and eret. After looking at the generated assembly I discovered the handlers don't fit in 128 bytes. They didn't crash since I have modules disabled for now, so the vmalloc path didn't get hit and the user path happened to fit, but it was pure luck. The path got hit before I fixed a bug in gas though -- that's the explanation of the false cache error exceptions I used to observe. Here is a temporary corrected version I use now. It works, but ultimately the chosen handler should get copied somewhere above KSEG0+0x200. Also the "non_vmalloc" path looks bogus -- k0 gets loaded with a random value from (k1) (if it doesn't happen to fault again), k1 retains the pointer and then both get loaded into the TLB -- intriguing... I believe the patch should get applied for now to avoid surprises. OK? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020726-mips64-tlbex-r4k-2 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/tlbex-r4k.S linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/tlbex-r4k.S --- linux-mips-2.4.19-rc1-20020726.macro/arch/mips64/mm/tlbex-r4k.S 2002-07-25 02:57:02.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020726/arch/mips64/mm/tlbex-r4k.S 2002-07-31 23:20:21.000000000 +0000 @@ -5,6 +5,7 @@ * * Copyright (C) 2000 Silicon Graphics, Inc. * Written by Ulf Carlsson (ulfc@engr.sgi.com) + * Copyright (C) 2002 Maciej W. Rozycki */ #include #include @@ -22,8 +23,7 @@ * After this macro runs we have a pointer to the pte of the address * that caused the fault in in PTR. */ - - .macro LOAD_PTE2, ptr, tmp + .macro LOAD_PTE2, ptr, tmp, kaddr #ifdef CONFIG_SMP dmfc0 \ptr, CP0_CONTEXT dmfc0 \tmp, CP0_BADVADDR @@ -32,8 +32,8 @@ dmfc0 \tmp, CP0_BADVADDR dla \ptr, pgd_current #endif - bltz \tmp, kaddr - ld \ptr, (\ptr) + bltz \tmp, \kaddr + ld \ptr, (\ptr) dsrl \tmp, (PGDIR_SHIFT-3) # get pgd offset in bytes andi \tmp, ((PTRS_PER_PGD - 1)<<3) daddu \ptr, \tmp # add in pgd offset @@ -48,6 +48,35 @@ daddu \ptr, \tmp .endm + + /* + * Ditto for the kernel table. + */ + .macro LOAD_KPTE2, ptr, tmp, not_vmalloc + /* + * First, determine that the address is in/above vmalloc range. + */ + dmfc0 \tmp, CP0_BADVADDR + dli \ptr, VMALLOC_START + + /* + * Now find offset into kptbl. + */ + dsubu \tmp, \tmp, \ptr + dla \ptr, kptbl + dsrl \tmp, (PAGE_SHIFT+1) # get vpn2 + dsll \tmp, 4 # byte offset of pte + daddu \ptr, \ptr, \tmp + + /* + * Determine that fault address is within vmalloc range. + */ + dla \tmp, ekptbl + sltu \tmp, \ptr, \tmp + beqz \tmp, \not_vmalloc # not vmalloc + .endm + + /* * This places the even/odd pte pair in the page table at the pte * entry pointed to by PTE into ENTRYLO0 and ENTRYLO1. @@ -59,6 +88,7 @@ dmtc0 \pte1, CP0_ENTRYLO1 # load it .endm + .text .set noreorder .set mips3 @@ -66,105 +96,93 @@ __INIT .align 5 -FEXPORT(except_vec0) +LEAF(except_vec0) .set noat PANIC("Unused vector called") 1: b 1b nop +END(except_vec0) + + /* + * TLB refill handler for the R4000. + * Attention: We may only use 32 instructions / 128 bytes. + */ .align 5 LEAF(except_vec1_r4k) .set noat - dla k1, pgd_current - dmfc0 k0, CP0_BADVADDR - ld k1, (k1) - bltz k0, vmaddr - dsrl k0, (PGDIR_SHIFT-3) # get pgd offset in bytes - andi k0, ((PTRS_PER_PGD - 1)<<3) - daddu k1, k0 # add in pgd offset - dmfc0 k0, CP0_BADVADDR - ld k1, (k1) # get pmd pointer - dsrl k0, (PMD_SHIFT-3) # get pmd offset in bytes - andi k0, ((PTRS_PER_PMD - 1)<<3) - daddu k1, k0 # add in pmd offset - dmfc0 k0, CP0_XCONTEXT - andi k0, 0xff0 # get pte offset - ld k1, (k1) # get pte pointer - daddu k1, k0 - ld k0, 0(k1) # get even pte - ld k1, 8(k1) # get odd pte - dsrl k0, 6 # convert to entrylo0 - dmtc0 k0, CP0_ENTRYLO0 # load it - dsrl k1, 6 # convert to entrylo1 - dmtc0 k1, CP0_ENTRYLO1 # load it - nop # Need 2 cycles between mtc0 - nop # and tlbwr (CP0 hazard). - tlbwr - nop - eret -vmaddr: - dla k0, handle_vmalloc_address + dla k0, handle_vec1_r4k jr k0 nop END(except_vec1_r4k) - + + __FINIT + + .align 5 +LEAF(handle_vec1_r4k) + .set noat + LOAD_PTE2 k1 k0 9f + ld k0, 0(k1) # get even pte + ld k1, 8(k1) # get odd pte + PTE_RELOAD k0 k1 + b 1f + tlbwr +1: nop + eret + +9: # handle the vmalloc range + LOAD_KPTE2 k1 k0 invalid_vmalloc_address + ld k0, 0(k1) # get even pte + ld k1, 8(k1) # get odd pte + PTE_RELOAD k0 k1 + b 1f + tlbwr +1: nop + eret +END(handle_vec1_r4k) + + __INIT + /* * TLB refill handler for the R10000. * Attention: We may only use 32 instructions / 128 bytes. */ - .align 5 LEAF(except_vec1_r10k) + .set noat + dla k0, handle_vec1_r10k + jr k0 + nop +END(except_vec1_r10k) + + __FINIT + + .align 5 +LEAF(handle_vec1_r10k) .set noat - LOAD_PTE2 k1 k0 + LOAD_PTE2 k1 k0 9f ld k0, 0(k1) # get even pte ld k1, 8(k1) # get odd pte PTE_RELOAD k0 k1 nop tlbwr eret -kaddr: - dla k0, handle_vmalloc_address # MAPPED kernel needs this - jr k0 - nop - END(except_vec1_r10k) - - __FINIT - .align 5 -LEAF(handle_vmalloc_address) - .set noat - /* - * First, determine that the address is in/above vmalloc range. - */ - dmfc0 k0, CP0_BADVADDR - dli k1, VMALLOC_START - - /* - * Now find offset into kptbl. - */ - dsubu k0, k0, k1 - dla k1, kptbl - dsrl k0, (PAGE_SHIFT+1) # get vpn2 - dsll k0, 4 # byte offset of pte - daddu k1, k1, k0 - - /* - * Determine that fault address is within vmalloc range. - */ - dla k0, ekptbl - sltu k0, k1, k0 - beqz k0, not_vmalloc - - /* - * Load cp0 registers. - */ +9: # handle the vmalloc range + LOAD_KPTE2 k1 k0 invalid_vmalloc_address ld k0, 0(k1) # get even pte ld k1, 8(k1) # get odd pte - -not_vmalloc: PTE_RELOAD k0 k1 nop tlbwr eret - END(handle_vmalloc_address) +END(handle_vec1_r10k) + + + .align 5 +LEAF(invalid_vmalloc_address) + .set noat + PANIC("Invalid kernel address") +1: b 1b + nop +END(invalid_vmalloc_address) From owner-linux-mips@oss.sgi.com Thu Aug 1 09:03:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71G3LRw006383 for ; Thu, 1 Aug 2002 09:03:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71G3LNe006382 for linux-mips-outgoing; Thu, 1 Aug 2002 09:03: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.5/8.12.5) with SMTP id g71G3ARw006373; Thu, 1 Aug 2002 09:03:11 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09605; Thu, 1 Aug 2002 18:05:17 +0200 (MET DST) Date: Thu, 1 Aug 2002 18:05:17 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes In-Reply-To: <20020801152500.A31808@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 1 Aug 2002, Ralf Baechle wrote: > Looks mostly right except that the code in config-shared.in which deciedes > if a system is coherent is wrong. Basically it assumes every R10000 or > every uniprocessor system is non-coherent and that's wrong. As coherency > between CPUs and for DMA I/O is basically the same thing I've changed your > code from the use of CONFIG_CPU_CACHE_COHERENCY to CONFIG_NONCOHERENT_IO > which did already exist; I don't think we need another config symbol to > handle this. Will apply once I did a few test builds and patches the > whole thing into 2.5 ... Huh? Coherent caching mode can be used for a few processors only, namely R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones that support the interprocessor coherency protocol. If you know of any other processor that supports the protocol, I'd be pleased to see a reference to a spec -- I hoped someone, possibly you, would fill the missing bits when I proposed the patch a month ago. Nobody bothered, though, sigh... I see your changes are broken conceptually, as the caching mode for the TLB should be inferred from the CPU configuration in the first place and not the system selection (actually it should be best selected ath the run time). Hence I'd invert the flag, since most systems are non-coherent, and only permit it for certain processors. Using a non-coherent configuration for an UP system that supports coherency (do SGI IP27 and SiByte SB1250 have another agent in the chipset that may issue coherent requests regardless of the number of processors started?) results in a performance hit only due to superfluous invalidations, but using a coherent configuration for a processor/system that doesn't support it may lead to a hard to debug hang with no apparent reason (as I wrote previously, even NMI/Reset stopped working on my system -- I had to hit the power switch). I'll cook another patch to fix what got broken. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Aug 1 09:48:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71GmERw007260 for ; Thu, 1 Aug 2002 09:48:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71GmEQr007259 for linux-mips-outgoing; Thu, 1 Aug 2002 09:48: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 (shaft16-f78.dialo.tiscali.de [62.246.16.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g71Gm2Rw007232 for ; Thu, 1 Aug 2002 09:48:04 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g71GnTM23294; Thu, 1 Aug 2002 18:49:29 +0200 Date: Thu, 1 Aug 2002 18:49:29 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020801184929.B22824@dea.linux-mips.net> References: <20020801152500.A31808@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 Thu, Aug 01, 2002 at 06:05:17PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 01, 2002 at 06:05:17PM +0200, Maciej W. Rozycki wrote: > Huh? Coherent caching mode can be used for a few processors only, namely > R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones > that support the interprocessor coherency protocol. If you know of any > other processor that supports the protocol, I'd be pleased to see a > reference to a spec -- I hoped someone, possibly you, would fill the > missing bits when I proposed the patch a month ago. Nobody bothered, > though, sigh... R10000. > I see your changes are broken conceptually, as the caching mode for the > TLB should be inferred from the CPU configuration in the first place and > not the system selection (actually it should be best selected ath the run > time). Hence I'd invert the flag, since most systems are non-coherent, > and only permit it for certain processors. Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO because the noncoherent case needs additional code and in general I'm trying to reduce the number of the #if !defined conditionals for easier readability. The R10000 is our standard example why looking at the processor type doesn't work. It's used in coherent mode in IP27 but in coherent mode but in coherent mode in IP28 or IP32. Otoh I don't know of any system that supports coherency but also is being used with non-coherent processors. > Using a non-coherent > configuration for an UP system that supports coherency (do SGI IP27 and > SiByte SB1250 have another agent in the chipset that may issue coherent > requests regardless of the number of processors started?) Yes. That's how coherency is working - all agents have to support coherent requests or coherency simply won't work. So basically we'd be trully picky we'd have to verify that all agents, processor and other support coherency but just using the system type seems to be sufficient. > results in a > performance hit only due to superfluous invalidations, but using a > coherent configuration for a processor/system that doesn't support it may > lead to a hard to debug hang with no apparent reason (as I wrote > previously, even NMI/Reset stopped working on my system -- I had to hit > the power switch). Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus errors. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 1 10:12:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71HCCRw007767 for ; Thu, 1 Aug 2002 10:12:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71HCC1Q007766 for linux-mips-outgoing; Thu, 1 Aug 2002 10:12: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.5/8.12.5) with SMTP id g71HBwRw007756; Thu, 1 Aug 2002 10:11:59 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA10809; Thu, 1 Aug 2002 19:14:05 +0200 (MET DST) Date: Thu, 1 Aug 2002 19:14:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes In-Reply-To: <20020801184929.B22824@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 1 Aug 2002, Ralf Baechle wrote: > R10000. OK. Any specs anywhere? > Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO > because the noncoherent case needs additional code and in general I'm > trying to reduce the number of the #if !defined conditionals for easier > readability. Hmm, what's wrong with "#ifndef"? Not much less readable than "#ifdef", IMO. > The R10000 is our standard example why looking at the processor type doesn't > work. It's used in coherent mode in IP27 but in coherent mode but in > coherent mode in IP28 or IP32. Otoh I don't know of any system that > supports coherency but also is being used with non-coherent processors. Yep, I suppose so, but the first criterion should be the CPU anyway. Basically: 1. Does the CPU support coherency? 2. If so, does the system? I'm going to express it this way in the config script. > > Using a non-coherent > > configuration for an UP system that supports coherency (do SGI IP27 and > > SiByte SB1250 have another agent in the chipset that may issue coherent > > requests regardless of the number of processors started?) > > Yes. That's how coherency is working - all agents have to support coherent > requests or coherency simply won't work. So basically we'd be trully > picky we'd have to verify that all agents, processor and other support > coherency but just using the system type seems to be sufficient. Well, inferring from docs and my experience it's not needed. A system may simply require areas used for DMA to be marked as non-coherent by CPUs. Often uncached accesses are used to prevent spoiling the caches anyway. > > results in a > > performance hit only due to superfluous invalidations, but using a > > coherent configuration for a processor/system that doesn't support it may > > lead to a hard to debug hang with no apparent reason (as I wrote > > previously, even NMI/Reset stopped working on my system -- I had to hit > > the power switch). > > Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus > errors. Weird, but I accept it as a fact. Still a bus error expresses more than a hang. ;-) -- + 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 Aug 1 10:16:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71HGjRw007880 for ; Thu, 1 Aug 2002 10:16:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71HGjpc007879 for linux-mips-outgoing; Thu, 1 Aug 2002 10:16: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 (shaft16-f78.dialo.tiscali.de [62.246.16.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g71HGdRw007870 for ; Thu, 1 Aug 2002 10:16:40 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g71HI4I23624; Thu, 1 Aug 2002 19:18:04 +0200 Date: Thu, 1 Aug 2002 19:18:04 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Carsten Langgaard , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards Message-ID: <20020801191804.D22824@dea.linux-mips.net> References: <20020731223158.A6394@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 Thu, Aug 01, 2002 at 05:24:43PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 01, 2002 at 05:24:43PM +0200, Maciej W. Rozycki wrote: > After looking at the generated assembly I discovered the handlers don't > fit in 128 bytes. They didn't crash since I have modules disabled for > now, so the vmalloc path didn't get hit and the user path happened to fit, > but it was pure luck. The path got hit before I fixed a bug in gas though > -- that's the explanation of the false cache error exceptions I used to > observe. Ouch. It was a known problem but we simply ignored it for a while as that handler just overwrites the cache error handler which normally should be used extremly rarely, if at all. The problem is somewhat itching by now as we're supporting the SB1 core which in it's revision one may throw spurious cache errors, so the handler is actually used ... Ralf From owner-linux-mips@oss.sgi.com Thu Aug 1 10:57:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71Hv4Rw008707 for ; Thu, 1 Aug 2002 10:57:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71Hv4fb008706 for linux-mips-outgoing; Thu, 1 Aug 2002 10:57:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f78.dialo.tiscali.de [62.246.16.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g71HuqRw008697 for ; Thu, 1 Aug 2002 10:56:53 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g71HwKg24078; Thu, 1 Aug 2002 19:58:20 +0200 Date: Thu, 1 Aug 2002 19:58:20 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020801195820.F22824@dea.linux-mips.net> References: <20020801184929.B22824@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 Thu, Aug 01, 2002 at 07:14:05PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 01, 2002 at 07:14:05PM +0200, Maciej W. Rozycki wrote: > > R10000. > > OK. Any specs anywhere? techpubs.sgi.com should have a somewhat older manual (must have!) and www.necel.com as well. The geniouses at NEC stripped the description of the cache instruction from their manual so it you really want both manuals. > > Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO > > because the noncoherent case needs additional code and in general I'm > > trying to reduce the number of the #if !defined conditionals for easier > > readability. > > Hmm, what's wrong with "#ifndef"? Not much less readable than "#ifdef", > IMO. Just a small detail. Nest conditions several times and the spaghetti starts :-) > Basically: > > 1. Does the CPU support coherency? > > 2. If so, does the system? > > I'm going to express it this way in the config script. Have fun expressing if a R4000 variant supports coherency :-) You can't if you don't want to introduce even more R4000 types or subtypes. > Well, inferring from docs and my experience it's not needed. A system > may simply require areas used for DMA to be marked as non-coherent by > CPUs. Often uncached accesses are used to prevent spoiling the caches > anyway. None such MIPS system known where this is a sensible mode of operation - and I've hacked quite a number of platforms. Anyway, if there were such systems they'd either have to be considered as coherent or as non-coherent. Our current model doesn't permit any finer grained configuration and unless such a system actually exists I don't think we should introduce one. Btw, I've seen a fairly new system in which the non-coherent bits in some agent are not working at all - it's easier to implement that way ... > > Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus > > errors. > > Weird, but I accept it as a fact. Still a bus error expresses more than > a hang. ;-) Not so weired. The system is still operating in coherent mode; that also means the directory caches still think they know where a particular memory address is cached. It's possible to operate an IP27 in non-coherent mode for I/O only by also reconfiguring the whole chipset but that turned out to be always slower and harder to get the software correct, so it's not used except for debugging with a logic analyzer; details are mindbogglingly complex. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 1 11:47:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71IlNRw010018 for ; Thu, 1 Aug 2002 11:47:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71IlNkr010017 for linux-mips-outgoing; Thu, 1 Aug 2002 11:47:23 -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.5/8.12.5) with SMTP id g71IlARw010008; Thu, 1 Aug 2002 11:47:11 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA12348; Thu, 1 Aug 2002 20:49:18 +0200 (MET DST) Date: Thu, 1 Aug 2002 20:49:18 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes In-Reply-To: <20020801195820.F22824@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, 1 Aug 2002, Ralf Baechle wrote: > techpubs.sgi.com should have a somewhat older manual (must have!) and > www.necel.com as well. The geniouses at NEC stripped the description of > the cache instruction from their manual so it you really want both manuals. Thanks for the reference. > > Hmm, what's wrong with "#ifndef"? Not much less readable than "#ifdef", > > IMO. > > Just a small detail. Nest conditions several times and the spaghetti > starts :-) Well, that should be avoided whether the condition is positive or negative. Comments after "#else", "#elif" and "#end" might help a bit if a discipline is kept. > > Basically: > > > > 1. Does the CPU support coherency? > > > > 2. If so, does the system? > > > > I'm going to express it this way in the config script. > > Have fun expressing if a R4000 variant supports coherency :-) You can't > if you don't want to introduce even more R4000 types or subtypes. Who said I don't want to? ;-) Not a big deal at this stage. > None such MIPS system known where this is a sensible mode of operation - > and I've hacked quite a number of platforms. Anyway, if there were such > systems they'd either have to be considered as coherent or as non-coherent. Thanks for the clarification. > Our current model doesn't permit any finer grained configuration and unless > such a system actually exists I don't think we should introduce one. Sure, but a one point we'll have an option to select the model at the run time anyway. At least this is one of goals I'd like to see fulfilled in the future. -- + 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 Aug 1 12:17:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71JHhRw012804 for ; Thu, 1 Aug 2002 12:17:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71JHhu6012803 for linux-mips-outgoing; Thu, 1 Aug 2002 12:17:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from tibook.netx4.com (154-84-51-66.reonbroadband.com [66.51.84.154]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g71JHbRw012790; Thu, 1 Aug 2002 12:17:37 -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 g71JIpv00702; Thu, 1 Aug 2002 15:18:51 -0400 Message-ID: <3D49899B.5080203@embeddededge.com> Date: Thu, 01 Aug 2002 15:18:51 -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: Ralf Baechle CC: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes References: <20020801184929.B22824@dea.linux-mips.net> <20020801195820.F22824@dea.linux-mips.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > Just a small detail. Nest conditions several times and the spaghetti > starts :-) Other cache coherency challenged processor architectures have adopted the same CONFIG_NONCOHERENT_IO configuration option. Some of these could eventually find their way into generic kernel software and clean up the architecture specific code. -- Dan From owner-linux-mips@oss.sgi.com Thu Aug 1 14:17:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g71LHNRw015678 for ; Thu, 1 Aug 2002 14:17:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g71LHN5D015677 for linux-mips-outgoing; Thu, 1 Aug 2002 14:17:23 -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.5/8.12.5) with SMTP id g71LGrRw015666; Thu, 1 Aug 2002 14:16:54 -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 g71LINf12689; Thu, 1 Aug 2002 23:18:23 +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 g71LIOfo012224; Thu, 1 Aug 2002 23:18:24 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17aNKx-0008V5-00; Thu, 01 Aug 2002 23:18:23 +0200 Date: Thu, 1 Aug 2002 23:18:23 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 patch] pci_dma fixes for mips64 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 X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hello, This patch should fix pci_dma_* functions for mips64, especially on non-coherent computers (and fixes a warning). Vivien. --- linux/include/asm-mips64/addrspace.h Thu Aug 1 20:22:00 2002 +++ linux.patch/include/asm-mips64/addrspace.h Thu Aug 1 20:21:54 2002 @@ -58,7 +58,7 @@ #ifndef __ASSEMBLY__ #define PHYSADDR(a) ({ \ - const _ATYPE64_ _a = (a); \ + const _ATYPE64_ _a = _ACAST64_ (a); \ _a == _ACAST32_ _a ? CPHYSADDR(_a) : XPHYSADDR(_a); }) #endif --- linux/include/asm-mips64/scatterlist.h Thu Aug 1 20:12:14 2002 +++ linux.patch/include/asm-mips64/scatterlist.h Thu Aug 1 20:12:01 2002 @@ -4,7 +4,7 @@ struct scatterlist { struct page * page; unsigned int offset; - dma_addr_t dma_address; + dma_addr_t address; unsigned int length; }; --- linux/include/asm-mips64/pci.h Thu Aug 1 21:22:41 2002 +++ linux.patch/include/asm-mips64/pci.h Thu Aug 1 21:37:46 2002 @@ -8,6 +8,7 @@ #include #include +#include /* for page_address() */ #include /* for virt_to_bus() */ #ifdef __KERNEL__ @@ -126,9 +125,11 @@ BUG(); #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)ptr, size); + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv((unsigned long)ptr, size); + } #endif - return virt_to_bus(ptr); + return bus_to_baddr(hwdev, virt_to_bus(ptr)); } /* @@ -145,7 +146,11 @@ if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + dma_cache_wback_inv((unsigned long)bus_to_virt(dma_addr), size); + } +#endif } /* pci_unmap_{page,single} is a nop so... */ @@ -171,10 +176,12 @@ addr = (unsigned long) page_address(page) + offset; #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv(addr, size); + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv(addr, size); + } #endif - return virt_to_bus((void *)addr); + return bus_to_baddr(hwdev, virt_to_bus((void *)addr)); } static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address, @@ -182,7 +189,12 @@ { if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ + +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + dma_cache_wback_inv((unsigned long) bus_to_virt(baddr_to_bus(hwdev, dma_address)), size); + } +#endif } /* @@ -205,17 +217,20 @@ int nents, int direction) { int i; + unsigned long addr; if (direction == PCI_DMA_NONE) BUG(); for (i = 0; i < nents; i++, sg++) { - dma_cache_wback_inv((unsigned long)page_address(sg->page), - sg->length); - sg->address = bus_to_baddr[hwdev->bus->number] + - page_to_bus(sg->page) + sg->offset; + addr = (unsigned long) page_address(sg->page) + sg->offset; +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv(addr, sg->length); + } +#endif + sg->address = bus_to_baddr(hwdev, virt_to_bus((void *)addr)); } - return nents; } @@ -227,10 +242,22 @@ static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { +#ifdef CONFIG_NONCOHERENT_IO + int i; + unsigned long addr; +#endif + if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + for (i = 0; i < nents; i++, sg++) { + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); + } + } +#endif } /* @@ -250,7 +277,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(baddr_to_bus(hwdev, dma_handle)), size); #endif } @@ -267,6 +294,7 @@ { #ifdef CONFIG_NONCOHERENT_IO int i; + unsigned long addr; #endif if (direction == PCI_DMA_NONE) @@ -274,9 +302,10 @@ /* 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)page_address(sg->page), - sg->length); + for (i = 0; i < nelems; i++, sg++) { + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); + } #endif } #endif /* CONFIG_MAPPED_PCI_IO */ --- linux/include/asm-mips64/io.h Thu Aug 1 22:15:19 2002 +++ linux.patch/include/asm-mips64/io.h Thu Aug 1 22:14:57 2002 @@ -35,7 +35,14 @@ #include #endif +#ifdef CONFIG_SGI_IP27 extern unsigned long bus_to_baddr[256]; +#define bus_to_baddr(hwdev, addr) (bus_to_baddr[(hwdev)->bus->number] | (addr)) +#define baddr_to_bus(hwdev, addr) ((addr) - bus_to_baddr[(hwdev)->bus->number]) +#else +#define bus_to_baddr(hwdev, addr) (addr) +#define baddr_to_bus(hwdev, addr) (addr) +#endif /* * Slowdown I/O port space accesses for antique hardware. From owner-linux-mips@oss.sgi.com Thu Aug 1 17:08:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7208URw019265 for ; Thu, 1 Aug 2002 17:08:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7208Umu019264 for linux-mips-outgoing; Thu, 1 Aug 2002 17:08:30 -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.5/8.12.5) with SMTP id g7207jRw019253; Thu, 1 Aug 2002 17:07:46 -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 g7209Ef19456; Fri, 2 Aug 2002 02:09:14 +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 g7209Ffo018150; Fri, 2 Aug 2002 02:09:15 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17aQ0I-0003yM-00; Fri, 02 Aug 2002 02:09:14 +0200 Date: Fri, 2 Aug 2002 02:09:13 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] pci_dma fixes, 2nd try.. 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 X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi, Here is a patch to fix pci_dma_* functions for both mips64 and mips. It adds cache flushes when unmapping if the transfer was from device for non-coherent systems, and abstracts the use of bus_to_baddr. The resulting patched pci.h in include/asm-mips64 should work for include/asm-mips as well (I've merged code, but couldn't test). Vivien. --- linux/include/asm-mips64/addrspace.h Thu Aug 1 20:22:00 2002 +++ linux.patch/include/asm-mips64/addrspace.h Thu Aug 1 20:21:54 2002 @@ -58,7 +58,7 @@ #ifndef __ASSEMBLY__ #define PHYSADDR(a) ({ \ - const _ATYPE64_ _a = (a); \ + const _ATYPE64_ _a = _ACAST64_ (a); \ _a == _ACAST32_ _a ? CPHYSADDR(_a) : XPHYSADDR(_a); }) #endif --- linux/include/asm-mips/io.h Wed Jul 24 01:03:20 2002 +++ linux.patch/include/asm-mips/io.h Fri Aug 2 01:05:57 2002 @@ -19,6 +19,15 @@ #include #include +#ifdef CONFIG_SGI_IP27 + extern unsigned long bus_to_baddr[256]; +#define bus_to_baddr(hwdev, addr) (bus_to_baddr[(hwdev)->bus->number] | (addr)) +#define baddr_to_bus(hwdev, addr) ((addr) - bus_to_baddr[(hwdev)->bus->number]) +#else +#define bus_to_baddr(hwdev, addr) (addr) +#define baddr_to_bus(hwdev, addr) (addr) +#endif + /* * Slowdown I/O port space accesses for antique hardware. */ --- linux/include/asm-mips64/io.h Thu Aug 1 22:15:19 2002 +++ linux.patch/include/asm-mips64/io.h Thu Aug 1 22:14:57 2002 @@ -35,7 +35,14 @@ #include #endif +#ifdef CONFIG_SGI_IP27 extern unsigned long bus_to_baddr[256]; +#define bus_to_baddr(hwdev, addr) (bus_to_baddr[(hwdev)->bus->number] | (addr)) +#define baddr_to_bus(hwdev, addr) ((addr) - bus_to_baddr[(hwdev)->bus->number]) +#else +#define bus_to_baddr(hwdev, addr) (addr) +#define baddr_to_bus(hwdev, addr) (addr) +#endif /* * Slowdown I/O port space accesses for antique hardware. --- linux/include/asm-mips64/pci.h Fri Aug 2 01:17:31 2002 +++ linux.patch/include/asm-mips64/pci.h Fri Aug 2 01:20:04 2002 @@ -8,6 +8,7 @@ #include #include +#include /* for page_address() */ #include /* for virt_to_bus() */ #ifdef __KERNEL__ @@ -47,6 +48,13 @@ #include #include +#if defined(CONFIG_DDB5074) || defined(CONFIG_DDB5476) +#undef PCIBIOS_MIN_IO +#undef PCIBIOS_MIN_MEM +#define PCIBIOS_MIN_IO 0x0100000 +#define PCIBIOS_MIN_MEM 0x1000000 +#endif + struct pci_dev; /* @@ -79,6 +87,19 @@ extern void pci_free_consistent(struct pci_dev *hwdev, size_t size, void *vaddr, dma_addr_t dma_handle); +/* pci_unmap_{single,page} is not a nop, thus... */ +#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) \ + dma_addr_t ADDR_NAME; +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) \ + __u32 LEN_NAME; +#define pci_unmap_addr(PTR, ADDR_NAME) \ + ((PTR)->ADDR_NAME) +#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) \ + (((PTR)->ADDR_NAME) = (VAL)) +#define pci_unmap_len(PTR, LEN_NAME) \ + ((PTR)->LEN_NAME) +#define pci_unmap_len_set(PTR, LEN_NAME, VAL) \ + (((PTR)->LEN_NAME) = (VAL)) #ifdef CONFIG_MAPPED_PCI_IO @@ -95,20 +116,6 @@ extern void pci_dma_sync_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nelems, int direction); -/* pci_unmap_{single,page} is not a nop, thus... */ -#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) \ - dma_addr_t ADDR_NAME; -#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) \ - __u32 LEN_NAME; -#define pci_unmap_addr(PTR, ADDR_NAME) \ - ((PTR)->ADDR_NAME) -#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) \ - (((PTR)->ADDR_NAME) = (VAL)) -#define pci_unmap_len(PTR, LEN_NAME) \ - ((PTR)->LEN_NAME) -#define pci_unmap_len_set(PTR, LEN_NAME, VAL) \ - (((PTR)->LEN_NAME) = (VAL)) - #else /* CONFIG_MAPPED_PCI_IO */ /* @@ -125,9 +132,11 @@ BUG(); #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv((unsigned long)ptr, size); + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv((unsigned long)ptr, size); + } #endif - return virt_to_bus(ptr); + return bus_to_baddr(hwdev, virt_to_bus(ptr)); } /* @@ -144,17 +153,13 @@ if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + dma_cache_wback_inv((unsigned long)bus_to_virt(baddr_to_bus(hwdev, dma_addr)), size); + } +#endif } -/* pci_unmap_{page,single} is a nop so... */ -#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) -#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) -#define pci_unmap_addr(PTR, ADDR_NAME) (0) -#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) -#define pci_unmap_len(PTR, LEN_NAME) (0) -#define pci_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) - /* * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t. identical * to pci_map_single, but takes a struct page instead of a virtual address @@ -170,10 +175,12 @@ addr = (unsigned long) page_address(page) + offset; #ifdef CONFIG_NONCOHERENT_IO - dma_cache_wback_inv(addr, size); + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv(addr, size); + } #endif - return virt_to_bus((void *)addr); + return bus_to_baddr(hwdev, virt_to_bus((void *)addr)); } static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address, @@ -181,7 +188,12 @@ { if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ + +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + dma_cache_wback_inv((unsigned long) bus_to_virt(baddr_to_bus(hwdev, dma_address)), size); + } +#endif } /* @@ -204,17 +216,20 @@ int nents, int direction) { int i; + unsigned long addr; if (direction == PCI_DMA_NONE) BUG(); for (i = 0; i < nents; i++, sg++) { - dma_cache_wback_inv((unsigned long)page_address(sg->page), - sg->length); - sg->address = bus_to_baddr[hwdev->bus->number] + - page_to_bus(sg->page) + sg->offset; + addr = (unsigned long) page_address(sg->page) + sg->offset; +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_FROMDEVICE) { + dma_cache_wback_inv(addr, sg->length); + } +#endif + sg->dma_address = bus_to_baddr(hwdev, virt_to_bus((void *)addr)); } - return nents; } @@ -226,10 +241,22 @@ static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { +#ifdef CONFIG_NONCOHERENT_IO + int i; + unsigned long addr; +#endif + if (direction == PCI_DMA_NONE) BUG(); - /* Nothing to do */ +#ifdef CONFIG_NONCOHERENT_IO + if (direction != PCI_DMA_TODEVICE) { + for (i = 0; i < nents; i++, sg++) { + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); + } + } +#endif } /* @@ -249,7 +276,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(baddr_to_bus(hwdev, dma_handle)), size); #endif } @@ -266,6 +293,7 @@ { #ifdef CONFIG_NONCOHERENT_IO int i; + unsigned long addr; #endif if (direction == PCI_DMA_NONE) @@ -273,13 +301,19 @@ /* 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)page_address(sg->page), - sg->length); + for (i = 0; i < nelems; i++, sg++) { + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); + } #endif } #endif /* CONFIG_MAPPED_PCI_IO */ +/* Return whether the given PCI device DMA address mask can + * be supported properly. For example, if your device can + * only drive the low 24-bits during PCI bus mastering, then + * you would pass 0x00ffffff as the mask to this function. + */ static inline int pci_dma_supported(struct pci_dev *hwdev, u64 mask) { /* @@ -329,6 +363,30 @@ } #endif +#if defined(CONFIG_MAPPED_PCI_IO) || defined(CONFIG_NONCOHERENT_IO) +/* pci_unmap_{single,page} is not a nop, thus... */ +#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) \ + dma_addr_t ADDR_NAME; +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) \ + __u32 LEN_NAME; +#define pci_unmap_addr(PTR, ADDR_NAME) \ + ((PTR)->ADDR_NAME) +#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) \ + (((PTR)->ADDR_NAME) = (VAL)) +#define pci_unmap_len(PTR, LEN_NAME) \ + ((PTR)->LEN_NAME) +#define pci_unmap_len_set(PTR, LEN_NAME, VAL) \ + (((PTR)->LEN_NAME) = (VAL)) +#else +/* pci_unmap_{page,single} is a nop so... */ +#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) +#define pci_unmap_addr(PTR, ADDR_NAME) (0) +#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) +#define pci_unmap_len(PTR, LEN_NAME) (0) +#define pci_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) +#endif + /* * Return the index of the PCI controller for device. */ @@ -341,7 +399,7 @@ * returns, or alternatively stop on the first sg_dma_len(sg) which * is 0. */ -#define sg_dma_address(sg) ((sg)->address) +#define sg_dma_address(sg) ((sg)->dma_address) #define sg_dma_len(sg) ((sg)->length) #endif /* __KERNEL__ */ From owner-linux-mips@oss.sgi.com Thu Aug 1 18:27:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g721RuRw020791 for ; Thu, 1 Aug 2002 18:27:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g721RuCf020790 for linux-mips-outgoing; Thu, 1 Aug 2002 18:27:56 -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.5/8.12.5) with SMTP id g721RnRw020781; Thu, 1 Aug 2002 18:27:49 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.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 SAA07213; Thu, 1 Aug 2002 18:29: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 17aJLz-001gBd-00; Thu, 01 Aug 2002 19:03:11 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17aJPV-00074A-00; Thu, 01 Aug 2002 19:06:49 +0200 Date: Thu, 1 Aug 2002 19:06:49 +0200 To: Ralf Baechle Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020801170649.GB15334@rembrandt.csv.ica.uni-stuttgart.de> References: <20020801152500.A31808@dea.linux-mips.net> <20020801184929.B22824@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020801184929.B22824@dea.linux-mips.net> User-Agent: Mutt/1.4i From: Thiemo Seufer X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: [snip] > Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO > because the noncoherent case needs additional code and in general I'm > trying to reduce the number of the #if !defined conditionals for easier > readability. > > The R10000 is our standard example why looking at the processor type doesn't > work. It's used in coherent mode in IP27 but in coherent mode but in > coherent mode in IP28 or IP32. Otoh I don't know of any system that JFTR: non-coherent mode in IP28 or IP32. Thiemo From owner-linux-mips@oss.sgi.com Fri Aug 2 01:09:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7289tRw027619 for ; Fri, 2 Aug 2002 01:09:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7289t8t027618 for linux-mips-outgoing; Fri, 2 Aug 2002 01:09: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 (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7289dRw027606; Fri, 2 Aug 2002 01:09:39 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g728ASXb029216; Fri, 2 Aug 2002 01:10:28 -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 BAA06717; Fri, 2 Aug 2002 01:10: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 g728AOb06191; Fri, 2 Aug 2002 10:10:25 +0200 (MEST) Message-ID: <3D4A3E68.E330BA7A@mips.com> Date: Fri, 02 Aug 2002 10:10: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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "Maciej W. Rozycki" wrote: > On Thu, 1 Aug 2002, Ralf Baechle wrote: > > > Looks mostly right except that the code in config-shared.in which deciedes > > if a system is coherent is wrong. Basically it assumes every R10000 or > > every uniprocessor system is non-coherent and that's wrong. As coherency > > between CPUs and for DMA I/O is basically the same thing I've changed your > > code from the use of CONFIG_CPU_CACHE_COHERENCY to CONFIG_NONCOHERENT_IO > > which did already exist; I don't think we need another config symbol to > > handle this. Will apply once I did a few test builds and patches the > > whole thing into 2.5 ... > > Huh? Coherent caching mode can be used for a few processors only, namely > R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones > that support the interprocessor coherency protocol. If you know of any > other processor that supports the protocol, I'd be pleased to see a > reference to a spec -- I hoped someone, possibly you, would fill the > missing bits when I proposed the patch a month ago. Nobody bothered, > though, sigh... The 20Kc has support for cache coherency, but it doesn't support Coherent Update on Write (CUW), it only support Coherent exclusive (CE). The way I implemented the coherency support locally, was I used a boot option (coherency), where I could tell whether I wanted to run coherent or not. The dma cache routines would then either be the normal (non-coherent version) or a empty function. As my system (a Malta board) can have different daughter cards attached, I can have different CPUs and system controllers and I really like the idea, that I can run the same kernel on all the different system setups. So if the kernel was started with the "coherency" option, I checked whether or not the CPU and system controller has support for coherency or not, if one or both didn't support coherency, I die telling the user that the system didn't support coherency. In both the coherency and non-coherency case, I used the write-back non-coherent cache attribute, as the 20Kc still responses to Intervention and Invalidate request from the system controller. The coherent exclusive cache attribute is really only needed in multi CPU systems. I don't know if other CPU works the same way as the 20Kc. > > I see your changes are broken conceptually, as the caching mode for the > TLB should be inferred from the CPU configuration in the first place and > not the system selection (actually it should be best selected ath the run > time). Hence I'd invert the flag, since most systems are non-coherent, > and only permit it for certain processors. Using a non-coherent > configuration for an UP system that supports coherency (do SGI IP27 and > SiByte SB1250 have another agent in the chipset that may issue coherent > requests regardless of the number of processors started?) results in a > performance hit only due to superfluous invalidations, but using a > coherent configuration for a processor/system that doesn't support it may > lead to a hard to debug hang with no apparent reason (as I wrote > previously, even NMI/Reset stopped working on my system -- I had to hit > the power switch). > > I'll cook another patch to fix what got broken. > > Maciej > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + -- _ _ ____ ___ 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 Fri Aug 2 01:23:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g728NFRw027790 for ; Fri, 2 Aug 2002 01:23:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g728NF8S027789 for linux-mips-outgoing; Fri, 2 Aug 2002 01:23:15 -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.5/8.12.5) with SMTP id g728N3Rw027779; Fri, 2 Aug 2002 01:23:03 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g728NsXb029243; Fri, 2 Aug 2002 01:23: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 BAA07040; Fri, 2 Aug 2002 01:23:53 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g728Nrb07296; Fri, 2 Aug 2002 10:23:53 +0200 (MEST) Message-ID: <3D4A4191.DF5EFFC4@mips.com> Date: Fri, 02 Aug 2002 10:23:53 +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: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes References: <20020801152500.A31808@dea.linux-mips.net> <20020801184929.B22824@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Aug 01, 2002 at 06:05:17PM +0200, Maciej W. Rozycki wrote: > > > Huh? Coherent caching mode can be used for a few processors only, namely > > R4[04]00MC and presumably SB1 (inferred from the sources), i.e. the ones > > that support the interprocessor coherency protocol. If you know of any > > other processor that supports the protocol, I'd be pleased to see a > > reference to a spec -- I hoped someone, possibly you, would fill the > > missing bits when I proposed the patch a month ago. Nobody bothered, > > though, sigh... > > R10000. > > > I see your changes are broken conceptually, as the caching mode for the > > TLB should be inferred from the CPU configuration in the first place and > > not the system selection (actually it should be best selected ath the run > > time). Hence I'd invert the flag, since most systems are non-coherent, > > and only permit it for certain processors. > > Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO > because the noncoherent case needs additional code and in general I'm > trying to reduce the number of the #if !defined conditionals for easier > readability. > > The R10000 is our standard example why looking at the processor type doesn't > work. It's used in coherent mode in IP27 but in coherent mode but in > coherent mode in IP28 or IP32. Otoh I don't know of any system that > supports coherency but also is being used with non-coherent processors. > > > Using a non-coherent > > configuration for an UP system that supports coherency (do SGI IP27 and > > SiByte SB1250 have another agent in the chipset that may issue coherent > > requests regardless of the number of processors started?) > > Yes. That's how coherency is working - all agents have to support coherent > requests or coherency simply won't work. So basically we'd be trully > picky we'd have to verify that all agents, processor and other support > coherency but just using the system type seems to be sufficient. > The Malta board is a system that both run coherent and non-coherent, so I would prefer, that we either make the coherency a configuration option or make it possible to determine at run time. > > > results in a > > performance hit only due to superfluous invalidations, but using a > > coherent configuration for a processor/system that doesn't support it may > > lead to a hard to debug hang with no apparent reason (as I wrote > > previously, even NMI/Reset stopped working on my system -- I had to hit > > the power switch). > > Using a non-coherent mode on IP27 may result in nice, hard to trackdown bus > errors. > > 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 Fri Aug 2 01:35:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g728Z7Rw027944 for ; Fri, 2 Aug 2002 01:35:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g728Z700027943 for linux-mips-outgoing; Fri, 2 Aug 2002 01:35:07 -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.5/8.12.5) with SMTP id g728Z0Rw027930; Fri, 2 Aug 2002 01:35:01 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA24499; Fri, 2 Aug 2002 10:36:58 +0200 (MET DST) Date: Fri, 2 Aug 2002 10:36:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes In-Reply-To: <3D4A4191.DF5EFFC4@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, 2 Aug 2002, Carsten Langgaard wrote: > The Malta board is a system that both run coherent and non-coherent, so I would > prefer, that we either make the coherency a configuration option or make it > possible to determine at run time. The latter, definitely. -- + 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 Aug 2 02:31:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g729VbRw029891 for ; Fri, 2 Aug 2002 02:31:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g729Vbam029890 for linux-mips-outgoing; Fri, 2 Aug 2002 02:31:37 -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.5/8.12.5) with SMTP id g729VTRw029880; Fri, 2 Aug 2002 02:31:29 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g729WLXb029430; Fri, 2 Aug 2002 02:32:21 -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 CAA08503; Fri, 2 Aug 2002 02:32:19 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g729WJb12022; Fri, 2 Aug 2002 11:32:19 +0200 (MEST) Message-ID: <3D4A519B.3EF5459@mips.com> Date: Fri, 02 Aug 2002 11:32:18 +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: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards References: <20020731223158.A6394@dea.linux-mips.net> <20020801191804.D22824@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Thu, Aug 01, 2002 at 05:24:43PM +0200, Maciej W. Rozycki wrote: > > > After looking at the generated assembly I discovered the handlers don't > > fit in 128 bytes. They didn't crash since I have modules disabled for > > now, so the vmalloc path didn't get hit and the user path happened to fit, > > but it was pure luck. The path got hit before I fixed a bug in gas though > > -- that's the explanation of the false cache error exceptions I used to > > observe. > > Ouch. It was a known problem but we simply ignored it for a while as that > handler just overwrites the cache error handler which normally should be > used extremly rarely, if at all. The problem is somewhat itching by now > as we're supporting the SB1 core which in it's revision one may throw > spurious cache errors, so the handler is actually used ... > Maybe it's time for some intelligent check for the size of these exception routine. /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 Fri Aug 2 03:14:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72AEjRw030321 for ; Fri, 2 Aug 2002 03:14:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72AEjYC030320 for linux-mips-outgoing; Fri, 2 Aug 2002 03:14: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 (shaft17-f126.dialo.tiscali.de [62.246.17.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72AEcRw030310 for ; Fri, 2 Aug 2002 03:14:40 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g72AG0H03001; Fri, 2 Aug 2002 12:16:00 +0200 Date: Fri, 2 Aug 2002 12:16:00 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020802121600.A27824@dea.linux-mips.net> References: <20020801152500.A31808@dea.linux-mips.net> <20020801184929.B22824@dea.linux-mips.net> <20020801170649.GB15334@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: <20020801170649.GB15334@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Thu, Aug 01, 2002 at 07:06:49PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Thu, Aug 01, 2002 at 07:06:49PM +0200, Thiemo Seufer wrote: > [snip] > > Back in time I prefered CONFIG_NONCOHERENT_IO over CONFIG_COHERENT_IO > > because the noncoherent case needs additional code and in general I'm > > trying to reduce the number of the #if !defined conditionals for easier > > readability. > > > > The R10000 is our standard example why looking at the processor type doesn't > > work. It's used in coherent mode in IP27 but in coherent mode but in > > coherent mode in IP28 or IP32. Otoh I don't know of any system that > > JFTR: non-coherent mode in IP28 or IP32. Yep, you're right. I hope everybody concluded that from my non-coherent sentence ;-) From owner-linux-mips@oss.sgi.com Fri Aug 2 03:36:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72AagRw030510 for ; Fri, 2 Aug 2002 03:36:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72Aagiw030509 for linux-mips-outgoing; Fri, 2 Aug 2002 03:36:42 -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 (shaft17-f126.dialo.tiscali.de [62.246.17.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72AaaRw030500 for ; Fri, 2 Aug 2002 03:36:38 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g72Ac5a03412; Fri, 2 Aug 2002 12:38:05 +0200 Date: Fri, 2 Aug 2002 12:38:05 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes Message-ID: <20020802123805.A3329@dea.linux-mips.net> References: <20020801152500.A31808@dea.linux-mips.net> <20020801184929.B22824@dea.linux-mips.net> <3D4A4191.DF5EFFC4@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: <3D4A4191.DF5EFFC4@mips.com>; from carstenl@mips.com on Fri, Aug 02, 2002 at 10:23:53AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 02, 2002 at 10:23:53AM +0200, Carsten Langgaard wrote: > The Malta board is a system that both run coherent and non-coherent, so I > would prefer, that we either make the coherency a configuration option or > make it possible to determine at run time. Definately the latter then. The price to pay is small and I don't think forcing the use to change the kernel when just changing CPU modules is acceptable. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 2 04:04:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72B4cRw031157 for ; Fri, 2 Aug 2002 04:04:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72B4cGj031156 for linux-mips-outgoing; Fri, 2 Aug 2002 04:04:38 -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 (shaft17-f74.dialo.tiscali.de [62.246.17.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72B4TRw031144 for ; Fri, 2 Aug 2002 04:04:31 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g72B5qj03625; Fri, 2 Aug 2002 13:05:52 +0200 Date: Fri, 2 Aug 2002 13:05:52 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards Message-ID: <20020802130552.C27824@dea.linux-mips.net> References: <20020731223158.A6394@dea.linux-mips.net> <20020801191804.D22824@dea.linux-mips.net> <3D4A519B.3EF5459@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: <3D4A519B.3EF5459@mips.com>; from carstenl@mips.com on Fri, Aug 02, 2002 at 11:32:18AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 02, 2002 at 11:32:18AM +0200, Carsten Langgaard wrote: > > > After looking at the generated assembly I discovered the handlers don't > > > fit in 128 bytes. They didn't crash since I have modules disabled for > > > now, so the vmalloc path didn't get hit and the user path happened to fit, > > > but it was pure luck. The path got hit before I fixed a bug in gas though > > > -- that's the explanation of the false cache error exceptions I used to > > > observe. > > > > Ouch. It was a known problem but we simply ignored it for a while as that > > handler just overwrites the cache error handler which normally should be > > used extremly rarely, if at all. The problem is somewhat itching by now > > as we're supporting the SB1 core which in it's revision one may throw > > spurious cache errors, so the handler is actually used ... > > > > Maybe it's time for some intelligent check for the size of these exception > routine. Easy trick at compile time which will just inflate the object code a little bit: .align 5 LEAF(except_vec1_r4k) [...] END(except_vec1_r4k) .org except_vec1_r4k + 0x80 This will result in an assembler error if the body of the except_vec1_r4k function is bigger than 0x80. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 2 04:08:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72B8tRw031369 for ; Fri, 2 Aug 2002 04:08:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72B8tFe031368 for linux-mips-outgoing; Fri, 2 Aug 2002 04:08: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.5/8.12.5) with SMTP id g72B8iRw031359; Fri, 2 Aug 2002 04:08:45 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g72B9bXb029611; Fri, 2 Aug 2002 04:09:37 -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 EAA10346; Fri, 2 Aug 2002 04:09: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 g72B9ab18657; Fri, 2 Aug 2002 13:09:36 +0200 (MEST) Message-ID: <3D4A6868.FBBB36CB@mips.com> Date: Fri, 02 Aug 2002 13:09:35 +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: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] MIPS64 R4k TLB refill CP0 hazards References: <20020731223158.A6394@dea.linux-mips.net> <20020801191804.D22824@dea.linux-mips.net> <3D4A519B.3EF5459@mips.com> <20020802130552.C27824@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralf Baechle wrote: > On Fri, Aug 02, 2002 at 11:32:18AM +0200, Carsten Langgaard wrote: > > > > > After looking at the generated assembly I discovered the handlers don't > > > > fit in 128 bytes. They didn't crash since I have modules disabled for > > > > now, so the vmalloc path didn't get hit and the user path happened to fit, > > > > but it was pure luck. The path got hit before I fixed a bug in gas though > > > > -- that's the explanation of the false cache error exceptions I used to > > > > observe. > > > > > > Ouch. It was a known problem but we simply ignored it for a while as that > > > handler just overwrites the cache error handler which normally should be > > > used extremly rarely, if at all. The problem is somewhat itching by now > > > as we're supporting the SB1 core which in it's revision one may throw > > > spurious cache errors, so the handler is actually used ... > > > > > > > Maybe it's time for some intelligent check for the size of these exception > > routine. > > Easy trick at compile time which will just inflate the object code a little > bit: > > .align 5 > LEAF(except_vec1_r4k) > [...] > END(except_vec1_r4k) > .org except_vec1_r4k + 0x80 > > This will result in an assembler error if the body of the except_vec1_r4k > function is bigger than 0x80. > Great idea, please put it in the code. /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 Fri Aug 2 04:46:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72BkRRw031723 for ; Fri, 2 Aug 2002 04:46:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72BkQSb031722 for linux-mips-outgoing; Fri, 2 Aug 2002 04:46:26 -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.5/8.12.5) with SMTP id g72BkMRw031713 for ; Fri, 2 Aug 2002 04:46:23 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g72BlsXb029707 for ; Fri, 2 Aug 2002 04:47: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 EAA11032 for ; Fri, 2 Aug 2002 04:47:55 -0700 (PDT) Received: from coplin18.mips.com (IDENT:dant@coplin18 [192.168.205.88]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g72Blsb20538 for ; Fri, 2 Aug 2002 13:47:55 +0200 (MEST) Date: Fri, 2 Aug 2002 13:47:54 +0200 (CEST) From: Dan Temple To: linux-mips@oss.sgi.com Subject: Web pages at http://www.linux-mips.org now online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The http://www.linux-mips.org/ webpages now reflect the latest FAQ from CVS. /Dan From owner-linux-mips@oss.sgi.com Fri Aug 2 10:05:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72H5kRw009038 for ; Fri, 2 Aug 2002 10:05:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72H5knE009037 for linux-mips-outgoing; Fri, 2 Aug 2002 10:05:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72H5eRw009015 for ; Fri, 2 Aug 2002 10:05:40 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020802170715.FPMM22139.rwcrmhc52.attbi.com@ocean.lucon.org>; Fri, 2 Aug 2002 17:07:15 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id E4E49125D2; Fri, 2 Aug 2002 10:07:14 -0700 (PDT) Date: Fri, 2 Aug 2002 10:07:14 -0700 From: "H. J. Lu" To: Carsten Langgaard Cc: linux-mips@oss.sgi.com Subject: Today's OSS doesn't work on Malta Message-ID: <20020802100714.A4669@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk The 2.4 kernel from today's OSS doesn't work on Malta. I got hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, (U)DMA Partition check: hda:<1>Unable to handle kernel paging request at virtual address 611c2000, epc4 Oops in fault.c::do_page_fault, line 206: $0 : 00000000 1000fc00 00000001 00001000 00001000 00001000 81191000 00000001 $8 : 811c0000 81199000 00000001 00008000 00010000 802d1358 00000000 00000080 $16: 611c2000 00000001 802d1338 00000000 00000000 00000008 00000000 00000000 $24: 0000000a 811ddd91 8027a000 8027bd10 8009e0d0 801eaa24 Hi : 0000004f Lo : df328000 epc : 801eaa98 Not tainted Status: 1000fc03 Cause : 0080000c Process swapper (pid: 0, stackpage=8027a000) Stack: 8027bd08 8027bd08 802b5c20 00000000 00001240 802d12c8 802d1338 801eb170 0000000e 00000001 b8000000 802d1338 81198320 802d1338 81198320 802d12c8 0000000e 00000001 801efc14 1000fc00 811dde48 802d1338 811dddd0 802d12c8 0000000e 00000001 801e3ca8 802d12c8 8027bd88 1000fc00 8027bde0 1000fc00 00000000 802d1338 81198320 801e406c 1000fc00 802d12c8 801e93e4 00000000 00000003 ... Call Trace: [<801eb170>] [<801efc14>] [<801e3ca8>] [<801e406c>] [<801e93e4>] [<] [<801db1b4>] [<801e44ec>] [<801e3008>] [<8012ea04>] [<801e9290>] [<801e4be8>] [<80109690>] [<80109970>] [<8010ae3c>] [<80254554>] [<80254d10>] [<80254860>] [<801089a4>] [<80102e40>] [<80102e9c>] [<80102e44>] [<8010042c>] [<80255800>] Code: 54e00001 00a02021 3083ffff 00a42823 14600008 26100004 263 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing From owner-linux-mips@oss.sgi.com Fri Aug 2 10:18:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72HI9Rw009407 for ; Fri, 2 Aug 2002 10:18:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72HI9DS009406 for linux-mips-outgoing; Fri, 2 Aug 2002 10:18:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from hermod.qsicorp.com (mail.qsicorp.com [216.190.147.34]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72HI1Rw009394 for ; Fri, 2 Aug 2002 10:18:02 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by hermod.qsicorp.com (Postfix) with ESMTP id A974B17086; Fri, 2 Aug 2002 11:19:41 -0600 (MDT) Received: from hermod.qsicorp.com ([127.0.0.1]) by localhost (hermod.qsicorp.com [127.0.0.1]) (amavisd-new) with ESMTP id 08180-02; Fri, 2 Aug 2002 11:19:39 -0000 (MDT) Received: from qsicorp.com (computer195.qsicorp.com [216.190.147.195]) by hermod.qsicorp.com (Postfix) with ESMTP id BC2EA1708B; Fri, 2 Aug 2002 11:19:39 -0600 (MDT) Message-ID: <3D4ACD9D.AB3FC45C@qsicorp.com> Date: Fri, 02 Aug 2002 11:21:17 -0700 From: Ryan Martindale X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "H. J. Lu" Cc: linux-mips@oss.sgi.com Subject: Re: Today's OSS doesn't work on Malta References: <20020802100714.A4669@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 X-Razor-id: f0502936caa018079f35f3e1a07b67ea3f4a8052 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk "H. J. Lu" wrote: > > The 2.4 kernel from today's OSS doesn't work on Malta. I got > > hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, (U)DMA > Partition check: > hda:<1>Unable to handle kernel paging request at virtual address 611c2000, > epc4 > Oops in fault.c::do_page_fault, line 206: > $0 : 00000000 1000fc00 00000001 00001000 00001000 00001000 81191000 00000001 > $8 : 811c0000 81199000 00000001 00008000 00010000 802d1358 00000000 00000080 > $16: 611c2000 00000001 802d1338 00000000 00000000 00000008 00000000 00000000 > $24: 0000000a 811ddd91 8027a000 8027bd10 8009e0d0 801eaa24 > Hi : 0000004f > Lo : df328000 > epc : 801eaa98 Not tainted > Status: 1000fc03 > Cause : 0080000c > Process swapper (pid: 0, stackpage=8027a000) > Stack: 8027bd08 8027bd08 802b5c20 00000000 00001240 802d12c8 802d1338 801eb170 > 0000000e 00000001 b8000000 802d1338 81198320 802d1338 81198320 802d12c8 > 0000000e 00000001 801efc14 1000fc00 811dde48 802d1338 811dddd0 802d12c8 > 0000000e 00000001 801e3ca8 802d12c8 8027bd88 1000fc00 8027bde0 1000fc00 > 00000000 802d1338 81198320 801e406c 1000fc00 802d12c8 801e93e4 00000000 > 00000003 ... > Call Trace: [<801eb170>] [<801efc14>] [<801e3ca8>] [<801e406c>] [<801e93e4>] > [<] > [<801db1b4>] [<801e44ec>] [<801e3008>] [<8012ea04>] [<801e9290>] [<801e4be8>] > [<80109690>] [<80109970>] [<8010ae3c>] [<80254554>] [<80254d10>] [<80254860>] > [<801089a4>] [<80102e40>] [<80102e9c>] [<80102e44>] [<8010042c>] [<80255800>] > > Code: 54e00001 00a02021 3083ffff 00a42823 14600008 26100004 263 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing Looks like what I was dealing with - check process.c patch I submitted a couple of days ago (gp doesn't get set to the appropriate type of structure). Ryan From owner-linux-mips@oss.sgi.com Fri Aug 2 10:29:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72HT8Rw009553 for ; Fri, 2 Aug 2002 10:29:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72HT8gB009552 for linux-mips-outgoing; Fri, 2 Aug 2002 10:29:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72HT0Rw009542 for ; Fri, 2 Aug 2002 10:29:00 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020802173035.WYPC19356.rwcrmhc51.attbi.com@ocean.lucon.org>; Fri, 2 Aug 2002 17:30:35 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id EA21D125D2; Fri, 2 Aug 2002 10:30:34 -0700 (PDT) Date: Fri, 2 Aug 2002 10:30:34 -0700 From: "H. J. Lu" To: Ryan Martindale Cc: linux-mips@oss.sgi.com Subject: Re: Today's OSS doesn't work on Malta Message-ID: <20020802103034.A5075@lucon.org> References: <20020802100714.A4669@lucon.org> <3D4ACD9D.AB3FC45C@qsicorp.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: <3D4ACD9D.AB3FC45C@qsicorp.com>; from ryan@qsicorp.com on Fri, Aug 02, 2002 at 11:21:17AM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk On Fri, Aug 02, 2002 at 11:21:17AM -0700, Ryan Martindale wrote: > "H. J. Lu" wrote: > > > > The 2.4 kernel from today's OSS doesn't work on Malta. I got > > > > hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, (U)DMA > > Partition check: > > hda:<1>Unable to handle kernel paging request at virtual address 611c2000, > > epc4 > > Oops in fault.c::do_page_fault, line 206: > > $0 : 00000000 1000fc00 00000001 00001000 00001000 00001000 81191000 00000001 > > $8 : 811c0000 81199000 00000001 00008000 00010000 802d1358 00000000 00000080 > > $16: 611c2000 00000001 802d1338 00000000 00000000 00000008 00000000 00000000 > > $24: 0000000a 811ddd91 8027a000 8027bd10 8009e0d0 801eaa24 > > Hi : 0000004f > > Lo : df328000 > > epc : 801eaa98 Not tainted > > Status: 1000fc03 > > Cause : 0080000c > > Process swapper (pid: 0, stackpage=8027a000) > > Stack: 8027bd08 8027bd08 802b5c20 00000000 00001240 802d12c8 802d1338 801eb170 > > 0000000e 00000001 b8000000 802d1338 81198320 802d1338 81198320 802d12c8 > > 0000000e 00000001 801efc14 1000fc00 811dde48 802d1338 811dddd0 802d12c8 > > 0000000e 00000001 801e3ca8 802d12c8 8027bd88 1000fc00 8027bde0 1000fc00 > > 00000000 802d1338 81198320 801e406c 1000fc00 802d12c8 801e93e4 00000000 > > 00000003 ... > > Call Trace: [<801eb170>] [<801efc14>] [<801e3ca8>] [<801e406c>] [<801e93e4>] > > [<] > > [<801db1b4>] [<801e44ec>] [<801e3008>] [<8012ea04>] [<801e9290>] [<801e4be8>] > > [<80109690>] [<80109970>] [<8010ae3c>] [<80254554>] [<80254d10>] [<80254860>] > > [<801089a4>] [<80102e40>] [<80102e9c>] [<80102e44>] [<8010042c>] [<80255800>] > > > > Code: 54e00001 00a02021 3083ffff 00a42823 14600008 26100004 263 > > Kernel panic: Aiee, killing interrupt handler! > > In interrupt handler - not syncing > > Looks like what I was dealing with - check process.c patch I submitted a > couple of days ago (gp doesn't get set to the appropriate type of > structure). > I couldn't find your process.c patch for 2.4 kernel. The only one I saw is for 2.5. H.J. From owner-linux-mips@oss.sgi.com Fri Aug 2 11:27:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72IRsRw012459 for ; Fri, 2 Aug 2002 11:27:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72IRsVq012458 for linux-mips-outgoing; Fri, 2 Aug 2002 11:27:54 -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.5/8.12.5) with SMTP id g72IQURw012445 for ; Fri, 2 Aug 2002 11:26:31 -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 <20020802182805.OGLF23732.sccrmhc01.attbi.com@ocean.lucon.org>; Fri, 2 Aug 2002 18:28:05 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id B7069125D2; Fri, 2 Aug 2002 11:28:02 -0700 (PDT) Date: Fri, 2 Aug 2002 11:28:02 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , 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.13.90.0.2 is released Message-ID: <20020802112802.A5938@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.3 required=5.0 tests=PORN_10,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk This is the beta release of binutils 2.13.90.0.2 for Linux, which is based on binutils 2002 0802 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.13.90.0.2 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.15: 1. Update from binutils 2002 0802. 2. Initial support for mips n32 ABI. 3. Fix some x86 TLS bugs. Changes from binutils 2.12.90.0.14: 1. Update from binutils 2002 0717. 2. Fix an ia64 assembler bug. 3. Fix a symbol versioning bug. 4. You have to apply the modutils patch enclosed here in order to support System.map generated by the new nm. Changes from binutils 2.12.90.0.12: 1. Update from binutils 2002 0627. 2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel. Changes from binutils 2.12.90.0.11: 1. Update from binutils 2002 0618. 2. Fix a 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.13.90.0.2.tar.gz. Source code. 2. binutils-2.12.90.0.15-2.13.90.0.2.diff.gz. Patch against the previous beta source code. 3. binutils-2.13.90.0.2-1.i386.rpm. IA-32 binary RPM for RedHat 7.3. There is no separate source rpm. You can do # rpm -ta binutils-2.13.90.0.2.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 08/02/2002 ---- > On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote: > > Something you might like to warn about in your next release.. > > > > The 2002-07-05 bfd change exposes a bug in modutils. depmod scans the > > output of nm for a `?' symbol type when looking for certain symbols. > > nm used to return `?' for symbols in sections other than some standard > > sections like .text and .data. Now, nm returns a better guess as to > > the symbol type. > No, but it parses System.map, which is generated by nm. This was in modutils-2.4.16. Fix follows. diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c --- modutils-2.4.16.orig/depmod/depmod.c 2002-04-28 17:23:35.000000000 +0930 +++ modutils-2.4.16/depmod/depmod.c 2002-07-15 16:41:20.000000000 +0930 @@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); /* The second word is either the symbol name or a type */ - if (p && strlen(p) == 1) { /* System.map */ + if (p && p[0] && !p[1]) { /* System.map */ is_mapfile = 1; - if (*p != '?') - p = NULL; - else - p = strtok(NULL, " \t\n"); + p = strtok(NULL, " \t\n"); } else { /* /proc/ksyms copy */ if (p && strtok(NULL, " \t\n")) p = NULL; @@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); if (is_mapfile) { - if (*p != '?') + if (!p || !p[0] || p[1]) continue; p = strtok(NULL, " \t\n"); /* Sparc has symbols like '.div' that need to be -- Alan Modra IBM OzLabs - Linux Technology Centre From owner-linux-mips@oss.sgi.com Fri Aug 2 11:50:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72IofRw012696 for ; Fri, 2 Aug 2002 11:50:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72IoeaN012695 for linux-mips-outgoing; Fri, 2 Aug 2002 11:50:40 -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.5/8.12.5) with SMTP id g72IoSRw012668 for ; Fri, 2 Aug 2002 11:50:28 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g72Iq0Xb000945; Fri, 2 Aug 2002 11:52:00 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA23142; Fri, 2 Aug 2002 11:52:00 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g72Ipxb18032; Fri, 2 Aug 2002 20:51:59 +0200 (MEST) Message-ID: <3D4AD609.21E224BE@mips.com> Date: Fri, 02 Aug 2002 20:57:13 +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: Today's OSS doesn't work on Malta References: <20020802100714.A4669@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk I thing it's the pci stuff that is broken, I have send Ralf a patch, but unfortunately he hasn't checked it in yet. Try the patch below and see if it help. /Carsten Index: arch/mips/kernel/pci-dma.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/pci-dma.c,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 pci-dma.c --- arch/mips/kernel/pci-dma.c 2002/08/01 12:40:14 1.7.2.1 +++ arch/mips/kernel/pci-dma.c 2002/08/02 18:46:46 @@ -30,11 +30,11 @@ if (ret != NULL) { memset(ret, 0, size); + *dma_handle = virt_to_bus(ret); #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long) ret, size); ret = UNCAC_ADDR(ret); #endif - *dma_handle = virt_to_bus(ret); } return ret; Index: include/asm-mips/page.h =================================================================== RCS file: /cvs/linux/include/asm-mips/page.h,v retrieving revision 1.14.2.9 diff -u -r1.14.2.9 page.h --- include/asm-mips/page.h 2002/08/01 12:40:14 1.14.2.9 +++ include/asm-mips/page.h 2002/08/02 18:49:26 @@ -125,8 +125,8 @@ #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#define UNCAC_ADDR(addr) ((addr) - (PAGE_OFFSET + UNCAC_BASE)) -#define CAC_ADDR(addr) ((addr) - (UNCAC_BASE + PAGE_OFFSET)) +#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) +#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET) /* * Memory above this physical address will be considered highmem. "H. J. Lu" wrote: > The 2.4 kernel from today's OSS doesn't work on Malta. I got > > hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, (U)DMA > Partition check: > hda:<1>Unable to handle kernel paging request at virtual address 611c2000, > epc4 > Oops in fault.c::do_page_fault, line 206: > $0 : 00000000 1000fc00 00000001 00001000 00001000 00001000 81191000 00000001 > $8 : 811c0000 81199000 00000001 00008000 00010000 802d1358 00000000 00000080 > $16: 611c2000 00000001 802d1338 00000000 00000000 00000008 00000000 00000000 > $24: 0000000a 811ddd91 8027a000 8027bd10 8009e0d0 801eaa24 > Hi : 0000004f > Lo : df328000 > epc : 801eaa98 Not tainted > Status: 1000fc03 > Cause : 0080000c > Process swapper (pid: 0, stackpage=8027a000) > Stack: 8027bd08 8027bd08 802b5c20 00000000 00001240 802d12c8 802d1338 801eb170 > 0000000e 00000001 b8000000 802d1338 81198320 802d1338 81198320 802d12c8 > 0000000e 00000001 801efc14 1000fc00 811dde48 802d1338 811dddd0 802d12c8 > 0000000e 00000001 801e3ca8 802d12c8 8027bd88 1000fc00 8027bde0 1000fc00 > 00000000 802d1338 81198320 801e406c 1000fc00 802d12c8 801e93e4 00000000 > 00000003 ... > Call Trace: [<801eb170>] [<801efc14>] [<801e3ca8>] [<801e406c>] [<801e93e4>] > [<] > [<801db1b4>] [<801e44ec>] [<801e3008>] [<8012ea04>] [<801e9290>] [<801e4be8>] > [<80109690>] [<80109970>] [<8010ae3c>] [<80254554>] [<80254d10>] [<80254860>] > [<801089a4>] [<80102e40>] [<80102e9c>] [<80102e44>] [<8010042c>] [<80255800>] > > Code: 54e00001 00a02021 3083ffff 00a42823 14600008 26100004 263 > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing From owner-linux-mips@oss.sgi.com Fri Aug 2 16:35:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g72NZBRw016516 for ; Fri, 2 Aug 2002 16:35:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g72NZBP4016515 for linux-mips-outgoing; Fri, 2 Aug 2002 16:35:11 -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 (shaft16-f164.dialo.tiscali.de [62.246.16.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g72NZ4Rw016506 for ; Fri, 2 Aug 2002 16:35:05 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g72NUEV13149; Sat, 3 Aug 2002 01:30:14 +0200 Date: Sat, 3 Aug 2002 01:30:14 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com Subject: Shutdown of linux-mips@fnet.fr Message-ID: <20020803013014.A12850@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 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Hi everybody, after over seven hears we've decieded to shutdown the linux-mips@fnet.fr mailing list; some of you subscribers have already mailed me after having received an unsubscription message. Most postings to the list were crossposted to linux-mips@oss.sgi.com and the volume had gone down significantly over the years. All in all, the list had become obsolete and therefore I shut it down. All other Linux/MIPS related services at FNet will also be shutdown. The old web site lena.fnet.fr which is no longer mentioned in documents since quite a while will become a pointer to www.linux-mips.org; the content of the mailing list archives will also be made available there just like the contents of the ftp server ftp.fnet.fr. I'd also like to thank FNet - in particular Stoned Elipot and Luc Beurton - for providing us free service over many years and being so helpful during and after business hours. As most subscribers to the FNet list probably already know there is another Linux/MIPS mailing list at linux-mips@oss.sgi.com. Subscription to that list is handled via Majordomo. To subscribe you just have to send an email containing "subscribe linux-mips" in the body to majordomo@oss.sgi.com. Thanks, Ralf From owner-linux-mips@oss.sgi.com Mon Aug 5 02:03:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7593XRw001556 for ; Mon, 5 Aug 2002 02:03:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7593X43001555 for linux-mips-outgoing; Mon, 5 Aug 2002 02:03: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.5/8.12.5) with SMTP id g7593MRw001509 for ; Mon, 5 Aug 2002 02:03:23 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA19252; Mon, 5 Aug 2002 11:05:40 +0200 (MET DST) Date: Mon, 5 Aug 2002 11:05:40 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , linux-mips@oss.sgi.com Subject: [patch] 2.4: Revert interface removal Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1825 Lines: 53 Hello, A recent change to include/asm-mips/scatterlist.h broke drivers/scsi/dec_esp.c. Since 2.4.19 is not the proper version to remove interfaces, I'm going to check in the following patch to the 2.4 branch to revert the change (with a slightly sanitized type for the dvma_address member). Any objections? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020802-sg-2 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020802.macro/include/asm-mips/scatterlist.h linux-mips-2.4.19-rc1-20020802/include/asm-mips/scatterlist.h --- linux-mips-2.4.19-rc1-20020802.macro/include/asm-mips/scatterlist.h 2002-08-01 15:57:53.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020802/include/asm-mips/scatterlist.h 2002-08-03 20:43:35.000000000 +0000 @@ -10,6 +10,13 @@ struct scatterlist { unsigned int length; }; +struct mmu_sglist { + char *addr; + char *__dont_touch; + unsigned int len; + dma_addr_t dvma_address; +}; + #define ISA_DMA_THRESHOLD (0x00ffffff) #endif /* __ASM_SCATTERLIST_H */ diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020802.macro/include/asm-mips64/scatterlist.h linux-mips-2.4.19-rc1-20020802/include/asm-mips64/scatterlist.h --- linux-mips-2.4.19-rc1-20020802.macro/include/asm-mips64/scatterlist.h 2002-08-01 15:57:54.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020802/include/asm-mips64/scatterlist.h 2002-08-03 20:43:44.000000000 +0000 @@ -10,6 +10,13 @@ struct scatterlist { unsigned long length; }; +struct mmu_sglist { + char *addr; + char *__dont_touch; + unsigned long len; + dma_addr_t dvma_address; +}; + #define ISA_DMA_THRESHOLD (0x00ffffff) #endif /* __ASM_SCATTERLIST_H */ From owner-linux-mips@oss.sgi.com Mon Aug 5 03:10:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75AARRw003159 for ; Mon, 5 Aug 2002 03:10:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75AAQnf003158 for linux-mips-outgoing; Mon, 5 Aug 2002 03:10:26 -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.5/8.12.5) with SMTP id g75A9aRw003132 for ; Mon, 5 Aug 2002 03:09:41 -0700 Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian)) id 17bTTZ-0001WR-00; Mon, 05 Aug 2002 00:03:49 +0200 Date: Mon, 5 Aug 2002 00:03:49 +0200 To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@oss.sgi.com Subject: Re: [patch] GIO bus support Message-ID: <20020804220348.GA5277@kopretinka> References: <20020626205956.GA2079@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 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 12466 Lines: 334 On Thu, Jun 27, 2002 at 02:21:30PM +0200, Maciej W. Rozycki wrote: > On Wed, 26 Jun 2002, Ladislav Michl wrote: > > > +int be_ip22_handler(struct pt_regs *regs, int is_fixup) > > +{ > > + save_and_clear_buserr(); > > + if (nofault) { > > + nofault = 0; > > + compute_return_epc(regs); > > + return MIPS_BE_DISCARD; > > + } > > + return MIPS_BE_FIXUP; > > +} > > I wouldn't use nofault -- it leads to reentrancy problems and I don't > think you really need it. You probably need to code it like this: > > { > save_and_clear_buserr(); > > return is_fixup ? MIPS_BE_FIXUP : MIPS_BE_FATAL; > } > > unless: > > 1. There is a condition when for is_fixup true you should ignore the fixup > anyway (e.g. what the bus error logic reports is irrelevant to fixups). > You should choose between MIPS_BE_FATAL and MIPS_BE_DISCARD then. > > 2. There is a condition when for is_fixup false, an error is not fatal and > execution should get restarted. You should return MIPS_BE_DISCARD then. You are probably right. Unfortunately I cannot verify following patch (my Indy is currently dead). I hope there is enough brave men for this dirty job :-) ladis --- linux/arch/mips/sgi-ip22/ip22-berr.c.orig Thu Aug 1 23:26:10 2002 +++ linux/arch/mips/sgi-ip22/ip22-berr.c Sun Aug 4 23:03:34 2002 @@ -20,8 +20,6 @@ unsigned int cpu_err_addr; /* Error address reg for CPU */ unsigned int gio_err_addr; /* Error address reg for GIO */ -volatile int nofault; - static void save_and_clear_buserr(void) { /* save memory controler's error status registers */ @@ -33,6 +31,35 @@ mcmisc_regs->cstat = mcmisc_regs->gstat = 0; } +#define GIO_ERRMASK 0xff00 +#define CPU_ERRMASK 0x3f00 + +static void print_buserr(void) +{ + if (cpu_err_stat & CPU_ERRMASK) + printk(KERN_ALERT "CPU Error/Addr 0x%x<%s%s%s%s%s%s> 0x%08x\n", + cpu_err_stat, + cpu_err_stat & SGIMC_CSTAT_RD ? "RD " : "", + cpu_err_stat & SGIMC_CSTAT_PAR ? "PAR " : "", + cpu_err_stat & SGIMC_CSTAT_ADDR ? "ADDR " : "", + cpu_err_stat & SGIMC_CSTAT_SYSAD_PAR ? "SYSAD " : "", + cpu_err_stat & SGIMC_CSTAT_SYSCMD_PAR ? "SYSCMD " : "", + cpu_err_stat & SGIMC_CSTAT_BAD_DATA ? "BAD_DATA " : "", + cpu_err_addr); + if (gio_err_stat & GIO_ERRMASK) + printk(KERN_ALERT "GIO Error/Addr 0x%x:<%s%s%s%s%s%s%s%s> 0x08%x\n", + gio_err_stat, + gio_err_stat & SGIMC_GSTAT_RD ? "RD " : "", + gio_err_stat & SGIMC_GSTAT_WR ? "WR " : "", + gio_err_stat & SGIMC_GSTAT_TIME ? "TIME " : "", + gio_err_stat & SGIMC_GSTAT_PROM ? "PROM " : "", + gio_err_stat & SGIMC_GSTAT_ADDR ? "ADDR " : "", + gio_err_stat & SGIMC_GSTAT_BC ? "BC " : "", + gio_err_stat & SGIMC_GSTAT_PIO_RD ? "PIO_RD " : "", + gio_err_stat & SGIMC_GSTAT_PIO_WR ? "PIO_WR " : "", + gio_err_addr); +} + /* * 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 @@ -43,6 +70,7 @@ void be_ip22_interrupt(int irq, struct pt_regs *regs) { save_and_clear_buserr(); + print_buserr(); printk(KERN_ALERT "Bus error, epc == %08lx, ra == %08lx\n", regs->cp0_epc, regs->regs[31]); die_if_kernel("Oops", regs); @@ -52,24 +80,10 @@ int be_ip22_handler(struct pt_regs *regs, int is_fixup) { save_and_clear_buserr(); - if (nofault) { - nofault = 0; - compute_return_epc(regs); - return MIPS_BE_DISCARD; - } - return MIPS_BE_FIXUP; -} - -int ip22_baddr(unsigned int *val, unsigned long addr) -{ - nofault = 1; - *val = *(volatile unsigned int *) addr; - __asm__ __volatile__("nop;nop;nop;nop"); - if (nofault) { - nofault = 0; - return 0; - } - return -EFAULT; + if (is_fixup) + return MIPS_BE_FIXUP; + print_buserr(); + return MIPS_BE_FATAL; } void __init bus_error_init(void) --- linux/arch/mips/sgi-ip22/ip22-gio.c.orig Thu Aug 1 23:26:23 2002 +++ linux/arch/mips/sgi-ip22/ip22-gio.c Sun Aug 4 23:43:35 2002 @@ -11,6 +11,7 @@ #include #include +#include #include #include @@ -118,8 +119,6 @@ #define GIO_ROM_PRESENT 0x20000 #define GIO_VENDOR_CODE(x) ((x >> 18) & 0x3fff) -extern int ip22_baddr(unsigned int *val, unsigned long addr); - /** * sgigio_init - scan the GIO space and figure out what hardware is actually * present. @@ -128,9 +127,10 @@ { unsigned int i, id, found = 0; - printk("GIO: Scanning for GIO cards...\n"); + printk("GIO: Probing bus...\n"); for (i = 0; i < GIO_NUM_SLOTS; i++) { - if (ip22_baddr(&id, KSEG1ADDR(gio_slot[i].base_addr))) + if (get_dbe(id, (volatile unsigned int *) + KSEG1ADDR(gio_slot[i].base_addr))) continue; found = 1; --- linux/include/asm-mips/sgi/sgimc.h.orig Sun Aug 4 22:16:03 2002 +++ linux/include/asm-mips/sgi/sgimc.h Sun Aug 4 22:34:43 2002 @@ -128,11 +128,29 @@ volatile u32 cerr; /* Error address reg for CPU */ u32 _unused22; volatile u32 cstat; /* Status reg for CPU */ +#define SGIMC_CSTAT_RD 0x00000100 /* read parity error */ +#define SGIMC_CSTAT_PAR 0x00000200 /* CPU parity error */ +#define SGIMC_CSTAT_ADDR 0x00000400 /* memory bus error bad addr */ +#define SGIMC_CSTAT_SYSAD_PAR 0x00000800 /* sysad parity error */ +#define SGIMC_CSTAT_SYSCMD_PAR 0x00001000 /* syscmd parity error */ +#define SGIMC_CSTAT_BAD_DATA 0x00002000 /* bad data identifier */ +#define SGIMC_CSTAT_PAR_MASK 0x00001f00 /* parity error mask */ +#define SGIMC_CSTAT_RD_PAR (SGIMC_CSTAT_RD | SGIMC_CSTAT_PAR) u32 _unused23; volatile u32 gerr; /* Error address reg for GIO */ u32 _unused24; volatile u32 gstat; /* Status reg for GIO */ - +#define SGIMC_GSTAT_RD 0x00000100 /* read parity error */ +#define SGIMC_GSTAT_WR 0x00000200 /* write parity error */ +#define SGIMC_GSTAT_TIME 0x00000400 /* GIO bus timed out */ +#define SGIMC_GSTAT_PROM 0x00000800 /* write to PROM when PROM_EN + not set */ +#define SGIMC_GSTAT_ADDR 0x00001000 /* parity error on addr + cycle */ +#define SGIMC_GSTAT_BC 0x00002000 /* parity error on byte count + cycle */ +#define SGIMC_GSTAT_PIO_RD 0x00004000 /* read data parity on pio */ +#define SGIMC_GSTAT_PIO_WR 0x00008000 /* write data parity on pio */ /* Special hard bus locking registers. */ u32 _unused25; volatile unsigned char syssembit; /* Uni-bit system semaphore */ @@ -146,13 +164,13 @@ /* GIO dma control registers. */ unsigned char _unused30[3]; u32 _unused31[14]; - volatile u32 gio_dma_trans;/* DMA mask to translation GIO addrs */ + volatile u32 gio_dma_trans; /* DMA mask to translation GIO addrs */ u32 _unused32; - volatile u32 gio_dma_sbits;/* DMA GIO addr substitution bits */ + volatile u32 gio_dma_sbits; /* DMA GIO addr substitution bits */ u32 _unused33; volatile u32 dma_intr_cause; /* DMA IRQ cause indicator bits */ u32 _unused34; - volatile u32 dma_ctrl; /* Main DMA control reg */ + volatile u32 dma_ctrl; /* Main DMA control reg */ /* DMA TLB entry 0 */ u32 _unused35; @@ -181,29 +199,29 @@ /* MC misc control registers live at physical 0x1fa00000. */ extern struct sgimc_misc_ctrl *mcmisc_regs; -extern u32 *rpsscounter; /* Chirps at 100ns */ +extern u32 *rpsscounter; /* Chirps at 100ns */ struct sgimc_dma_ctrl { u32 _unused1; - volatile u32 maddronly; /* Address DMA goes at */ + volatile u32 maddronly; /* Address DMA goes at */ u32 _unused2; volatile u32 maddrpdeflts; /* Same as above, plus set defaults */ u32 _unused3; - volatile u32 dmasz; /* DMA count */ + volatile u32 dmasz; /* DMA count */ u32 _unused4; - volatile u32 ssize; /* DMA stride size */ + volatile u32 ssize; /* DMA stride size */ u32 _unused5; - volatile u32 gmaddronly; /* Set GIO DMA but do not start trans */ + volatile u32 gmaddronly; /* Set GIO DMA but do not start trans */ u32 _unused6; - volatile u32 dmaddnpgo; /* Set GIO DMA addr + start transfer */ + volatile u32 dmaddnpgo; /* Set GIO DMA addr + start transfer */ u32 _unused7; - volatile u32 dmamode; /* DMA mode config bit settings */ + volatile u32 dmamode; /* DMA mode config bit settings */ u32 _unused8; volatile u32 dmaccount; /* Zoom and byte count for DMA */ u32 _unused9; - volatile u32 dmastart; /* Pedal to the metal. */ + volatile u32 dmastart; /* Pedal to the metal. */ u32 _unused10; - volatile u32 dmarunning; /* DMA op is in progress */ + volatile u32 dmarunning; /* DMA op is in progress */ u32 _unused11; /* Set dma addr, defaults, and kick it */ --- linux/include/asm-mips64/sgi/sgimc.h.orig Sun Aug 4 22:40:27 2002 +++ linux/include/asm-mips64/sgi/sgimc.h Sun Aug 4 22:40:40 2002 @@ -128,11 +128,29 @@ volatile u32 cerr; /* Error address reg for CPU */ u32 _unused22; volatile u32 cstat; /* Status reg for CPU */ +#define SGIMC_CSTAT_RD 0x00000100 /* read parity error */ +#define SGIMC_CSTAT_PAR 0x00000200 /* CPU parity error */ +#define SGIMC_CSTAT_ADDR 0x00000400 /* memory bus error bad addr */ +#define SGIMC_CSTAT_SYSAD_PAR 0x00000800 /* sysad parity error */ +#define SGIMC_CSTAT_SYSCMD_PAR 0x00001000 /* syscmd parity error */ +#define SGIMC_CSTAT_BAD_DATA 0x00002000 /* bad data identifier */ +#define SGIMC_CSTAT_PAR_MASK 0x00001f00 /* parity error mask */ +#define SGIMC_CSTAT_RD_PAR (SGIMC_CSTAT_RD | SGIMC_CSTAT_PAR) u32 _unused23; volatile u32 gerr; /* Error address reg for GIO */ u32 _unused24; volatile u32 gstat; /* Status reg for GIO */ - +#define SGIMC_GSTAT_RD 0x00000100 /* read parity error */ +#define SGIMC_GSTAT_WR 0x00000200 /* write parity error */ +#define SGIMC_GSTAT_TIME 0x00000400 /* GIO bus timed out */ +#define SGIMC_GSTAT_PROM 0x00000800 /* write to PROM when PROM_EN + not set */ +#define SGIMC_GSTAT_ADDR 0x00001000 /* parity error on addr + cycle */ +#define SGIMC_GSTAT_BC 0x00002000 /* parity error on byte count + cycle */ +#define SGIMC_GSTAT_PIO_RD 0x00004000 /* read data parity on pio */ +#define SGIMC_GSTAT_PIO_WR 0x00008000 /* write data parity on pio */ /* Special hard bus locking registers. */ u32 _unused25; volatile unsigned char syssembit; /* Uni-bit system semaphore */ @@ -146,13 +164,13 @@ /* GIO dma control registers. */ unsigned char _unused30[3]; u32 _unused31[14]; - volatile u32 gio_dma_trans;/* DMA mask to translation GIO addrs */ + volatile u32 gio_dma_trans; /* DMA mask to translation GIO addrs */ u32 _unused32; - volatile u32 gio_dma_sbits;/* DMA GIO addr substitution bits */ + volatile u32 gio_dma_sbits; /* DMA GIO addr substitution bits */ u32 _unused33; volatile u32 dma_intr_cause; /* DMA IRQ cause indicator bits */ u32 _unused34; - volatile u32 dma_ctrl; /* Main DMA control reg */ + volatile u32 dma_ctrl; /* Main DMA control reg */ /* DMA TLB entry 0 */ u32 _unused35; @@ -181,29 +199,29 @@ /* MC misc control registers live at physical 0x1fa00000. */ extern struct sgimc_misc_ctrl *mcmisc_regs; -extern u32 *rpsscounter; /* Chirps at 100ns */ +extern u32 *rpsscounter; /* Chirps at 100ns */ struct sgimc_dma_ctrl { u32 _unused1; - volatile u32 maddronly; /* Address DMA goes at */ + volatile u32 maddronly; /* Address DMA goes at */ u32 _unused2; volatile u32 maddrpdeflts; /* Same as above, plus set defaults */ u32 _unused3; - volatile u32 dmasz; /* DMA count */ + volatile u32 dmasz; /* DMA count */ u32 _unused4; - volatile u32 ssize; /* DMA stride size */ + volatile u32 ssize; /* DMA stride size */ u32 _unused5; - volatile u32 gmaddronly; /* Set GIO DMA but do not start trans */ + volatile u32 gmaddronly; /* Set GIO DMA but do not start trans */ u32 _unused6; - volatile u32 dmaddnpgo; /* Set GIO DMA addr + start transfer */ + volatile u32 dmaddnpgo; /* Set GIO DMA addr + start transfer */ u32 _unused7; - volatile u32 dmamode; /* DMA mode config bit settings */ + volatile u32 dmamode; /* DMA mode config bit settings */ u32 _unused8; - volatile u32 dmacount; /* Zoom and byte count for DMA */ + volatile u32 dmaccount; /* Zoom and byte count for DMA */ u32 _unused9; - volatile u32 dmastart; /* Pedal to the metal. */ + volatile u32 dmastart; /* Pedal to the metal. */ u32 _unused10; - volatile u32 dmarunning; /* DMA op is in progress */ + volatile u32 dmarunning; /* DMA op is in progress */ u32 _unused11; /* Set dma addr, defaults, and kick it */ From owner-linux-mips@oss.sgi.com Mon Aug 5 03:41:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75AfGRw003622 for ; Mon, 5 Aug 2002 03:41:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75AfGBQ003621 for linux-mips-outgoing; Mon, 5 Aug 2002 03:41: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 (shaft18-f80.dialo.tiscali.de [62.246.18.80]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g75Af8Rw003612 for ; Mon, 5 Aug 2002 03:41:10 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g75AfsP06441; Mon, 5 Aug 2002 12:41:54 +0200 Date: Mon, 5 Aug 2002 12:41:54 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal Message-ID: <20020805124154.B6365@dea.linux-mips.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 05, 2002 at 11:05:40AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 607 Lines: 18 On Mon, Aug 05, 2002 at 11:05:40AM +0200, Maciej W. Rozycki wrote: > A recent change to include/asm-mips/scatterlist.h broke > drivers/scsi/dec_esp.c. Since 2.4.19 is not the proper version to remove > interfaces, I'm going to check in the following patch to the 2.4 branch to > revert the change (with a slightly sanitized type for the dvma_address > member). > > Any objections? Sorry for simply removing the structure, that was an accident. The question why the use of struct mmu_sglist still hasn't been replaced by newer interfaces stays ... So please go ahead and commit your patch. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 5 04:04:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75B4dRw004847 for ; Mon, 5 Aug 2002 04:04:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75B4c6v004846 for linux-mips-outgoing; Mon, 5 Aug 2002 04:04: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.5/8.12.5) with SMTP id g75B4URw004837; Mon, 5 Aug 2002 04:04:30 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g75B5cXb006358; Mon, 5 Aug 2002 04:05:38 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA03696; Mon, 5 Aug 2002 04:05:36 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g75B5Zb16216; Mon, 5 Aug 2002 13:05:35 +0200 (MEST) Message-ID: <3D4E5BFE.595DA175@mips.com> Date: Mon, 05 Aug 2002 13:05:35 +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: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal References: <20020805124154.B6365@dea.linux-mips.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1071 Lines: 35 Changing the scatterlist and the pci functions seems to break things in the IDE interface. /Carsten Ralf Baechle wrote: > On Mon, Aug 05, 2002 at 11:05:40AM +0200, Maciej W. Rozycki wrote: > > > A recent change to include/asm-mips/scatterlist.h broke > > drivers/scsi/dec_esp.c. Since 2.4.19 is not the proper version to remove > > interfaces, I'm going to check in the following patch to the 2.4 branch to > > revert the change (with a slightly sanitized type for the dvma_address > > member). > > > > Any objections? > > Sorry for simply removing the structure, that was an accident. The > question why the use of struct mmu_sglist still hasn't been replaced by > newer interfaces stays ... > > So please go ahead and commit your patch. > > 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 Aug 5 04:17:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75BHxRw005148 for ; Mon, 5 Aug 2002 04:17:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75BHxcg005147 for linux-mips-outgoing; Mon, 5 Aug 2002 04:17: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.5/8.12.5) with SMTP id g75BHoRw005135; Mon, 5 Aug 2002 04:17:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA21395; Mon, 5 Aug 2002 13:20:12 +0200 (MET DST) Date: Mon, 5 Aug 2002 13:20:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal In-Reply-To: <20020805124154.B6365@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 729 Lines: 18 On Mon, 5 Aug 2002, Ralf Baechle wrote: > Sorry for simply removing the structure, that was an accident. The > question why the use of struct mmu_sglist still hasn't been replaced by > newer interfaces stays ... Because the structure wasn't removed at the 2.3 time? M68k still keeps it as well and their sun3x_esp.c driver uses it (I think dec_esp.c was derived from that one). For 2.5, I'll work on adding an appropriate DMA addressing layer for the TURBOchannel bus and the I/O ASIC and fixing the driver, of course. -- + 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 Aug 5 04:52:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75BqbRw005668 for ; Mon, 5 Aug 2002 04:52:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75BqbU4005667 for linux-mips-outgoing; Mon, 5 Aug 2002 04:52:37 -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.5/8.12.5) with SMTP id g75BqRRw005657; Mon, 5 Aug 2002 04:52:27 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g75BrdXb006428; Mon, 5 Aug 2002 04:53:39 -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 EAA04826; Mon, 5 Aug 2002 04:53:40 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g75Brdb18990; Mon, 5 Aug 2002 13:53:39 +0200 (MEST) Message-ID: <3D4E6743.58776F67@mips.com> Date: Mon, 05 Aug 2002 13:53:39 +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 , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal References: <20020805124154.B6365@dea.linux-mips.net> <3D4E5BFE.595DA175@mips.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1583 Lines: 49 Ralf, could we please revert the latest changes to include/asm-mips/scatterlist.h and include/asm-mips/pci.h /Carsten Carsten Langgaard wrote: > Changing the scatterlist and the pci functions seems to break things in the IDE > interface. > > /Carsten > > Ralf Baechle wrote: > > > On Mon, Aug 05, 2002 at 11:05:40AM +0200, Maciej W. Rozycki wrote: > > > > > A recent change to include/asm-mips/scatterlist.h broke > > > drivers/scsi/dec_esp.c. Since 2.4.19 is not the proper version to remove > > > interfaces, I'm going to check in the following patch to the 2.4 branch to > > > revert the change (with a slightly sanitized type for the dvma_address > > > member). > > > > > > Any objections? > > > > Sorry for simply removing the structure, that was an accident. The > > question why the use of struct mmu_sglist still hasn't been replaced by > > newer interfaces stays ... > > > > So please go ahead and commit your patch. > > > > 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 -- _ _ ____ ___ 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 Aug 5 05:03:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75C31Rw005901 for ; Mon, 5 Aug 2002 05:03:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75C30X6005900 for linux-mips-outgoing; Mon, 5 Aug 2002 05:03:00 -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.5/8.12.5) with SMTP id g75C2GRw005881; Mon, 5 Aug 2002 05:02:17 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA22083; Mon, 5 Aug 2002 14:04:40 +0200 (MET DST) Date: Mon, 5 Aug 2002 14:04:39 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Carsten Langgaard cc: linux-mips@oss.sgi.com Subject: Re: [update] [patch] linux: Cache coherency fixes In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10681 Lines: 302 On Thu, 1 Aug 2002, Maciej W. Rozycki wrote: > I'll cook another patch to fix what got broken. OK, here is my proposal, based on my assumptions and the feedback I received. The intent is as follows: systems that want coherent I/O mark it by setting CONFIG_COHERENT_SYSTEM to "y" and CONFIG_NONCOHERENT_IO is then set to "n" if both CONFIG_COHERENT_SYSTEM is "y" and the selected CPU supports it; otherwise it's set to "y". This implementation retains the current semantics, (hopefully) provides the least confusion and should be a reasonable temporary solution until we have a run-time selection. Any comments? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020802-cache-coherency-7 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020802.macro/arch/mips/config-shared.in linux-mips-2.4.19-rc1-20020802/arch/mips/config-shared.in --- linux-mips-2.4.19-rc1-20020802.macro/arch/mips/config-shared.in 2002-08-03 14:03:11.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020802/arch/mips/config-shared.in 2002-08-03 14:23:38.000000000 +0000 @@ -108,7 +108,6 @@ if [ "$CONFIG_ACER_PICA_61" = "y" ]; the define_bool CONFIG_I8259 y define_bool CONFIG_ISA y define_bool CONFIG_MIPS_JAZZ y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_bool CONFIG_ROTTEN_IRQ y define_bool CONFIG_OLD_TIME_C y @@ -118,7 +117,6 @@ if [ "$CONFIG_MIPS_PB1000" = "y" ]; then define_bool CONFIG_NEW_IRQ y define_bool CONFIG_PCI y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_int MAX_HWIFS 1 fi @@ -128,7 +126,6 @@ if [ "$CONFIG_MIPS_PB1100" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_PCI_AUTO n define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_bool CONFIG_SWAP_IO_SPACE y define_bool CONFIG_AU1000_USB_DEVICE y @@ -139,12 +136,10 @@ if [ "$CONFIG_MIPS_PB1500" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y fi if [ "$CONFIG_ALGOR_P4032" = "y" ]; then define_bool CONFIG_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_OLD_TIME_C y fi if [ "$CONFIG_MIPS_COBALT" = "y" ]; then @@ -152,18 +147,15 @@ if [ "$CONFIG_MIPS_COBALT" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y fi if [ "$CONFIG_DECSTATION" = "y" ]; then define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_IRQ y - define_bool CONFIG_NONCOHERENT_IO y fi if [ "$CONFIG_MIPS_EV64120" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_ISA n define_bool CONFIG_MIPS_GT64120 y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_OLD_TIME_C y fi if [ "$CONFIG_MIPS_EV96100" = "y" ]; then @@ -171,7 +163,6 @@ if [ "$CONFIG_MIPS_EV96100" = "y" ]; the define_bool CONFIG_MIPS_GT96100 y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_SWAP_IO_SPACE y fi @@ -179,7 +170,6 @@ if [ "$CONFIG_MIPS_IVR" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_PC_KEYB y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_IT8172_CIR y define_bool CONFIG_NEW_IRQ y @@ -190,7 +180,6 @@ if [ "$CONFIG_HP_LASERJET" = "y" ]; then define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI y #not yet define_bool CONFIG_PCI_AUTO y fi @@ -199,7 +188,6 @@ if [ "$CONFIG_MIPS_ITE8172" = "y" ]; the define_bool CONFIG_IT8712 y define_bool CONFIG_PC_KEYB y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_IT8172_CIR y define_bool CONFIG_NEW_IRQ y @@ -210,7 +198,6 @@ if [ "$CONFIG_MIPS_ATLAS" = "y" ]; then define_int CONFIG_L1_CACHE_SHIFT 5 define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI y define_bool CONFIG_SWAP_IO_SPACE y fi @@ -222,7 +209,6 @@ if [ "$CONFIG_MIPS_MAGNUM_4000" = "y" -o define_bool CONFIG_FB y define_bool CONFIG_FB_G364 y define_bool CONFIG_MIPS_JAZZ y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_bool CONFIG_OLD_TIME_C y fi @@ -233,7 +219,6 @@ if [ "$CONFIG_MIPS_MALTA" = "y" ]; then define_int CONFIG_L1_CACHE_SHIFT 5 define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_SWAP_IO_SPACE y define_bool CONFIG_PC_KEYB y define_bool CONFIG_PCI y @@ -242,7 +227,6 @@ if [ "$CONFIG_MIPS_SEAD" = "y" ]; then define_int CONFIG_L1_CACHE_SHIFT 5 define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI n fi if [ "$CONFIG_MOMENCO_OCELOT" = "y" ]; then @@ -250,14 +234,12 @@ if [ "$CONFIG_MOMENCO_OCELOT" = "y" ]; t define_bool CONFIG_SYSCLK_100 y define_bool CONFIG_SWAP_IO_SPACE y define_bool CONFIG_NEW_IRQ y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_OLD_TIME_C y fi if [ "$CONFIG_DDB5074" = "y" ]; then define_bool CONFIG_HAVE_STD_PC_SERIAL_PORT y define_bool CONFIG_I8259 y define_bool CONFIG_ISA y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI y define_bool CONFIG_PC_KEYB y define_bool CONFIG_NEW_TIME_C y @@ -277,7 +259,6 @@ if [ "$CONFIG_DDB5476" = "y" ]; then define_bool CONFIG_NEW_PCI y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y fi if [ "$CONFIG_DDB5477" = "y" ]; then define_bool CONFIG_PCI y @@ -285,7 +266,6 @@ if [ "$CONFIG_DDB5477" = "y" ]; then define_bool CONFIG_NEW_IRQ y define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_PCI y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO y define_bool CONFIG_DUMMY_KEYB y define_bool CONFIG_I8259 y @@ -297,7 +277,6 @@ if [ "$CONFIG_NEC_OSPREY" = "y" ]; then define_bool CONFIG_NEW_IRQ y define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_DUMMY_KEYB y define_bool CONFIG_SCSI n fi @@ -307,7 +286,6 @@ if [ "$CONFIG_NEC_EAGLE" = "y" ]; then define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_VR41XX_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_ISA n define_bool CONFIG_PCI y define_bool CONFIG_NEW_PCI y @@ -318,7 +296,6 @@ fi if [ "$CONFIG_NINO" = "y" ]; then define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y fi if [ "$CONFIG_SGI_IP22" = "y" ]; then @@ -330,10 +307,8 @@ if [ "$CONFIG_SGI_IP22" = "y" ]; then define_bool CONFIG_SWAP_IO_SPACE y define_bool CONFIG_IRQ_CPU y define_int CONFIG_L1_CACHE_SHIFT 5 - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_bool CONFIG_SGI y define_bool CONFIG_SWAP_IO_SPACE y @@ -345,6 +320,7 @@ if [ "$CONFIG_SGI_IP27" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_QL_ISP_A64 y define_int CONFIG_L1_CACHE_SHIFT 7 + define_bool CONFIG_COHERENT_SYSTEM y fi if [ "$CONFIG_SGI_IP32" = "y" ]; then define_bool CONFIG_ARC_MEMORY y @@ -353,7 +329,6 @@ if [ "$CONFIG_SGI_IP32" = "y" ]; then define_bool CONFIG_BOOT_ELF32 y define_int CONFIG_L1_CACHE_SHIFT 5 define_bool CONFIG_MAPPED_PCI_IO n - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PC_KEYB y define_bool CONFIG_PCI y fi @@ -362,13 +337,13 @@ if [ "$CONFIG_SIBYTE_SB1250" = "y" ]; th define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_DUMMY_KEYB y define_bool CONFIG_SWAP_IO_SPACE y + define_bool CONFIG_COHERENT_SYSTEM y fi if [ "$CONFIG_SNI_RM200_PCI" = "y" ]; then define_bool CONFIG_ARC32 y define_bool CONFIG_I8259 y define_bool CONFIG_ISA y define_bool CONFIG_NEW_IRQ y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_OLD_TIME_C y define_bool CONFIG_PC_KEYB y define_bool CONFIG_PCI y @@ -380,7 +355,6 @@ if [ "$CONFIG_TOSHIBA_JMR3927" = "y" ]; define_bool CONFIG_PCI_AUTO y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_SWAP_IO_SPACE y define_bool CONFIG_PC_KEYB y fi @@ -391,7 +365,6 @@ if [ "$CONFIG_ZAO_CAPCELLA" = "y" ]; the define_bool CONFIG_IRQ_CPU y define_bool CONFIG_NEW_TIME_C y define_bool CONFIG_VR41XX_TIME_C y - define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_ISA n define_bool CONFIG_PCI y define_bool CONFIG_NEW_PCI y @@ -415,7 +388,8 @@ choice 'CPU type' \ R39XX CONFIG_CPU_TX39XX \ R41xx CONFIG_CPU_VR41XX \ R4300 CONFIG_CPU_R4300 \ - R4x00 CONFIG_CPU_R4X00 \ + R4x00 CONFIG_CPU_R4X00XX \ + R4x00MC CONFIG_CPU_R4X00MC \ R49XX CONFIG_CPU_TX49XX \ R5000 CONFIG_CPU_R5000 \ R5432 CONFIG_CPU_R5432 \ @@ -426,6 +400,10 @@ choice 'CPU type' \ RM7000 CONFIG_CPU_RM7000 \ SB1 CONFIG_CPU_SB1" R4x00 +if [ "$CONFIG_CPU_R4X00XX" = "y" -o "$CONFIG_CPU_R4X00MC" = "y" ]; then + define_bool CONFIG_CPU_R4X00 y +fi + if [ "$CONFIG_CPU_MIPS32" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE @@ -492,6 +470,19 @@ if [ "$CONFIG_CPU_R3000" = "y" ]; then else define_bool CONFIG_CPU_HAS_SYNC y fi +if [ "$CONFIG_CPU_MIPS32" = "y" -o \ + "$CONFIG_CPU_MIPS64" = "y" -o \ + "$CONFIG_CPU_R4X00MC" = "y" -o \ + "$CONFIG_CPU_R10000" = "y" -o \ + "$CONFIG_CPU_SB1" = "y" ]; then + if [ "$CONFIG_COHERENT_SYSTEM" = "y" ]; then + define_bool CONFIG_NONCOHERENT_IO n + else + define_bool CONFIG_NONCOHERENT_IO y + fi +else + define_bool CONFIG_NONCOHERENT_IO y +fi endmenu mainmenu_option next_comment From owner-linux-mips@oss.sgi.com Mon Aug 5 05:36:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75Ca3Rw006497 for ; Mon, 5 Aug 2002 05:36:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75Ca3kb006496 for linux-mips-outgoing; Mon, 5 Aug 2002 05:36:03 -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.5/8.12.5) with SMTP id g75CZfRw006485 for ; Mon, 5 Aug 2002 05:35:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA22694; Mon, 5 Aug 2002 14:38:05 +0200 (MET DST) Date: Mon, 5 Aug 2002 14:38:04 +0200 (MET DST) From: "Maciej W. Rozycki" To: linux-mips@oss.sgi.com cc: Ralf Baechle Subject: [patch] Provide useful siginfo_t data for integer overflow traps Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3439 Lines: 142 Hello, Here is an update to the overflow trap handler that is used for add/addi/sub/etc. signed integer operations that trap on the 2's-complement overflow. With an example test program as follows: $ cat addi.c #define _GNU_SOURCE #include #include #include #define y 0x7654 static volatile sig_atomic_t fpe_caught; static void catch_fpe(int sig, siginfo_t *info, void *ptr) { struct sigcontext *sc; fpe_caught = 1; sc = ptr; printf("SIGFPE caught, info:\n"); printf("si_code: %i\n", info->si_code); printf("si_addr: %08lx\n", (long)info->si_addr); #if 0 /* Until the kernel is fixed not to advance... */ sc->sc_pc += 4; #endif } int main(void) { int32_t x = 0x7fff9876; int32_t z; printf("Testing 32-bit signed addition:\n"); { struct sigaction sa, osa; long __r0; sa.sa_flags = SA_SIGINFO; sa.sa_sigaction = catch_fpe; sigemptyset(&sa.sa_mask); sigaction(SIGFPE, &sa, &osa); asm volatile( "lw %1,%2\n\t" "addi %1,%1,%3\n\t" "sw %1,%0\n\t" : "=m" (z), "=r" (__r0) : "m" (x), "i" (y) : "memory" ); sigaction(SIGFPE, &osa, NULL); if (!fpe_caught) { printf("No signal caught, dumping status:\n"); printf("%08x + %08x = %08x\n", x, (int32_t)y, z); } } return !fpe_caught; } I'm getting the following information without the patch: $ ./addi Testing 32-bit signed addition: SIGFPE caught, info: si_code: 128 si_addr: 00000000 and the following one with the patch: $ ./addi Testing 32-bit signed addition: SIGFPE caught, info: si_code: 2 si_addr: 0040095c which is more useful to the userland and corresponds to what do_tr() and do_bp() already do for explicitly coded multiply/divide overflow traps. Any comments? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020802-ov-0 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020802.macro/arch/mips/kernel/traps.c linux-mips-2.4.19-rc1-20020802/arch/mips/kernel/traps.c --- linux-mips-2.4.19-rc1-20020802.macro/arch/mips/kernel/traps.c 2002-07-23 03:00:18.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020802/arch/mips/kernel/traps.c 2002-08-04 19:32:38.000000000 +0000 @@ -462,10 +462,16 @@ asmlinkage void do_be(struct pt_regs *re asmlinkage void do_ov(struct pt_regs *regs) { + siginfo_t info; + if (compute_return_epc(regs)) return; - force_sig(SIGFPE, current); + info.si_code = FPE_INTOVF; + info.si_signo = SIGFPE; + info.si_errno = 0; + info.si_addr = (void *)regs->cp0_epc; + force_sig_info(SIGFPE, &info, current); } /* diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020802.macro/arch/mips64/kernel/traps.c linux-mips-2.4.19-rc1-20020802/arch/mips64/kernel/traps.c --- linux-mips-2.4.19-rc1-20020802.macro/arch/mips64/kernel/traps.c 2002-07-31 02:58:45.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020802/arch/mips64/kernel/traps.c 2002-08-04 19:36:55.000000000 +0000 @@ -365,9 +365,16 @@ asmlinkage void do_be(struct pt_regs *re asmlinkage void do_ov(struct pt_regs *regs) { + siginfo_t info; + if (compute_return_epc(regs)) return; - force_sig(SIGFPE, current); + + info.si_code = FPE_INTOVF; + info.si_signo = SIGFPE; + info.si_errno = 0; + info.si_addr = (void *)regs->cp0_epc; + force_sig_info(SIGFPE, &info, current); } /* From owner-linux-mips@oss.sgi.com Mon Aug 5 06:03:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75D3ORw007514 for ; Mon, 5 Aug 2002 06:03:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75D3OAm007513 for linux-mips-outgoing; Mon, 5 Aug 2002 06:03: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 (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g75D32Rw007501; Mon, 5 Aug 2002 06:03:02 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g75D4EXb006583; Mon, 5 Aug 2002 06:04:14 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA06942; Mon, 5 Aug 2002 06:04: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 g75D4Eb24739; Mon, 5 Aug 2002 15:04:14 +0200 (MEST) Message-ID: <3D4E77CD.A4E7B78B@mips.com> Date: Mon, 05 Aug 2002 15:04:13 +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 , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal References: <20020805124154.B6365@dea.linux-mips.net> <3D4E5BFE.595DA175@mips.com> <3D4E6743.58776F67@mips.com> Content-Type: multipart/mixed; boundary="------------DD625EA309C62AE684359CB8" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4692 Lines: 142 This is a multi-part message in MIME format. --------------DD625EA309C62AE684359CB8 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Ok, I finally figured out what the problem is. The attached patch fix the problems, please apply. /Carsten Carsten Langgaard wrote: > Ralf, could we please revert the latest changes to include/asm-mips/scatterlist.h > and include/asm-mips/pci.h > > /Carsten > > Carsten Langgaard wrote: > > > Changing the scatterlist and the pci functions seems to break things in the IDE > > interface. > > > > /Carsten > > > > Ralf Baechle wrote: > > > > > On Mon, Aug 05, 2002 at 11:05:40AM +0200, Maciej W. Rozycki wrote: > > > > > > > A recent change to include/asm-mips/scatterlist.h broke > > > > drivers/scsi/dec_esp.c. Since 2.4.19 is not the proper version to remove > > > > interfaces, I'm going to check in the following patch to the 2.4 branch to > > > > revert the change (with a slightly sanitized type for the dvma_address > > > > member). > > > > > > > > Any objections? > > > > > > Sorry for simply removing the structure, that was an accident. The > > > question why the use of struct mmu_sglist still hasn't been replaced by > > > newer interfaces stays ... > > > > > > So please go ahead and commit your patch. > > > > > > 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 > > -- > _ _ ____ ___ 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 --------------DD625EA309C62AE684359CB8 Content-Type: text/plain; charset=iso-8859-15; name="pci.3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci.3.patch" Index: arch/mips/kernel/pci-dma.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/pci-dma.c,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 pci-dma.c --- arch/mips/kernel/pci-dma.c 2002/08/01 12:40:14 1.7.2.1 +++ arch/mips/kernel/pci-dma.c 2002/08/05 12:54:19 @@ -30,11 +30,11 @@ if (ret != NULL) { memset(ret, 0, size); + *dma_handle = virt_to_bus(ret); #ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv((unsigned long) ret, size); ret = UNCAC_ADDR(ret); #endif - *dma_handle = virt_to_bus(ret); } return ret; Index: include/asm-mips/page.h =================================================================== RCS file: /cvs/linux/include/asm-mips/page.h,v retrieving revision 1.14.2.9 diff -u -r1.14.2.9 page.h --- include/asm-mips/page.h 2002/08/01 12:40:14 1.14.2.9 +++ include/asm-mips/page.h 2002/08/05 12:54:32 @@ -125,8 +125,8 @@ #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#define UNCAC_ADDR(addr) ((addr) - (PAGE_OFFSET + UNCAC_BASE)) -#define CAC_ADDR(addr) ((addr) - (UNCAC_BASE + PAGE_OFFSET)) +#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) +#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET) /* * Memory above this physical address will be considered highmem. Index: include/asm-mips/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.7 diff -u -r1.24.2.7 pci.h --- include/asm-mips/pci.h 2002/08/01 12:40:14 1.24.2.7 +++ include/asm-mips/pci.h 2002/08/05 12:54:32 @@ -180,7 +180,7 @@ else if (!sg->address && !sg->page) out_of_line_bug(); - if (sg[i].address) { + if (sg->address) { dma_cache_wback_inv((unsigned long)sg->address, sg->length); sg->dma_address = virt_to_bus(sg->address); @@ -317,7 +317,7 @@ * returns, or alternatively stop on the first sg_dma_len(sg) which * is 0. */ -#define sg_dma_address(sg) ((sg)->address) +#define sg_dma_address(sg) ((sg)->dma_address) #define sg_dma_len(sg) ((sg)->length) #endif /* __KERNEL__ */ --------------DD625EA309C62AE684359CB8-- From owner-linux-mips@oss.sgi.com Mon Aug 5 07:46:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75EkXRw011333 for ; Mon, 5 Aug 2002 07:46:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75EkXIb011332 for linux-mips-outgoing; Mon, 5 Aug 2002 07:46:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f218.dialo.tiscali.de [62.246.16.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g75EkQRw011322 for ; Mon, 5 Aug 2002 07:46:29 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g75ElT011860; Mon, 5 Aug 2002 16:47:29 +0200 Date: Mon, 5 Aug 2002 16:47:29 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal Message-ID: <20020805164729.A11853@dea.linux-mips.net> References: <20020805124154.B6365@dea.linux-mips.net> <3D4E5BFE.595DA175@mips.com> <3D4E6743.58776F67@mips.com> <3D4E77CD.A4E7B78B@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: <3D4E77CD.A4E7B78B@mips.com>; from carstenl@mips.com on Mon, Aug 05, 2002 at 03:04:13PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 248 Lines: 9 On Mon, Aug 05, 2002 at 03:04:13PM +0200, Carsten Langgaard wrote: > Ok, I finally figured out what the problem is. > The attached patch fix the problems, please apply. Applied, along with the 64-bit and 2.5 bits your patch was missing. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 5 11:37:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g75IbrRw018024 for ; Mon, 5 Aug 2002 11:37:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g75IbqBw018023 for linux-mips-outgoing; Mon, 5 Aug 2002 11:37:52 -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.5/8.12.5) with SMTP id g75IbkRw018012 for ; Mon, 5 Aug 2002 11:37:46 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA03006 for ; Mon, 5 Aug 2002 11:39:34 -0700 Subject: DECSTATION breaks xconfig From: Pete Popov To: linux-mips Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 05 Aug 2002 11:41:49 -0700 Message-Id: <1028572909.19215.61.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.7 required=5.0 tests=TO_LOCALPART_EQ_REAL,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 856 Lines: 26 This "if" in arch/mips/config-shared.in breaks xconfig because there are duplicate variables, such as CONFIG_RTC, which are used elsewhere. Why does the DECSTATION RTC and SERIAL_CONSOLE selection have to be in this file instead of selecting it from drivers/char/Config.in? Pete if [ "$CONFIG_DECSTATION" = "y" ]; then mainmenu_option next_comment comment 'DECStation Character devices' tristate 'Standard/generic (dumb) serial support' CONFIG_SERIAL dep_bool ' DZ11 Serial Support' CONFIG_DZ $CONFIG_SERIAL dep_bool ' Z85C30 Serial Support' CONFIG_ZS $CONFIG_SERIAL $CONFIG_TC dep_bool ' Support for console on serial port' CONFIG_SERIAL_CONSOLE $CONFIG_SERIAL # dep_bool 'MAXINE Access.Bus mouse (VSXXX-BB/GB) support' CONFIG_DTOP_MOUSE $CONFIG_ACCESSBUS bool 'Enhanced Real Time Clock Support' CONFIG_RTC endmenu fi From owner-linux-mips@oss.sgi.com Mon Aug 5 23:47:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g766ljRw002020 for ; Mon, 5 Aug 2002 23:47:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g766ljXF002019 for linux-mips-outgoing; Mon, 5 Aug 2002 23:47:45 -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.5/8.12.5) with SMTP id g766lXRw002010; Mon, 5 Aug 2002 23:47:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g766ktXb010116; Mon, 5 Aug 2002 23:46: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 XAA14711; Mon, 5 Aug 2002 23:46:57 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g766kvb25641; Tue, 6 Aug 2002 08:46:57 +0200 (MEST) Message-ID: <3D4F70E0.5DCC7AD4@mips.com> Date: Tue, 06 Aug 2002 08:46:56 +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: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal References: <20020805124154.B6365@dea.linux-mips.net> <3D4E5BFE.595DA175@mips.com> <3D4E6743.58776F67@mips.com> <3D4E77CD.A4E7B78B@mips.com> <20020805164729.A11853@dea.linux-mips.net> Content-Type: multipart/mixed; boundary="------------90A4148FC0DD876EEAD2CD73" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2092 Lines: 72 This is a multi-part message in MIME format. --------------90A4148FC0DD876EEAD2CD73 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Ralf Baechle wrote: > On Mon, Aug 05, 2002 at 03:04:13PM +0200, Carsten Langgaard wrote: > > > Ok, I finally figured out what the problem is. > > The attached patch fix the problems, please apply. > > Applied, along with the 64-bit and 2.5 bits your patch was missing. > I was waiting for you to fix the bus_to_baddr in the 64-bit, I can see you have have done something about it now, but I'm afraid you didn't get it quite right. Here is a patch to fix the typos. /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 --------------90A4148FC0DD876EEAD2CD73 Content-Type: text/plain; charset=iso-8859-15; name="pci.h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci.h.patch" Index: include/asm-mips64/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pci.h,v retrieving revision 1.16.2.9 diff -u -r1.16.2.9 pci.h --- include/asm-mips64/pci.h 2002/08/06 02:21:50 1.16.2.9 +++ include/asm-mips64/pci.h 2002/08/06 06:36:35 @@ -213,8 +213,8 @@ out_of_line_bug(); dma_cache_wback_inv((unsigned long)sg->address, sg->length); - sg->address = bus_to_baddr(hwdev->bus->number) | - virt_to_bus(sg->address); + sg->address = bus_to_baddr(hwdev->bus->number, + virt_to_bus(sg->address)); } return nents; @@ -251,7 +251,7 @@ if (direction == PCI_DMA_NONE) out_of_line_bug(); - dma_cache_wback_inv((unsigned long)__va(dma_handle - bus_to_baddr(hwdev->bus->number)), size); + dma_cache_wback_inv((unsigned long)__va(bus_to_baddr(hwdev->bus->number, dma_handle)), size); } /* --------------90A4148FC0DD876EEAD2CD73-- From owner-linux-mips@oss.sgi.com Tue Aug 6 02:05:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7695mRw003326 for ; Tue, 6 Aug 2002 02:05:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7695mxb003325 for linux-mips-outgoing; Tue, 6 Aug 2002 02:05: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 (mx2.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7695QRw003291; Tue, 6 Aug 2002 02:05:26 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g7695tXb010489; Tue, 6 Aug 2002 02:05: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 CAA19256; Tue, 6 Aug 2002 02:05:54 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g7695sb24456; Tue, 6 Aug 2002 11:05:54 +0200 (MEST) Message-ID: <3D4F9171.33E0F05A@mips.com> Date: Tue, 06 Aug 2002 11:05: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 , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: [patch] 2.4: Revert interface removal References: <20020805124154.B6365@dea.linux-mips.net> <3D4E5BFE.595DA175@mips.com> <3D4E6743.58776F67@mips.com> <3D4E77CD.A4E7B78B@mips.com> <20020805164729.A11853@dea.linux-mips.net> <3D4F70E0.5DCC7AD4@mips.com> Content-Type: multipart/mixed; boundary="------------B8E3CF4BB83809C78E22C043" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4097 Lines: 123 This is a multi-part message in MIME format. --------------B8E3CF4BB83809C78E22C043 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Carsten Langgaard wrote: > Ralf Baechle wrote: > > > On Mon, Aug 05, 2002 at 03:04:13PM +0200, Carsten Langgaard wrote: > > > > > Ok, I finally figured out what the problem is. > > > The attached patch fix the problems, please apply. > > > > Applied, along with the 64-bit and 2.5 bits your patch was missing. > > > Another reason why I didn't send the patch against the 64-bit is that the pci handling is not completely identical. So the patch should actually look like this for things to work. > > I was waiting for you to fix the bus_to_baddr in the 64-bit, I can see > you have have done something about it now, but I'm afraid you didn't get > it quite right. > Here is a patch to fix the typos. > > /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: include/asm-mips64/pci.h > =================================================================== > RCS file: /cvs/linux/include/asm-mips64/pci.h,v > retrieving revision 1.16.2.9 > diff -u -r1.16.2.9 pci.h > --- include/asm-mips64/pci.h 2002/08/06 02:21:50 1.16.2.9 > +++ include/asm-mips64/pci.h 2002/08/06 06:36:35 > @@ -213,8 +213,8 @@ > out_of_line_bug(); > > dma_cache_wback_inv((unsigned long)sg->address, sg->length); > - sg->address = bus_to_baddr(hwdev->bus->number) | > - virt_to_bus(sg->address); > + sg->address = bus_to_baddr(hwdev->bus->number, > + virt_to_bus(sg->address)); > } > > return nents; > @@ -251,7 +251,7 @@ > if (direction == PCI_DMA_NONE) > out_of_line_bug(); > > - dma_cache_wback_inv((unsigned long)__va(dma_handle - bus_to_baddr(hwdev->bus->number)), size); > + dma_cache_wback_inv((unsigned long)__va(bus_to_baddr(hwdev->bus->number, dma_handle)), size); > } > > /* -- _ _ ____ ___ 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 --------------B8E3CF4BB83809C78E22C043 Content-Type: text/plain; charset=iso-8859-15; name="pci.h.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci.h.patch" Index: include/asm-mips64/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pci.h,v retrieving revision 1.16.2.9 diff -u -r1.16.2.9 pci.h --- include/asm-mips64/pci.h 2002/08/06 02:21:50 1.16.2.9 +++ include/asm-mips64/pci.h 2002/08/06 09:01:25 @@ -213,8 +213,8 @@ out_of_line_bug(); dma_cache_wback_inv((unsigned long)sg->address, sg->length); - sg->address = bus_to_baddr(hwdev->bus->number) | - virt_to_bus(sg->address); + sg->address = bus_to_baddr(hwdev->bus->number, + virt_to_bus(sg->address)); } return nents; @@ -251,7 +251,7 @@ if (direction == PCI_DMA_NONE) out_of_line_bug(); - dma_cache_wback_inv((unsigned long)__va(dma_handle - bus_to_baddr(hwdev->bus->number)), size); + dma_cache_wback_inv((unsigned long)__va(bus_to_baddr(hwdev->bus->number, dma_handle)), size); } /* @@ -341,7 +341,7 @@ * returns, or alternatively stop on the first sg_dma_len(sg) which * is 0. */ -#define sg_dma_address(sg) ((sg)->dma_address) +#define sg_dma_address(sg) ((sg)->address) #define sg_dma_len(sg) ((sg)->length) #endif /* __KERNEL__ */ --------------B8E3CF4BB83809C78E22C043-- From owner-linux-mips@oss.sgi.com Tue Aug 6 04:33:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76BXMRw014923 for ; Tue, 6 Aug 2002 04:33:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76BXMG9014922 for linux-mips-outgoing; Tue, 6 Aug 2002 04:33:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from pacrs180.mgmt.panalpina.ch (ns2.panalpina.ch [194.11.79.70]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76BXDRw014909 for ; Tue, 6 Aug 2002 04:33:14 -0700 Received: from pac2k460.corp.panorg.com (pac2k460.corp.panorg.com [157.168.190.17]) by pacrs180.mgmt.panalpina.ch (8.10.1/8.10.1) with ESMTP id g76BZ9p400126 for ; Tue, 6 Aug 2002 13:35:09 +0200 Received: from pac2k540.corp.panorg.com (unverified) by pac2k460.corp.panorg.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 6 Aug 2002 13:35:09 +0200 Received: from ams2k020.europe.panorg.com ([194.11.64.156]) by pac2k540.corp.panorg.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 6 Aug 2002 13:35:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: how to build a kernel for the Origin 200 ? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 6 Aug 2002 13:34:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: how to build a kernel for the Origin 200 ? Thread-Index: AcI9PcpgncxC6KkIEdatmwAEdYa7pA== From: "AMS Hoogland Yvar" To: X-OriginalArrivalTime: 06 Aug 2002 11:35:08.0944 (UTC) FILETIME=[51800900:01C23D3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g76BXFRw014911 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1273 Lines: 44 Hi, I'm pretty new to all this, but am planning on installing Debian on an Origin 200 server I got from my IT dept. However, when I got it it lacked a cd-rom and harddisk, I got both, a correct Toshiba CD-ROM and a 4.3 GB SCA harddisk in the bottom (system disk) slot. The hard disk is to my best knowledge empty ! So I do not have IRIX installed or available. I hooked the server (which does not have a display connector) to an Etherminal C thin client through a serial connection and its ANSI emulator So know I can see the boot sequence and the prompt below the 5 options looking like this: +++++++++++++++ 1) Start System 2) Install System Software 3) Run Diagnostics 4) Recover System 5) Enter Command Monitor Option? +++++++++++++++ So where do I go from here ? I understand by now that I first need to build a cross-compiler and binutils then crosscompile a kernel. I read the FAQ at the linux-mips site. My first concern is how to get the needed software onto the Origin's hdd, is it possible from cd-rom or are there other options ? And make it accessible. Also I noticed that the Origin does not have fdisk ? Do I need to partition anything ? Lot of questions, I know, hope someone can spare some time to get me on the road. Appreciate it, Yvar From owner-linux-mips@oss.sgi.com Tue Aug 6 05:05:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76C5VRw016341 for ; Tue, 6 Aug 2002 05:05:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76C5Vtm016340 for linux-mips-outgoing; Tue, 6 Aug 2002 05:05:31 -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.5/8.12.5) with SMTP id g76C5GRw016306; Tue, 6 Aug 2002 05:05:16 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g76C5QXb011093; Tue, 6 Aug 2002 05:05:30 -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 FAA26213; Tue, 6 Aug 2002 05:05: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 g76C5Qb21112; Tue, 6 Aug 2002 14:05:26 +0200 (MEST) Message-ID: <3D4FBB85.FA28A0C7@mips.com> Date: Tue, 06 Aug 2002 14:05: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: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: 64-bit kernel Content-Type: multipart/mixed; boundary="------------5760143622786E77B5EF0B2D" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2609 Lines: 82 This is a multi-part message in MIME format. --------------5760143622786E77B5EF0B2D Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Here is a patch, which have a more cosmetic value rather than fixing anything, but it makes the compiler happier. /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 --------------5760143622786E77B5EF0B2D Content-Type: text/plain; charset=iso-8859-15; name="cosmetic.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cosmetic.patch" 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/08/06 11:35:06 @@ -46,6 +46,13 @@ struct irqaction; extern int i8259_setup_irq(int irq, struct irqaction * new); extern void disable_irq(unsigned int); + +#ifndef CONFIG_NEW_IRQ +#define disable_irq_nosync disable_irq +#else +extern void disable_irq_nosync(unsigned int); +#endif + extern void enable_irq(unsigned int); /* Machine specific interrupt initialization */ Index: include/asm-mips64/pgtable.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pgtable.h,v retrieving revision 1.47.2.16 diff -u -r1.47.2.16 pgtable.h --- include/asm-mips64/pgtable.h 2002/08/05 23:53:39 1.47.2.16 +++ include/asm-mips64/pgtable.h 2002/08/06 11:35:07 @@ -77,10 +77,6 @@ #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) @@ -89,12 +85,6 @@ #define flush_icache_user_range(vma, page, addr, len) \ flush_icache_page((vma), (page)) #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 */ --------------5760143622786E77B5EF0B2D-- From owner-linux-mips@oss.sgi.com Tue Aug 6 05:26:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76CQcRw016718 for ; Tue, 6 Aug 2002 05:26:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76CQcZm016715 for linux-mips-outgoing; Tue, 6 Aug 2002 05:26:38 -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 (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76CPwRw016577 for ; Tue, 6 Aug 2002 05:26:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA12141; Tue, 6 Aug 2002 14:26:57 +0200 (MET DST) Date: Tue, 6 Aug 2002 14:26:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Pete Popov cc: linux-mips Subject: Re: DECSTATION breaks xconfig In-Reply-To: <1028572909.19215.61.camel@zeus.mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 770 Lines: 17 On 5 Aug 2002, Pete Popov wrote: > This "if" in arch/mips/config-shared.in breaks xconfig because there are > duplicate variables, such as CONFIG_RTC, which are used elsewhere. Why > does the DECSTATION RTC and SERIAL_CONSOLE selection have to be in this > file instead of selecting it from drivers/char/Config.in? Both files are broken in this area, e.g. CONFIG_SERIAL in the latter one should be for CONFIG_ISA or CONFIG_PCI only (it isn't, under the assumption: "everything is a PC"). I'll see if something non-intrusive can be cooked; otherwise wait for 2.6. -- + 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 Aug 6 08:18:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76FIVRw027120 for ; Tue, 6 Aug 2002 08:18:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76FIVsx027119 for linux-mips-outgoing; Tue, 6 Aug 2002 08:18:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rail.cita.utoronto.ca (rail.cita.utoronto.ca [128.100.76.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76FIJRw027110 for ; Tue, 6 Aug 2002 08:18:20 -0700 Received: from [128.100.76.25] (marmot.cita.utoronto.ca) by rail.cita.utoronto.ca id 784; Tue, 6 Aug 2002 11:20:11 Date: Tue, 6 Aug 2002 11:20:00 -0400 From: Robin Humble To: linux-mips@oss.sgi.com Subject: R4600SC Indy Message-ID: <20020806111959.C15670@marmot.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2422 Lines: 59 Hi, I have an R4600SC Indy and an R5000 Indy and the R4600SC hasn't worked with a kernel since around 2.4.17 13feb2002. Are there any patches or new toolchain that I could try? Or is there some way I can configure/boot the kernel to help sort out the problem? The R5k with same root disk and same kernel (compiled for either R4600 or R5000) works fine on last week's 2.4.19-rc1 31july2002 OSS CVS, as well with the old 2.4.17 kernel... I've tried 1/2 a dozen kernels since feb on my poor little R4600SC and they all fail to fully boot. For example, 2.4.19-rc1 gets to mounting the disks and starting RedHat services and then locks up with no messages at some random time after that - during sshd or eth0 startup or similar - has to be paperclipped off - magic sysrq key doesn't work. The 2.4.17-13feb2002 kernel on the R4600SC seems pretty stable (apart from the ubiquitous X shared mem/bitmap corruption) so I'm quietly confident that there are no broken hardware issues... I'm running redhat-7.1 + much of 7.2 and some 7.3. Toolchain is: % gcc -v ; ld -v Reading specs from /usr/lib/gcc-lib/mips-redhat-linux-gnu/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110.1) GNU ld version 2.12.90.0.7 20020423 % rpm -qa | grep binutil binutils-2.12.90.0.7-1 Here's the top part from the working 2.4.17's dmesg for both machines showing the CPU versions: --------- R4600SC --------- ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4600 FPU ICACHE DCACHE SCACHE CPU revision is: 00002010 FPU revision is: 00002000 Primary instruction cache 16kb, linesize 32 bytes. Primary data cache 16kb, linesize 32 bytes. Linux version 2.4.17-13feb (root@elan) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1)) #1 Wed Feb 13 20:49:52 EST 2002 MC: SGI memory controller Revision 3 R4600/R5000 SCACHE size 512K, linesize 32 bytes. --------- R5000 --------- ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R5000 FPU ICACHE DCACHE SCACHE CPU revision is: 00002310 FPU revision is: 00002310 Primary instruction cache 32kb, linesize 32 bytes. Primary data cache 32kb, linesize 32 bytes. Linux version 2.4.17-13feb (root@elan) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-99.1)) #1 Wed Feb 13 20:49:52 EST 2002 MC: SGI memory controller Revision 3 R4600/R5000 SCACHE size 512K, linesize 32 bytes. ------------------------ cheers, robin From owner-linux-mips@oss.sgi.com Tue Aug 6 09:31:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76GVuRw028291 for ; Tue, 6 Aug 2002 09:31:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76GVu62028290 for linux-mips-outgoing; Tue, 6 Aug 2002 09:31:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76GVmRw028281 for ; Tue, 6 Aug 2002 09:31:49 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7936E7F3; Tue, 6 Aug 2002 18:33:44 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 320D03714B; Tue, 6 Aug 2002 18:33:38 +0200 (CEST) Date: Tue, 6 Aug 2002 18:33:38 +0200 From: Florian Lohoff To: Robin Humble Cc: linux-mips@oss.sgi.com Subject: Re: R4600SC Indy Message-ID: <20020806163338.GA8378@paradigm.rfc822.org> References: <20020806111959.C15670@marmot.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20020806111959.C15670@marmot.cita.utoronto.ca> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1093 Lines: 36 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 06, 2002 at 11:20:00AM -0400, Robin Humble wrote: > The 2.4.17-13feb2002 kernel on the R4600SC seems pretty stable (apart > from the ubiquitous X shared mem/bitmap corruption) so I'm quietly > confident that there are no broken hardware issues... I'm running > redhat-7.1 + much of 7.2 and some 7.3. Toolchain is: The debian mips kernel has a fix for the shmem issues - It has been posted to this list a couple of times but was found to be an incomplete fix. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --BXVAT5kNtrzKuDFl 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 iD8DBQE9T/piUaz2rXW+gJcRAgYVAKDf7jJ6X6UNosdocds+NghWmZZtkgCcDzHk uHulBTqvgsmvFyNbJMMJvV8= =8LTy -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-linux-mips@oss.sgi.com Tue Aug 6 12:37:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76JbBRw008716 for ; Tue, 6 Aug 2002 12:37:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76JbBco008715 for linux-mips-outgoing; Tue, 6 Aug 2002 12:37:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76JaTRw008676 for ; Tue, 6 Aug 2002 12:36:30 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g76JcKui001857 for ; Tue, 6 Aug 2002 21:38:21 +0200 Message-ID: <3D5025AC.9020203@murphy.dk> Date: Tue, 06 Aug 2002 21:38:20 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 CC: linux-mips@oss.sgi.com Subject: Re: [2.5 patch] R5K SC support References: <20020715144315.A4837@dea.linux-mips.net> Content-Type: multipart/mixed; boundary="------------030806050001020409090604" X-Spam-Status: No, hits=-4.0 required=5.0 tests=PORN_10,UNIFIED_PATCH,MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7748 Lines: 307 This is a multi-part message in MIME format. --------------030806050001020409090604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ralf Baechle wrote: >>+static void r5k_dma_cache_wback_inv_sc(unsigned long addr, unsigned long size) >>+static void r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) >> > >You can hook the second level cache support into the bcache hook. That's >working because unlike the R4000SC the R5000's second level cache does not >have the additional constraint of the primary caches always being a subset >of the second level caches. > >Arch/mips/sgi-ip22/ip22-sc.c is an example how this can be done. > > > This is all very fine in theory but the R5000 cache routines are automatically selected by the R4000 secondary setup routines which pick out the incorrect flush_range function and wback_inv and inv functions. These do not call board cache routines at all. It must be that the secondary cache for the ip22 architecture with an R5000 is not flagged as having a secondary cache in a way that the R4000 secondary cache routines can detect. On the other hand with the application of this (attached) patch the cache is detected correctly and appropriate routines are selected. /Brian --------------030806050001020409090604 Content-Type: text/plain; name="r5k-sc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r5k-sc.patch" Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /cvs/linux-mips/arch/mips/mm/c-r4k.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- arch/mips/mm/c-r4k.c 18 Jul 2002 17:35:18 -0000 1.1 +++ arch/mips/mm/c-r4k.c 18 Jul 2002 17:41:34 -0000 1.2 @@ -36,6 +36,7 @@ /* Secondary cache (if present) parameters. */ static unsigned int scache_size, sc_lsize; /* Again, in bytes */ +static int sc_present = 0; #include #include @@ -1195,6 +1196,126 @@ #endif } +static void r5k_flush_cache_range(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->active_mm->context) { + _flush_cache_all(); + } else { + pgd_t *pgd; + pmd_t *pmd; + pte_t *pte; + int text; + + __save_and_cli(flags); + text = vma->vm_flags & VM_EXEC; + 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_dcache32_page(start); + if (text) + blast_icache32_page(start); + } + start += PAGE_SIZE; + } + __restore_flags(flags); + } + } +} + +static void +r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + blast_r5000_scache(); + return; + } + + /* We assume the address is in KSEG0. On the R5000 we + * cannot invalidate less than a page at a time, and + * there is no Hit_xxx cache operations. + */ + a = addr & ~(PAGE_SIZE - 1); + end = (addr + size - 1) & ~(PAGE_SIZE - 1); + while (a <= end) { + blast_r5000_scache_page_indexed(a); /* Page_Invalidate */ + a += PAGE_SIZE; + } +} + +static void +r5k_dma_cache_wback_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + flush_dcache_line(a); /* Hit_Writeback_Inv_D */ + a += dc_lsize; + } + } + if (sc_present) + r5k_dma_cache_inv_sc(addr, size); +} + +static void +r5k_dma_cache_inv(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + invalidate_dcache_line(a); /* Hit_Invalidate_D */ + a += dc_lsize; + } + } + if (sc_present) + r5k_dma_cache_inv_sc(addr, size); +} + +static void +r5k_dma_cache_wback(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= dcache_size) { + blast_dcache32(); + } else { + a = addr & ~(dc_lsize - 1); + end = (addr + size - 1) & ~(dc_lsize - 1); + while (a <= end) { + flush_dcache_line_wb(a); /* Hit_Writeback_D */ + a += dc_lsize; + } + } +} + /* Detect and size the various r4k caches. */ static void __init probe_icache(unsigned long config) { @@ -1374,7 +1495,7 @@ _dma_cache_inv = r4k_dma_cache_inv_pc; } -static void __init setup_scache_funcs(void) +static void __init setup_scache_funcs_r4k(void) { switch(sc_lsize) { case 16: @@ -1457,19 +1578,36 @@ _dma_cache_inv = r4k_dma_cache_inv_sc; } +static void __init setup_scache_funcs_r5k(void) { + _clear_page = r4k_clear_page_d32; + _copy_page = r4k_copy_page_d32; + _flush_cache_all = r4k_flush_cache_all_d32i32; + _flush_cache_range = r5k_flush_cache_range; + _flush_cache_mm = r4k_flush_cache_mm_d32i32; + _flush_page_to_ram = r4k_flush_page_to_ram_d32; + + ___flush_cache_all = _flush_cache_all; + _flush_icache_page = r4k_flush_icache_page_p; + _dma_cache_wback_inv = r5k_dma_cache_wback_inv; + _dma_cache_wback = r5k_dma_cache_wback; + _dma_cache_inv = r5k_dma_cache_inv; +} + 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) { - setup_scache_funcs(); + if (mips_cpu.cputype == CPU_R5000) + setup_scache_funcs_r5k(); + else + setup_scache_funcs_r4k(); return; } Index: include/asm-mips/r4kcache.h =================================================================== RCS file: /cvs/linux-mips/include/asm-mips/r4kcache.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- include/asm-mips/r4kcache.h 18 Jul 2002 17:34:01 -0000 1.1 +++ include/asm-mips/r4kcache.h 18 Jul 2002 17:41:35 -0000 1.2 @@ -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) */ --------------030806050001020409090604-- From owner-linux-mips@oss.sgi.com Tue Aug 6 16:12:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g76NCfRw015608 for ; Tue, 6 Aug 2002 16:12:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g76NCfGu015607 for linux-mips-outgoing; Tue, 6 Aug 2002 16:12:41 -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 (shaft18-f131.dialo.tiscali.de [62.246.18.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g76NCZRw015598 for ; Tue, 6 Aug 2002 16:12:37 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g76NERf03744; Wed, 7 Aug 2002 01:14:27 +0200 Date: Wed, 7 Aug 2002 01:14:26 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: 64-bit kernel Message-ID: <20020807011426.B28735@dea.linux-mips.net> References: <3D4FBB85.FA28A0C7@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: <3D4FBB85.FA28A0C7@mips.com>; from carstenl@mips.com on Tue, Aug 06, 2002 at 02:05:25PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 258 Lines: 11 On Tue, Aug 06, 2002 at 02:05:25PM +0200, Carsten Langgaard wrote: > Here is a patch, which have a more cosmetic value rather than fixing > anything, but it makes the compiler happier. Happy compilers are good compilers :-) Applied with changes, Ralf From owner-linux-mips@oss.sgi.com Wed Aug 7 01:19:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g778JdRw029736 for ; Wed, 7 Aug 2002 01:19:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g778JdOH029735 for linux-mips-outgoing; Wed, 7 Aug 2002 01:19: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 (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g778JMRw029726; Wed, 7 Aug 2002 01:19:22 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g778KfXb015056; Wed, 7 Aug 2002 01:20:41 -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 BAA19530; Wed, 7 Aug 2002 01:20:42 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g778Keb12139; Wed, 7 Aug 2002 10:20:42 +0200 (MEST) Message-ID: <3D50D857.E2DDC84F@mips.com> Date: Wed, 07 Aug 2002 10:20:39 +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 , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: PCI patch of the day Content-Type: multipart/mixed; boundary="------------08E27668F641EB845943C2B1" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3147 Lines: 105 This is a multi-part message in MIME format. --------------08E27668F641EB845943C2B1 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit It's apparently not that easy to get the PCI code right, the current code won't compile, so here is the patch of the day. /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 --------------08E27668F641EB845943C2B1 Content-Type: text/plain; charset=iso-8859-15; name="pci.4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pci.4.patch" Index: include/asm-mips/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips/pci.h,v retrieving revision 1.24.2.10 diff -u -r1.24.2.10 pci.h --- include/asm-mips/pci.h 2002/08/07 03:33:30 1.24.2.10 +++ include/asm-mips/pci.h 2002/08/07 08:06:54 @@ -120,8 +120,8 @@ if (direction != PCI_DMA_TODEVICE) { unsigned long addr; - addr = bus_to_virt(baddr_to_bus(hwdev, dma_address)); - dma_cache_back_inv(addr, size); + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev, dma_addr)); + dma_cache_wback_inv(addr, size); } } @@ -153,8 +153,8 @@ if (direction != PCI_DMA_TODEVICE) { unsigned long addr; - addr = bus_to_virt(baddr_to_bus(hwdev, dma_address)); - dma_cache_back_inv(addr, size); + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev, dma_address)); + dma_cache_wback_inv(addr, size); } } @@ -255,7 +255,7 @@ if (direction == PCI_DMA_NONE) out_of_line_bug(); - addr = dma_handle - bus_to_baddr(hwdev->bus->number) + PAGE_OFFSET; + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev->bus->number, dma_handle)); dma_cache_wback_inv(addr, size); } Index: include/asm-mips64/pci.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/pci.h,v retrieving revision 1.16.2.11 diff -u -r1.16.2.11 pci.h --- include/asm-mips64/pci.h 2002/08/07 03:33:30 1.16.2.11 +++ include/asm-mips64/pci.h 2002/08/07 08:06:55 @@ -146,8 +146,8 @@ if (direction != PCI_DMA_TODEVICE) { unsigned long addr; - addr = bus_to_virt(baddr_to_bus(hwdev, dma_address)); - dma_cache_back_inv(addr, size); + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev, dma_addr)); + dma_cache_wback_inv(addr, size); } } @@ -187,8 +187,8 @@ if (direction != PCI_DMA_TODEVICE) { unsigned long addr; - addr = bus_to_virt(baddr_to_bus(hwdev, dma_address)); - dma_cache_back_inv(addr, size); + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev, dma_address)); + dma_cache_wback_inv(addr, size); } } @@ -281,7 +281,7 @@ if (direction == PCI_DMA_NONE) out_of_line_bug(); - addr = dma_handle - bus_to_baddr(hwdev->bus->number) + PAGE_OFFSET; + addr = (dma_addr_t)bus_to_virt(baddr_to_bus(hwdev->bus->number, dma_handle)); dma_cache_wback_inv(addr, size); } --------------08E27668F641EB845943C2B1-- From owner-linux-mips@oss.sgi.com Wed Aug 7 02:53:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g779rORw030666 for ; Wed, 7 Aug 2002 02:53:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g779rOWr030665 for linux-mips-outgoing; Wed, 7 Aug 2002 02:53: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.5/8.12.5) with SMTP id g779qnRw030638; Wed, 7 Aug 2002 02:52:49 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g779s8Xb015294; Wed, 7 Aug 2002 02:54:08 -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 CAA23864; Wed, 7 Aug 2002 02:54:08 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g779s8b20146; Wed, 7 Aug 2002 11:54:09 +0200 (MEST) Message-ID: <3D50EE40.A4B44B4B@mips.com> Date: Wed, 07 Aug 2002 11:54:08 +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 , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: siginfo structure in 64-bit kernel Content-Type: multipart/mixed; boundary="------------A08090B0506A55B1C01F1226" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6652 Lines: 240 This is a multi-part message in MIME format. --------------A08090B0506A55B1C01F1226 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The siginfo structure is containing longs, which isn't consistent between o32 and n64. So we need a routine to convert siginfo from 64-bit to 32-bit, when we are running a 64-bit kernel on o32 userland. Please take a look at the 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 --------------A08090B0506A55B1C01F1226 Content-Type: text/plain; charset=iso-8859-15; name="siginfo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="siginfo.patch" Index: arch/mips64/kernel/signal32.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/signal32.c,v retrieving revision 1.20.2.7 diff -u -r1.20.2.7 signal32.c --- arch/mips64/kernel/signal32.c 2002/08/05 23:53:36 1.20.2.7 +++ arch/mips64/kernel/signal32.c 2002/08/07 08:52:00 @@ -360,13 +360,55 @@ sigset_t sf_mask; }; -struct rt_sigframe { +struct rt_sigframe32 { u32 rs_ass[4]; /* argument save space for o32 */ u32 rs_code[2]; /* signal trampoline */ - struct siginfo rs_info; + struct siginfo32 rs_info; struct ucontext rs_uc; }; +static int copy_siginfo_to_user32(siginfo_t32 *to, siginfo_t *from) +{ + int err; + + if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t32))) + return -EFAULT; + + /* If you change siginfo_t structure, please be sure + this code is fixed accordingly. + It should never copy any pad contained in the structure + to avoid security leaks, but must copy the generic + 3 ints plus the relevant union member. + This routine must convert siginfo from 64bit to 32bit as well + at the same time. */ + err = __put_user(from->si_signo, &to->si_signo); + err |= __put_user(from->si_errno, &to->si_errno); + err |= __put_user((short)from->si_code, &to->si_code); + if (from->si_code < 0) + err |= __copy_to_user(&to->_sifields._pad, &from->_sifields._pad, SI_PAD_SIZE); + else { + switch (from->si_code >> 16) { + case __SI_CHLD >> 16: + err |= __put_user(from->si_utime, &to->si_utime); + err |= __put_user(from->si_stime, &to->si_stime); + err |= __put_user(from->si_status, &to->si_status); + default: + err |= __put_user(from->si_pid, &to->si_pid); + err |= __put_user(from->si_uid, &to->si_uid); + break; + case __SI_FAULT >> 16: + err |= __put_user((long)from->si_addr, &to->si_addr); + break; + case __SI_POLL >> 16: + err |= __put_user(from->si_band, &to->si_band); + err |= __put_user(from->si_fd, &to->si_fd); + break; + /* case __SI_RT: This is not generated by the kernel as of now. */ + } + } + return err; +} + asmlinkage void sys32_sigreturn(abi64_no_regargs, struct pt_regs regs) { struct sigframe *frame; @@ -405,11 +447,11 @@ asmlinkage void sys32_rt_sigreturn(abi64_no_regargs, struct pt_regs regs) { - struct rt_sigframe *frame; + struct rt_sigframe32 *frame; sigset_t set; stack_t st; - frame = (struct rt_sigframe *) regs.regs[29]; + frame = (struct rt_sigframe32 *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) goto badframe; if (__copy_from_user(&set, &frame->rs_uc.uc_sigmask, sizeof(set))) @@ -588,7 +630,7 @@ struct pt_regs *regs, int signr, sigset_t *set, siginfo_t *info) { - struct rt_sigframe *frame; + struct rt_sigframe32 *frame; int err = 0; frame = get_sigframe(ka, regs, sizeof(*frame)); @@ -613,8 +655,8 @@ flush_cache_sigtramp((unsigned long) frame->rs_code); } - /* Create siginfo. */ - err |= __copy_to_user(&frame->rs_info, info, sizeof(*info)); + /* Convert (siginfo_t -> siginfo_t32) and copy to user. */ + err |= copy_siginfo_to_user32(&frame->rs_info,info); /* Create the ucontext. */ err |= __put_user(0, &frame->rs_uc.uc_flags); @@ -639,7 +681,7 @@ * a2 = pointer to ucontext * * $25 and c0_epc point to the signal handler, $29 points to - * the struct rt_sigframe. + * the struct rt_sigframe32. */ regs->regs[ 4] = signr; regs->regs[ 5] = (unsigned long) &frame->rs_info; Index: include/asm-mips64/siginfo.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/siginfo.h,v retrieving revision 1.6.2.2 diff -u -r1.6.2.2 siginfo.h --- include/asm-mips64/siginfo.h 2002/08/05 23:53:39 1.6.2.2 +++ include/asm-mips64/siginfo.h 2002/08/07 08:52:16 @@ -18,11 +18,21 @@ void *sival_ptr; } sigval_t; +#ifdef __KERNEL__ + +typedef union sigval32 { + int sival_int; + u32 sival_ptr; +} sigval_t32; + +#endif /* __KERNEL__ */ + /* This structure matches IRIX 32/n32 ABIs for binary compatibility but has Linux extensions. */ #define SI_MAX_SIZE 128 -#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 3) +#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 4) +#define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3) typedef struct siginfo { int si_signo; @@ -81,6 +91,67 @@ } _sifields; } siginfo_t; + +#ifdef __KERNEL__ + +typedef struct siginfo32 { + int si_signo; + int si_errno; + int si_code; + union { + int _pad[SI_PAD_SIZE32]; + + /* kill() */ + struct { + __kernel_pid_t32 _pid; /* sender's pid */ + __kernel_uid_t32 _uid; /* sender's uid */ + } _kill; + + /* SIGCHLD */ + struct { + __kernel_pid_t32 _pid; /* which child */ + __kernel_uid_t32 _uid; /* sender's uid */ + __kernel_clock_t32 _utime; + int _status; /* exit code */ + __kernel_clock_t32 _stime; + } _sigchld; + + /* IRIX SIGCHLD */ + struct { + __kernel_pid_t32 _pid; /* which child */ + __kernel_clock_t32 _utime; + int _status; /* exit code */ + __kernel_clock_t32 _stime; + } _irix_sigchld; + + /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */ + struct { + u32 _addr; /* faulting insn/memory ref. */ + } _sigfault; + + /* SIGPOLL, SIGXFSZ (To do ...) */ + struct { + int _band; /* POLL_IN, POLL_OUT, POLL_MSG */ + int _fd; + } _sigpoll; + + /* POSIX.1b timers */ + struct { + unsigned int _timer1; + unsigned int _timer2; + } _timer; + + /* POSIX.1b signals */ + struct { + __kernel_pid_t32 _pid; /* sender's pid */ + __kernel_uid_t32 _uid; /* sender's uid */ + sigval_t32 _sigval; + } _rt; + + } _sifields; +} siginfo_t32; + +#endif /* __KERNEL__ */ /* * How these fields are to be accessed. --------------A08090B0506A55B1C01F1226-- From owner-linux-mips@oss.sgi.com Wed Aug 7 04:05:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77B5HRw032515 for ; Wed, 7 Aug 2002 04:05:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77B5HHl032514 for linux-mips-outgoing; Wed, 7 Aug 2002 04:05:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft19-f33.dialo.tiscali.de [62.246.19.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g77B59Rw032504 for ; Wed, 7 Aug 2002 04:05:11 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g77A9cp13920; Wed, 7 Aug 2002 12:09:38 +0200 Date: Wed, 7 Aug 2002 12:09:38 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: PCI patch of the day Message-ID: <20020807120938.A13850@dea.linux-mips.net> References: <3D50D857.E2DDC84F@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: <3D50D857.E2DDC84F@mips.com>; from carstenl@mips.com on Wed, Aug 07, 2002 at 10:20:39AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 667 Lines: 16 On Wed, Aug 07, 2002 at 10:20:39AM +0200, Carsten Langgaard wrote: > It's apparently not that easy to get the PCI code right, the current > code won't compile, so here is the patch of the day. Sigh, yes. The whole flushing thing was done improperly and the patches to fix that which I was integrating last night were not right either. The big question for me is why nobody was complaining or is suddently everybody only using coherent machines ... And all the DAC stuff also wants to be implemented. We've got a bunch of cruel hacks for the sake of IP27 and want to get rid of those. The god news is that now 32-bit and 64-bit pci.h are identical :-) Ralf From owner-linux-mips@oss.sgi.com Wed Aug 7 04:47:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77BlJRw000621 for ; Wed, 7 Aug 2002 04:47:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77BlJCs000620 for linux-mips-outgoing; Wed, 7 Aug 2002 04:47: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.5/8.12.5) with SMTP id g77BlBRw000611; Wed, 7 Aug 2002 04:47:12 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA18583; Wed, 7 Aug 2002 13:49:40 +0200 (MET DST) Date: Wed, 7 Aug 2002 13:49:40 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: siginfo structure in 64-bit kernel In-Reply-To: <3D50EE40.A4B44B4B@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 676 Lines: 19 On Wed, 7 Aug 2002, Carsten Langgaard wrote: > The siginfo structure is containing longs, which isn't consistent > between o32 and n64. > So we need a routine to convert siginfo from 64-bit to 32-bit, when we > are running a 64-bit kernel on o32 userland. Yep, I've noticed we don't get it quite right recently, too. > Please take a look at the patch below. It looks good in principle, but please use signed types for addresses. I'll check the patch at run-time later. -- + 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 Aug 7 05:09:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77C9NRw001064 for ; Wed, 7 Aug 2002 05:09:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77C9NPa001063 for linux-mips-outgoing; Wed, 7 Aug 2002 05:09:23 -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.5/8.12.5) with SMTP id g77C9HRw001053 for ; Wed, 7 Aug 2002 05:09:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA18963; Wed, 7 Aug 2002 14:11:47 +0200 (MET DST) Date: Wed, 7 Aug 2002 14:11:47 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Brian Murphy cc: linux-mips@oss.sgi.com Subject: Re: [2.5 patch] R5K SC support In-Reply-To: <3D5025AC.9020203@murphy.dk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 461 Lines: 14 On Tue, 6 Aug 2002, Brian Murphy wrote: > On the other hand with the application of this (attached) patch the > cache is > detected correctly and appropriate routines are selected. Hmm, I bet you wanted to put the code to arch/mips/mm/c-r5k.c, didn't you? -- + 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 Aug 7 07:41:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77EffRw004342 for ; Wed, 7 Aug 2002 07:41:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77Efflw004341 for linux-mips-outgoing; Wed, 7 Aug 2002 07:41: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.5/8.12.5) with SMTP id g77EesRw004250; Wed, 7 Aug 2002 07:40:55 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g77EgFXb015996; Wed, 7 Aug 2002 07:42:15 -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 HAA02593; Wed, 7 Aug 2002 07:42:16 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g77EgFb11645; Wed, 7 Aug 2002 16:42:16 +0200 (MEST) Message-ID: <3D5131C7.17F9E00@mips.com> Date: Wed, 07 Aug 2002 16:42: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: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: IPC syscall fixup (o32 conversion layer) Content-Type: multipart/mixed; boundary="------------6B1ECBD578E3C6C296058FA1" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10460 Lines: 340 This is a multi-part message in MIME format. --------------6B1ECBD578E3C6C296058FA1 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Here is a patch that fixes the ipc syscalls in the o32 wrapper/conversion routines. Needed when running a 64-bit kernel on an o32 userland. /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 --------------6B1ECBD578E3C6C296058FA1 Content-Type: text/plain; charset=iso-8859-15; name="linux32.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux32.patch" Index: arch/mips64/kernel/linux32.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/linux32.c,v retrieving revision 1.42.2.9 diff -u -r1.42.2.9 linux32.c --- arch/mips64/kernel/linux32.c 2002/07/23 12:26:09 1.42.2.9 +++ arch/mips64/kernel/linux32.c 2002/08/07 14:28:03 @@ -35,8 +35,16 @@ #include #include - +/* Use this to get at 32-bit user passed pointers. */ +/* A() macro should be used for places where you e.g. + have some internal variable u32 and just want to get + rid of a compiler warning. AA() has to be used in + places where you want to convert a function argument + to 32bit pointer or when you e.g. access pt_regs + structure and want to consider 32bit registers only. + */ #define A(__x) ((unsigned long)(__x)) +#define AA(__x) ((unsigned long)((int)__x)) #ifdef __MIPSEB__ #define merge_64(r1,r2) ((((r1) & 0xffffffffUL) << 32) + ((r2) & 0xffffffffUL)) @@ -1494,6 +1502,19 @@ unsigned short seq; }; +struct ipc64_perm32 { + key_t key; + __kernel_uid_t32 uid; + __kernel_gid_t32 gid; + __kernel_uid_t32 cuid; + __kernel_gid_t32 cgid; + __kernel_mode_t32 mode; + unsigned short seq; + unsigned short __pad1; + unsigned int __unused1; + unsigned int __unused2; +}; + struct semid_ds32 { struct ipc_perm32 sem_perm; /* permissions .. see ipc.h */ __kernel_time_t32 sem_otime; /* last semop time */ @@ -1522,6 +1543,23 @@ __kernel_ipc_pid_t32 msg_lrpid; }; +struct msqid64_ds32 { + struct ipc64_perm32 msg_perm; + __kernel_time_t32 msg_stime; + unsigned int __unused1; + __kernel_time_t32 msg_rtime; + unsigned int __unused2; + __kernel_time_t32 msg_ctime; + unsigned int __unused3; + unsigned int msg_cbytes; + unsigned int msg_qnum; + unsigned int msg_qbytes; + __kernel_pid_t32 msg_lspid; + __kernel_pid_t32 msg_lrpid; + unsigned int __unused4; + unsigned int __unused5; +}; + struct shmid_ds32 { struct ipc_perm32 shm_perm; int shm_segsz; @@ -1533,9 +1571,25 @@ unsigned short shm_nattch; }; +struct ipc_kludge32 { + u32 msgp; + s32 msgtyp; +}; + #define IPCOP_MASK(__x) (1UL << (__x)) static int +ipc_parse_version32(int *cmd) +{ + if (*cmd & IPC_64) { + *cmd ^= IPC_64; + return IPC_64; + } else { + return IPC_OLD; + } +} + +static int do_sys32_semctl(int first, int second, int third, void *uptr) { union semun fourth; @@ -1603,12 +1657,15 @@ static int do_sys32_msgsnd (int first, int second, int third, void *uptr) { - struct msgbuf *p = kmalloc (second + sizeof (struct msgbuf) - + 4, GFP_USER); struct msgbuf32 *up = (struct msgbuf32 *)uptr; + struct msgbuf *p; mm_segment_t old_fs; int err; + if (second < 0) + return -EINVAL; + p = kmalloc (second + sizeof (struct msgbuf) + + 4, GFP_USER); if (!p) return -ENOMEM; err = get_user (p->mtype, &up->mtype); @@ -1636,18 +1693,21 @@ int err; if (!version) { - struct ipc_kludge *uipck = (struct ipc_kludge *)uptr; - struct ipc_kludge ipck; + struct ipc_kludge32 *uipck = (struct ipc_kludge32 *)uptr; + struct ipc_kludge32 ipck; err = -EINVAL; if (!uptr) goto out; err = -EFAULT; - if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge))) + if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge32))) goto out; - uptr = (void *)A(ipck.msgp); + uptr = (void *)AA(ipck.msgp); msgtyp = ipck.msgtyp; } + + if (second < 0) + return -EINVAL; err = -ENOMEM; p = kmalloc (second + sizeof (struct msgbuf) + 4, GFP_USER); if (!p) @@ -1673,9 +1733,10 @@ { int err = -EINVAL, err2; struct msqid_ds m; - struct msqid64_ds m64; - struct msqid_ds32 *up = (struct msqid_ds32 *)uptr; + struct msqid_ds32 *up32 = (struct msqid_ds32 *)uptr; + struct msqid64_ds32 *up64 = (struct msqid64_ds32 *)uptr; mm_segment_t old_fs; + int version = ipc_parse_version32(&second); switch (second) { @@ -1686,10 +1747,25 @@ break; case IPC_SET: - err = get_user (m.msg_perm.uid, &up->msg_perm.uid); - err |= __get_user (m.msg_perm.gid, &up->msg_perm.gid); - err |= __get_user (m.msg_perm.mode, &up->msg_perm.mode); - err |= __get_user (m.msg_qbytes, &up->msg_qbytes); + if (version == IPC_64) { + if (!access_ok(VERIFY_READ, up64, sizeof(*up64))) { + err = -EFAULT; + break; + } + err = __get_user(m.msg_perm.uid, &up64->msg_perm.uid); + err |= __get_user(m.msg_perm.gid, &up64->msg_perm.gid); + err |= __get_user(m.msg_perm.mode, &up64->msg_perm.mode); + err |= __get_user(m.msg_qbytes, &up64->msg_qbytes); + } else { + if (!access_ok(VERIFY_READ, up32, sizeof(*up32))) { + err = -EFAULT; + break; + } + err = __get_user(m.msg_perm.uid, &up32->msg_perm.uid); + err |= __get_user(m.msg_perm.gid, &up32->msg_perm.gid); + err |= __get_user(m.msg_perm.mode, &up32->msg_perm.mode); + err |= __get_user(m.msg_qbytes, &up32->msg_qbytes); + } if (err) break; old_fs = get_fs (); @@ -1702,27 +1778,54 @@ case MSG_STAT: old_fs = get_fs (); set_fs (KERNEL_DS); - err = sys_msgctl (first, second, (void *) &m64); + err = sys_msgctl (first, second, &m); set_fs (old_fs); - err2 = put_user (m64.msg_perm.key, &up->msg_perm.key); - err2 |= __put_user(m64.msg_perm.uid, &up->msg_perm.uid); - err2 |= __put_user(m64.msg_perm.gid, &up->msg_perm.gid); - err2 |= __put_user(m64.msg_perm.cuid, &up->msg_perm.cuid); - err2 |= __put_user(m64.msg_perm.cgid, &up->msg_perm.cgid); - err2 |= __put_user(m64.msg_perm.mode, &up->msg_perm.mode); - err2 |= __put_user(m64.msg_perm.seq, &up->msg_perm.seq); - err2 |= __put_user(m64.msg_stime, &up->msg_stime); - err2 |= __put_user(m64.msg_rtime, &up->msg_rtime); - err2 |= __put_user(m64.msg_ctime, &up->msg_ctime); - err2 |= __put_user(m64.msg_cbytes, &up->msg_cbytes); - err2 |= __put_user(m64.msg_qnum, &up->msg_qnum); - err2 |= __put_user(m64.msg_qbytes, &up->msg_qbytes); - err2 |= __put_user(m64.msg_lspid, &up->msg_lspid); - err2 |= __put_user(m64.msg_lrpid, &up->msg_lrpid); - if (err2) - err = -EFAULT; + if (version == IPC_64) { + if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) { + err = -EFAULT; + break; + } + err2 = __put_user(m.msg_perm.key, &up64->msg_perm.key); + err2 |= __put_user(m.msg_perm.uid, &up64->msg_perm.uid); + err2 |= __put_user(m.msg_perm.gid, &up64->msg_perm.gid); + err2 |= __put_user(m.msg_perm.cuid, &up64->msg_perm.cuid); + err2 |= __put_user(m.msg_perm.cgid, &up64->msg_perm.cgid); + err2 |= __put_user(m.msg_perm.mode, &up64->msg_perm.mode); + err2 |= __put_user(m.msg_perm.seq, &up64->msg_perm.seq); + err2 |= __put_user(m.msg_stime, &up64->msg_stime); + err2 |= __put_user(m.msg_rtime, &up64->msg_rtime); + err2 |= __put_user(m.msg_ctime, &up64->msg_ctime); + err2 |= __put_user(m.msg_cbytes, &up64->msg_cbytes); + err2 |= __put_user(m.msg_qnum, &up64->msg_qnum); + err2 |= __put_user(m.msg_qbytes, &up64->msg_qbytes); + err2 |= __put_user(m.msg_lspid, &up64->msg_lspid); + err2 |= __put_user(m.msg_lrpid, &up64->msg_lrpid); + if (err2) + err = -EFAULT; + } else { + if (!access_ok(VERIFY_WRITE, up32, sizeof(*up32))) { + err = -EFAULT; + break; + } + err2 = __put_user(m.msg_perm.key, &up32->msg_perm.key); + err2 |= __put_user(m.msg_perm.uid, &up32->msg_perm.uid); + err2 |= __put_user(m.msg_perm.gid, &up32->msg_perm.gid); + err2 |= __put_user(m.msg_perm.cuid, &up32->msg_perm.cuid); + err2 |= __put_user(m.msg_perm.cgid, &up32->msg_perm.cgid); + err2 |= __put_user(m.msg_perm.mode, &up32->msg_perm.mode); + err2 |= __put_user(m.msg_perm.seq, &up32->msg_perm.seq); + err2 |= __put_user(m.msg_stime, &up32->msg_stime); + err2 |= __put_user(m.msg_rtime, &up32->msg_rtime); + err2 |= __put_user(m.msg_ctime, &up32->msg_ctime); + err2 |= __put_user(m.msg_cbytes, &up32->msg_cbytes); + err2 |= __put_user(m.msg_qnum, &up32->msg_qnum); + err2 |= __put_user(m.msg_qbytes, &up32->msg_qbytes); + err2 |= __put_user(m.msg_lspid, &up32->msg_lspid); + err2 |= __put_user(m.msg_lrpid, &up32->msg_lrpid); + if (err2) + err = -EFAULT; + } break; - } return err; @@ -1845,7 +1948,7 @@ case SEMOP: /* struct sembuf is the same on 32 and 64bit :)) */ - err = sys_semop (first, (struct sembuf *)A(ptr), + err = sys_semop (first, (struct sembuf *)AA(ptr), second); break; case SEMGET: @@ -1853,36 +1956,36 @@ break; case SEMCTL: err = do_sys32_semctl (first, second, third, - (void *)A(ptr)); + (void *)AA(ptr)); break; case MSGSND: err = do_sys32_msgsnd (first, second, third, - (void *)A(ptr)); + (void *)AA(ptr)); break; case MSGRCV: err = do_sys32_msgrcv (first, second, fifth, third, - version, (void *)A(ptr)); + version, (void *)AA(ptr)); break; case MSGGET: err = sys_msgget ((key_t) first, second); break; case MSGCTL: - err = do_sys32_msgctl (first, second, (void *)A(ptr)); + err = do_sys32_msgctl (first, second, (void *)AA(ptr)); break; case SHMAT: err = do_sys32_shmat (first, second, third, - version, (void *)A(ptr)); + version, (void *)AA(ptr)); break; case SHMDT: - err = sys_shmdt ((char *)A(ptr)); + err = sys_shmdt ((char *)AA(ptr)); break; case SHMGET: err = sys_shmget (first, second, third); break; case SHMCTL: - err = do_sys32_shmctl (first, second, (void *)A(ptr)); + err = do_sys32_shmctl (first, second, (void *)AA(ptr)); break; default: err = -EINVAL; --------------6B1ECBD578E3C6C296058FA1-- From owner-linux-mips@oss.sgi.com Wed Aug 7 07:56:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77EuDRw004665 for ; Wed, 7 Aug 2002 07:56:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77EuDEa004664 for linux-mips-outgoing; Wed, 7 Aug 2002 07:56:13 -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.5/8.12.5) with SMTP id g77Eu3Rw004645; Wed, 7 Aug 2002 07:56:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA21584; Wed, 7 Aug 2002 16:58:32 +0200 (MET DST) Date: Wed, 7 Aug 2002 16:58:32 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) In-Reply-To: <3D5131C7.17F9E00@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 848 Lines: 30 On Wed, 7 Aug 2002, Carsten Langgaard wrote: > Here is a patch that fixes the ipc syscalls in the o32 > wrapper/conversion routines. > Needed when running a 64-bit kernel on an o32 userland. Hmm, this looks dubious: +#define AA(__x) ((unsigned long)((int)__x)) You probably want either: ((unsigned long)((unsigned int)__x)) or ((long)((int)__x)). Since you are using pointers, likely the latter. Sending patches within a mail's body would ease commenting them, BTW. I had to copy and paste the line above manually -- with gpm it's not a big problem for a single line, but it gets tedious for larger chunks and gpm is not everywhere. -- + 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 Aug 7 08:02:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77F2lRw004914 for ; Wed, 7 Aug 2002 08:02:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77F2lqi004913 for linux-mips-outgoing; Wed, 7 Aug 2002 08:02:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sbrodie.cam.pace.co.uk (host-33-223.pace.co.uk [136.170.33.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g77F2gRw004901 for ; Wed, 7 Aug 2002 08:02:43 -0700 Received: from loopback ([127.0.0.1]) by sbrodie.cam.pace.co.uk with SMTP; Wed, 07 Aug 2002 15:04:42 GMT Date: Wed, 07 Aug 2002 16:04:16 +0100 From: Stewart Brodie To: linux-mips@oss.sgi.com Message-ID: <0de052624b.sbrodie@sbrodie.cam.pace.co.uk> X-Organization: Pace Micro Technology plc User-Agent: Messenger-Pro/2.59beta2 (Newsbase/0.61b) (RISC-OS/4.00-Ursula002f) Subject: CONFIG_MIPS32 implies CONFIG_CPU_HAS_PREFETCH X-Editor: Zap, using ZapEmail 0.22 (27 Nov 1998) patch-3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1070 Lines: 21 linux_2_4 branch question: In config-shared.in, and previously in config.in, whether or not the CPU has prefetch instructions seems to be dependent only on whether CONFIG_MIPS32 is y. However, this causes our kernel builds to die when compiling memcpy.S because the compiler is objecting to the pref/prefx instructions. The gcc 2.96 compiler options we are using are -mtune=r4600 and -mips2. Is it simply the case that the processors on all the boards supported in the MIPS builds all support prefetch? At the moment, I've just put a specific check in for our particular processor to stop CONFIG_CPU_HAS_PREFETCH from being set to y and that stops the problem. In earlier (2.4.17 pre-release) kernels, whether or not to define PREF/PREFX as pref/prefx or the empty string was determined on a stricter set of criteria based around actual CPU types rather than a blanket check on being a 32-bit MIPS. -- Stewart Brodie, Senior Software Engineer Pace Micro Technology PLC 645 Newmarket Road Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/ From owner-linux-mips@oss.sgi.com Wed Aug 7 08:14:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77FE9Rw005234 for ; Wed, 7 Aug 2002 08:14:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77FE890005233 for linux-mips-outgoing; Wed, 7 Aug 2002 08:14:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft19-f76.dialo.tiscali.de [62.246.19.76]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g77FDKRw005215 for ; Wed, 7 Aug 2002 08:13:47 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g77FDF916652; Wed, 7 Aug 2002 17:13:15 +0200 Date: Wed, 7 Aug 2002 17:13:15 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) Message-ID: <20020807171315.A16633@dea.linux-mips.net> References: <3D5131C7.17F9E00@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 Wed, Aug 07, 2002 at 04:58:32PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 581 Lines: 16 On Wed, Aug 07, 2002 at 04:58:32PM +0200, Maciej W. Rozycki wrote: > Sending patches within a mail's body would ease commenting them, BTW. I > had to copy and paste the line above manually -- with gpm it's not a big > problem for a single line, but it gets tedious for larger chunks and gpm > is not everywhere. Carsten is using Mozilla which garbles patches, so he's forced to use attachments. (Doesn't change the fact that imho Mozilla is a horribly slow mailer that needs forces to use of the mouse for more than activating the window - but that's his choice :-) Ralf From owner-linux-mips@oss.sgi.com Wed Aug 7 08:22:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77FM5Rw005424 for ; Wed, 7 Aug 2002 08:22:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77FM5Gu005423 for linux-mips-outgoing; Wed, 7 Aug 2002 08:22: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.5/8.12.5) with SMTP id g77FLuRw005409; Wed, 7 Aug 2002 08:21:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA21994; Wed, 7 Aug 2002 17:24:28 +0200 (MET DST) Date: Wed, 7 Aug 2002 17:24:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) In-Reply-To: <20020807171315.A16633@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 740 Lines: 20 On Wed, 7 Aug 2002, Ralf Baechle wrote: > Carsten is using Mozilla which garbles patches, so he's forced to use > attachments. Well, sources to the program are available, so that can be fixed. I'm not sure it's worth the effort, though... > (Doesn't change the fact that imho Mozilla is a horribly slow mailer > that needs forces to use of the mouse for more than activating the > window - but that's his choice :-) Moreover, it requires X11, which can be a major PITA (when running remotely) or a showstopper (on a text terminal). -- + 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 Aug 7 08:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77FNjRw005525 for ; Wed, 7 Aug 2002 08:23:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77FNjdx005524 for linux-mips-outgoing; Wed, 7 Aug 2002 08:23: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 (shaft19-f76.dialo.tiscali.de [62.246.19.76]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g77FNcRw005515 for ; Wed, 7 Aug 2002 08:23:39 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g77FPV716777; Wed, 7 Aug 2002 17:25:31 +0200 Date: Wed, 7 Aug 2002 17:25:31 +0200 From: Ralf Baechle To: Stewart Brodie Cc: linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS32 implies CONFIG_CPU_HAS_PREFETCH Message-ID: <20020807172531.A16609@dea.linux-mips.net> References: <0de052624b.sbrodie@sbrodie.cam.pace.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0de052624b.sbrodie@sbrodie.cam.pace.co.uk>; from stewart.brodie@pace.co.uk on Wed, Aug 07, 2002 at 04:04:16PM +0100 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1320 Lines: 25 On Wed, Aug 07, 2002 at 04:04:16PM +0100, Stewart Brodie wrote: > linux_2_4 branch question: In config-shared.in, and previously in config.in, > whether or not the CPU has prefetch instructions seems to be dependent only > on whether CONFIG_MIPS32 is y. However, this causes our kernel builds to die > when compiling memcpy.S because the compiler is objecting to the pref/prefx > instructions. The gcc 2.96 compiler options we are using are -mtune=r4600 > and -mips2. > > Is it simply the case that the processors on all the boards supported in the > MIPS builds all support prefetch? At the moment, I've just put a specific > check in for our particular processor to stop CONFIG_CPU_HAS_PREFETCH from > being set to y and that stops the problem. In earlier (2.4.17 pre-release) > kernels, whether or not to define PREF/PREFX as pref/prefx or the empty > string was determined on a stricter set of criteria based around actual CPU > types rather than a blanket check on being a 32-bit MIPS. The MIPS32 architecture specifies a prefetch instruction. So it's correct (though not necessarily alway the most efficient thing) to assume your system has this instruction available. The compiler option -mips2 which you're specifying however tells the tools that you do not have that instruction, so is wrong. Ralf From owner-linux-mips@oss.sgi.com Wed Aug 7 08:39:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77FdIRw005974 for ; Wed, 7 Aug 2002 08:39:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77FdICf005973 for linux-mips-outgoing; Wed, 7 Aug 2002 08:39:18 -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.5/8.12.5) with SMTP id g77Fd5Rw005963 for ; Wed, 7 Aug 2002 08:39:06 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22271; Wed, 7 Aug 2002 17:41:30 +0200 (MET DST) Date: Wed, 7 Aug 2002 17:41:29 +0200 (MET DST) From: "Maciej W. Rozycki" To: Stewart Brodie cc: linux-mips@oss.sgi.com Subject: Re: CONFIG_MIPS32 implies CONFIG_CPU_HAS_PREFETCH In-Reply-To: <0de052624b.sbrodie@sbrodie.cam.pace.co.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2636 Lines: 71 On Wed, 7 Aug 2002, Stewart Brodie wrote: > linux_2_4 branch question: In config-shared.in, and previously in config.in, > whether or not the CPU has prefetch instructions seems to be dependent only > on whether CONFIG_MIPS32 is y. However, this causes our kernel builds to die Well, what I see is CONFIG_CPU_HAS_PREFETCH is set for the following CPU selection options: - CONFIG_CPU_MIPS32, - CONFIG_CPU_MIPS64, - CONFIG_CPU_RM7000, - CONFIG_CPU_SB1, presumably because they support prefetching instructions. > when compiling memcpy.S because the compiler is objecting to the pref/prefx > instructions. The gcc 2.96 compiler options we are using are -mtune=r4600 > and -mips2. Check you have a sufficiently new version of binutils -- the instructions are guarded by ".set mips4", so they should be assembled just fine regardless of the options passed to as. What is the exact error message printed (the usual first question, sigh...)? > Is it simply the case that the processors on all the boards supported in the > MIPS builds all support prefetch? At the moment, I've just put a specific > check in for our particular processor to stop CONFIG_CPU_HAS_PREFETCH from > being set to y and that stops the problem. In earlier (2.4.17 pre-release) > kernels, whether or not to define PREF/PREFX as pref/prefx or the empty > string was determined on a stricter set of criteria based around actual CPU > types rather than a blanket check on being a 32-bit MIPS. Please make sure you have a clean checkout of the CVS tree -- here is an extract of the relevant part of current config-shared.in from the 2.4 branch: if [ "$CONFIG_CPU_MIPS32" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE fi if [ "$CONFIG_CPU_MIPS64" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE fi if [ "$CONFIG_CPU_RM7000" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y fi 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 define_bool CONFIG_CPU_HAS_PREFETCH y fi as you might see there is no CONFIG_MIPS32 dependency anywhere (also the kernel works for the R3k, which definitely lacks prefetching intructions). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Wed Aug 7 09:36:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g77GafRw006685 for ; Wed, 7 Aug 2002 09:36:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g77Gaf0T006684 for linux-mips-outgoing; Wed, 7 Aug 2002 09:36:41 -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.5/8.12.5) with SMTP id g77GaWRw006675; Wed, 7 Aug 2002 09:36:32 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g77GcSo06346; Wed, 7 Aug 2002 09:38:28 -0700 Date: Wed, 7 Aug 2002 09:38:28 -0700 From: William Jhun To: Ralf Baechle Cc: Carsten Langgaard , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: PCI patch of the day Message-ID: <20020807093828.A6317@ayrnetworks.com> References: <3D50D857.E2DDC84F@mips.com> <20020807120938.A13850@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: <20020807120938.A13850@dea.linux-mips.net>; from ralf@oss.sgi.com on Wed, Aug 07, 2002 at 12:09:38PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1741 Lines: 42 Ralf, Will the *_dma_cache_wback() routines ever be implemented? I sent out a set of patches a while ago that defaults them to calling _wback_inv() instead of calling panic(). Additionally I sent out some PCI DMA coherency patches that would, for pci_map_*(): - Invalidate if DMAing from the device - Writeback if DMAing to the device - Writeback/Invalidate if bidirectional pci_dma_sync_*() was changed to simply invalidate if DMAing from the device or bidirectional. Conceivably, the pci_unmap_*() should invalidate as well, since the following could happen: - pci_dma_sync_*() - driver reads out of buffer - DMA happens again - pci_unmap_*() - buffer cachelines better be invalidated! Not to mention that the whole PCI DMA interface is inherently broken. I've cogitated on this and sent patches to those responsible, but was told to buzz off. The above is a good example of this broken-ness: you'll have an extra invalidate for no reason if you never end up using pci_dma_sync_*() but just simply map, DMA and unmap. Otherwise, it'll be broken for the pci_dma_sync_*() case. And I've already went on before about how streaming mappings are broken for PCI_DMA_TODEVICE when re-using one buffer. I've already spent a lot of time trying to sort this out and get the patches right, but since I received almost zero response I dropped it. Apparently it's still broken enough to need further attention. Will On Wed, Aug 07, 2002 at 12:09:38PM +0200, Ralf Baechle wrote: > Sigh, yes. The whole flushing thing was done improperly and the patches > to fix that which I was integrating last night were not right either. The > big question for me is why nobody was complaining or is suddently everybody > only using coherent machines ... From owner-linux-mips@oss.sgi.com Wed Aug 7 23:56:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g786udRw000870 for ; Wed, 7 Aug 2002 23:56:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g786ucwg000869 for linux-mips-outgoing; Wed, 7 Aug 2002 23:56: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.5/8.12.5) with SMTP id g786uMRw000858; Wed, 7 Aug 2002 23:56:22 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g786veXb019491; Wed, 7 Aug 2002 23:57: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 XAA07942; Wed, 7 Aug 2002 23:57: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 g786vhb02622; Thu, 8 Aug 2002 08:57:43 +0200 (MEST) Message-ID: <3D521667.AE4FA491@mips.com> Date: Thu, 08 Aug 2002 08:57:43 +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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1564 Lines: 54 "Maciej W. Rozycki" wrote: > On Wed, 7 Aug 2002, Carsten Langgaard wrote: > > > Here is a patch that fixes the ipc syscalls in the o32 > > wrapper/conversion routines. > > Needed when running a 64-bit kernel on an o32 userland. > > Hmm, this looks dubious: > > +#define AA(__x) ((unsigned long)((int)__x)) > > You probably want either: > > ((unsigned long)((unsigned int)__x)) > > or > > ((long)((int)__x)). > > Since you are using pointers, likely the latter. > A(__x) is returning a unsigned long, so I try to stick to that. I need the (int) typecast to make sure things got sign extended. So if you want to change it, please go for the latter ((long)(int)). What about the rest of the patch ? > > Sending patches within a mail's body would ease commenting them, BTW. I > had to copy and paste the line above manually -- with gpm it's not a big > problem for a single line, but it gets tedious for larger chunks and gpm > is not everywhere. Ralf has asked me to send the patches as attachment, because I use Netscape as my mailer. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + -- _ _ ____ ___ 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 Aug 8 06:27:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78DRjRw015136 for ; Thu, 8 Aug 2002 06:27:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78DRjrc015135 for linux-mips-outgoing; Thu, 8 Aug 2002 06:27:45 -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.5/8.12.5) with SMTP id g78DRXRw015117; Thu, 8 Aug 2002 06:27:33 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g78DOsXb020449; Thu, 8 Aug 2002 06:24: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 GAA17574; Thu, 8 Aug 2002 06:24:53 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g78DOmb12558; Thu, 8 Aug 2002 15:24:50 +0200 (MEST) Message-ID: <3D52711F.D5C6A8FC@mips.com> Date: Thu, 08 Aug 2002 15:24: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: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: memcpy.S patch in 64-bit Content-Type: multipart/mixed; boundary="------------F6E7F0A5F1691FA9120D6760" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1686 Lines: 60 This is a multi-part message in MIME format. --------------F6E7F0A5F1691FA9120D6760 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit The __copy_user function (in arch/mips64/lib/memcpy.S) calls __bzero. We can't do that because __bzero might modify len, which we want to return in case of an error. The following patch take care of 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 --------------F6E7F0A5F1691FA9120D6760 Content-Type: text/plain; charset=iso-8859-15; name="memcpy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="memcpy.patch" Index: arch/mips64/lib/memcpy.S =================================================================== RCS file: /cvs/linux/arch/mips64/lib/memcpy.S,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 memcpy.S --- arch/mips64/lib/memcpy.S 2002/08/05 23:53:36 1.9.2.1 +++ arch/mips64/lib/memcpy.S 2002/08/08 13:19:10 @@ -762,8 +762,18 @@ dsubu a2, AT, ta0 # a2 bytes to go daddu a0, ta0 # compute start address in a1 dsubu a0, a1 - j __bzero - move a1, zero + /* + * Clear len bytes starting at dst. Can't call __bzero because it + * might modify len. An inefficient loop for these rare times... + */ + beqz a2, 2f + dsubu a1, a2, 1 +1: sb zero, 0(a0) + daddu a0, a0, 1 + bnez a1, 1b + dsubu a1, a1, 1 +2: jr ra + nop s_fixup: jr ra --------------F6E7F0A5F1691FA9120D6760-- From owner-linux-mips@oss.sgi.com Thu Aug 8 07:24:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78EOpRw016393 for ; Thu, 8 Aug 2002 07:24:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78EOp0b016392 for linux-mips-outgoing; Thu, 8 Aug 2002 07:24: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.5/8.12.5) with SMTP id g78EOIRw016380; Thu, 8 Aug 2002 07:24:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA14259; Thu, 8 Aug 2002 16:26:46 +0200 (MET DST) Date: Thu, 8 Aug 2002 16:26:45 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: siginfo structure in 64-bit kernel In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6555 Lines: 216 On Wed, 7 Aug 2002, Maciej W. Rozycki wrote: > I'll check the patch at run-time later. I checked the patch and discovered you somehow made the order of struct members wrong. Here is an updated version that works for me. It includes both the ordering fix and unsigned type changes I suggested before. This version should be OK to apply. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020807-carsten-signal32-3 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/kernel/signal32.c linux-mips-2.4.19-rc1-20020807/arch/mips64/kernel/signal32.c --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/kernel/signal32.c 2002-08-06 02:57:36.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips64/kernel/signal32.c 2002-08-08 00:20:04.000000000 +0000 @@ -360,13 +360,55 @@ struct sigframe { sigset_t sf_mask; }; -struct rt_sigframe { +struct rt_sigframe32 { u32 rs_ass[4]; /* argument save space for o32 */ u32 rs_code[2]; /* signal trampoline */ - struct siginfo rs_info; + struct siginfo32 rs_info; struct ucontext rs_uc; }; +static int copy_siginfo_to_user32(siginfo_t32 *to, siginfo_t *from) +{ + int err; + + if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t32))) + return -EFAULT; + + /* If you change siginfo_t structure, please be sure + this code is fixed accordingly. + It should never copy any pad contained in the structure + to avoid security leaks, but must copy the generic + 3 ints plus the relevant union member. + This routine must convert siginfo from 64bit to 32bit as well + at the same time. */ + err = __put_user(from->si_signo, &to->si_signo); + err |= __put_user(from->si_errno, &to->si_errno); + err |= __put_user((short)from->si_code, &to->si_code); + if (from->si_code < 0) + err |= __copy_to_user(&to->_sifields._pad, &from->_sifields._pad, SI_PAD_SIZE); + else { + switch (from->si_code >> 16) { + case __SI_CHLD >> 16: + err |= __put_user(from->si_utime, &to->si_utime); + err |= __put_user(from->si_stime, &to->si_stime); + err |= __put_user(from->si_status, &to->si_status); + default: + err |= __put_user(from->si_pid, &to->si_pid); + err |= __put_user(from->si_uid, &to->si_uid); + break; + case __SI_FAULT >> 16: + err |= __put_user((long)from->si_addr, &to->si_addr); + break; + case __SI_POLL >> 16: + err |= __put_user(from->si_band, &to->si_band); + err |= __put_user(from->si_fd, &to->si_fd); + break; + /* case __SI_RT: This is not generated by the kernel as of now. */ + } + } + return err; +} + asmlinkage void sys32_sigreturn(abi64_no_regargs, struct pt_regs regs) { struct sigframe *frame; @@ -405,11 +447,11 @@ badframe: asmlinkage void sys32_rt_sigreturn(abi64_no_regargs, struct pt_regs regs) { - struct rt_sigframe *frame; + struct rt_sigframe32 *frame; sigset_t set; stack_t st; - frame = (struct rt_sigframe *) regs.regs[29]; + frame = (struct rt_sigframe32 *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) goto badframe; if (__copy_from_user(&set, &frame->rs_uc.uc_sigmask, sizeof(set))) @@ -588,7 +630,7 @@ static void inline setup_rt_frame(struct struct pt_regs *regs, int signr, sigset_t *set, siginfo_t *info) { - struct rt_sigframe *frame; + struct rt_sigframe32 *frame; int err = 0; frame = get_sigframe(ka, regs, sizeof(*frame)); @@ -613,8 +655,8 @@ static void inline setup_rt_frame(struct flush_cache_sigtramp((unsigned long) frame->rs_code); } - /* Create siginfo. */ - err |= __copy_to_user(&frame->rs_info, info, sizeof(*info)); + /* Convert (siginfo_t -> siginfo_t32) and copy to user. */ + err |= copy_siginfo_to_user32(&frame->rs_info, info); /* Create the ucontext. */ err |= __put_user(0, &frame->rs_uc.uc_flags); @@ -639,7 +681,7 @@ static void inline setup_rt_frame(struct * a2 = pointer to ucontext * * $25 and c0_epc point to the signal handler, $29 points to - * the struct rt_sigframe. + * the struct rt_sigframe32. */ regs->regs[ 4] = signr; regs->regs[ 5] = (unsigned long) &frame->rs_info; diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/siginfo.h linux-mips-2.4.19-rc1-20020807/include/asm-mips64/siginfo.h --- linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/siginfo.h 2002-08-06 02:58:32.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/include/asm-mips64/siginfo.h 2002-08-08 07:14:29.000000000 +0000 @@ -18,11 +18,21 @@ typedef union sigval { void *sival_ptr; } sigval_t; +#ifdef __KERNEL__ + +typedef union sigval32 { + int sival_int; + s32 sival_ptr; +} sigval_t32; + +#endif /* __KERNEL__ */ + /* This structure matches IRIX 32/n32 ABIs for binary compatibility but has Linux extensions. */ #define SI_MAX_SIZE 128 -#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 3) +#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 4) +#define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3) typedef struct siginfo { int si_signo; @@ -82,6 +92,68 @@ typedef struct siginfo { } _sifields; } siginfo_t; +#ifdef __KERNEL__ + +typedef struct siginfo32 { + int si_signo; + int si_code; + int si_errno; + + union { + int _pad[SI_PAD_SIZE32]; + + /* kill() */ + struct { + __kernel_pid_t32 _pid; /* sender's pid */ + __kernel_uid_t32 _uid; /* sender's uid */ + } _kill; + + /* SIGCHLD */ + struct { + __kernel_pid_t32 _pid; /* which child */ + __kernel_uid_t32 _uid; /* sender's uid */ + __kernel_clock_t32 _utime; + int _status; /* exit code */ + __kernel_clock_t32 _stime; + } _sigchld; + + /* IRIX SIGCHLD */ + struct { + __kernel_pid_t32 _pid; /* which child */ + __kernel_clock_t32 _utime; + int _status; /* exit code */ + __kernel_clock_t32 _stime; + } _irix_sigchld; + + /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */ + struct { + s32 _addr; /* faulting insn/memory ref. */ + } _sigfault; + + /* SIGPOLL, SIGXFSZ (To do ...) */ + struct { + int _band; /* POLL_IN, POLL_OUT, POLL_MSG */ + int _fd; + } _sigpoll; + + /* POSIX.1b timers */ + struct { + unsigned int _timer1; + unsigned int _timer2; + } _timer; + + /* POSIX.1b signals */ + struct { + __kernel_pid_t32 _pid; /* sender's pid */ + __kernel_uid_t32 _uid; /* sender's uid */ + sigval_t32 _sigval; + } _rt; + + } _sifields; +} siginfo_t32; + +#endif /* __KERNEL__ */ + /* * How these fields are to be accessed. */ From owner-linux-mips@oss.sgi.com Thu Aug 8 08:05:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78F5gRw017852 for ; Thu, 8 Aug 2002 08:05:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78F5fDx017851 for linux-mips-outgoing; Thu, 8 Aug 2002 08:05:41 -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.5/8.12.5) with SMTP id g78F5XRw017841; Thu, 8 Aug 2002 08:05:34 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA14957; Thu, 8 Aug 2002 17:08:08 +0200 (MET DST) Date: Thu, 8 Aug 2002 17:08:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: memcpy.S patch in 64-bit In-Reply-To: <3D52711F.D5C6A8FC@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 628 Lines: 20 On Thu, 8 Aug 2002, Carsten Langgaard wrote: > The __copy_user function (in arch/mips64/lib/memcpy.S) calls __bzero. > We can't do that because __bzero might modify len, which we want to > return in case of an error. > The following patch take care of the problem. Hmm, how about simply cloning arch/mips/lib/memcpy.S? It seems: 1. Designed to work on mips64 as well. 2. More up to date. And it would ease maintenance. -- + 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 Aug 8 08:41:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78FfPRw018681 for ; Thu, 8 Aug 2002 08:41:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78FfPKr018680 for linux-mips-outgoing; Thu, 8 Aug 2002 08:41:25 -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 (shaft19-f135.dialo.tiscali.de [62.246.19.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g78FfHRw018671 for ; Thu, 8 Aug 2002 08:41:19 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g78FgkE27282; Thu, 8 Aug 2002 17:42:46 +0200 Date: Thu, 8 Aug 2002 17:42:46 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: memcpy.S patch in 64-bit Message-ID: <20020808174246.A27274@dea.linux-mips.net> References: <3D52711F.D5C6A8FC@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 Thu, Aug 08, 2002 at 05:08:07PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 559 Lines: 20 On Thu, Aug 08, 2002 at 05:08:07PM +0200, Maciej W. Rozycki wrote: > > The __copy_user function (in arch/mips64/lib/memcpy.S) calls __bzero. > > We can't do that because __bzero might modify len, which we want to > > return in case of an error. > > The following patch take care of the problem. > > Hmm, how about simply cloning arch/mips/lib/memcpy.S? It seems: > > 1. Designed to work on mips64 as well. > > 2. More up to date. > > And it would ease maintenance. Right but Carsten's patch is already ready, so I'm going to use it for now. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 8 12:56:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78JuMRw022754 for ; Thu, 8 Aug 2002 12:56:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78JuMJd022753 for linux-mips-outgoing; Thu, 8 Aug 2002 12:56:22 -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.5/8.12.5) with SMTP id g78JtmRw022739; Thu, 8 Aug 2002 12:55:48 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g78JvFXb021942; Thu, 8 Aug 2002 12:57:15 -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 MAA02221; Thu, 8 Aug 2002 12:57:15 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g78JvEb13962; Thu, 8 Aug 2002 21:57:14 +0200 (MEST) Message-ID: <3D52CE5B.CD8C72C4@mips.com> Date: Thu, 08 Aug 2002 22:02:35 +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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: siginfo structure in 64-bit kernel References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8801 Lines: 231 "Maciej W. Rozycki" wrote: > On Wed, 7 Aug 2002, Maciej W. Rozycki wrote: > > > I'll check the patch at run-time later. > > I checked the patch and discovered you somehow made the order of struct > members wrong. Good spotted, that's what happens when MIPS is the only one that put 'si_code' before 'si_errno' in the structure. > Here is an updated version that works for me. It includes > both the ordering fix and unsigned type changes I suggested before. > With your sign changes we are doing things a little bit different than others, I know that's not really an argument, but does the unsigned types not work for you ? > > This version should be OK to apply. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > patch-mips-2.4.19-rc1-20020807-carsten-signal32-3 > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/kernel/signal32.c linux-mips-2.4.19-rc1-20020807/arch/mips64/kernel/signal32.c > --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/kernel/signal32.c 2002-08-06 02:57:36.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020807/arch/mips64/kernel/signal32.c 2002-08-08 00:20:04.000000000 +0000 > @@ -360,13 +360,55 @@ struct sigframe { > sigset_t sf_mask; > }; > > -struct rt_sigframe { > +struct rt_sigframe32 { > u32 rs_ass[4]; /* argument save space for o32 */ > u32 rs_code[2]; /* signal trampoline */ > - struct siginfo rs_info; > + struct siginfo32 rs_info; > struct ucontext rs_uc; > }; > > +static int copy_siginfo_to_user32(siginfo_t32 *to, siginfo_t *from) > +{ > + int err; > + > + if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t32))) > + return -EFAULT; > + > + /* If you change siginfo_t structure, please be sure > + this code is fixed accordingly. > + It should never copy any pad contained in the structure > + to avoid security leaks, but must copy the generic > + 3 ints plus the relevant union member. > + This routine must convert siginfo from 64bit to 32bit as well > + at the same time. */ > + err = __put_user(from->si_signo, &to->si_signo); > + err |= __put_user(from->si_errno, &to->si_errno); > + err |= __put_user((short)from->si_code, &to->si_code); > + if (from->si_code < 0) > + err |= __copy_to_user(&to->_sifields._pad, &from->_sifields._pad, SI_PAD_SIZE); > + else { > + switch (from->si_code >> 16) { > + case __SI_CHLD >> 16: > + err |= __put_user(from->si_utime, &to->si_utime); > + err |= __put_user(from->si_stime, &to->si_stime); > + err |= __put_user(from->si_status, &to->si_status); > + default: > + err |= __put_user(from->si_pid, &to->si_pid); > + err |= __put_user(from->si_uid, &to->si_uid); > + break; > + case __SI_FAULT >> 16: > + err |= __put_user((long)from->si_addr, &to->si_addr); > + break; > + case __SI_POLL >> 16: > + err |= __put_user(from->si_band, &to->si_band); > + err |= __put_user(from->si_fd, &to->si_fd); > + break; > + /* case __SI_RT: This is not generated by the kernel as of now. */ > + } > + } > + return err; > +} > + > asmlinkage void sys32_sigreturn(abi64_no_regargs, struct pt_regs regs) > { > struct sigframe *frame; > @@ -405,11 +447,11 @@ badframe: > > asmlinkage void sys32_rt_sigreturn(abi64_no_regargs, struct pt_regs regs) > { > - struct rt_sigframe *frame; > + struct rt_sigframe32 *frame; > sigset_t set; > stack_t st; > > - frame = (struct rt_sigframe *) regs.regs[29]; > + frame = (struct rt_sigframe32 *) regs.regs[29]; > if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) > goto badframe; > if (__copy_from_user(&set, &frame->rs_uc.uc_sigmask, sizeof(set))) > @@ -588,7 +630,7 @@ static void inline setup_rt_frame(struct > struct pt_regs *regs, int signr, > sigset_t *set, siginfo_t *info) > { > - struct rt_sigframe *frame; > + struct rt_sigframe32 *frame; > int err = 0; > > frame = get_sigframe(ka, regs, sizeof(*frame)); > @@ -613,8 +655,8 @@ static void inline setup_rt_frame(struct > flush_cache_sigtramp((unsigned long) frame->rs_code); > } > > - /* Create siginfo. */ > - err |= __copy_to_user(&frame->rs_info, info, sizeof(*info)); > + /* Convert (siginfo_t -> siginfo_t32) and copy to user. */ > + err |= copy_siginfo_to_user32(&frame->rs_info, info); > > /* Create the ucontext. */ > err |= __put_user(0, &frame->rs_uc.uc_flags); > @@ -639,7 +681,7 @@ static void inline setup_rt_frame(struct > * a2 = pointer to ucontext > * > * $25 and c0_epc point to the signal handler, $29 points to > - * the struct rt_sigframe. > + * the struct rt_sigframe32. > */ > regs->regs[ 4] = signr; > regs->regs[ 5] = (unsigned long) &frame->rs_info; > diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/siginfo.h linux-mips-2.4.19-rc1-20020807/include/asm-mips64/siginfo.h > --- linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/siginfo.h 2002-08-06 02:58:32.000000000 +0000 > +++ linux-mips-2.4.19-rc1-20020807/include/asm-mips64/siginfo.h 2002-08-08 07:14:29.000000000 +0000 > @@ -18,11 +18,21 @@ typedef union sigval { > void *sival_ptr; > } sigval_t; > > +#ifdef __KERNEL__ > + > +typedef union sigval32 { > + int sival_int; > + s32 sival_ptr; > +} sigval_t32; > + > +#endif /* __KERNEL__ */ > + > /* This structure matches IRIX 32/n32 ABIs for binary compatibility but > has Linux extensions. */ > > #define SI_MAX_SIZE 128 > -#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 3) > +#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 4) > +#define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3) > > typedef struct siginfo { > int si_signo; > @@ -82,6 +92,68 @@ typedef struct siginfo { > } _sifields; > } siginfo_t; > > +#ifdef __KERNEL__ > + > +typedef struct siginfo32 { > + int si_signo; > + int si_code; > + int si_errno; > + > + union { > + int _pad[SI_PAD_SIZE32]; > + > + /* kill() */ > + struct { > + __kernel_pid_t32 _pid; /* sender's pid */ > + __kernel_uid_t32 _uid; /* sender's uid */ > + } _kill; > + > + /* SIGCHLD */ > + struct { > + __kernel_pid_t32 _pid; /* which child */ > + __kernel_uid_t32 _uid; /* sender's uid */ > + __kernel_clock_t32 _utime; > + int _status; /* exit code */ > + __kernel_clock_t32 _stime; > + } _sigchld; > + > + /* IRIX SIGCHLD */ > + struct { > + __kernel_pid_t32 _pid; /* which child */ > + __kernel_clock_t32 _utime; > + int _status; /* exit code */ > + __kernel_clock_t32 _stime; > + } _irix_sigchld; > + > + /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */ > + struct { > + s32 _addr; /* faulting insn/memory ref. */ > + } _sigfault; > + > + /* SIGPOLL, SIGXFSZ (To do ...) */ > + struct { > + int _band; /* POLL_IN, POLL_OUT, POLL_MSG */ > + int _fd; > + } _sigpoll; > + > + /* POSIX.1b timers */ > + struct { > + unsigned int _timer1; > + unsigned int _timer2; > + } _timer; > + > + /* POSIX.1b signals */ > + struct { > + __kernel_pid_t32 _pid; /* sender's pid */ > + __kernel_uid_t32 _uid; /* sender's uid */ > + sigval_t32 _sigval; > + } _rt; > + > + } _sifields; > +} siginfo_t32; > + > +#endif /* __KERNEL__ */ > + > /* > * How these fields are to be accessed. > */ From owner-linux-mips@oss.sgi.com Thu Aug 8 12:58:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g78JwhRw022889 for ; Thu, 8 Aug 2002 12:58:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g78JwhiL022888 for linux-mips-outgoing; Thu, 8 Aug 2002 12:58:43 -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.5/8.12.5) with SMTP id g78JwaRw022860; Thu, 8 Aug 2002 12:58:36 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g78K02Xb021952; Thu, 8 Aug 2002 13:00:02 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA02336; Thu, 8 Aug 2002 13:00:03 -0700 (PDT) Received: from mips.com ([172.18.27.100]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g78K02b14116; Thu, 8 Aug 2002 22:00:02 +0200 (MEST) Message-ID: <3D52CF03.4173541D@mips.com> Date: Thu, 08 Aug 2002 22:05:23 +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: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: memcpy.S patch in 64-bit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 760 Lines: 27 "Maciej W. Rozycki" wrote: > On Thu, 8 Aug 2002, Carsten Langgaard wrote: > > > The __copy_user function (in arch/mips64/lib/memcpy.S) calls __bzero. > > We can't do that because __bzero might modify len, which we want to > > return in case of an error. > > The following patch take care of the problem. > > Hmm, how about simply cloning arch/mips/lib/memcpy.S? It seems: > > 1. Designed to work on mips64 as well. > > 2. More up to date. > > And it would ease maintenance. > If it works then it's the right thing to do, so please go a head :-) > > -- > + 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 Aug 9 01:37:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g798bYRw001875 for ; Fri, 9 Aug 2002 01:37:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g798bYRR001874 for linux-mips-outgoing; Fri, 9 Aug 2002 01:37:34 -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.5/8.12.5) with SMTP id g798bMRw001862; Fri, 9 Aug 2002 01:37:23 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA00579; Fri, 9 Aug 2002 10:39:57 +0200 (MET DST) Date: Fri, 9 Aug 2002 10:39:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: siginfo structure in 64-bit kernel In-Reply-To: <3D52CE5B.CD8C72C4@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1951 Lines: 41 On Thu, 8 Aug 2002, Carsten Langgaard wrote: > > I checked the patch and discovered you somehow made the order of struct > > members wrong. > > Good spotted, that's what happens when MIPS is the only one that put > 'si_code' before 'si_errno' in the structure. That's why I'm always using MIPS-specific definitions as a reference first. The actual reason of the differences is the SysV ABI supplement for MIPS which defines things a bit differently than the others here and there, often with no justified reason (well, the reason is really Irix, but then again, there is no justified reason for Irix to be different there). > > Here is an updated version that works for me. It includes > > both the ordering fix and unsigned type changes I suggested before. > > With your sign changes we are doing things a little bit different than > others, I know that's not really an argument, but does the unsigned > types not work for you ? Others are different here, actually. With a signed type if a 32-bit address is cast to "long" or "void *" implicitly (the latter is normally spotted by the compiler and marked with a warning; the former is usually silent), it becomes a valid 64-bit address that still refers to the same location. With an unsigned one it doesn't work for KSEG addresses anymore. That's because addresses are signed on MIPS -- 32-bit addresses are sign-extended (as opposed to zero-extended) by the hardware the 32-bit address space is in the middle of the 64-bit one (and not at the bottom as in the zero-extension variant). I suppose the unsigned types would usually work if casts were applied carefully everywhere. I'd prefer code to work automatically, though, without corner cases triggered every now and then. -- + 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 Aug 9 01:39:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g798d0Rw001926 for ; Fri, 9 Aug 2002 01:39:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g798d0Rm001925 for linux-mips-outgoing; Fri, 9 Aug 2002 01:39:00 -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.5/8.12.5) with SMTP id g798cqRw001915; Fri, 9 Aug 2002 01:38:53 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA00633; Fri, 9 Aug 2002 10:41:30 +0200 (MET DST) Date: Fri, 9 Aug 2002 10:41:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: memcpy.S patch in 64-bit In-Reply-To: <3D52CF03.4173541D@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 454 Lines: 12 On Thu, 8 Aug 2002, Carsten Langgaard wrote: > If it works then it's the right thing to do, so please go a head :-) I'll do that later, but don't hesitate to do it yourself if you have some time to spare. The most effort will likely be in testing. -- + 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 Aug 9 01:41:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g798f9Rw002080 for ; Fri, 9 Aug 2002 01:41:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g798f909002079 for linux-mips-outgoing; Fri, 9 Aug 2002 01:41:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from cmsoutbound.mx.net (cmsrelay05.mx.net [165.212.11.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g798exRw002070 for ; Fri, 9 Aug 2002 01:40:59 -0700 Received: from uadvg143.cms.usa.net (HELO localhost) (165.212.11.143) by cmsoutbound.mx.net with SMTP; 9 Aug 2002 08:42:48 -0000 Received: from uwdvg002.cms.usa.net [165.212.8.2] by uadvg143.cms.usa.net via mtad (CM.0402.2.02C) with ESMTP id 665gHiiQQ0510M43; Fri, 09 Aug 2002 08:42:42 GMT Message-ID: <20020809084304.20279.qmail@uwdvg002.cms.usa.net> Received: from 213.84.222.138 [213.84.222.138] by uwdvg002.cms.usa.net (USANET web-mailer CM.0402.1.07D); Fri, 09 Aug 2002 08:43:04 -0000 Date: Fri, 09 Aug 2002 10:43:04 +0200 From: Sander Wichers To: Subject: What cvs branch to use to compile mips64? X-Mailer: USANET web-mailer (CM.0402.1.07D) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g798exRw002071 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2594 Lines: 67 Hi, I'm "trying" to compile a mips 64 kernel for a IP28 Indigo 2 R10000 (using the default binutils and egcs from oss.sgi.com) The default cvs branch will not link (even with minimal config options selected). The scsi wd93 driver in that branch will not compile at all.. So I tried the linux_2_5_[1/2] branches which compile completely but don't link: arch/mips64/mm/mm.o: In function `local_flush_tlb_mm': andes.c(.text+0x11f4): undefined reference to `flush_icache_all' arch/mips64/mm/mm.o: In function `local_flush_tlb_range': andes.c(.text+0x1374): undefined reference to `flush_icache_all' kernel/kernel.o: In function `schedule': sched.c(.text+0xfcc): undefined reference to `flush_icache_all' kernel/kernel.o: In function `set_cpus_allowed': sched.c(.text+0x1a54): undefined reference to `flush_icache_all' kernel/kernel.o: In function `end_lazy_tlb': exit.c(.text+0x6748): undefined reference to `flush_icache_all' fs/fs.o(.text+0xba98):exec.c: more undefined references to `flush_icache_all' follow fs/fs.o: In function `nfs_read_super': inode.c(.text+0x3a244): undefined reference to `nfs_v3_clientops' inode.c(.text+0x3a248): undefined reference to `nfs_v3_clientops' fs/fs.o: In function `nfs_async_unlink': unlink.c(.text+0x40310): undefined reference to `BUG' fs/fs.o: In function `unlock_buffer': buffer.c(.data+0x2f84): undefined reference to `nfs_version3' fs/fs.o: In function `invalidate_bdev': buffer.c(.data+0x3eb4): undefined reference to `nlmsvc_procedures4' fs/fs.o: In function `balance_dirty_state': buffer.c(.data+0x4854): undefined reference to `nlm_version4' arch/mips/sgi-ip22/ip22-kern.o: In function `indy_rtc_set_time': ip22-time.c(.text.init+0xd84): undefined reference to `bcops' ip22-time.c(.text.init+0xd88): undefined reference to `bcops' arch/mips64/arc/arclib.a(misc.o): In function `ArcHalt': misc.c(.text+0x0): undefined reference to `bcops' misc.c(.text+0x4): undefined reference to `bcops' arch/mips64/arc/arclib.a(misc.o): In function `ArcPowerDown': misc.c(.text+0x6c): undefined reference to `bcops' arch/mips64/arc/arclib.a(misc.o)(.text+0x70):misc.c: more undefined references to `bcops' follow drivers/char/char.o: In function `write_mem': mem.c(.text.init+0x138): undefined reference to `serial_console_init' net/network.o: In function `move_addr_to_user': socket.c(.text.init+0x78): undefined reference to `init_netlink' make: *** [vmlinux] Error 1 Am I doing something wrong? Do I have the correct branch? Or do I need some patches? thanks in advance, Sander From owner-linux-mips@oss.sgi.com Fri Aug 9 03:03:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79A3jRw003924 for ; Fri, 9 Aug 2002 03:03:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79A3jq6003923 for linux-mips-outgoing; Fri, 9 Aug 2002 03:03: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.5/8.12.5) with SMTP id g79A3dRw003914 for ; Fri, 9 Aug 2002 03:03:41 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA02411; Fri, 9 Aug 2002 12:06:11 +0200 (MET DST) Date: Fri, 9 Aug 2002 12:06:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Sander Wichers cc: linux-mips@oss.sgi.com Subject: Re: What cvs branch to use to compile mips64? In-Reply-To: <20020809084304.20279.qmail@uwdvg002.cms.usa.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 423 Lines: 13 On Fri, 9 Aug 2002, Sander Wichers wrote: > Am I doing something wrong? Do I have the correct branch? Or do I need > some patches? The linux_2_4 branch should build and run as it's what most people actively work on. -- + 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 Aug 9 05:48:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79CmkRw005678 for ; Fri, 9 Aug 2002 05:48:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79Cmjim005677 for linux-mips-outgoing; Fri, 9 Aug 2002 05:48:45 -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.5/8.12.5) with SMTP id g79CmdRw005668 for ; Fri, 9 Aug 2002 05:48:40 -0700 Received: (qmail 31585 invoked by uid 0); 9 Aug 2002 12:50:43 -0000 Received: from unknown (HELO bogon.ms20.nix) (134.34.147.122) by mail.gmx.net (mp019-rz3) with SMTP; 9 Aug 2002 12:50:43 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id 02466364F7; Fri, 9 Aug 2002 14:47:45 +0200 (CEST) Date: Fri, 9 Aug 2002 14:47:45 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: ip22 build fix Message-ID: <20020809124745.GA32507@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 X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 721 Lines: 25 Hi, I need the attached patch against arch/mips/arc/Makefile to get current CVS (linux_2_4) to build on IP22. Otherwise prom_meminit is undefined. Please apply. Index: arch/mips/arc/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/arc/Makefile,v retrieving revision 1.5.2.1 diff -u -u -r1.5.2.1 Makefile --- arch/mips/arc/Makefile 2002/08/01 22:26:40 1.5.2.1 +++ arch/mips/arc/Makefile 2002/08/09 12:44:57 @@ -4,7 +4,7 @@ L_TARGET = arclib.a -obj-y += cmdline.o console.o env.o file.o \ +obj-y += cmdline.o console.o env.o file.o memory.o \ identify.o init.o misc.o time.o tree.o obj-$(CONFIG_ARC_MEMORY) += memory.o Regards, -- Guido From owner-linux-mips@oss.sgi.com Fri Aug 9 06:11:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79DBfRw006073 for ; Fri, 9 Aug 2002 06:11:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79DBftu006072 for linux-mips-outgoing; Fri, 9 Aug 2002 06:11:41 -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.5/8.12.5) with SMTP id g79DBZRw006062 for ; Fri, 9 Aug 2002 06:11:36 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA05529; Fri, 9 Aug 2002 15:14:08 +0200 (MET DST) Date: Fri, 9 Aug 2002 15:14:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Guido Guenther cc: linux-mips@oss.sgi.com Subject: Re: ip22 build fix In-Reply-To: <20020809124745.GA32507@bogon.ms20.nix> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 730 Lines: 20 On Fri, 9 Aug 2002, Guido Guenther wrote: > I need the attached patch against arch/mips/arc/Makefile to > get current CVS (linux_2_4) to build on IP22. Otherwise prom_meminit > is undefined. Please apply. [...] > -obj-y += cmdline.o console.o env.o file.o \ > +obj-y += cmdline.o console.o env.o file.o memory.o \ > identify.o init.o misc.o time.o tree.o > > obj-$(CONFIG_ARC_MEMORY) += memory.o Well, $(CONFIG_ARC_MEMORY) equals to "y" for IP22, so please check you haven't got your configuration messed up. -- + 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 Aug 9 06:19:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79DJaRw006249 for ; Fri, 9 Aug 2002 06:19:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79DJa8g006248 for linux-mips-outgoing; Fri, 9 Aug 2002 06:19:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g79DJPRw006234 for ; Fri, 9 Aug 2002 06:19:26 -0700 Received: (qmail 32296 invoked by uid 0); 9 Aug 2002 13:21:29 -0000 Received: from unknown (HELO bogon.ms20.nix) (134.34.147.122) by mail.gmx.net (mp017-rz3) with SMTP; 9 Aug 2002 13:21:29 -0000 Received: by bogon.ms20.nix (Postfix, from userid 1000) id A4436364F7; Fri, 9 Aug 2002 15:18:32 +0200 (CEST) Date: Fri, 9 Aug 2002 15:18:32 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Cc: Ladislav Michl Subject: move /proc/gio to /proc/bus/gio/devices Message-ID: <20020809131832.GA29117@bogon.ms20.nix> Mail-Followup-To: linux-mips@oss.sgi.com, Ladislav Michl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1708 Lines: 53 Hi, the patch reformats /proc/gio and moves it to /proc/bus/gio/devices (for better conformance with other busses). It also changes the format to be better machine parseable. I discussed this with Ladis and he said it's o.k. Can it be applied? The new format is: "Slot DeviceID BaseAddress MapSize". I'd like to see this in to cleanup the X-Server code. -- Guido Index: arch/mips/sgi-ip22/ip22-gio.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-gio.c,v retrieving revision 1.1.2.3 diff -u -u -r1.1.2.3 ip22-gio.c --- arch/mips/sgi-ip22/ip22-gio.c 2002/08/05 23:53:35 1.1.2.3 +++ arch/mips/sgi-ip22/ip22-gio.c 2002/08/09 13:09:43 @@ -69,14 +69,12 @@ int i; char *p = buf; - p += sprintf(p, "GIO devices found:\n"); for (i = 0; i < GIO_NUM_SLOTS; i++) { if (gio_slot[i].flags & GIO_NO_DEVICE) continue; - p += sprintf(p, " Slot %s, DeviceId 0x%02x\n", - gio_slot[i].slot_name, gio_slot[i].device); - p += sprintf(p, " BaseAddr 0x%08lx, MapSize 0x%08x\n", - gio_slot[i].base_addr, gio_slot[i].map_size); + p += sprintf(p, "%s 0x%02x 0x%08lx 0x%08x\n", + gio_slot[i].slot_name, gio_slot[i].device, + gio_slot[i].base_addr, gio_slot[i].map_size); } return p - buf; @@ -84,7 +82,16 @@ void create_gio_proc_entry(void) { - create_proc_read_entry("gio", 0, NULL, gio_read_proc, NULL); + int i; + + for (i = 0; i < GIO_NUM_SLOTS; i++) { + /* only create proc entry if we have at least one device */ + if (! (gio_slot[i].flags & GIO_NO_DEVICE)) + if( proc_mkdir("bus/gio", NULL) ) + create_proc_read_entry("bus/gio/devices", 0, + NULL, gio_read_proc, NULL); + break; + } } /** From owner-linux-mips@oss.sgi.com Fri Aug 9 06:41:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79DfKRw006516 for ; Fri, 9 Aug 2002 06:41:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79DfKu0006515 for linux-mips-outgoing; Fri, 9 Aug 2002 06:41:20 -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.5/8.12.5) with SMTP id g79DfGRw006506 for ; Fri, 9 Aug 2002 06:41:16 -0700 Received: from merry.physik.uni-konstanz.de (merry.physik.uni-konstanz.de [134.34.144.91]) by gandalf.physik.uni-konstanz.de (Postfix) with ESMTP id 7581A8D35; Fri, 9 Aug 2002 15:43:25 +0200 (CEST) Received: from agx by merry.physik.uni-konstanz.de with local (Exim 3.35 #1 (Debian)) id 17dA33-00075T-00; Fri, 09 Aug 2002 15:43:25 +0200 Date: Fri, 9 Aug 2002 15:43:25 +0200 From: Guido Guenther To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: ip22 build fix Message-ID: <20020809134325.GA27234@merry> Mail-Followup-To: "Maciej W. Rozycki" , linux-mips@oss.sgi.com References: <20020809124745.GA32507@bogon.ms20.nix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 535 Lines: 13 On Fri, Aug 09, 2002 at 03:14:07PM +0200, Maciej W. Rozycki wrote: > On Fri, 9 Aug 2002, Guido Guenther wrote: > Well, $(CONFIG_ARC_MEMORY) equals to "y" for IP22, so please check you > haven't got your configuration messed up. Hmmm...another "make oldconfig" fixed it and defines CONFIG_ARC_MEMORY=y while the first one didn't - weird. Forget about the patch then. Judging from the notes in memory.c maybe the option should correctly be called CONFIG_ARCS_MEMORY instead or will any subarch using ARC ever use it? Thanks, -- Guido From owner-linux-mips@oss.sgi.com Fri Aug 9 11:11:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79IBIRw015798 for ; Fri, 9 Aug 2002 11:11:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79IBIeT015797 for linux-mips-outgoing; Fri, 9 Aug 2002 11:11:18 -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.5/8.12.5) with SMTP id g79IBCRw015783 for ; Fri, 9 Aug 2002 11:11:13 -0700 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id LAA05901; Fri, 9 Aug 2002 11:13:18 -0700 Message-ID: <3D54040C.8060703@mvista.com> Date: Fri, 09 Aug 2002 11:03:56 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: [PATCH] typo for sibyte swarm board Content-Type: multipart/mixed; boundary="------------030205060005080706030509" X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1005 Lines: 34 This is a multi-part message in MIME format. --------------030205060005080706030509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Otherwise we will see zero-sized memory chunk... Jun --------------030205060005080706030509 Content-Type: text/plain; name="junk" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="junk" diff -Nru smp/arch/mips/sibyte/swarm/setup.c.orig smp/arch/mips/sibyte/swarm/setup.c --- smp/arch/mips/sibyte/swarm/setup.c.orig Wed May 22 18:35:59 2002 +++ smp/arch/mips/sibyte/swarm/setup.c Fri Aug 9 10:56:43 2002 @@ -367,8 +367,8 @@ if (!rd_flag) { if (addr > MAX_RAM_SIZE) continue; - if (addr+size > MAX_RAM_SIZE) - size = MAX_RAM_SIZE - (addr+size) + 1; + if (addr+size-1 > MAX_RAM_SIZE) + size = MAX_RAM_SIZE - addr + 1; add_memory_region(addr, size, BOOT_MEM_RAM); } swarm_mem_region_addrs[swarm_mem_region_count] = addr; --------------030205060005080706030509-- From owner-linux-mips@oss.sgi.com Fri Aug 9 16:45:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g79NjIRw027429 for ; Fri, 9 Aug 2002 16:45:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g79NjIgn027428 for linux-mips-outgoing; Fri, 9 Aug 2002 16:45:18 -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.5/8.12.5) with SMTP id g79Nj7Rw027418 for ; Fri, 9 Aug 2002 16:45:07 -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 QAA03212 for ; Fri, 9 Aug 2002 16:47:18 -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 QAA14579; Fri, 9 Aug 2002 16:31:27 -0700 Message-ID: <3D544E9B.6040205@mvista.com> Date: Fri, 09 Aug 2002 16:22:03 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: a really really weird crash on swarm Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3685 Lines: 79 Call me crazy - I have seen crash like this. As you can see, the register is loaded with one value and on next instruction it shows another value. What the hell is it possibly going on? This is with today's OSS tree 2.4 branch. Jun Unable to handle kernel paging request at virtual address ffffcbf4, epc == 80120 9d4, ra == 8011bc30 Oops in fault.c::do_page_fault, line 206: $0 : 00000000 10001f00 80120998 00000000 00000001 00000000 00000000 802c71e0 $8 : 10001f00 00001000 8029bca4 8028e060 00000000 00000000 00000012 00000000 $16: ffffcbf4 00000000 00000000 00000001 00000002 8028e880 802c71e0 8feabe48 $24: 00000000 2ad78fd0 8027c000 8027ddd8 ffff6e08 8011bc30 Hi : fffd4abb Lo : 0000e717 epc : 801209d4 Not tainted Status: 10001f02 Cause : 00800008 Process swapper (pid: 0, stackpage=8027c000) Stack: 813da000 ffffffff 8fb40e60 0000008a 813da26c 813da160 00000000 8fb40e60 802c75e0 00000000 00000000 8011bc30 00000000 00000024 813da160 00000000 8011ba58 00000000 00012cf7 0000012b 00000000 8028ec90 00000000 8028ec80 fffffffe 00000000 10001f00 8fe8f1a0 8ffb8cc0 8011b300 00000000 00000000 8010c5d0 8010c7e0 00000000 00000000 8ff9229c 43464531 8ff90bd8 8010c7e0 ... Call Trace: [<8011bc30>] [<8011ba58>] [<8011b300>] [<8010c5d0>] [<8010c7e0>] [<8010c7e0>] [<80255870>] [<80255508>] [<80103240>] [<8010324c>] [<80100450>] [<80258b20>] [<80258b60>] Code: 00000040 0010802a 2610cbf4 1460fffe 3c038000 e2030000 1060 fffb 0000000f Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing <0>Rebooting in 5 seconds..swarm_linux_exit called...passing control back to CF E ffffffff80120998 : ffffffff80120998: 27bdffd0 addiu $sp,$sp,-48 ffffffff8012099c: afbf002c sw $ra,44($sp) ffffffff801209a0: afb20028 sw $s2,40($sp) ffffffff801209a4: afb10024 sw $s1,36($sp) ffffffff801209a8: afb00020 sw $s0,32($sp) ffffffff801209ac: 40016000 mfc0 $at,$12 ffffffff801209b0: 00000000 nop ffffffff801209b4: 34210001 ori $at,$at,0x1 ffffffff801209b8: 38210001 xori $at,$at,0x1 ffffffff801209bc: 40816000 mtc0 $at,$12 ffffffff801209c0: 00000040 ssnop ffffffff801209c4: 00000040 ssnop ffffffff801209c8: 00000040 ssnop ffffffff801209cc: 3c10802a lui $s0,0x802a ffffffff801209d0: 2610cbf4 addiu $s0,$s0,-13324 ffffffff801209d4: c2030000 ll $v1,0($s0) ffffffff801209d8: 1460fffe bnez $v1,ffffffff801209d4 ffffffff801209dc: 3c038000 lui $v1,0x8000 ffffffff801209e0: e2030000 sc $v1,0($s0) ffffffff801209e4: 1060fffb beqz $v1,ffffffff801209d4 ffffffff801209e8: 0000000f sync ffffffff801209ec: 3c02802c lui $v0,0x802c ffffffff801209f0: 8c427984 lw $v0,31108($v0) ffffffff801209f4: 3c03802d lui $v1,0x802d ffffffff801209f8: 8c6389c8 lw $v1,-30264($v1) ffffffff801209fc: 00438823 subu $s1,$v0,$v1 ffffffff80120a00: 12200005 beqz $s1,ffffffff80120a18 ffffffff80120a04: 00711021 addu $v0,$v1,$s1 ffffffff80120a08: 3c01802d lui $at,0x802d ffffffff80120a0c: ac2289c8 sw $v0,-30264($at) ffffffff80120a10: 0c048180 jal ffffffff80120600 ffffffff80120a14: 02202021 move $a0,$s1 ffffffff80120a18: 0000000f sync From owner-linux-mips@oss.sgi.com Fri Aug 9 17:05:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7A05SRw027730 for ; Fri, 9 Aug 2002 17:05:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7A05SaD027729 for linux-mips-outgoing; Fri, 9 Aug 2002 17:05:28 -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.5/8.12.5) with SMTP id g7A05NRw027720 for ; Fri, 9 Aug 2002 17:05:23 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g7A07xd01812; Fri, 9 Aug 2002 17:07:59 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to carlson@broadcom.com using -f Subject: Re: a really really weird crash on swarm From: Justin Carlson To: Jun Sun Cc: linux-mips@oss.sgi.com In-Reply-To: <3D544E9B.6040205@mvista.com> References: <3D544E9B.6040205@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 09 Aug 2002 17:07:58 -0700 Message-Id: <1028938078.1531.8.camel@xyzzy.rlson.org> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 857 Lines: 22 On Fri, 2002-08-09 at 16:22, Jun Sun wrote: > > Call me crazy - I have seen crash like this. As you can see, the register is > loaded with one value and on next instruction it shows another value. What > the hell is it possibly going on? > As presented, this seems exceedingly unlikely; even processor bugs don't look quite like this. You just don't lose state in such a blatant manner. I'd be more inclined to believe that we took an interrupt and somehow the saved processor state was corrupted. The positioning of the code looks suspicious to me; we're shortly into a bottom half, which means if we just, say, unmasked an interrupt in the SCD, we could quite possibly take the interrupt around then. Unfortunately, unless you can reliably reproduce this crash, there's not enough info there to really do more than speculate wildly. -Justin From owner-linux-mips@oss.sgi.com Fri Aug 9 17:22:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7A0MfRw028078 for ; Fri, 9 Aug 2002 17:22:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7A0MfZ5028077 for linux-mips-outgoing; Fri, 9 Aug 2002 17:22:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7A0LGRw028062 for ; Fri, 9 Aug 2002 17:21:16 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020810002322.XJIK221.sccrmhc02.attbi.com@ocean.lucon.org>; Sat, 10 Aug 2002 00:23:22 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id A7C48125D4; Fri, 9 Aug 2002 17:23:04 -0700 (PDT) Date: Fri, 9 Aug 2002 17:23:04 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , 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.13.90.0.3 is released Message-ID: <20020809172304.A21804@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.3 required=5.0 tests=PORN_10,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 18185 Lines: 647 This is the beta release of binutils 2.13.90.0.3 for Linux, which is based on binutils 2002 0809 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.13.90.0.3 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. Changes from binutils 2.12.90.0.15: 1. Update from binutils 2002 0802. 2. Initial support for mips n32 ABI. 3. Fix some x86 TLS bugs. Changes from binutils 2.12.90.0.14: 1. Update from binutils 2002 0717. 2. Fix an ia64 assembler bug. 3. Fix a symbol versioning bug. 4. You have to upgrade to modutils 2.4.19 or apply the modutils patch enclosed here in order to support System.map generated by the new nm. Changes from binutils 2.12.90.0.12: 1. Update from binutils 2002 0627. 2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel. Changes from binutils 2.12.90.0.11: 1. Update from binutils 2002 0618. 2. Fix a 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.13.90.0.3.tar.gz. Source code. 2. binutils-2.13.90.0.2-2.13.90.0.3.diff.gz. Patch against the previous beta source code. 3. binutils-2.13.90.0.3-1.i386.rpm. IA-32 binary RPM for RedHat 7.3. There is no separate source rpm. You can do # rpm -ta binutils-2.13.90.0.3.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 08/09/2002 ---- > On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote: > > Something you might like to warn about in your next release.. > > > > The 2002-07-05 bfd change exposes a bug in modutils. depmod scans the > > output of nm for a `?' symbol type when looking for certain symbols. > > nm used to return `?' for symbols in sections other than some standard > > sections like .text and .data. Now, nm returns a better guess as to > > the symbol type. > No, but it parses System.map, which is generated by nm. This was in modutils-2.4.16. Fix follows. diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c --- modutils-2.4.16.orig/depmod/depmod.c 2002-04-28 17:23:35.000000000 +0930 +++ modutils-2.4.16/depmod/depmod.c 2002-07-15 16:41:20.000000000 +0930 @@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); /* The second word is either the symbol name or a type */ - if (p && strlen(p) == 1) { /* System.map */ + if (p && p[0] && !p[1]) { /* System.map */ is_mapfile = 1; - if (*p != '?') - p = NULL; - else - p = strtok(NULL, " \t\n"); + p = strtok(NULL, " \t\n"); } else { /* /proc/ksyms copy */ if (p && strtok(NULL, " \t\n")) p = NULL; @@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); if (is_mapfile) { - if (*p != '?') + if (!p || !p[0] || p[1]) continue; p = strtok(NULL, " \t\n"); /* Sparc has symbols like '.div' that need to be -- Alan Modra IBM OzLabs - Linux Technology Centre From owner-linux-mips@oss.sgi.com Fri Aug 9 19:25:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7A2PZRw029681 for ; Fri, 9 Aug 2002 19:25:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7A2PZBd029680 for linux-mips-outgoing; Fri, 9 Aug 2002 19:25:35 -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.5/8.12.5) with SMTP id g7A2PNRw029671; Fri, 9 Aug 2002 19:25:23 -0700 Received: (from wjhun@localhost) by ayrnetworks.com (8.11.2/8.11.2) id g7A2RUS28242; Fri, 9 Aug 2002 19:27:30 -0700 Date: Fri, 9 Aug 2002 19:27:30 -0700 From: William Jhun To: "linux-mips@oss.sgi.com"@ayrnetworks.com, ralf@oss.sgi.com Subject: [PATCH] delay.h fix for HZ != 100 or 128 Message-ID: <20020809192730.H6317@ayrnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=-4.5 required=5.0 tests=PLING,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2395 Lines: 68 The current include/asm-mips/delay.h uses fixed constants for either HZ = 100 or 128, but won't work for other values, such as HZ = 1000 or 1024. This patch calculates that constant (still to infinite precision) and does 64-bit arithmetic (not really, though - gcc does it with only one additional 32-bit multiply) for HZ > 1000 so that udelay() will still work for usec <= 1000 (mdelay(), etc). Thanks, Will --- Index: include/asm-mips/delay.h =================================================================== RCS file: /cvs/linux/include/asm-mips/delay.h,v retrieving revision 1.10.2.1 diff -u -r1.10.2.1 delay.h --- include/asm-mips/delay.h 2002/08/09 22:17:48 1.10.2.1 +++ include/asm-mips/delay.h 2002/08/10 02:18:47 @@ -29,26 +29,35 @@ /* * division by multiplication: you don't have to worry about * loss of precision. - * - * Use only for very small delays ( < 1 msec). Should probably use a + * + * Use only for very small delays ( <= 1 msec). Should probably use a * lookup table, really, as the multiplications take much too long with * short delays. This is a "reasonable" implementation, though (and the * first constant multiplications gets optimized away if the delay is * a constant) */ extern __inline__ void __udelay(unsigned long usecs, unsigned long lpj) -{ - unsigned long lo; - -#if (HZ == 100) - usecs *= 0x00068db8; /* 2**32 / (1000000 / HZ) */ -#elif (HZ == 128) - usecs *= 0x0008637b; /* 2**32 / (1000000 / HZ) */ +{ + const unsigned long long mult_const = + (((unsigned long long)HZ << 32)/1000000); +#if (HZ > 1000) + /* If HZ > 1000, udelay() did't work for usecs <= 1000. + * + * GCC is smart enough to do this with just three + * 32-bit multiplies. + */ + unsigned long long xusecs; + xusecs = (unsigned long long)usecs * (unsigned long long)lpj * + mult_const; + __delay((unsigned long)(xusecs>>32)); +#else + unsigned long lo; + usecs *= (unsigned long long)mult_const; + __asm__("multu\t%2,%3" + :"=h" (usecs), "=l" (lo) + :"r" (usecs),"r" (lpj)); + __delay(usecs); #endif - __asm__("multu\t%2,%3" - :"=h" (usecs), "=l" (lo) - :"r" (usecs),"r" (lpj)); - __delay(usecs); } #ifdef CONFIG_SMP From owner-linux-mips@oss.sgi.com Fri Aug 9 20:05:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7A351Rw030494 for ; Fri, 9 Aug 2002 20:05:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7A351tC030493 for linux-mips-outgoing; Fri, 9 Aug 2002 20:05:01 -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-234-207-60.client.attbi.com [12.234.207.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7A34tRw030473 for ; Fri, 9 Aug 2002 20:04:55 -0700 Received: (qmail 14166 invoked by uid 502); 10 Aug 2002 03:07:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Aug 2002 03:07:07 -0000 Date: Fri, 9 Aug 2002 20:07:01 -0700 (PDT) From: ilya@theIlya.com X-X-Sender: ilya@ns2.total-knowledge.com To: Sander Wichers cc: linux-mips@oss.sgi.com Subject: Re: What cvs branch to use to compile mips64? In-Reply-To: <20020809084304.20279.qmail@uwdvg002.cms.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,NO_REAL_NAME,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 660 Lines: 19 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Am I doing something wrong? Do I have the correct branch? Or do I need > some patches? You are doing two things wrong: 1. Trying to compile cvs HEAD (it's really br0ken now) 2. Trying to compile for IP28. I don't think R10000 speculative execution workarround esists already. Thus, even if you get kernel to compile, you'll have very unstable environment. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE9VINa84S94bALfyURAhomAJ96OWVFAdK6ZH2Rvl7N70ua2t8z6QCgz8Wh 4MfJJv4O+8HoWY9LqVuSjQo= =8Rjq -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Sat Aug 10 05:33:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7ACXvRw003260 for ; Sat, 10 Aug 2002 05:33:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7ACXvkL003259 for linux-mips-outgoing; Sat, 10 Aug 2002 05:33:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from ubik.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7ACXJRw003245 for ; Sat, 10 Aug 2002 05:33:23 -0700 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g7ACZRui031503 for ; Sat, 10 Aug 2002 14:35:27 +0200 Message-ID: <3D55088F.4020503@murphy.dk> Date: Sat, 10 Aug 2002 14:35:27 +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 2.4] R5000 secondary cache support Content-Type: multipart/mixed; boundary="------------090100090209060001070007" X-Spam-Status: No, hits=-4.3 required=5.0 tests=TO_LOCALPART_EQ_REAL,PORN_10,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7220 Lines: 255 This is a multi-part message in MIME format. --------------090100090209060001070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have (re)implimented R5000 secondary cache support as a board cache with the attached patch. Comments are welcome. /Brian --------------090100090209060001070007 Content-Type: text/plain; name="r5k-sc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r5k-sc.patch" Index: include/asm-mips/mipsregs.h =================================================================== RCS file: /cvs/linux-mips/include/asm-mips/mipsregs.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- include/asm-mips/mipsregs.h 18 Jul 2002 17:34:00 -0000 1.1.1.1 +++ include/asm-mips/mipsregs.h 10 Aug 2002 11:51:38 -0000 1.2 @@ -376,6 +376,7 @@ #define CONF_CM_CMASK 7 #define CONF_DB (1 << 4) #define CONF_IB (1 << 5) +#define CONF_SE (1 << 12) #define CONF_SC (1 << 17) #define CONF_AC (1 << 23) #define CONF_HALT (1 << 25) Index: include/asm-mips/cacheops.h =================================================================== RCS file: /cvs/linux-mips/include/asm-mips/cacheops.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- include/asm-mips/cacheops.h 18 Jul 2002 17:34:01 -0000 1.1.1.1 +++ include/asm-mips/cacheops.h 18 Jul 2002 17:41:35 -0000 1.2 @@ -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: arch/mips/mm/c-r4k.c =================================================================== RCS file: /cvs/linux-mips/arch/mips/mm/c-r4k.c,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- arch/mips/mm/c-r4k.c 18 Jul 2002 17:35:18 -0000 1.1.1.1 +++ arch/mips/mm/c-r4k.c 10 Aug 2002 11:47:56 -0000 1.3 @@ -1457,6 +1457,8 @@ _dma_cache_inv = r4k_dma_cache_inv_sc; } +extern void r5k_sc_init(void); + typedef int (*probe_func_t)(unsigned long); static inline void __init setup_scache(unsigned int config) @@ -1469,7 +1471,13 @@ sc_present = probe_scache_kseg1(config); if (sc_present) { - setup_scache_funcs(); +#ifdef CONFIG_CPU_R5000 + if (mips_cpu.cputype == CPU_R5000) { + setup_noscache_funcs(); + r5k_sc_init(); + } else +#endif + setup_scache_funcs(); return; } Index: arch/mips/mm/r5k-sc.c =================================================================== RCS file: arch/mips/mm/r5k-sc.c diff -N arch/mips/mm/r5k-sc.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ arch/mips/mm/r5k-sc.c 10 Aug 2002 11:48:23 -0000 1.1 @@ -0,0 +1,126 @@ +/* + * Copyright (C) 1997, 2001 Ralf Baechle (ralf@gnu.org), + * derived from r4xx0.c by David S. Miller (dm@engr.sgi.com). + */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* Secondary cache size in bytes, if present. */ +static unsigned long scache_size; + +#define SC_LINE 32 + +#define cache_unroll(base,op) \ +__asm__ __volatile__(" \ + .set noreorder; \ + .set mips3; \ + cache %1, (%0); \ + .set mips0; \ + .set reorder" \ + : \ + : "r" (base), \ + "i" (op)); + +static 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_LINE; + } +} + +static 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_LINE; + } +} + +static void +r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + blast_r5000_scache(); + return; + } + + /* We assume the address is in KSEG0. On the R5000 we + * cannot invalidate less than a page at a time, and + * there is no Hit_xxx cache operations. + */ + a = addr & ~(PAGE_SIZE - 1); + end = (addr + size - 1) & ~(PAGE_SIZE - 1); + while (a <= end) { + blast_r5000_scache_page_indexed(a); /* Page_Invalidate */ + a += PAGE_SIZE; + } +} + +static void r5k_sc_enable(void) +{ + unsigned long flags; + + __save_and_cli(flags); + change_cp0_config(CONF_SE, CONF_SE); + blast_r5000_scache(); + __restore_flags(flags); +} + +static void r5k_sc_disable(void) +{ + unsigned long flags; + + __save_and_cli(flags); + blast_r5000_scache(); + change_cp0_config(CONF_SE, 0); + __restore_flags(flags); +} + +static inline int __init r5k_sc_probe(void) +{ + unsigned long config = read_32bit_cp0_register(CP0_CONFIG); + + if(config & CONF_SC) + return(0); + + scache_size = (512*1024) << ((config >> 20)&3); + + printk("R5000 SCACHE size %ldK, linesize 32 bytes.\n", + scache_size >> 10); + + return 1; +} + +struct bcache_ops r5k_sc_ops = { + r5k_sc_enable, + r5k_sc_disable, + r5k_dma_cache_inv_sc, + r5k_dma_cache_inv_sc +}; + +void __init r5k_sc_init(void) +{ + if (r5k_sc_probe()) { + r5k_sc_enable(); + bcops = &r5k_sc_ops; + } +} Index: arch/mips/mm/Makefile =================================================================== RCS file: /cvs/linux-mips/arch/mips/mm/Makefile,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- arch/mips/mm/Makefile 18 Jul 2002 17:35:18 -0000 1.1.1.1 +++ arch/mips/mm/Makefile 10 Aug 2002 11:48:30 -0000 1.2 @@ -20,7 +20,8 @@ obj-$(CONFIG_CPU_R4300) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o 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_R5000) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o \ + r5k-sc.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/config.in =================================================================== RCS file: /cvs/linux-mips/arch/mips/config.in,v retrieving revision 1.1.1.1 retrieving revision 1.5 diff -u -r1.1.1.1 -r1.5 --- arch/mips/config.in 18 Jul 2002 17:35:15 -0000 1.1.1.1 +++ arch/mips/config.in 10 Aug 2002 11:49:49 -0000 1.5 @@ -382,6 +395,10 @@ MIPS32 CONFIG_CPU_MIPS32 \ MIPS64 CONFIG_CPU_MIPS64" R4x00 +if [ "$CONFIG_CPU_R5000" = "y" ]; then + define_bool CONFIG_BOARD_SCACHE y +if + if [ "$CONFIG_CPU_MIPS32" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE --------------090100090209060001070007-- From owner-linux-mips@oss.sgi.com Sat Aug 10 17:57:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7B0vmRw009673 for ; Sat, 10 Aug 2002 17:57:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7B0vmYA009672 for linux-mips-outgoing; Sat, 10 Aug 2002 17:57:48 -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.5/8.12.5) with SMTP id g7B0vbRw009662 for ; Sat, 10 Aug 2002 17:57:38 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id D98681359C; Sun, 11 Aug 2002 02:59:53 +0200 (CEST) Date: Sun, 11 Aug 2002 02:59:53 +0200 From: Jan-Benedict Glaw To: linux-mips Subject: [PATCH] dec_esp.c compile fix Message-ID: <20020811005953.GB19435@lug-owl.de> Mail-Followup-To: linux-mips Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=TO_LOCALPART_EQ_REAL,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1805 Lines: 64 --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Karsten Merker and I just made dec_esp.c compileable again. Please apply, but beware: it's untested because we currently don't have HDDs here... MfG, JBG Index: dec_esp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/linux/drivers/scsi/dec_esp.c,v retrieving revision 1.10.2.2 diff -u -r1.10.2.2 dec_esp.c --- dec_esp.c 2002/07/24 17:55:47 1.10.2.2 +++ dec_esp.c 2002/08/11 00:25:15 @@ -447,15 +447,15 @@ struct mmu_sglist *sg =3D (struct mmu_sglist *) sp->SCp.buffer; =20 while (sz >=3D 0) { - sg[sz].dvma_addr =3D PHYSADDR(sg[sz].addr); + sg[sz].dvma_address =3D PHYSADDR(sg[sz].addr); sz--; } - sp->SCp.ptr =3D (char *) ((unsigned long) sp->SCp.buffer->dvma_address); + sp->SCp.ptr =3D (char *) ((unsigned long) sp->SCp.buffer->dma_address); } =20 static void dma_advance_sg(Scsi_Cmnd * sp) { - sp->SCp.ptr =3D (char *) ((unsigned long) sp->SCp.buffer->dvma_address); + sp->SCp.ptr =3D (char *) ((unsigned long) sp->SCp.buffer->dma_address); } =20 static void pmaz_dma_drain(struct NCR_ESP *esp) --=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/ --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9VbcJHb1edYOZ4bsRAl2VAJ9/Uoy9F5FzaaxlRSF97XqFOiFgnQCfRdlO 4cChYX9e7LgD9xL1MLGoahQ= =kdXa -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From owner-linux-mips@oss.sgi.com Sun Aug 11 14:22:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7BLMbRw023029 for ; Sun, 11 Aug 2002 14:22:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7BLMbRr023028 for linux-mips-outgoing; Sun, 11 Aug 2002 14:22:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7BLMSRw023018 for ; Sun, 11 Aug 2002 14:22:29 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020811212444.GLGL19356.rwcrmhc51.attbi.com@ocean.lucon.org> for ; Sun, 11 Aug 2002 21:24:44 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 566CE125DB; Sun, 11 Aug 2002 14:24:43 -0700 (PDT) Date: Sun, 11 Aug 2002 14:24:43 -0700 From: "H. J. Lu" To: linux-mips@oss.sgi.com Subject: Updates for RedHat 7.3 Message-ID: <20020811142443.A1692@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1833 Lines: 59 I updated the following rpms in RedHat 7.3: binutils-2.13.90.0.3-1.src.rpm freetype-2.1.2-0.1.src.rpm gcc-2.96-112.1.src.rpm gdb-5.2.1-0.2.src.rpm glibc-2.2.5-37.1.src.rpm libelf-0.7.0-6.1.src.rpm modutils-2.4.14-3.2.src.rpm openssl-0.9.6b-28.1.src.rpm psmisc-20.2-3.73.1.src.rpm util-linux-2.11n-12.7.3.1.src.rpm Please note that its new home is at ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/ H.J. --- My mini-port of RedHat 7.3 is at ftp://ftp.linux-mips.org/pub/linux/mips/redhat/7.3/ It has both mips (big endian) and mipsel (little endian) binary rpms. You should be able to put a small RedHat 7.3 on the mips/mipsel box and compile the rest of RedHat 7.3 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.3/x86 is provided as the toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. This toolchain is a combination of gcc, binutils, gdb and glibc. It is packaged for the cross compiling. It allows you to cross compile to RedHat 7.3/mips/mipsel from a RedHat 7.3/x86 host. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. baseline.tar.bz2 contains the cross build tree. You may need to install i386 rpm binary included here to rebuild mips/mipsel rpms on an x86 host. The "installer" directory has a simple installer, which can be used to prepare NFS root and install RedHat 7.3/mips/mipsel on a hard drive. 4. Since everything is cross compiled from x86, which is little endian, many data files for mips, which is big endian, are either missing or wrong. To get those data files for mips, you have to rebuild/install the folowing rpms: cracklib glibc natively on Linux/mips. 5. You should build/install perl rpm natively on your newly installed mips/mipsel box. Thanks. H.J. From owner-linux-mips@oss.sgi.com Sun Aug 11 17:34:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7C0Y7Rw027173 for ; Sun, 11 Aug 2002 17:34:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7C0Y76g027172 for linux-mips-outgoing; Sun, 11 Aug 2002 17:34:07 -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.5/8.12.5) with SMTP id g7C0XURw027159; Sun, 11 Aug 2002 17:33:30 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) 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 RAA06617; Sun, 11 Aug 2002 17:35:49 -0700 (PDT) mail_from (vivien.chappelier@enst-bretagne.fr) 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 g7C0HqY31596; Mon, 12 Aug 2002 02:17:52 +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 g7C0Hqfo020680; Mon, 12 Aug 2002 02:17:53 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17e2u8-0008Cj-00; Mon, 12 Aug 2002 02:17:52 +0200 Date: Mon, 12 Aug 2002 02:17:51 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: [2.5 PATCH] pci.h cleanup and fixes 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 X-Spam-Status: No, hits=-3.7 required=5.0 tests=MAY_BE_FORGED,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7173 Lines: 268 Hi, This patch fixes the following things for pci.h: - flush cache only on non-coherent archs - fix usage of bus_to_baddr - fix DECLARE_PCI_UNMAP_ADDR, ... for non-coherent arch where pci_unmap_* functions are not a empty. - change __pa, '+ PAGE_OFFSET' to virt_to_phys() and phys_to_virt() - adds sg->offset to page_address(sg->page) when mapping a scatter-gather buffer This is a patch against CVS HEAD (2.5.5)/mips64. It should apply directly to 2.5.5/mips as well. As for 2.5.4 care should be taken with the old 'sg->address' interface for scatter-gather buffers, but these fixes should probably be applied as well. Please comment and/or apply, Vivien. --- linux/include/asm-mips64/addrspace.h Thu Aug 1 20:22:00 2002 +++ linux.patch/include/asm-mips64/addrspace.h Thu Aug 1 20:21:54 2002 @@ -58,7 +58,7 @@ #ifndef __ASSEMBLY__ #define PHYSADDR(a) ({ \ - const _ATYPE64_ _a = (a); \ + const _ATYPE64_ _a = _ACAST64_ (a); \ _a == _ACAST32_ _a ? CPHYSADDR(_a) : XPHYSADDR(_a); }) #endif --- linux/include/asm-mips64/pci.h Mon Aug 12 00:25:23 2002 +++ linux.patch/include/asm-mips64/pci.h Mon Aug 12 00:19:27 2002 @@ -120,14 +120,20 @@ static inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction) { +#ifdef CONFIG_NONCOHERENT_IO unsigned long addr = (unsigned long) ptr; +#endif if (direction == PCI_DMA_NONE) BUG(); +#ifdef CONFIG_NONCOHERENT_IO + /* even if DMAing from device, make sure there is no dirty entry */ + /* in the cache that could be evicted during the DMA transfer */ + /* thus overwritting the device data */ dma_cache_wback_inv(addr, size); - - return bus_to_baddr(hwdev->bus->number, __pa(ptr)); +#endif + return bus_to_baddr(hwdev, virt_to_phys(ptr)); } /* @@ -141,17 +147,37 @@ static inline void pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr, size_t size, int direction) { +#ifdef CONFIG_NONCOHERENT_IO + unsigned long addr; +#endif + if (direction == PCI_DMA_NONE) BUG(); - if (direction != PCI_DMA_TODEVICE) { - unsigned long addr; + if (direction == PCI_DMA_TODEVICE) + return; /* nothing to do */ - addr = baddr_to_bus(hwdev, dma_addr) + PAGE_OFFSET; - dma_cache_wback_inv(addr, size); - } +#ifdef CONFIG_NONCOHERENT_IO + addr = (unsigned long) phys_to_virt(baddr_to_bus(hwdev, dma_addr)); + dma_cache_wback_inv(addr, size); +#endif } +#ifdef CONFIG_NONCOHERENT_IO +/* pci_unmap_{single,page} is not a nop, thus... */ +#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) \ + dma_addr_t ADDR_NAME; +#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) \ + __u32 LEN_NAME; +#define pci_unmap_addr(PTR, ADDR_NAME) \ + ((PTR)->ADDR_NAME) +#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) \ + (((PTR)->ADDR_NAME) = (VAL)) +#define pci_unmap_len(PTR, LEN_NAME) \ + ((PTR)->LEN_NAME) +#define pci_unmap_len_set(PTR, LEN_NAME, VAL) \ + (((PTR)->LEN_NAME) = (VAL)) +#else /* pci_unmap_{page,single} is a nop so... */ #define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) #define DECLARE_PCI_UNMAP_LEN(LEN_NAME) @@ -159,6 +185,7 @@ #define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) do { } while (0) #define pci_unmap_len(PTR, LEN_NAME) (0) #define pci_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0) +#endif /* * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t. identical @@ -168,13 +195,17 @@ unsigned long offset, size_t size, int direction) { +#ifdef CONFIG_NONCOHERENT_IO unsigned long addr; +#endif if (direction == PCI_DMA_NONE) BUG(); +#ifdef CONFIG_NONCOHERENT_IO addr = (unsigned long) page_address(page) + offset; dma_cache_wback_inv(addr, size); +#endif return bus_to_baddr(hwdev, page_to_phys(page) + offset); } @@ -182,15 +213,20 @@ static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address, size_t size, int direction) { +#ifdef CONFIG_NONCOHERENT_IO + unsigned long addr; +#endif + if (direction == PCI_DMA_NONE) BUG(); - if (direction != PCI_DMA_TODEVICE) { - unsigned long addr; + if (direction == PCI_DMA_TODEVICE) + return; /* nothing to do */ - addr = baddr_to_bus(hwdev, dma_address) + PAGE_OFFSET; - dma_cache_wback_inv(addr, size); - } +#ifdef CONFIG_NONCOHERENT_IO + addr = (unsigned long) phys_to_virt(baddr_to_bus(hwdev, dma_address)); + dma_cache_wback_inv(addr, size); +#endif } /* @@ -212,21 +248,23 @@ static inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { +#ifdef CONFIG_NONCOHERENT_IO int i; +#endif if (direction == PCI_DMA_NONE) BUG(); +#ifdef CONFIG_NONCOHERENT_IO for (i = 0; i < nents; i++, sg++) { unsigned long addr; - addr = (unsigned long) page_address(sg->page); - if (addr) - dma_cache_wback_inv(addr, sg->length); + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); sg->dma_address = (dma_addr_t) bus_to_baddr(hwdev, page_to_phys(sg->page) + sg->offset); } - +#endif return nents; } @@ -238,24 +276,27 @@ static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg, int nents, int direction) { +#ifdef CONFIG_NONCOHERENT_IO int i; +#endif if (direction == PCI_DMA_NONE) BUG(); if (direction == PCI_DMA_TODEVICE) - return; + return; /* nothing to do */ +#ifdef CONFIG_NONCOHERENT_IO for (i = 0; i < nents; i++, sg++) { unsigned long addr; if (!sg->page) BUG(); - addr = (unsigned long) page_address(sg->page); - if (addr) - dma_cache_wback_inv(addr + sg->offset, sg->length); + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); } +#endif } /* @@ -272,13 +313,17 @@ dma_addr_t dma_handle, size_t size, int direction) { +#ifdef CONFIG_NONCOHERENT_IO unsigned long addr; +#endif if (direction == PCI_DMA_NONE) BUG(); - addr = baddr_to_bus(hwdev, dma_handle) + PAGE_OFFSET; +#ifdef CONFIG_NONCOHERENT_IO + addr = (unsigned long) phys_to_virt(baddr_to_bus(hwdev, dma_handle)); dma_cache_wback_inv(addr, size); +#endif } /* @@ -301,9 +346,12 @@ /* 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)page_address(sg->page), - sg->length); + for (i = 0; i < nelems; i++, sg++) { + unsigned long addr; + + addr = (unsigned long) page_address(sg->page) + sg->offset; + dma_cache_wback_inv(addr, sg->length); + } #endif } #endif /* CONFIG_MAPPED_PCI_IO */ @@ -337,7 +385,7 @@ { dma64_addr_t addr = page_to_phys(page) + offset; - return (dma64_addr_t) bus_to_baddr(hwdev->bus->number, addr); + return (dma64_addr_t) bus_to_baddr(hwdev, addr); } static inline struct page *pci_dac_dma_to_page(struct pci_dev *pdev, @@ -362,8 +410,10 @@ if (direction == PCI_DMA_NONE) BUG(); - addr = baddr_to_bus(hwdev->bus->number, dma_addr) + PAGE_OFFSET; + addr = (unsigned long) phys_to_virt(baddr_to_bus(hwdev, dma_addr)); +#ifdef CONFIG_NONCOHERENT_IO dma_cache_wback_inv(addr, len); +#endif } /* From owner-linux-mips@oss.sgi.com Mon Aug 12 04:34:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7CBYPRw002728 for ; Mon, 12 Aug 2002 04:34:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7CBYPoO002727 for linux-mips-outgoing; Mon, 12 Aug 2002 04:34:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from webmail22.rediffmail.com (webmail22.rediffmail.com [203.199.83.144] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7CBYKRw002718 for ; Mon, 12 Aug 2002 04:34:21 -0700 Received: (qmail 17365 invoked by uid 510); 12 Aug 2002 11:36:05 -0000 Date: 12 Aug 2002 11:36:05 -0000 Message-ID: <20020812113605.17364.qmail@webmail22.rediffmail.com> Received: from unknown (203.197.184.35) by rediffmail.com via HTTP; 12 Aug 2002 11:36:05 -0000 MIME-Version: 1.0 From: "ashish anand" Reply-To: "ashish anand" To: linux-mips@oss.sgi.com Subject: mips idt cpu's linux port Content-type: text/plain; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 435 Lines: 15 just a quick question.. 1.i have just started new on mips idt procesors. is there available cpu port of linux for these processors. and 2.secondly what would be the source for getting a working ramdisk ? Best Regards, Atul __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-linux-mips@oss.sgi.com Mon Aug 12 04:42:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7CBgiRw002862 for ; Mon, 12 Aug 2002 04:42:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7CBgiIv002861 for linux-mips-outgoing; Mon, 12 Aug 2002 04:42:44 -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.5/8.12.5) with SMTP id g7CBgdRw002852 for ; Mon, 12 Aug 2002 04:42:40 -0700 Received: from merry.physik.uni-konstanz.de (merry.physik.uni-konstanz.de [134.34.144.91]) by gandalf.physik.uni-konstanz.de (Postfix) with ESMTP id CD2D98D35; Mon, 12 Aug 2002 13:45:01 +0200 (CEST) Received: from agx by merry.physik.uni-konstanz.de with local (Exim 3.35 #1 (Debian)) id 17eDd7-00082T-00; Mon, 12 Aug 2002 13:45:01 +0200 Date: Mon, 12 Aug 2002 13:45:01 +0200 From: Guido Guenther To: Ladislav Michl Cc: linux-mips@oss.sgi.com Subject: GIO bus ids on different machines Message-ID: <20020812114501.GA30885@merry> Mail-Followup-To: Ladislav Michl , 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 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 655 Lines: 15 Hi, /proc/gio gives weird results on the SGI systems I could check: - busid 0x04 in slot GFX for Indy with XL(newport) card - busid 0x04 in slot GFX for an Indy *without* any graphics hardware - busid 0x3f in slot GFX and 0x04 in EXP0 for a I2 with a single XZ board - busid 0x3f in slot GFX and 0x04 in EXP0 for a I2 *without* any graphics hardware - busid 0x3f in slot GFX and 0x00 in EXP0 for a I2 with an Elan as primary and XZ as secondary card What worries me most is that it doesn't seem to matter if there's hardware in a GIO slot or not - it reports the same busid - which screws the GIO bus handling in the X-server completely. -- Guido From owner-linux-mips@oss.sgi.com Mon Aug 12 07:08:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7CE8JRw004818 for ; Mon, 12 Aug 2002 07:08:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7CE8J0S004817 for linux-mips-outgoing; Mon, 12 Aug 2002 07:08:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mailgate.bodgit-n-scarper.com (mailgate.bodgit-n-scarper.com [62.49.233.146]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7CE8CRw004808 for ; Mon, 12 Aug 2002 07:08:13 -0700 Received: (qmail 2891 invoked from network); 12 Aug 2002 14:10:30 -0000 Received: from butterlicious.wired.bodgit-n-scarper.com (192.168.1.2) by mould.wired.bodgit-n-scarper.com with QMQP; 12 Aug 2002 14:10:30 -0000 Date: Mon, 12 Aug 2002 15:12:33 +0100 From: Matt Dainty To: linux-mips@oss.sgi.com Subject: Serial console output twice Message-ID: <20020812151233.D19420@butterlicious.bodgit-n-scarper.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.3.23i X-Operating-System: Linux 2.4.17 on i686 (butterlicious), up 3:48 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 969 Lines: 38 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I've just successfully cross-compiled a 2.4.18 kernel from the OSS CVS, for my R4600 SGI Indy. When I netboot it with a serial console, every printk is printed twice. I've tried various options to disable serial console/newport but it always does the same thing. If I try say, the Debian TFTP image, the kernel works fine. Does someone know what the problem is? Should I be using 2.4.18? Cheers Matt --=20 "Phased plasma rifle in a forty-watt range?" "Hey, just what you see, pal" --T4sUOijqQbZv57TR 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 iD8DBQE9V8JRKP58eR+X2TMRAtBpAJ9tJ0RxMj42L1muD6eFjZE8xzplAACgmBbu 8ejefYk7ehvnZRhUz3ibOZM= =WDrl -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-linux-mips@oss.sgi.com Mon Aug 12 11:01:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7CI1jRw012938 for ; Mon, 12 Aug 2002 11:01:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7CI1iOS012937 for linux-mips-outgoing; Mon, 12 Aug 2002 11:01: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-67.ka.dial.de.ignite.net [62.180.196.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7CI1cRw012928 for ; Mon, 12 Aug 2002 11:01:40 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7BGpd202146; Sun, 11 Aug 2002 18:51:39 +0200 Date: Sun, 11 Aug 2002 18:51:38 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: a really really weird crash on swarm Message-ID: <20020811185138.A2133@dea.linux-mips.net> References: <3D544E9B.6040205@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: <3D544E9B.6040205@mvista.com>; from jsun@mvista.com on Fri, Aug 09, 2002 at 04:22:03PM -0700 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 423 Lines: 13 On Fri, Aug 09, 2002 at 04:22:03PM -0700, Jun Sun wrote: > Call me crazy - I have seen crash like this. As you can see, the register is > loaded with one value and on next instruction it shows another value. What > the hell is it possibly going on? > > This is with today's OSS tree 2.4 branch. Really odd because the register only lost the upper 16 bits; the lower 16 bits still have their expected value. Ralf From owner-linux-mips@oss.sgi.com Mon Aug 12 20:43:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7D3h8Rw013521 for ; Mon, 12 Aug 2002 20:43:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7D3h8e4013520 for linux-mips-outgoing; Mon, 12 Aug 2002 20:43:08 -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.5/8.12.5) with SMTP id g7D3gPRw013508 for ; Mon, 12 Aug 2002 20:42:25 -0700 Received: from dea.linux-mips.net (c-180-196-67.ka.dial.de.ignite.net [62.180.196.67]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09587 for ; Mon, 12 Aug 2002 20:45:24 -0700 (PDT) mail_from (ralf@linux-mips.org) Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7D3NOe22453; Tue, 13 Aug 2002 05:23:24 +0200 Date: Tue, 13 Aug 2002 05:23:24 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) Message-ID: <20020813052324.A22438@linux-mips.org> References: <3D5131C7.17F9E00@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: <3D5131C7.17F9E00@mips.com>; from carstenl@mips.com on Wed, Aug 07, 2002 at 04:42:15PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10689 Lines: 327 Carsten, On Wed, Aug 07, 2002 at 04:42:15PM +0200, Carsten Langgaard wrote: > Here is a patch that fixes the ipc syscalls in the o32 > wrapper/conversion routines. > Needed when running a 64-bit kernel on an o32 userland. before I finally apply this one, can you do me a favour and check your code is still working correctly even after I applied yesterdays fix which changes struct msqid64_id to eleminate the mismatch of the kernel and libc definitions? Thanks, Ralf > Index: arch/mips64/kernel/linux32.c > =================================================================== > RCS file: /cvs/linux/arch/mips64/kernel/linux32.c,v > retrieving revision 1.42.2.9 > diff -u -r1.42.2.9 linux32.c > --- arch/mips64/kernel/linux32.c 2002/07/23 12:26:09 1.42.2.9 > +++ arch/mips64/kernel/linux32.c 2002/08/07 14:28:03 > @@ -35,8 +35,16 @@ > #include > #include > > - > +/* Use this to get at 32-bit user passed pointers. */ > +/* A() macro should be used for places where you e.g. > + have some internal variable u32 and just want to get > + rid of a compiler warning. AA() has to be used in > + places where you want to convert a function argument > + to 32bit pointer or when you e.g. access pt_regs > + structure and want to consider 32bit registers only. > + */ > #define A(__x) ((unsigned long)(__x)) > +#define AA(__x) ((unsigned long)((int)__x)) > > #ifdef __MIPSEB__ > #define merge_64(r1,r2) ((((r1) & 0xffffffffUL) << 32) + ((r2) & 0xffffffffUL)) > @@ -1494,6 +1502,19 @@ > unsigned short seq; > }; > > +struct ipc64_perm32 { > + key_t key; > + __kernel_uid_t32 uid; > + __kernel_gid_t32 gid; > + __kernel_uid_t32 cuid; > + __kernel_gid_t32 cgid; > + __kernel_mode_t32 mode; > + unsigned short seq; > + unsigned short __pad1; > + unsigned int __unused1; > + unsigned int __unused2; > +}; > + > struct semid_ds32 { > struct ipc_perm32 sem_perm; /* permissions .. see ipc.h */ > __kernel_time_t32 sem_otime; /* last semop time */ > @@ -1522,6 +1543,23 @@ > __kernel_ipc_pid_t32 msg_lrpid; > }; > > +struct msqid64_ds32 { > + struct ipc64_perm32 msg_perm; > + __kernel_time_t32 msg_stime; > + unsigned int __unused1; > + __kernel_time_t32 msg_rtime; > + unsigned int __unused2; > + __kernel_time_t32 msg_ctime; > + unsigned int __unused3; > + unsigned int msg_cbytes; > + unsigned int msg_qnum; > + unsigned int msg_qbytes; > + __kernel_pid_t32 msg_lspid; > + __kernel_pid_t32 msg_lrpid; > + unsigned int __unused4; > + unsigned int __unused5; > +}; > + > struct shmid_ds32 { > struct ipc_perm32 shm_perm; > int shm_segsz; > @@ -1533,9 +1571,25 @@ > unsigned short shm_nattch; > }; > > +struct ipc_kludge32 { > + u32 msgp; > + s32 msgtyp; > +}; > + > #define IPCOP_MASK(__x) (1UL << (__x)) > > static int > +ipc_parse_version32(int *cmd) > +{ > + if (*cmd & IPC_64) { > + *cmd ^= IPC_64; > + return IPC_64; > + } else { > + return IPC_OLD; > + } > +} > + > +static int > do_sys32_semctl(int first, int second, int third, void *uptr) > { > union semun fourth; > @@ -1603,12 +1657,15 @@ > static int > do_sys32_msgsnd (int first, int second, int third, void *uptr) > { > - struct msgbuf *p = kmalloc (second + sizeof (struct msgbuf) > - + 4, GFP_USER); > struct msgbuf32 *up = (struct msgbuf32 *)uptr; > + struct msgbuf *p; > mm_segment_t old_fs; > int err; > > + if (second < 0) > + return -EINVAL; > + p = kmalloc (second + sizeof (struct msgbuf) > + + 4, GFP_USER); > if (!p) > return -ENOMEM; > err = get_user (p->mtype, &up->mtype); > @@ -1636,18 +1693,21 @@ > int err; > > if (!version) { > - struct ipc_kludge *uipck = (struct ipc_kludge *)uptr; > - struct ipc_kludge ipck; > + struct ipc_kludge32 *uipck = (struct ipc_kludge32 *)uptr; > + struct ipc_kludge32 ipck; > > err = -EINVAL; > if (!uptr) > goto out; > err = -EFAULT; > - if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge))) > + if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge32))) > goto out; > - uptr = (void *)A(ipck.msgp); > + uptr = (void *)AA(ipck.msgp); > msgtyp = ipck.msgtyp; > } > + > + if (second < 0) > + return -EINVAL; > err = -ENOMEM; > p = kmalloc (second + sizeof (struct msgbuf) + 4, GFP_USER); > if (!p) > @@ -1673,9 +1733,10 @@ > { > int err = -EINVAL, err2; > struct msqid_ds m; > - struct msqid64_ds m64; > - struct msqid_ds32 *up = (struct msqid_ds32 *)uptr; > + struct msqid_ds32 *up32 = (struct msqid_ds32 *)uptr; > + struct msqid64_ds32 *up64 = (struct msqid64_ds32 *)uptr; > mm_segment_t old_fs; > + int version = ipc_parse_version32(&second); > > switch (second) { > > @@ -1686,10 +1747,25 @@ > break; > > case IPC_SET: > - err = get_user (m.msg_perm.uid, &up->msg_perm.uid); > - err |= __get_user (m.msg_perm.gid, &up->msg_perm.gid); > - err |= __get_user (m.msg_perm.mode, &up->msg_perm.mode); > - err |= __get_user (m.msg_qbytes, &up->msg_qbytes); > + if (version == IPC_64) { > + if (!access_ok(VERIFY_READ, up64, sizeof(*up64))) { > + err = -EFAULT; > + break; > + } > + err = __get_user(m.msg_perm.uid, &up64->msg_perm.uid); > + err |= __get_user(m.msg_perm.gid, &up64->msg_perm.gid); > + err |= __get_user(m.msg_perm.mode, &up64->msg_perm.mode); > + err |= __get_user(m.msg_qbytes, &up64->msg_qbytes); > + } else { > + if (!access_ok(VERIFY_READ, up32, sizeof(*up32))) { > + err = -EFAULT; > + break; > + } > + err = __get_user(m.msg_perm.uid, &up32->msg_perm.uid); > + err |= __get_user(m.msg_perm.gid, &up32->msg_perm.gid); > + err |= __get_user(m.msg_perm.mode, &up32->msg_perm.mode); > + err |= __get_user(m.msg_qbytes, &up32->msg_qbytes); > + } > if (err) > break; > old_fs = get_fs (); > @@ -1702,27 +1778,54 @@ > case MSG_STAT: > old_fs = get_fs (); > set_fs (KERNEL_DS); > - err = sys_msgctl (first, second, (void *) &m64); > + err = sys_msgctl (first, second, &m); > set_fs (old_fs); > - err2 = put_user (m64.msg_perm.key, &up->msg_perm.key); > - err2 |= __put_user(m64.msg_perm.uid, &up->msg_perm.uid); > - err2 |= __put_user(m64.msg_perm.gid, &up->msg_perm.gid); > - err2 |= __put_user(m64.msg_perm.cuid, &up->msg_perm.cuid); > - err2 |= __put_user(m64.msg_perm.cgid, &up->msg_perm.cgid); > - err2 |= __put_user(m64.msg_perm.mode, &up->msg_perm.mode); > - err2 |= __put_user(m64.msg_perm.seq, &up->msg_perm.seq); > - err2 |= __put_user(m64.msg_stime, &up->msg_stime); > - err2 |= __put_user(m64.msg_rtime, &up->msg_rtime); > - err2 |= __put_user(m64.msg_ctime, &up->msg_ctime); > - err2 |= __put_user(m64.msg_cbytes, &up->msg_cbytes); > - err2 |= __put_user(m64.msg_qnum, &up->msg_qnum); > - err2 |= __put_user(m64.msg_qbytes, &up->msg_qbytes); > - err2 |= __put_user(m64.msg_lspid, &up->msg_lspid); > - err2 |= __put_user(m64.msg_lrpid, &up->msg_lrpid); > - if (err2) > - err = -EFAULT; > + if (version == IPC_64) { > + if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) { > + err = -EFAULT; > + break; > + } > + err2 = __put_user(m.msg_perm.key, &up64->msg_perm.key); > + err2 |= __put_user(m.msg_perm.uid, &up64->msg_perm.uid); > + err2 |= __put_user(m.msg_perm.gid, &up64->msg_perm.gid); > + err2 |= __put_user(m.msg_perm.cuid, &up64->msg_perm.cuid); > + err2 |= __put_user(m.msg_perm.cgid, &up64->msg_perm.cgid); > + err2 |= __put_user(m.msg_perm.mode, &up64->msg_perm.mode); > + err2 |= __put_user(m.msg_perm.seq, &up64->msg_perm.seq); > + err2 |= __put_user(m.msg_stime, &up64->msg_stime); > + err2 |= __put_user(m.msg_rtime, &up64->msg_rtime); > + err2 |= __put_user(m.msg_ctime, &up64->msg_ctime); > + err2 |= __put_user(m.msg_cbytes, &up64->msg_cbytes); > + err2 |= __put_user(m.msg_qnum, &up64->msg_qnum); > + err2 |= __put_user(m.msg_qbytes, &up64->msg_qbytes); > + err2 |= __put_user(m.msg_lspid, &up64->msg_lspid); > + err2 |= __put_user(m.msg_lrpid, &up64->msg_lrpid); > + if (err2) > + err = -EFAULT; > + } else { > + if (!access_ok(VERIFY_WRITE, up32, sizeof(*up32))) { > + err = -EFAULT; > + break; > + } > + err2 = __put_user(m.msg_perm.key, &up32->msg_perm.key); > + err2 |= __put_user(m.msg_perm.uid, &up32->msg_perm.uid); > + err2 |= __put_user(m.msg_perm.gid, &up32->msg_perm.gid); > + err2 |= __put_user(m.msg_perm.cuid, &up32->msg_perm.cuid); > + err2 |= __put_user(m.msg_perm.cgid, &up32->msg_perm.cgid); > + err2 |= __put_user(m.msg_perm.mode, &up32->msg_perm.mode); > + err2 |= __put_user(m.msg_perm.seq, &up32->msg_perm.seq); > + err2 |= __put_user(m.msg_stime, &up32->msg_stime); > + err2 |= __put_user(m.msg_rtime, &up32->msg_rtime); > + err2 |= __put_user(m.msg_ctime, &up32->msg_ctime); > + err2 |= __put_user(m.msg_cbytes, &up32->msg_cbytes); > + err2 |= __put_user(m.msg_qnum, &up32->msg_qnum); > + err2 |= __put_user(m.msg_qbytes, &up32->msg_qbytes); > + err2 |= __put_user(m.msg_lspid, &up32->msg_lspid); > + err2 |= __put_user(m.msg_lrpid, &up32->msg_lrpid); > + if (err2) > + err = -EFAULT; > + } > break; > - > } > > return err; > @@ -1845,7 +1948,7 @@ > > case SEMOP: > /* struct sembuf is the same on 32 and 64bit :)) */ > - err = sys_semop (first, (struct sembuf *)A(ptr), > + err = sys_semop (first, (struct sembuf *)AA(ptr), > second); > break; > case SEMGET: > @@ -1853,36 +1956,36 @@ > break; > case SEMCTL: > err = do_sys32_semctl (first, second, third, > - (void *)A(ptr)); > + (void *)AA(ptr)); > break; > > case MSGSND: > err = do_sys32_msgsnd (first, second, third, > - (void *)A(ptr)); > + (void *)AA(ptr)); > break; > case MSGRCV: > err = do_sys32_msgrcv (first, second, fifth, third, > - version, (void *)A(ptr)); > + version, (void *)AA(ptr)); > break; > case MSGGET: > err = sys_msgget ((key_t) first, second); > break; > case MSGCTL: > - err = do_sys32_msgctl (first, second, (void *)A(ptr)); > + err = do_sys32_msgctl (first, second, (void *)AA(ptr)); > break; > > case SHMAT: > err = do_sys32_shmat (first, second, third, > - version, (void *)A(ptr)); > + version, (void *)AA(ptr)); > break; > case SHMDT: > - err = sys_shmdt ((char *)A(ptr)); > + err = sys_shmdt ((char *)AA(ptr)); > break; > case SHMGET: > err = sys_shmget (first, second, third); > break; > case SHMCTL: > - err = do_sys32_shmctl (first, second, (void *)A(ptr)); > + err = do_sys32_shmctl (first, second, (void *)AA(ptr)); > break; > default: > err = -EINVAL; From owner-linux-mips@oss.sgi.com Tue Aug 13 02:21:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7D9L6Rw027832 for ; Tue, 13 Aug 2002 02:21:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7D9L6Kn027831 for linux-mips-outgoing; Tue, 13 Aug 2002 02:21:06 -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.5/8.12.5) with SMTP id g7D9L1Rw027821 for ; Tue, 13 Aug 2002 02:21:02 -0700 Received: (qmail 26139 invoked from network); 13 Aug 2002 09:22:09 -0000 Received: from unknown (HELO ict.ac.cn) (159.226.40.185) by 159.226.39.4 with SMTP; 13 Aug 2002 09:22:09 -0000 Message-ID: <3D58D109.8010908@ict.ac.cn> Date: Tue, 13 Aug 2002 17:27:37 +0800 From: Zheng BaoJian User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.0.0) Gecko/20020607 X-Accept-Language: zh-cn, en-us, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: KDE for Mips Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 233 Lines: 13 Hello: Who have run kde on mips box sucdessfully? -- Baojian Zheng Institute of Computing Technology Chinese Academy of Sciences P.O. Box 2704-25 Beijing, China,100080 Tel: 86-10-62565533 ex. 9311 E-mail: bjzheng@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Aug 13 02:34:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7D9YWRw028018 for ; Tue, 13 Aug 2002 02:34:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7D9YWWT028017 for linux-mips-outgoing; Tue, 13 Aug 2002 02:34:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from relay-1.interhouse.redbus.com (mail.interhouse.redbus.com [80.85.66.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7D9YSRw028007 for ; Tue, 13 Aug 2002 02:34:29 -0700 Received: from [192.168.11.27] (account simone.caronni@interhouse.redbus.com HELO control2) by relay-1.interhouse.redbus.com (CommuniGate Pro SMTP 4.0b4) with ESMTP id 436581 for linux-mips@oss.sgi.com; Tue, 13 Aug 2002 10:36:04 +0100 From: "Simone Caronni" To: "Linux-Mips" Subject: framebuffer + ethernet Date: Tue, 13 Aug 2002 11:41:37 +0200 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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 166 Lines: 7 Hello, I have an O2 R5000 I would like to try Linux on. Can someone please tell me the status and usability of the O2 fb and internal ethernet? Many thanks Simone From owner-linux-mips@oss.sgi.com Tue Aug 13 04:27:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7DBRSRw031260 for ; Tue, 13 Aug 2002 04:27:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7DBRShf031259 for linux-mips-outgoing; Tue, 13 Aug 2002 04:27:28 -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.5/8.12.5) with SMTP id g7DBRLRw031247 for ; Tue, 13 Aug 2002 04:27:21 -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 g7DBTbY10968; Tue, 13 Aug 2002 13:29:37 +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 g7DBTXfo019918; Tue, 13 Aug 2002 13:29:37 +0200 Received: from glaurung (helo=localhost) by melkor with local-esmtp (Exim 3.35 #1 (Debian)) id 17eZrg-0004jv-00; Tue, 13 Aug 2002 13:29:32 +0200 Date: Tue, 13 Aug 2002 13:29:32 +0200 (CEST) From: Vivien Chappelier X-Sender: glaurung@melkor To: Simone Caronni cc: linux-mips@oss.sgi.com Subject: Re: framebuffer + ethernet In-Reply-To: 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 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1143 Lines: 29 On Tue, 13 Aug 2002, Simone Caronni wrote: > Hello, I have an O2 R5000 I would like to try Linux on. Linux on the SGI O2 R5000 is still *very experimental*. You'll need a 2.5 kernel from the CVS at oss.sgi.com and the patches available there: http://www.linux-mips.org/~glaurung/ 2.5.5 is work in progress, you might have higher chances with 2.5.4. There are also compiled kernels available if you want to try. > Can someone please tell me the status and usability of the O2 fb and > internal ethernet? The O2 ethernet is working for simple operations, but has a bug when transmitting a lot of data from the O2. However I've a fix for that I'll make available in the next few days (needs cleanup). The framebuffer is also working approximatively, with two known bugs: the display sometimes (randomly) appears as 'wrapped around' and the colormap is not working properly in 8 bit mode. I've also tried Xfree86 on framebuffer which displays wrong colors (an X bug this time), but works well apart from that. Overall, the O2 is starting to work, but is not stable at all... rather a hacker's toy currently :) regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Tue Aug 13 05:27:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7DCRjRw002889 for ; Tue, 13 Aug 2002 05:27:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7DCRjD4002888 for linux-mips-outgoing; Tue, 13 Aug 2002 05:27:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from relay-1.interhouse.redbus.com (mail.interhouse.redbus.com [80.85.66.51]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7DCRSRw002879 for ; Tue, 13 Aug 2002 05:27:37 -0700 Received: from [192.168.11.27] (account simone.caronni@interhouse.redbus.com HELO control2) by relay-1.interhouse.redbus.com (CommuniGate Pro SMTP 4.0b4) with ESMTP id 437210 for linux-mips@oss.sgi.com; Tue, 13 Aug 2002 13:29:03 +0100 From: "Simone Caronni" To: "Linux-Mips" Subject: RE: framebuffer + ethernet Date: Tue, 13 Aug 2002 14:34:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1412 Lines: 41 Many thanks, I will definitely give it a try. Simone -----Original Message----- From: Vivien Chappelier [mailto:vivien.chappelier@enst-bretagne.fr] Sent: martedi 13 agosto 2002 13.30 To: Simone Caronni Cc: linux-mips@oss.sgi.com Subject: Re: framebuffer + ethernet On Tue, 13 Aug 2002, Simone Caronni wrote: > Hello, I have an O2 R5000 I would like to try Linux on. Linux on the SGI O2 R5000 is still *very experimental*. You'll need a 2.5 kernel from the CVS at oss.sgi.com and the patches available there: http://www.linux-mips.org/~glaurung/ 2.5.5 is work in progress, you might have higher chances with 2.5.4. There are also compiled kernels available if you want to try. > Can someone please tell me the status and usability of the O2 fb and > internal ethernet? The O2 ethernet is working for simple operations, but has a bug when transmitting a lot of data from the O2. However I've a fix for that I'll make available in the next few days (needs cleanup). The framebuffer is also working approximatively, with two known bugs: the display sometimes (randomly) appears as 'wrapped around' and the colormap is not working properly in 8 bit mode. I've also tried Xfree86 on framebuffer which displays wrong colors (an X bug this time), but works well apart from that. Overall, the O2 is starting to work, but is not stable at all... rather a hacker's toy currently :) regards, Vivien Chappelier. From owner-linux-mips@oss.sgi.com Tue Aug 13 10:26:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7DHQVRw010466 for ; Tue, 13 Aug 2002 10:26:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7DHQVkt010464 for linux-mips-outgoing; Tue, 13 Aug 2002 10:26:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7DHQSRw010454 for ; Tue, 13 Aug 2002 10:26:28 -0700 Received: (qmail 2418 invoked by uid 0); 13 Aug 2002 17:28:50 -0000 Received: from pd953e0f6.dip.t-dialin.net (HELO linux) (217.83.224.246) by mail.gmx.net (mp008-rz3) with SMTP; 13 Aug 2002 17:28:50 -0000 Date: Tue, 13 Aug 2002 19:57:57 +0200 From: Michael Grützner To: linux-mips@oss.sgi.com Subject: X Server for RM200 Message-Id: <20020813195757.641cf149.Michael_Gruetzner@gmx.de> In-Reply-To: <200208131716.g7DHGNNu010345@oss.sgi.com> References: <200208131716.g7DHGNNu010345@oss.sgi.com> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.8; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 249 Lines: 9 Hello everyone, this is probably off topic. I've got an SNI RM200 and I need an X server tu run the SINIX/Windows environment. Does anyone know, if XFree86 works with sinix or where I can get a working X Server????? THANKS IN ADVANCE.....Michael From owner-linux-mips@oss.sgi.com Wed Aug 14 01:18:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7E8I8Rw019170 for ; Wed, 14 Aug 2002 01:18:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7E8I83h019169 for linux-mips-outgoing; Wed, 14 Aug 2002 01:18:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-193.ka.dial.de.ignite.net [62.180.196.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7E8I2Rw019159 for ; Wed, 14 Aug 2002 01:18:03 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7E8KNC14437; Wed, 14 Aug 2002 10:20:23 +0200 Date: Wed, 14 Aug 2002 10:20:23 +0200 From: Ralf Baechle To: Florian Lohoff Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20020814102023.B14307@linux-mips.org> References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20011109145443.J8243@paradigm.rfc822.org>; from flo@rfc822.org on Fri, Nov 09, 2001 at 02:54:43PM -0800 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 451 Lines: 14 On Fri, Nov 09, 2001 at 02:54:43PM -0800, Florian Lohoff wrote: > The RM600 is big endian only AFAIK and was running Sinix/Reliant > only. The RM200 port which existed and which might be completely > outdated and non-functional now is for little endian which > the RM200 were delivered with for running Windows-NT. > > Thus - Its a completely new port ... Oh, I need my RM200C as a router so I'm just working on resurrecting that port :) Ralf From owner-linux-mips@oss.sgi.com Wed Aug 14 04:21:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7EBLPRw022008 for ; Wed, 14 Aug 2002 04:21:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7EBLPWI022007 for linux-mips-outgoing; Wed, 14 Aug 2002 04:21:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7EBLGRw021998 for ; Wed, 14 Aug 2002 04:21:17 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8B8C6844; Wed, 14 Aug 2002 13:23:46 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D4EDF37171; Wed, 14 Aug 2002 13:23:00 +0200 (CEST) Date: Wed, 14 Aug 2002 13:23:00 +0200 From: Florian Lohoff To: Ralf Baechle Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20020814112300.GB1331@paradigm.rfc822.org> References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> <20020814102023.B14307@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline In-Reply-To: <20020814102023.B14307@linux-mips.org> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1215 Lines: 41 --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2002 at 10:20:23AM +0200, Ralf Baechle wrote: > On Fri, Nov 09, 2001 at 02:54:43PM -0800, Florian Lohoff wrote: >=20 > > The RM600 is big endian only AFAIK and was running Sinix/Reliant > > only. The RM200 port which existed and which might be completely=20 > > outdated and non-functional now is for little endian which > > the RM200 were delivered with for running Windows-NT. > >=20 > > Thus - Its a completely new port ... >=20 > Oh, I need my RM200C as a router so I'm just working on resurrecting > that port :) Little or Big endian ? I still have an RM200 big endian :) FLo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --wzJLGUyc3ArbnUjN 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 iD8DBQE9Wj2UUaz2rXW+gJcRAlypAJ93qRJW9c5JZot3/EF5f9nUs3TgGwCfcSCx 9cvPEdQ2FE/hhanUsNnDWeQ= =GI09 -----END PGP SIGNATURE----- --wzJLGUyc3ArbnUjN-- From owner-linux-mips@oss.sgi.com Wed Aug 14 06:21:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7EDLORw024362 for ; Wed, 14 Aug 2002 06:21:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7EDLOiQ024361 for linux-mips-outgoing; Wed, 14 Aug 2002 06:21:24 -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.5/8.12.5) with SMTP id g7EDLLRw024352 for ; Wed, 14 Aug 2002 06:21:22 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 08:23:03 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA379C06@ATVX> From: "Siders, Keith" To: "Linux-Mips (E-mail)" Subject: Heap test Date: Wed, 14 Aug 2002 08:21:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 66 Lines: 4 Does the kernel have a heap memory test? I could use one. Keith From owner-linux-mips@oss.sgi.com Wed Aug 14 06:34:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7EDYARw024876 for ; Wed, 14 Aug 2002 06:34:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7EDYAVX024874 for linux-mips-outgoing; Wed, 14 Aug 2002 06:34:10 -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.5/8.12.5) with SMTP id g7EDY6Rw024863 for ; Wed, 14 Aug 2002 06:34:07 -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 g7EDYiu6026657; Wed, 14 Aug 2002 14:34:44 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g7EDYhql026655; Wed, 14 Aug 2002 14:34:43 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: Heap test From: Alan Cox To: "Siders, Keith" Cc: "Linux-Mips (E-mail)" In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA379C06@ATVX> References: <7DF7BFDC95ECD411B4010090278A44CA379C06@ATVX> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 14 Aug 2002 14:34:43 +0100 Message-Id: <1029332083.26226.45.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 379 Lines: 9 On Wed, 2002-08-14 at 14:21, Siders, Keith wrote: > Does the kernel have a heap memory test? I could use one. It does some sanity checking as it goes, but its very hard to do this in a kernel. Virtually allocated spaces have guard pages. Physically allocated space does not, but we do support slab poisoning to spot scribbles in freed memory and failure to do initializations From owner-linux-mips@oss.sgi.com Wed Aug 14 19:43:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7F2hlRw022338 for ; Wed, 14 Aug 2002 19:43:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7F2hlYF022337 for linux-mips-outgoing; Wed, 14 Aug 2002 19:43:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7F2hgRw022328 for ; Wed, 14 Aug 2002 19:43:43 -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 17f5xz-0004PZ-00; Wed, 14 Aug 2002 16:46:11 -0500 Message-ID: <3D5B15DE.7000007@realitydiluted.com> Date: Wed, 14 Aug 2002 21:45:50 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 MIME-Version: 1.0 To: uclibc@uclibc.org, linux-mips@oss.sgi.com Subject: New MIPS native uClibc toolchain RPMS... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 629 Lines: 23 Greetings. I am pleased to announce the availability of the first uClibc native toolchain RPMS for both little and big endian MIPS. These toolchains allow you to compile C and C++ applications for uClibc. They use the last stable 0.9.12 code which was available on 20020807. These RPMS use the following sources: binutils-2.12.1 gcc-3.1 uClibc-0.9.12 linux-2.4.18-headers These were tested exhaustively on both endians of MIPS processors. I would appreciate any feedback. These toolchains can also compile Linux kernels. They are available here: ftp://ftp.realitydiluted.com/MIPS/uclibc Cheers. -Steve From owner-linux-mips@oss.sgi.com Wed Aug 14 23:06:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7F66TRw025218 for ; Wed, 14 Aug 2002 23:06:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7F66Tsg025217 for linux-mips-outgoing; Wed, 14 Aug 2002 23:06:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from rail.cita.utoronto.ca (rail.cita.utoronto.ca [128.100.76.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7F64ARw025170 for ; Wed, 14 Aug 2002 23:04:11 -0700 Received: from [128.100.76.25] (marmot.cita.utoronto.ca) by rail.cita.utoronto.ca id 28191; Thu, 15 Aug 2002 02:06:43 Date: Thu, 15 Aug 2002 02:06:42 -0400 From: Robin Humble To: linux-mips@oss.sgi.com Subject: Re: R4600SC Indy Message-ID: <20020815020642.A23230@marmot.cita.utoronto.ca> References: <20020806111959.C15670@marmot.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020806111959.C15670@marmot.cita.utoronto.ca>; from rjh@marmot.cita.utoronto.ca on Tue, Aug 06, 2002 at 11:19:59AM -0400 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 24028 Lines: 1092 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Aug 06, 2002 at 11:19:59AM -0400, Robin Humble wrote: >I have an R4600SC Indy and an R5000 Indy and the R4600SC hasn't worked >with a kernel since around 2.4.17 13feb2002. I apologise for the vagueness of my previous post. To be precise, the changes that were checked in on 6-mar-2002 broke R4600SC support. These changes were to arch/mips/mm/c-r4k.c (and its mips64 counterpart). The patch below (to 13-aug-02 linux_2_4 CVS) is simply a reversal of the changes made on 6-mar-02 and makes my R4600SC Indy work just fine. I presume that these changes were made for a reason though, so reversing them is presumably not a fix, just a dodgy workaround?? :-/ If there's anything I can do to help narrow the problem down further and find a real fix then please let me know. eg. just applying these saves/restore's to some of the function in c-r4k.c? Unfortunately I have little mips architecture or assembly knowledge (and not heaps of time) so can't really help except to try out things... My R5000SC Indy works fine with unpatched current cvs. Hope this is of some assistance. cheers, robin --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.addSavesForR4600" diff -ruN linux-2.4.19-rc1-13aug02/arch/mips/mm/c-r4k.c linux-2.4.19-rc1-13aug02-rjh/arch/mips/mm/c-r4k.c --- linux-2.4.19-rc1-13aug02/arch/mips/mm/c-r4k.c Tue Aug 13 21:12:38 2002 +++ linux-2.4.19-rc1-13aug02-rjh/arch/mips/mm/c-r4k.c Tue Aug 13 22:05:59 2002 @@ -77,47 +77,83 @@ static inline void r4k_flush_cache_all_s16d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache16(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s32d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache32(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s64d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache64(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s128d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache128(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s32d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache32(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s64d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache64(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s128d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache128(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); + __restore_flags(flags); } static void @@ -126,6 +162,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -143,6 +180,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while (start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -152,6 +190,7 @@ blast_scache16_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -162,6 +201,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -179,6 +219,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -188,6 +229,7 @@ blast_scache32_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -197,6 +239,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -214,6 +257,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -223,6 +267,7 @@ blast_scache64_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -232,6 +277,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -249,6 +295,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -258,6 +305,7 @@ blast_scache128_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -267,6 +315,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -284,6 +333,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -293,6 +343,7 @@ blast_scache32_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -302,6 +353,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -319,6 +371,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -328,6 +381,7 @@ blast_scache64_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -337,6 +391,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (mm->context == 0) return; @@ -354,6 +409,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -363,6 +419,7 @@ blast_scache128_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -372,10 +429,14 @@ 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_dcache16(); blast_icache16(); + __restore_flags(flags); } } @@ -384,10 +445,14 @@ 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_dcache32(); blast_icache32(); + __restore_flags(flags); } } @@ -490,6 +555,7 @@ unsigned long page) { struct mm_struct *mm = vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -504,6 +570,7 @@ #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); @@ -533,12 +600,14 @@ } else blast_scache16_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s32d16i16(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; @@ -553,6 +622,7 @@ #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); @@ -581,12 +651,14 @@ } else blast_scache32_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s64d16i16(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; @@ -601,6 +673,7 @@ #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); @@ -629,12 +702,14 @@ } else blast_scache64_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s128d16i16(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; @@ -649,6 +724,7 @@ #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); @@ -678,12 +754,14 @@ } else blast_scache128_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s32d32i32(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; @@ -698,6 +776,7 @@ #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); @@ -727,12 +806,14 @@ } else blast_scache32_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s64d32i32(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; @@ -747,6 +828,7 @@ #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); @@ -776,12 +858,14 @@ } else blast_scache64_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s128d32i32(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; @@ -796,6 +880,7 @@ #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); @@ -824,12 +909,14 @@ } else blast_scache128_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_d16i16(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; @@ -844,6 +931,7 @@ #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); @@ -872,12 +960,14 @@ blast_dcache16_page_indexed(page); } out: + __restore_flags(flags); } static void r4k_flush_cache_page_d32i32(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; @@ -892,6 +982,7 @@ #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); @@ -921,12 +1012,14 @@ blast_dcache32_page_indexed(page); } out: + __restore_flags(flags); } static void r4k_flush_cache_page_d32i32_r4600(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; @@ -941,6 +1034,7 @@ #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); @@ -970,6 +1064,7 @@ blast_dcache32_page_indexed(page ^ dcache_waybit); } out: + __restore_flags(flags); } /* If the addresses passed to these routines are valid, they are diff -ruN linux-2.4.19-rc1-13aug02/arch/mips64/mm/r4xx0.c linux-2.4.19-rc1-13aug02-rjh/arch/mips64/mm/r4xx0.c --- linux-2.4.19-rc1-13aug02/arch/mips64/mm/r4xx0.c Tue Aug 13 21:12:43 2002 +++ linux-2.4.19-rc1-13aug02-rjh/arch/mips64/mm/r4xx0.c Tue Aug 13 22:05:59 2002 @@ -693,47 +693,83 @@ static inline void r4k_flush_cache_all_s16d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache16(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s32d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache32(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s64d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache64(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s128d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); blast_scache128(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s32d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache32(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s64d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache64(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_s128d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); blast_scache128(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_d16i16(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16(); blast_icache16(); + __restore_flags(flags); } static inline void r4k_flush_cache_all_d32i32(void) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32(); blast_icache32(); + __restore_flags(flags); } static void r4k_flush_cache_range_s16d16i16(struct mm_struct *mm, @@ -741,6 +777,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -759,6 +796,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -768,6 +806,7 @@ blast_scache16_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -777,6 +816,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -795,6 +835,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -804,6 +845,7 @@ blast_scache32_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -813,6 +855,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -831,6 +874,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -840,6 +884,7 @@ blast_scache64_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -849,6 +894,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -867,6 +913,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -876,6 +923,7 @@ blast_scache128_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -885,6 +933,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -903,6 +952,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -912,6 +962,7 @@ blast_scache32_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -921,6 +972,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) == 0) return; @@ -939,6 +991,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -948,6 +1001,7 @@ blast_scache64_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -957,6 +1011,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; if (CPU_CONTEXT(smp_processor_id(), mm) != 0) return; @@ -975,6 +1030,7 @@ pmd_t *pmd; pte_t *pte; + __save_and_cli(flags); while(start < end) { pgd = pgd_offset(mm, start); pmd = pmd_offset(pgd, start); @@ -984,6 +1040,7 @@ blast_scache128_page(start); start += PAGE_SIZE; } + __restore_flags(flags); } } } @@ -993,10 +1050,14 @@ unsigned long end) { if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { + unsigned long flags; + #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + __save_and_cli(flags); blast_dcache16(); blast_icache16(); + __restore_flags(flags); } } @@ -1005,10 +1066,14 @@ unsigned long end) { if (CPU_CONTEXT(smp_processor_id(), mm) != 0) { + unsigned long flags; + #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + __save_and_cli(flags); blast_dcache32(); blast_icache32(); + __restore_flags(flags); } } @@ -1111,6 +1176,7 @@ unsigned long page) { struct mm_struct *mm = vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -1125,6 +1191,7 @@ #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); @@ -1153,12 +1220,14 @@ } else blast_scache16_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s32d16i16(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; @@ -1173,6 +1242,7 @@ #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); @@ -1200,12 +1270,14 @@ } else blast_scache32_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s64d16i16(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; @@ -1220,6 +1292,7 @@ #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); @@ -1248,12 +1321,14 @@ } else blast_scache64_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s128d16i16(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; @@ -1268,6 +1343,7 @@ #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); @@ -1297,12 +1373,14 @@ } else blast_scache128_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s32d32i32(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; @@ -1317,6 +1395,7 @@ #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); @@ -1347,12 +1426,14 @@ } else blast_scache32_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s64d32i32(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; @@ -1367,6 +1448,7 @@ #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); @@ -1397,12 +1479,14 @@ } else blast_scache64_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_s128d32i32(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; @@ -1417,6 +1501,7 @@ #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); @@ -1445,12 +1530,14 @@ } else blast_scache128_page(page); out: + __restore_flags(flags); } static void r4k_flush_cache_page_d16i16(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; @@ -1465,6 +1552,7 @@ #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); @@ -1492,12 +1580,14 @@ blast_dcache16_page_indexed(page); } out: + __restore_flags(flags); } static void r4k_flush_cache_page_d32i32(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; @@ -1512,6 +1602,7 @@ #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); @@ -1541,12 +1632,14 @@ blast_dcache32_page_indexed(page); } out: + __restore_flags(flags); } static void r4k_flush_cache_page_d32i32_r4600(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; @@ -1561,6 +1654,7 @@ #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); @@ -1590,6 +1684,7 @@ blast_dcache32_page_indexed(page ^ dcache_waybit); } out: + __restore_flags(flags); } static void r4k_flush_page_to_ram_s16(struct page *page) @@ -1614,12 +1709,20 @@ static void r4k_flush_page_to_ram_d16(struct page *page) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache16_page((unsigned long)page_address(page)); + __restore_flags(flags); } static void r4k_flush_page_to_ram_d32(struct page *page) { + unsigned long flags; + + __save_and_cli(flags); blast_dcache32_page((unsigned long)page_address(page)); + __restore_flags(flags); } static void --liOOAslEiF7prFVr-- From owner-linux-mips@oss.sgi.com Thu Aug 15 03:04:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FA49Rw028412 for ; Thu, 15 Aug 2002 03:04:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FA49Xp028411 for linux-mips-outgoing; Thu, 15 Aug 2002 03:04:09 -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.5/8.12.5) with SMTP id g7FA43Rw028400 for ; Thu, 15 Aug 2002 03:04:03 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g7FA6WXb014275 for ; Thu, 15 Aug 2002 03:06:32 -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 DAA22510 for ; Thu, 15 Aug 2002 03:06:31 -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 g7FA6Vb26171 for ; Thu, 15 Aug 2002 12:06:31 +0200 (MEST) Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g7FA6VN02588 for ; Thu, 15 Aug 2002 12:06:31 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Thu, 15 Aug 2002 12:06:31 +0200 (MEST) From: Kjeld Borch Egevang To: linux-mips mailing list Subject: N32 support in 64-bit MIPS Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1192 Lines: 33 Hi all. I would like to hear your opinion on this. Currently we have the N64 interface which is the basic interface to the kernel. Then we have the O32 interface which is implemented as a separate set of syscalls in unistd.h and proper conversion in the kernel. Now, how can we support N32? Many syscalls will work if N32 is treated the same way as O32. This will of course mean, that O32 must be compiled in in order to support N32. But e.g. a syscall like: int _llseek(unsigned int fd, unsigned long offset_high, unsigned long offset_low, loff_t *result, unsigned int whence); needs special treatment since loff_t is a long long (passed in a single register for N32) and there are 6 arguments (all passed in registers for N32, passed in registers and on the stack for O32). Should we simply add 235 new syscall numbers to unistd.h named __NR_LinuxN32...? /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 Aug 15 04:28:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FBSuRw032170 for ; Thu, 15 Aug 2002 04:28:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FBSujP032169 for linux-mips-outgoing; Thu, 15 Aug 2002 04:28:56 -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.5/8.12.5) with SMTP id g7FBSlRw032159 for ; Thu, 15 Aug 2002 04:28:48 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E526D13587; Thu, 15 Aug 2002 13:31:21 +0200 (CEST) Date: Thu, 15 Aug 2002 13:31:21 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: R4600SC Indy Message-ID: <20020815113121.GV19435@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20020806111959.C15670@marmot.cita.utoronto.ca> <20020815020642.A23230@marmot.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="80wSvbVxSilpZkXN" Content-Disposition: inline In-Reply-To: <20020815020642.A23230@marmot.cita.utoronto.ca> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1861 Lines: 52 --80wSvbVxSilpZkXN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2002-08-15 02:06:42 -0400, Robin Humble wrote in message <20020815020642.A23230@marmot.cita.utoronto.ca>: > On Tue, Aug 06, 2002 at 11:19:59AM -0400, Robin Humble wrote: > >I have an R4600SC Indy and an R5000 Indy and the R4600SC hasn't worked > >with a kernel since around 2.4.17 13feb2002.=20 >=20 > To be precise, the changes that were checked in on 6-mar-2002 broke > R4600SC support. These changes were to arch/mips/mm/c-r4k.c (and its mips= 64 > counterpart). The patch below (to 13-aug-02 linux_2_4 CVS) is simply a > reversal of the changes made on 6-mar-02 and makes my R4600SC Indy work > just fine. They broke R4600 Version 1.7 to be exactly, as this CPU has got some bugs in it's cache flush commands. The result is: you need to disable interrupts to get the desired result, but that's some kind of PITA performance-wise, so the workaround for R4k6 V1.7 was dropped later on. I've got a somewhat better patch introducing all needed routines for the buggy R4k6 V1.7 and setting them up (more or less correctly). However, it seems that I did bug somewhere. My patch seems to not be as stable as expected. I tried to post it at the weekend, but it didn't show up (size?). I'll try it again these days, though. 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/ --80wSvbVxSilpZkXN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9W5EJHb1edYOZ4bsRAjW2AJ9hRHkMaoAOX9w6Tk2lVU3SXzXP3gCeKg84 +LYkIkf6aW2sYWa/Vg4dXsk= =zRuK -----END PGP SIGNATURE----- --80wSvbVxSilpZkXN-- From owner-linux-mips@oss.sgi.com Thu Aug 15 08:43:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FFhXRw005854 for ; Thu, 15 Aug 2002 08:43:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FFhXB7005853 for linux-mips-outgoing; Thu, 15 Aug 2002 08:43:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-116.ka.dial.de.ignite.net [62.180.196.116]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7FFhRRw005844 for ; Thu, 15 Aug 2002 08:43:28 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7FFjoc10244; Thu, 15 Aug 2002 17:45:50 +0200 Date: Thu, 15 Aug 2002 17:45:49 +0200 From: Ralf Baechle To: Florian Lohoff Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20020815174549.A10199@linux-mips.org> References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> <20020814102023.B14307@linux-mips.org> <20020814112300.GB1331@paradigm.rfc822.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: <20020814112300.GB1331@paradigm.rfc822.org>; from flo@rfc822.org on Wed, Aug 14, 2002 at 01:23:00PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 304 Lines: 11 On Wed, Aug 14, 2002 at 01:23:00PM +0200, Florian Lohoff wrote: > > Oh, I need my RM200C as a router so I'm just working on resurrecting > > that port :) > > Little or Big endian ? I still have an RM200 big endian :) Little endian - still don't have a floppy with the big endian firmware ... Ralf From owner-linux-mips@oss.sgi.com Thu Aug 15 09:17:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FGHVRw006662 for ; Thu, 15 Aug 2002 09:17:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FGHVo0006661 for linux-mips-outgoing; Thu, 15 Aug 2002 09:17: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-116.ka.dial.de.ignite.net [62.180.196.116]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7FGHMRw006652 for ; Thu, 15 Aug 2002 09:17:24 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7FGJqw10543; Thu, 15 Aug 2002 18:19:52 +0200 Date: Thu, 15 Aug 2002 18:19:52 +0200 From: Ralf Baechle To: Kjeld Borch Egevang Cc: linux-mips mailing list Subject: Re: N32 support in 64-bit MIPS Linux Message-ID: <20020815181952.B10199@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from kjelde@mips.com on Thu, Aug 15, 2002 at 12:06:31PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1454 Lines: 34 On Thu, Aug 15, 2002 at 12:06:31PM +0200, Kjeld Borch Egevang wrote: > I would like to hear your opinion on this. > > Currently we have the N64 interface which is the basic interface to the > kernel. Then we have the O32 interface which is implemented as a separate > set of syscalls in unistd.h and proper conversion in the kernel. > > Now, how can we support N32? Many syscalls will work if N32 is treated the > same way as O32. This will of course mean, that O32 must be compiled in in > order to support N32. But e.g. a syscall like: > > int _llseek(unsigned int fd, unsigned long offset_high, unsigned long > offset_low, loff_t *result, unsigned int whence); > > needs special treatment since loff_t is a long long (passed in a single > register for N32) and there are 6 arguments (all passed in registers for > N32, passed in registers and on the stack for O32). > > Should we simply add 235 new syscall numbers to unistd.h named > __NR_LinuxN32...? o32 currently has 240 syscalls. Of these a good number is simply junk. No syscall(2), oldstat(2), oldfstat(2), no experimental UNIX Version 7 bs like mpx(2) for new ABIs; away with stupid multiplexor calls like socketcall(2) and funny intelisms like vm86(2). That's the first cleanup I'm planning. For what will be left over, N32 and N64 use the same subroutine calling interface we'll be able to share most if not all syscalls between the two. llseek(2) is just one example. Ralf From owner-linux-mips@oss.sgi.com Thu Aug 15 09:29:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FGTFRw006867 for ; Thu, 15 Aug 2002 09:29:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FGTFm9006866 for linux-mips-outgoing; Thu, 15 Aug 2002 09:29:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7FGRoRw006850 for ; Thu, 15 Aug 2002 09:27:50 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815163020.BVZ13899.sccrmhc02.attbi.com@ocean.lucon.org>; Thu, 15 Aug 2002 16:30:20 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id 8EFE6125D6; Thu, 15 Aug 2002 09:30:14 -0700 (PDT) Date: Thu, 15 Aug 2002 09:30:14 -0700 From: "H. J. Lu" To: linux-gcc@vger.kernel.org, Kenneth Albanowski , Mat Hostetter , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , gcc@gcc.gnu.org, GNU C Library Subject: The Linux binutils 2.13.90.0.4 is released Message-ID: <20020815093014.A17859@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.3 required=5.0 tests=PORN_10,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 18392 Lines: 658 This version of binutils may be required for gcc 3.2 on Linux. H.J. ---- This is the beta release of binutils 2.13.90.0.4 for Linux, which is based on binutils 2002 0814 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.13.90.0.4 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.13.90.0.3: 1. Update from binutils 2002 0814. 2. Fix symbol versioning bugs for gcc 3.2. 3. Fix mips gas. Changes from binutils 2.13.90.0.2: 1. Update from binutils 2002 0809. 2. Fix a mips gas compatibility bug. 3. Fix an x86 TLS bfd bug. 4. Fix an x86 PIC gas bug. 5. Improve symbol versioning support. Changes from binutils 2.12.90.0.15: 1. Update from binutils 2002 0802. 2. Initial support for mips n32 ABI. 3. Fix some x86 TLS bugs. Changes from binutils 2.12.90.0.14: 1. Update from binutils 2002 0717. 2. Fix an ia64 assembler bug. 3. Fix a symbol versioning bug. 4. You have to upgrade to modutils 2.4.19 or apply the modutils patch enclosed here in order to support System.map generated by the new nm. Changes from binutils 2.12.90.0.12: 1. Update from binutils 2002 0627. 2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel. Changes from binutils 2.12.90.0.11: 1. Update from binutils 2002 0618. 2. Fix a 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.13.90.0.4.tar.gz. Source code. 2. binutils-2.13.90.0.3-2.13.90.0.4.diff.gz. Patch against the previous beta source code. 3. binutils-2.13.90.0.4-1.i386.rpm. IA-32 binary RPM for RedHat 7.3. There is no separate source rpm. You can do # rpm -ta binutils-2.13.90.0.4.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 08/14/2002 ---- > On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote: > > Something you might like to warn about in your next release.. > > > > The 2002-07-05 bfd change exposes a bug in modutils. depmod scans the > > output of nm for a `?' symbol type when looking for certain symbols. > > nm used to return `?' for symbols in sections other than some standard > > sections like .text and .data. Now, nm returns a better guess as to > > the symbol type. > No, but it parses System.map, which is generated by nm. This was in modutils-2.4.16. Fix follows. diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c --- modutils-2.4.16.orig/depmod/depmod.c 2002-04-28 17:23:35.000000000 +0930 +++ modutils-2.4.16/depmod/depmod.c 2002-07-15 16:41:20.000000000 +0930 @@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); /* The second word is either the symbol name or a type */ - if (p && strlen(p) == 1) { /* System.map */ + if (p && p[0] && !p[1]) { /* System.map */ is_mapfile = 1; - if (*p != '?') - p = NULL; - else - p = strtok(NULL, " \t\n"); + p = strtok(NULL, " \t\n"); } else { /* /proc/ksyms copy */ if (p && strtok(NULL, " \t\n")) p = NULL; @@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms) if (!isspace(*line)) /* Adressless symbol? */ p = strtok(NULL, " \t\n"); if (is_mapfile) { - if (*p != '?') + if (!p || !p[0] || p[1]) continue; p = strtok(NULL, " \t\n"); /* Sparc has symbols like '.div' that need to be -- Alan Modra IBM OzLabs - Linux Technology Centre From owner-linux-mips@oss.sgi.com Thu Aug 15 12:44:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7FJiERw010099 for ; Thu, 15 Aug 2002 12:44:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7FJiDJa010098 for linux-mips-outgoing; Thu, 15 Aug 2002 12:44:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (c-180-196-116.ka.dial.de.ignite.net [62.180.196.116]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7FJi5Rw010089 for ; Thu, 15 Aug 2002 12:44:07 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7FJkfn12337 for linux-mips@oss.sgi.com; Thu, 15 Aug 2002 21:46:41 +0200 Date: Thu, 15 Aug 2002 21:46:41 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20020815214641.A8335@linux-mips.org> References: <200208151925.g7FJPbfD009802@oss.sgi.com> <20020815193340.GB10730@lug-owl.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: <20020815193340.GB10730@lug-owl.de>; from jbglaw@lug-owl.de on Thu, Aug 15, 2002 at 09:33:40PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 848 Lines: 23 On Thu, Aug 15, 2002 at 09:33:40PM +0200, Jan-Benedict Glaw wrote: > > arch/mips/boot : Tag: linux_2_4 elf2ecoff.c > > > > Log message: > > Run through indent. Convert from K&R C to ANSI. Further crapectomy. > > Only a notice: is by now known what elf2ecoff broke? As an effect, I see > that modern (TM) elf2ecoffs fail to produce an loadable kernel for my > indy (which boots fine with ELF, too). > > However, it could also be a problem with changes addresses or so > somewhere else (eg. ./linux/arch/mips/Makefile)... Could you try older versions of the elf2ecoff utility from CVS to see if that is making a difference? Ralf PS: Please obey the reply-to header of linux-cvs postings. This is not a discussion list and I plan to configure the list to send anything that isn't a CVS notification to /dev/null in the future. From owner-linux-mips@oss.sgi.com Fri Aug 16 00:59:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7G7xlRw027949 for ; Fri, 16 Aug 2002 00:59:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7G7xlGl027948 for linux-mips-outgoing; Fri, 16 Aug 2002 00:59:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from v-wall.ihep.ac.cn (v-wall.ihep.ac.cn [202.38.128.171]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7G7xRRw027938 for ; Fri, 16 Aug 2002 00:59:32 -0700 Received: from mail.ihep.ac.cn (v-wall.ihep.ac.cn [127.0.0.1]) by v-wall.ihep.ac.cn (8.11.6/8.11.6) with ESMTP id g7G7pau26656 for ; Fri, 16 Aug 2002 15:51:36 +0800 Received: from bixy (nsg.ihep.ac.cn [202.38.128.36]) by mail.ihep.ac.cn (8.11.6/8.11.6) with SMTP id g7G7uvR08742 for ; Fri, 16 Aug 2002 15:56:57 +0800 Message-Id: <200208160756.g7G7uvR08742@mail.ihep.ac.cn> Date: Fri, 16 Aug 2002 16:1:48 +0800 From: "±ÏѧҢ" To: "linux-mips@oss.sgi.com" Subject: irq handle of sb1250 X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====000_Dragon468832073236_=====" X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1982 Lines: 38 This is a multi-part message in MIME format. --=====000_Dragon468832073236_===== Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit hi, who is using sb1250/swarm board? i have mapped all the interrupts of second cpu to IP7(default IP2). after changing irq.c and irq_handler.S, second cpu can't get any interrupt. I don't know why it is. --=====000_Dragon468832073236_===== Content-Type: image/gif; name="LittleBoy.GIF" Content-Disposition: FoxmailIcon; filename="LittleBoy.GIF" Content-Transfer-Encoding: base64 R0lGODlhIAAgANQAAGCXzwCAgGBnYP/IkPzJmpFjPBsNA2Q8HxQDACIGAk4HADYDAA0AAP///wAA ANPT05KSkm5ubmVlZUZGRiUlJRgYGBEREQ8PDwcHBwMDAwAAAAAAAAAAAAAAAAAAAAAAACH/C05F VFNDQVBFMi4wAwEAAAAh/sJodHRwOi8vd3d3LnJ0bHNvZnQuY29tL2FuaW1hZ2ljLwoKQ3JlYXRl ZCB3aXRoIEFuaW1hZ2ljIEdJRiBWIDEuMjJhCmJ5IFJpZ2h0IHRvIExlZnQgU29mdHdhcmUgSW5j LgoKVG8gc3VwcHJlc3MgdGhpcyBtZXNzYWdlIGluIHRoZSByZWdpc3RlcmVkIHZlcnNpb24KdW5j aGVjayAiT3B0aW9ucyB8IEFuaW1hZ2ljIGNvbW1lbnQgZnJhbWUiCgAh+QQJGQABACwAAAAAIAAg AAAF1mAgjmRpnmiqrqrjvjCLugNsO3LpDPz91rgcggf07XqyYa/nI9ZWytqy6HQGT1HrtEq8mhjc 45b7NImB5DTSrP6py6UoLfweLEwGpuBcJ95LYEANYm5vfyQOeQ4Ng12LfFyHIw5gi41AApdqkiIO CUxdjJppnAGBYYyQBQUERAoleW2QRAWuJFmOfbW1rySnfVy7A70jsV3ARAc8xCO/RXNkC8rDWGGz ZAgpzsgD2Srbfd4rCZ/ALjki5OXWXjKWoz2D6AEvooM2ojEtAADvqfz+BgE0EQIAIfkECRkAAQAs AAAAACAAIAAABc5gII5kaZ5oqq6q474wi7oDbDty6Qz8/da4HIIH9O16smGv5yPWVsrasuh0Bk9R 67RKvJoY3OOW+zSJgeQ00qz+qculKC38HixMhum5TryXwFKBVHV+JA55R2KJhGZgMFt7XIUjDglM XZhvkyKAYW5OBQUERAoleW2RRAWkJFldqVWrq6UknXxcsgO0I6eZtwMHPLsjtkVzZAvBulievwgp xb8DzyrRfNQrCZa3Ljki2tueXjIODeaR5eMrL+bnNu0xLQAA5e0NDvP18PkmIQAh+QQJGQABACwA AAAAIAAgAAAF02AgjmRpnmiqrqrjvjCLug9sO3LpPPz91rgchgf07XqyYa/nI9ZWytqy6HQGT1Hr tEq8mjLc45b7NImB5DTSrP6py6UoLfx+VEwWpuRcJ95LYEANYm5vfyQOeQ4Ng12LfFyHIw5gi41A EpdqkiIOF0xdjJppnAGBYYyQERFOFCV5bZBErDyuI1mOfaystiOnfVy7D70isF3ARBO1X1U2m8rD WGGyZBgpv8g81irYwNsrF5/ALjki4eLTXjKWoz2D5QEvooM2ojEtEBDsqfn7g/0mQgAAOw== --=====000_Dragon468832073236_=====-- From owner-linux-mips@oss.sgi.com Fri Aug 16 01:58:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7G8wLRw013658 for ; Fri, 16 Aug 2002 01:58:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7G8wK9R013657 for linux-mips-outgoing; Fri, 16 Aug 2002 01:58: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.5/8.12.5) with SMTP id g7G8wBRw013638 for ; Fri, 16 Aug 2002 01:58:11 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g7G90eXb018654 for ; Fri, 16 Aug 2002 02:00: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 CAA12088 for ; Fri, 16 Aug 2002 02:00:43 -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 g7G90hb00902 for ; Fri, 16 Aug 2002 11:00:43 +0200 (MEST) Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g7G90ht08462 for ; Fri, 16 Aug 2002 11:00:43 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Fri, 16 Aug 2002 11:00:43 +0200 (MEST) From: Kjeld Borch Egevang To: linux-mips mailing list Subject: Re: N32 support in 64-bit MIPS Linux In-Reply-To: <20020815181952.B10199@linux-mips.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2477 Lines: 64 On Thu, 15 Aug 2002, Ralf Baechle wrote: > On Thu, Aug 15, 2002 at 12:06:31PM +0200, Kjeld Borch Egevang wrote: > > > I would like to hear your opinion on this. > > > > Currently we have the N64 interface which is the basic interface to the > > kernel. Then we have the O32 interface which is implemented as a separate > > set of syscalls in unistd.h and proper conversion in the kernel. > > > > Now, how can we support N32? Many syscalls will work if N32 is treated the > > same way as O32. This will of course mean, that O32 must be compiled in in > > order to support N32. But e.g. a syscall like: > > > > int _llseek(unsigned int fd, unsigned long offset_high, unsigned long > > offset_low, loff_t *result, unsigned int whence); > > > > needs special treatment since loff_t is a long long (passed in a single > > register for N32) and there are 6 arguments (all passed in registers for > > N32, passed in registers and on the stack for O32). > > > > Should we simply add 235 new syscall numbers to unistd.h named > > __NR_LinuxN32...? > > o32 currently has 240 syscalls. Of these a good number is simply > junk. No syscall(2), oldstat(2), oldfstat(2), no experimental > UNIX Version 7 bs like mpx(2) for new ABIs; away with stupid multiplexor > calls like socketcall(2) and funny intelisms like vm86(2). That's > the first cleanup I'm planning. > > For what will be left over, N32 and N64 use the same subroutine calling > interface we'll be able to share most if not all syscalls between the two. > llseek(2) is just one example. Some syscalls will definitely not work for N32 with the N64 calling interface: int execve(const char *filename, char *const argv [], char *const envp[]); - where argv and envp points to arrays of pointers (4 bytes in N32, 8 bytes in N64) int fstat(int filedes, struct stat *buf); int utime(const char *filename, struct utimbuf *buf); clock_t times(struct tms *buf); int ioctl(int d, int request, ...); int fcntl(int fd, int cmd, struct flock * lock); - struct contains long (4 bytes in N32, 8 bytes in N64) So my point is, that we will need some of the O32 conversion stuff for N32 as well. /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 Fri Aug 16 02:26:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7G9QgRw014204 for ; Fri, 16 Aug 2002 02:26:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7G9QgN5014203 for linux-mips-outgoing; Fri, 16 Aug 2002 02:26:42 -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.5/8.12.5) with SMTP id g7G9QYRw014194 for ; Fri, 16 Aug 2002 02:26:35 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id A7A78133EF; Fri, 16 Aug 2002 11:29:12 +0200 (CEST) Date: Fri, 16 Aug 2002 11:29:12 +0200 From: Jan-Benedict Glaw To: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 Message-ID: <20020816092912.GF10730@lug-owl.de> Mail-Followup-To: linux-mips@oss.sgi.com References: <20011109212516.D16534@lug-owl.de> <20011109131211.D8243@paradigm.rfc822.org> <20011109233555.G16534@lug-owl.de> <20011109145443.J8243@paradigm.rfc822.org> <20020814102023.B14307@linux-mips.org> <20020814112300.GB1331@paradigm.rfc822.org> <20020815174549.A10199@linux-mips.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: <20020815174549.A10199@linux-mips.org> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1230 Lines: 41 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2002-08-15 17:45:49 +0200, Ralf Baechle wrote in message <20020815174549.A10199@linux-mips.org>: > On Wed, Aug 14, 2002 at 01:23:00PM +0200, Florian Lohoff wrote: > > > Oh, I need my RM200C as a router so I'm just working on resurrecting > > > that port :) > >=20 > > Little or Big endian ? I still have an RM200 big endian :) >=20 > Little endian - still don't have a floppy with the big endian firmware ... Flo has got EB, you've got EL. I once again think about an archive of EPROM, EEPROM and flash contents... That would especially also help those broken /240 with MOP-only firmware... 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/ --ni93GHxFvA+th69W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9XMXnHb1edYOZ4bsRApq9AJ9qQy4fESkE6mf/EDuRRKUbuSJc8QCdFwbh 29tKZbcggaKOysHkwX3w7sc= =ecKc -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From owner-linux-mips@oss.sgi.com Fri Aug 16 02:33:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7G9X8Rw014324 for ; Fri, 16 Aug 2002 02:33:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7G9X8Uh014323 for linux-mips-outgoing; Fri, 16 Aug 2002 02:33:08 -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.5/8.12.5) with SMTP id g7G9WtRw014314 for ; Fri, 16 Aug 2002 02:32:56 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id A945D133EF; Fri, 16 Aug 2002 11:35:31 +0200 (CEST) Date: Fri, 16 Aug 2002 11:35:31 +0200 From: Jan-Benedict Glaw To: linux-mips mailing list Subject: [Q]: Was this chunk of a patch really intended? Message-ID: <20020816093531.GG10730@lug-owl.de> Mail-Followup-To: linux-mips mailing list Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HKEL+t8MFpg/ASTE" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net X-Spam-Status: No, hits=-5.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2385 Lines: 79 --HKEL+t8MFpg/ASTE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! I'm once again looking at R4k6 V1.7 support. Diffing out the patch which removed V1.7 support, I find this chunk: --------------------------------------------------------------------------- @@ -1010,14 +921,12 @@ blast_dcache32_page_indexed(page); } out: - __restore_flags(flags); } static void r4k_flush_cache_page_d32i32_r4600(struct vm_area_struct *vma, unsigned long page) { =20 struct mm_struct *mm =3D vma->vm_mm; - unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -1032,7 +941,6 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif - __save_and_cli(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -1062,7 +970,6 @@ blast_dcache32_page_indexed(page ^ dcache_waybit); } out: - __restore_flags(flags); } /* If the addresses passed to these routines are valid, they are --------------------------------------------------------------------------- Depending on this function's name, I think this part of the patch is not that shiny. I'd suspect to leave __save_and_cli()/__restore_flags() in this function, or to rename the function, as it used for more than only R4600: -------------------------------------------------------------------------- switch(mips_cpu.cputype) { case CPU_R4600: /* QED style two way caches? */ case CPU_R4700: case CPU_R5000: case CPU_NEVADA: _flush_cache_page =3D r4k_flush_cache_page_d32i32_r4600; } -------------------------------------------------------------------------- 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/ --HKEL+t8MFpg/ASTE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9XMdjHb1edYOZ4bsRAtwmAJ9cx0eYsaSoEWFXPjHJi9naVBwVawCfVOtZ 8aHgp59G0bqCRmNwgI7h6Ac= =o59m -----END PGP SIGNATURE----- --HKEL+t8MFpg/ASTE-- From owner-linux-mips@oss.sgi.com Fri Aug 16 04:24:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7GBOhRw021814 for ; Fri, 16 Aug 2002 04:24:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7GBOhhv021813 for linux-mips-outgoing; Fri, 16 Aug 2002 04:24:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from webmail24.rediffmail.com (webmail24.rediffmail.com [203.199.83.146] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7GBOZRw021804 for ; Fri, 16 Aug 2002 04:24:36 -0700 Received: (qmail 1293 invoked by uid 510); 16 Aug 2002 11:26:24 -0000 Date: 16 Aug 2002 11:26:24 -0000 Message-ID: <20020816112624.1292.qmail@webmail24.rediffmail.com> Received: from unknown (203.197.186.246) by rediffmail.com via HTTP; 16 Aug 2002 11:26:24 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@oss.sgi.com Subject: boot hangs in execeving the shell Content-type: text/plain; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1057 Lines: 36 Hello All, I have been able to boot linux on mips idt cpu , but it gets hanged while execving the "/bin/sh" in init/main.c. it hangs after "submit_bh(READ...)" called from block_read_full_page (fs/buffer.c). also if i use debugging functions like show_trace() or show_stack() it reports unable to handle kernel paging request at virtual address 000000c8 and then oops process name it reports is "swapper". this virtual address 000000c8 is quite strange. as kernel starts from 0x80000000 onwards. can initrd be faulty someway to cause this? i have taken initrd from some other source which i amn't sure whether it is was compiled little or big endian. my kernel is compiled with "mips-linux-" the big endian toolchain set. anybody can share source for minimal rootfilesystem so that i can compile appropiately and check. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-linux-mips@oss.sgi.com Fri Aug 16 08:13:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7GFDSRw026652 for ; Fri, 16 Aug 2002 08:13:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7GFDRS9026651 for linux-mips-outgoing; Fri, 16 Aug 2002 08:13:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from therocky.oushi.org (165.125.26.24.cfl.rr.com [24.26.125.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7GFDNRw026642 for ; Fri, 16 Aug 2002 08:13:24 -0700 Received: from curtis by therocky.oushi.org with local (Exim 3.35 #1 (Debian)) id 17fjqa-0007os-00 for ; Fri, 16 Aug 2002 11:21:12 -0500 Date: Fri, 16 Aug 2002 11:21:12 -0500 To: linux-mips@oss.sgi.com Subject: SGI O2 R5000 Message-ID: <20020816162112.GB29649@therocky> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Curtis Robinson X-Spam-Status: No, hits=1.9 required=5.0 tests=SUBJ_ALL_CAPS version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 383 Lines: 10 I know this question is probably asked alot. I tried looking at some of the mailing list archives. I wanted to know if it is possible to install Linux on SGI 02 R5000's I noticed there was support for R5000s, but not for R5000 that had CPU-controlled secondary cache. I couldnt figure out how to find out if the 02 I have is one or the other. -- Curtis Robinson crobinso@fit.edu From owner-linux-mips@oss.sgi.com Fri Aug 16 08:56:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7GFuGRw027590 for ; Fri, 16 Aug 2002 08:56:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7GFuFCr027589 for linux-mips-outgoing; Fri, 16 Aug 2002 08:56:15 -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-146.ka.dial.de.ignite.net [62.180.196.146]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7GFu6Rw027580 for ; Fri, 16 Aug 2002 08:56:11 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7GFwba02794; Fri, 16 Aug 2002 17:58:37 +0200 Date: Fri, 16 Aug 2002 17:58:37 +0200 From: Ralf Baechle To: Curtis Robinson Cc: linux-mips@oss.sgi.com Subject: Re: SGI O2 R5000 Message-ID: <20020816175837.B2597@linux-mips.org> References: <20020816162112.GB29649@therocky> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020816162112.GB29649@therocky>; from curtis@oushi.org on Fri, Aug 16, 2002 at 11:21:12AM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 514 Lines: 13 On Fri, Aug 16, 2002 at 11:21:12AM -0500, Curtis Robinson wrote: > I know this question is probably asked alot. > I tried looking at some of the mailing list archives. > I wanted to know if it is possible to install Linux on SGI 02 R5000's > I noticed there was support for R5000s, but not for R5000 that had CPU-controlled secondary > cache. I couldnt figure out how to find out if the 02 I have is one or the other. O2 uses the builtin cache controller which people are currently adding support for. Ralf From owner-linux-mips@oss.sgi.com Fri Aug 16 10:49:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7GHnnRw029465 for ; Fri, 16 Aug 2002 10:49:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7GHnnGi029464 for linux-mips-outgoing; Fri, 16 Aug 2002 10:49:49 -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-234-207-60.client.attbi.com [12.234.207.60]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7GHnhRw029455 for ; Fri, 16 Aug 2002 10:49:44 -0700 Received: (qmail 4511 invoked by uid 502); 16 Aug 2002 17:52:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Aug 2002 17:52:24 -0000 Date: Fri, 16 Aug 2002 10:52:18 -0700 (PDT) From: ilya@theIlya.com X-X-Sender: ilya@ns2.total-knowledge.com To: Curtis Robinson cc: linux-mips@oss.sgi.com Subject: Re: SGI O2 R5000 In-Reply-To: <20020816175837.B2597@linux-mips.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1135 Lines: 33 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And yes, it is possible to run Linux on O2. Look at http://www.linux-mips.org/~glaurung for pre-built kernels. There was also Linux-O2 HOWTO posted to the list recently, which you should read. I don't think it made to any of Linux/MIPS websites yet :( On Fri, 16 Aug 2002, Ralf Baechle wrote: > On Fri, Aug 16, 2002 at 11:21:12AM -0500, Curtis Robinson wrote: > > > I know this question is probably asked alot. > > I tried looking at some of the mailing list archives. > > I wanted to know if it is possible to install Linux on SGI 02 R5000's > > I noticed there was support for R5000s, but not for R5000 that had CPU-controlled secondary > > cache. I couldnt figure out how to find out if the 02 I have is one or the other. > > O2 uses the builtin cache controller which people are currently adding > support for. > > Ralf > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE9XTvY84S94bALfyURAnbzAJ9kXymejTkims1SQOS+gJwiWIL3hgCgzcc7 y/M6NJMxqU1Lo7ElbhUU9o8= =RDaZ -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Fri Aug 16 11:30:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7GIUlRw030308 for ; Fri, 16 Aug 2002 11:30:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7GIUlf0030307 for linux-mips-outgoing; Fri, 16 Aug 2002 11:30:47 -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-27-208.hu.sd.cox.net [68.6.27.208]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7GIUiRw030298 for ; Fri, 16 Aug 2002 11:30:44 -0700 Received: (from justin@localhost) by localhost.localdomain (8.11.6/8.11.6) id g7GIY0K01581; Fri, 16 Aug 2002 11:34:00 -0700 X-Authentication-Warning: localhost.localdomain: justin set sender to justinca@cs.cmu.edu using -f Subject: Re: irq handle of sb1250 From: Justin Carlson To: bxy@mail.ihep.ac.cn Cc: "linux-mips@oss.sgi.com" In-Reply-To: <200208160756.g7G7uvR08742@mail.ihep.ac.cn> References: <200208160756.g7G7uvR08742@mail.ihep.ac.cn> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Aug 2002 11:33:59 -0700 Message-Id: <1029522839.1502.1.camel@xyzzy.rlson.org> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 462 Lines: 12 On Fri, 2002-08-16 at 01:01, bxy@mail.ihep.ac.cn wrote: > hi, who is using sb1250/swarm board? i have mapped all the interrupts of > second cpu to IP7(default IP2). after changing irq.c and irq_handler.S, > second cpu can't get any interrupt. I don't know why it is. Which cpu gets the interrupt depends on how you've programmed the SCD. It's kind of hard to tell you anything useful, when you've posted no code so we can't see what you're doing. -Justin From owner-linux-mips@oss.sgi.com Sat Aug 17 09:22:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7HGMmRw026558 for ; Sat, 17 Aug 2002 09:22:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7HGMmuS026557 for linux-mips-outgoing; Sat, 17 Aug 2002 09:22: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-43.ka.dial.de.ignite.net [62.180.196.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7HGMfRw026548 for ; Sat, 17 Aug 2002 09:22:43 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7HGPCU24881; Sat, 17 Aug 2002 18:25:12 +0200 Date: Sat, 17 Aug 2002 18:25:12 +0200 From: Ralf Baechle To: =?iso-8859-1?Q?=B1=CF=D1=A7=D2=A2?= Cc: "linux-mips@oss.sgi.com" Subject: Re: irq handle of sb1250 Message-ID: <20020817182512.A24834@linux-mips.org> References: <200208160756.g7G7uvR08742@mail.ihep.ac.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200208160756.g7G7uvR08742@mail.ihep.ac.cn>; from bxy@mail.ihep.ac.cn on Fri, Aug 16, 2002 at 04:01:48PM +0800 X-MIME-Autoconverted: from 8bit to quoted-printable by dea.linux-mips.net id g7HGPCU24881 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g7HGMiRw026549 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 347 Lines: 10 On Fri, Aug 16, 2002 at 04:01:48PM +0800, ±ÏѧҢ wrote: > hi, who is using sb1250/swarm board? i have mapped all the interrupts of > second cpu to IP7(default IP2). after changing irq.c and irq_handler.S, > second cpu can't get any interrupt. I don't know why it is. Did you enable IP7 on the second CPU? I think it's off by default. Ralf From owner-linux-mips@oss.sgi.com Sat Aug 17 11:44:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7HIimRw027670 for ; Sat, 17 Aug 2002 11:44:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7HIimPd027669 for linux-mips-outgoing; Sat, 17 Aug 2002 11:44:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from columba.www.eur.3com.com (ip-161-71-171-238.corp-eur.3com.com [161.71.171.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7HIibRw027658 for ; Sat, 17 Aug 2002 11:44:43 -0700 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g7HIn3RG014757 for ; Sat, 17 Aug 2002 19:49:04 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g7HIm4R21212 for ; Sat, 17 Aug 2002 19:48:04 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256C18.0067B09A ; Sat, 17 Aug 2002 19:52:34 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: linux-mips@oss.sgi.com Message-ID: <80256C18.0067AFA2.00@notesmta.eur.3com.com> Date: Sat, 17 Aug 2002 19:47:02 +0100 Subject: Improving /dev/random by using CP0_COUNT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 818 Lines: 20 The kernel code to support /dev/random on Mips on currently uses 'jiffies' as an input to random number process. The code has a special case to use the high precision TSC on x86 when it is availble. (see linux/drivers/char/random.c : add_timer_randomness() ) It looks like it would only take a few lines of code to use the CP0_COUNT register on Mips to perform a similar function. We have a headless embedded system which has none of tradional sources of random entropy such as keyboard, mouse or disk activity. Currently our only option is to use the network interrupt, but I know this is considered a poor source since an attacker could generating a known sequence of packets. If we could increase the resolution of the timing then it would make it harder to exploit. Has anyone tried this? Jon Burgess From owner-linux-mips@oss.sgi.com Sat Aug 17 17:27:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7I0R8Rw030439 for ; Sat, 17 Aug 2002 17:27:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7I0R8Tn030438 for linux-mips-outgoing; Sat, 17 Aug 2002 17:27:08 -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.5/8.12.5) with SMTP id g7I0PnRw030419 for ; Sat, 17 Aug 2002 17:25:50 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id AEEC7133F0; Sun, 18 Aug 2002 02:28:34 +0200 (CEST) Date: Sun, 18 Aug 2002 02:28:34 +0200 From: Jan-Benedict Glaw To: SGI MIPS list Subject: [PATCH] Bring back R4600 V1.7 support Message-ID: <20020818002834.GQ10730@lug-owl.de> Mail-Followup-To: SGI MIPS list Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xSu31lw3TgkWXnjh" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14505 Lines: 605 --xSu31lw3TgkWXnjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Here's my current patch to bring back R4600 V1.7 support. MfG, JBG Index: include/asm-mips/war.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/src/packages/foreign_CVS_reps/oss.sgi.com/linux/include/asm-= mips/war.h,v retrieving revision 1.1.2.3 diff -u -r1.1.2.3 war.h --- include/asm-mips/war.h 5 Aug 2002 23:53:38 -0000 1.1.2.3 +++ include/asm-mips/war.h 17 Aug 2002 23:53:01 -0000 @@ -65,6 +65,24 @@ */ #define R5432_CP0_INTERRUPT_WAR =20 -#endif +#endif /* CONFIG_CPU_R5432 */ + +#ifdef R4600_V1_HIT_DCACHE_WAR +#define r4600_v1_7_cache_war_disable_irq(CACHE_FLAGS) \ + do { \ + __save_and_cli(CACHE_FLAGS); \ + } while (0) +#define r4600_v1_7_cache_war_enable_irq(CACHE_FLAGS) \ + do { \ + __restore_flags(CACHE_FLAGS); \ + } while (0) +#else +#define r4600_v1_7_cache_war_disable_irq(CACHE_FLAGS) \ + do {} while (0) +#define r4600_v1_7_cache_war_enable_irq(CACHE_FLAGS) \ + do {} while (0) +#endif /* R4600_V1_HIT_DCACHE_WAR */ + =09 +=09 =20 #endif /* _ASM_WAR_H */ Index: arch/mips/mm/c-r4k.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/src/packages/foreign_CVS_reps/oss.sgi.com/linux/arch/mips/mm= /c-r4k.c,v retrieving revision 1.3.2.6 diff -u -r1.3.2.6 c-r4k.c --- arch/mips/mm/c-r4k.c 9 Aug 2002 06:04:48 -0000 1.3.2.6 +++ arch/mips/mm/c-r4k.c 17 Aug 2002 23:55:53 -0000 @@ -77,47 +77,83 @@ =20 static inline void r4k_flush_cache_all_s16d16i16(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); blast_scache16(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s32d16i16(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); blast_scache32(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s64d16i16(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); blast_scache64(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s128d16i16(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); blast_scache128(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s32d32i32(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache32(); blast_icache32(); blast_scache32(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s64d32i32(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache32(); blast_icache32(); blast_scache64(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_s128d32i32(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache32(); blast_icache32(); blast_scache128(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_d16i16(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static inline void r4k_flush_cache_all_d32i32(void) { + unsigned long flags; + + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache32(); blast_icache32(); + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void @@ -126,6 +162,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -143,6 +180,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while (start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -152,6 +190,7 @@ blast_scache16_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -162,6 +201,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -179,6 +219,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -188,6 +229,7 @@ blast_scache32_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -197,6 +239,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -214,6 +257,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -223,6 +267,7 @@ blast_scache64_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -232,6 +277,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -249,6 +295,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -258,6 +305,7 @@ blast_scache128_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -267,6 +315,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -284,6 +333,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -293,6 +343,7 @@ blast_scache32_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -302,6 +353,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -319,6 +371,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -328,6 +381,7 @@ blast_scache64_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -337,6 +391,7 @@ unsigned long end) { struct vm_area_struct *vma; + unsigned long flags; =20 if (mm->context =3D=3D 0) return; @@ -354,6 +409,7 @@ pmd_t *pmd; pte_t *pte; =20 + r4600_v1_7_cache_war_disable_irq(flags); while(start < end) { pgd =3D pgd_offset(mm, start); pmd =3D pmd_offset(pgd, start); @@ -363,6 +419,7 @@ blast_scache128_page(start); start +=3D PAGE_SIZE; } + r4600_v1_7_cache_war_enable_irq(flags); } } } @@ -371,11 +428,15 @@ unsigned long start, unsigned long end) { + unsigned long flags; + if (mm->context !=3D 0) { #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache16(); blast_icache16(); + r4600_v1_7_cache_war_enable_irq(flags); } } =20 @@ -383,11 +444,15 @@ unsigned long start, unsigned long end) { + unsigned long flags; + if (mm->context !=3D 0) { #ifdef DEBUG_CACHE printk("crange[%d,%08lx,%08lx]", (int)mm->context, start, end); #endif + r4600_v1_7_cache_war_disable_irq(flags); blast_dcache32(); blast_icache32(); + r4600_v1_7_cache_war_enable_irq(flags); } } =20 @@ -490,6 +555,7 @@ unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -504,6 +570,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -533,12 +600,14 @@ } else blast_scache16_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s32d16i16(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -553,6 +622,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -581,12 +651,14 @@ } else blast_scache32_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s64d16i16(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -601,6 +673,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -629,12 +702,14 @@ } else blast_scache64_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s128d16i16(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -649,6 +724,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -678,12 +754,14 @@ } else blast_scache128_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s32d32i32(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -698,6 +776,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -727,12 +806,14 @@ } else blast_scache32_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s64d32i32(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -747,6 +828,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -776,12 +858,14 @@ } else blast_scache64_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_s128d32i32(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -796,6 +880,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -824,12 +909,14 @@ } else blast_scache128_page(page); out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_d16i16(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -844,6 +931,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -872,12 +960,14 @@ blast_dcache16_page_indexed(page); } out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_d32i32(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -892,6 +982,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -921,12 +1012,14 @@ blast_dcache32_page_indexed(page); } out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 static void r4k_flush_cache_page_d32i32_r4600(struct vm_area_struct *vma, unsigned long page) { struct mm_struct *mm =3D vma->vm_mm; + unsigned long flags; pgd_t *pgdp; pmd_t *pmdp; pte_t *ptep; @@ -941,6 +1034,7 @@ #ifdef DEBUG_CACHE printk("cpage[%d,%08lx]", (int)mm->context, page); #endif + r4600_v1_7_cache_war_disable_irq(flags); page &=3D PAGE_MASK; pgdp =3D pgd_offset(mm, page); pmdp =3D pmd_offset(pgdp, page); @@ -970,6 +1064,7 @@ blast_dcache32_page_indexed(page ^ dcache_waybit); } out: + r4600_v1_7_cache_war_enable_irq(flags); } =20 /* If the addresses passed to these routines are valid, they are @@ -1063,7 +1158,7 @@ flush_cache_all(); } else { #ifdef R4600_V2_HIT_CACHEOP_WAR - /* Workaround for R4600 bug. See comment in . */ + /* Workaround for R4600 bug. See comment in . */ __save_and_cli(flags); *(volatile unsigned long *)KSEG1; #endif --=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/ --xSu31lw3TgkWXnjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9XuoyHb1edYOZ4bsRApQmAJwNSQ7xxs3JSa5+x5RMW/BtPqFd5wCfVjXw KJVf2g4ttoE/w9YXfse9Pns= =tVj5 -----END PGP SIGNATURE----- --xSu31lw3TgkWXnjh-- From owner-linux-mips@oss.sgi.com Mon Aug 19 04:49:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JBnYRw005450 for ; Mon, 19 Aug 2002 04:49:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JBnYCY005449 for linux-mips-outgoing; Mon, 19 Aug 2002 04:49:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from brian.localnet (port48.ds1-vbr.adsl.cybercity.dk [212.242.58.113]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7JBmjRw005425 for ; Mon, 19 Aug 2002 04:48:46 -0700 Received: from brm by brian.localnet with local (Exim 3.32 #1 (Debian)) id 17gl4G-0002Za-00; Mon, 19 Aug 2002 13:51:32 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH 2.4] r5k Secondary Cache support Cc: vivien.chappelier@enst-bretagne.fr Message-Id: From: Brian Murphy Date: Mon, 19 Aug 2002 13:51:32 +0200 X-Spam-Status: No, hits=-4.9 required=5.0 tests=PORN_10,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9777 Lines: 359 I have changed the patch slightly so that the nevada cpu is also supported. Should this be patched onto mips64 too? /Brian Index: arch/mips/mm/Makefile =================================================================== RCS file: /cvs/linux/arch/mips/mm/Makefile,v retrieving revision 1.27.2.1 diff -u -r1.27.2.1 Makefile --- arch/mips/mm/Makefile 2002/06/25 15:47:00 1.27.2.1 +++ arch/mips/mm/Makefile 2002/08/19 11:33:28 @@ -20,8 +20,10 @@ obj-$(CONFIG_CPU_R4300) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o 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_NEVADA) += 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 \ + r5k-sc.o +obj-$(CONFIG_CPU_NEVADA) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o \ + r5k-sc.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 obj-$(CONFIG_CPU_R10000) += pg-andes.o c-andes.o tlb-r4k.o tlbex-r4k.o Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.3.2.6 diff -u -r1.3.2.6 c-r4k.c --- arch/mips/mm/c-r4k.c 2002/08/09 06:04:48 1.3.2.6 +++ arch/mips/mm/c-r4k.c 2002/08/19 11:33:30 @@ -1451,7 +1451,9 @@ _dma_cache_inv = r4k_dma_cache_inv_sc; } + typedef int (*probe_func_t)(unsigned long); +extern void r5k_sc_init(void); static inline void __init setup_scache(unsigned int config) { @@ -1462,12 +1464,24 @@ probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache)); sc_present = probe_scache_kseg1(config); - if (sc_present) { - setup_scache_funcs(); + if (!sc_present) { + setup_noscache_funcs(); return; } + + switch(mips_cpu.cputype) { + case CPU_R5000: + case CPU_NEVADA: + setup_noscache_funcs(); +#if defined(CONFIG_CPU_R5000) || defined(CONFIG_CPU_NEVADA) + r5k_sc_init(); +#endif + break; + default: + setup_scache_funcs(); + } + - setup_noscache_funcs(); } void __init ld_mmu_r4xx0(void) Index: arch/mips/config-shared.in =================================================================== RCS file: /cvs/linux/arch/mips/config-shared.in,v retrieving revision 1.1.2.10 diff -u -r1.1.2.10 config-shared.in --- arch/mips/config-shared.in 2002/08/15 18:42:02 1.1.2.10 +++ arch/mips/config-shared.in 2002/08/19 11:33:30 @@ -428,6 +428,14 @@ RM7000 CONFIG_CPU_RM7000 \ SB1 CONFIG_CPU_SB1" R4x00 +if [ "$CONFIG_CPU_R5000" = "y" ]; then + define_bool CONFIG_BOARD_SCACHE y +fi + +if [ "$CONFIG_CPU_NEVADA" = "y" ]; then + define_bool CONFIG_BOARD_SCACHE y +fi + if [ "$CONFIG_CPU_MIPS32" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y bool ' Support for Virtual Tagged I-cache' CONFIG_VTAG_ICACHE @@ -517,35 +525,35 @@ fi if [ "$CONFIG_CPU_R10000" = "y" ]; then - dep_bool 'Support for large 64-bit configurations' CONFIG_MIPS_INSANE_LARGE $CONFIG_MIPS64 +dep_bool 'Support for large 64-bit configurations' CONFIG_MIPS_INSANE_LARGE $CONFIG_MIPS64 fi if [ "$CONFIG_ARC32" = "y" ]; then - bool 'ARC console support' CONFIG_ARC_CONSOLE +bool 'ARC console support' CONFIG_ARC_CONSOLE fi if [ "$CONFIG_SGI_IP22" = "y" ]; then - dep_bool 'Indigo-2 (IP22) EISA bus support' CONFIG_IP22_EISA $CONFIG_EXPERIMENTAL +dep_bool 'Indigo-2 (IP22) EISA bus support' CONFIG_IP22_EISA $CONFIG_EXPERIMENTAL fi if [ "$CONFIG_IP22_EISA" = "y" ]; then - define_bool CONFIG_EISA y - bool ' ISA bus support' CONFIG_ISA +define_bool CONFIG_EISA y +bool ' ISA bus support' CONFIG_ISA fi bool 'Networking support' CONFIG_NET if [ "$CONFIG_PCI" != "y" ]; then - define_bool CONFIG_PCI n +define_bool CONFIG_PCI n fi source drivers/pci/Config.in if [ "$CONFIG_ISA" != "y" ]; then - define_bool CONFIG_ISA n - define_bool CONFIG_EISA n +define_bool CONFIG_ISA n +define_bool CONFIG_EISA n else - define_bool CONFIG_EISA y +define_bool CONFIG_EISA y fi dep_bool 'TURBOchannel support' CONFIG_TC $CONFIG_DECSTATION @@ -557,11 +565,11 @@ bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG if [ "$CONFIG_HOTPLUG" = "y" ] ; then - source drivers/pcmcia/Config.in - source drivers/hotplug/Config.in +source drivers/pcmcia/Config.in +source drivers/hotplug/Config.in else - define_bool CONFIG_PCMCIA n - define_bool CONFIG_HOTPLUG_PCI n +define_bool CONFIG_PCMCIA n +define_bool CONFIG_HOTPLUG_PCI n fi bool 'System V IPC' CONFIG_SYSVIPC @@ -587,16 +595,16 @@ source drivers/block/Config.in if [ "$CONFIG_BLK_DEV_INITRD" = "y" ]; then - mainmenu_option next_comment - comment 'MIPS initrd options' - bool ' Embed root filesystem ramdisk into the kernel' CONFIG_EMBEDDED_RAMDISK - endmenu +mainmenu_option next_comment +comment 'MIPS initrd options' +bool ' Embed root filesystem ramdisk into the kernel' CONFIG_EMBEDDED_RAMDISK +endmenu fi source drivers/md/Config.in if [ "$CONFIG_NET" = "y" ]; then - source net/Config.in +source net/Config.in fi source drivers/telephony/Config.in @@ -607,10 +615,10 @@ tristate 'ATA/IDE/MFM/RLL support' CONFIG_IDE if [ "$CONFIG_IDE" != "n" ]; then - source drivers/ide/Config.in +source drivers/ide/Config.in else - define_bool CONFIG_BLK_DEV_IDE_MODES n - define_bool CONFIG_BLK_DEV_HD n +define_bool CONFIG_BLK_DEV_IDE_MODES n +define_bool CONFIG_BLK_DEV_HD n fi endmenu @@ -620,7 +628,7 @@ tristate 'SCSI support' CONFIG_SCSI if [ "$CONFIG_SCSI" != "n" ]; then - source drivers/scsi/Config.in +source drivers/scsi/Config.in fi endmenu 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/08/19 11:33:30 @@ -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/mipsregs.h =================================================================== RCS file: /cvs/linux/include/asm-mips/mipsregs.h,v retrieving revision 1.30.2.14 diff -u -r1.30.2.14 mipsregs.h --- include/asm-mips/mipsregs.h 2002/08/05 23:53:37 1.30.2.14 +++ include/asm-mips/mipsregs.h 2002/08/19 11:33:31 @@ -377,6 +377,7 @@ #define CONF_CU (1 << 3) #define CONF_DB (1 << 4) #define CONF_IB (1 << 5) +#define CONF_SE (1 << 12) #define CONF_SC (1 << 17) #define CONF_AC (1 << 23) #define CONF_HALT (1 << 25) --- /dev/null Wed Aug 22 17:18:34 2001 +++ arch/mips/mm/r5k-sc.c Mon Aug 19 13:30:04 2002 @@ -0,0 +1,127 @@ +/* + * Copyright (C) 1997, 2001 Ralf Baechle (ralf@gnu.org), + * derived from r4xx0.c by David S. Miller (dm@engr.sgi.com). + */ +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* Secondary cache size in bytes, if present. */ +static unsigned long scache_size; + +#define SC_LINE 32 +#define SC_PAGE (128*SC_LINE) + +#define cache_op(base,op) \ +__asm__ __volatile__(" \ + .set noreorder; \ + .set mips3; \ + cache %1, (%0); \ + .set mips0; \ + .set reorder" \ + : \ + : "r" (base), \ + "i" (op)); + +static inline void blast_r5000_scache(void) +{ + unsigned long start = KSEG0; + unsigned long end = KSEG0 + scache_size; + + while(start < end) { + cache_op(start,Page_Invalidate); + start += SC_PAGE; + } +} + +static inline void blast_r5000_scache_page_indexed(unsigned long page) +{ + unsigned long start = page; + unsigned long end = page + PAGE_SIZE; + + while(start < end) { + cache_op(start,Page_Invalidate); + start += SC_PAGE; + } +} + +static void +r5k_dma_cache_inv_sc(unsigned long addr, unsigned long size) +{ + unsigned long end, a; + + if (size >= scache_size) { + blast_r5000_scache(); + return; + } + + /* We assume the address is in KSEG0. On the R5000 we + * cannot invalidate less than a page at a time, and + * there is no Hit_xxx cache operations. + */ + a = addr & ~(SC_PAGE - 1); + end = (addr + size - 1) & ~(SC_PAGE - 1); + while (a <= end) { + blast_r5000_scache_page_indexed(a); /* Page_Invalidate */ + a += SC_PAGE; + } +} + +static void r5k_sc_enable(void) +{ + unsigned long flags; + + __save_and_cli(flags); + change_cp0_config(CONF_SE, CONF_SE); + blast_r5000_scache(); + __restore_flags(flags); +} + +static void r5k_sc_disable(void) +{ + unsigned long flags; + + __save_and_cli(flags); + blast_r5000_scache(); + change_cp0_config(CONF_SE, 0); + __restore_flags(flags); +} + +static inline int __init r5k_sc_probe(void) +{ + unsigned long config = read_32bit_cp0_register(CP0_CONFIG); + + if(config & CONF_SC) + return(0); + + scache_size = (512*1024) << ((config >> 20)&3); + + printk("R5000 SCACHE size %ldK, linesize 32 bytes.\n", + scache_size >> 10); + + return 1; +} + +struct bcache_ops r5k_sc_ops = { + r5k_sc_enable, + r5k_sc_disable, + r5k_dma_cache_inv_sc, + r5k_dma_cache_inv_sc +}; + +void __init r5k_sc_init(void) +{ + if (r5k_sc_probe()) { + r5k_sc_enable(); + bcops = &r5k_sc_ops; + } +} From owner-linux-mips@oss.sgi.com Mon Aug 19 05:29:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JCTARw005959 for ; Mon, 19 Aug 2002 05:29:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JCTANG005958 for linux-mips-outgoing; Mon, 19 Aug 2002 05:29:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7JCT4Rw005949 for ; Mon, 19 Aug 2002 05:29:05 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA15542; Mon, 19 Aug 2002 14:32:19 +0200 (MET DST) Date: Mon, 19 Aug 2002 14:32:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20020815214641.A8335@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 512 Lines: 13 On Thu, 15 Aug 2002, Ralf Baechle wrote: > PS: Please obey the reply-to header of linux-cvs postings. This is not > a discussion list and I plan to configure the list to send anything > that isn't a CVS notification to /dev/null in the future. Well, a bounce would likely be a friendlier choice... -- + 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 Aug 19 05:32:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JCW3Rw006059 for ; Mon, 19 Aug 2002 05:32:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JCW3Nk006058 for linux-mips-outgoing; Mon, 19 Aug 2002 05:32:03 -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.5/8.12.5) with SMTP id g7JCVuRw006049 for ; Mon, 19 Aug 2002 05:31:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA15593 for ; Mon, 19 Aug 2002 14:35:20 +0200 (MET DST) Date: Mon, 19 Aug 2002 14:35:19 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <200208130138.g7D1cYk3010974@oss.sgi.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1231 Lines: 28 On Mon, 12 Aug 2002, Ralf Baechle wrote: > Modified files: > arch/mips : config-shared.in defconfig defconfig-decstation > defconfig-ip22 defconfig-nino defconfig-osprey > defconfig-sb1250-swarm defconfig-sead > arch/mips64 : defconfig-ip22 defconfig-sb1250-swarm > defconfig-sead > > Log message: > Make CONFIG_IDE selectable independant of the bus type. Hmm, what's the intent of the change? IDE, or more properly ATA, was originally an ISA-only device and is still only available as ISA-style implementations, AFAIK. I'd prefer it to be available only if any of CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set. That said, the place for such decisions seems to be inappropriate currently. It'd be much more elegant just to source all relevant drivers, net, etc. Config.in scripts unconditionally and make global enable/disable decisions at the top of the relevant script, like e.g. drivers/message/i2o/Config.in already does. -- + 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 Aug 19 05:54:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JCs4Rw006355 for ; Mon, 19 Aug 2002 05:54:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JCs4Zx006354 for linux-mips-outgoing; Mon, 19 Aug 2002 05:54:04 -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.5/8.12.5) with SMTP id g7JCrsRw006339; Mon, 19 Aug 2002 05:53:55 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA15909; Mon, 19 Aug 2002 14:57:15 +0200 (MET DST) Date: Mon, 19 Aug 2002 14:57:14 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: a really really weird crash on swarm In-Reply-To: <20020811185138.A2133@dea.linux-mips.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1284 Lines: 28 On Sun, 11 Aug 2002, Ralf Baechle wrote: > > Call me crazy - I have seen crash like this. As you can see, the register is > > loaded with one value and on next instruction it shows another value. What > > the hell is it possibly going on? > > > > This is with today's OSS tree 2.4 branch. > > Really odd because the register only lost the upper 16 bits; the lower 16 > bits still have their expected value. It is a typical symptom of a register being corrupted between a "lui" and an "addiu" -- an exception must have done it in the immediately preceding code. You might be able to track a reason down by carefully studying possible exception paths at the place of the problem. Unfortunately you don't have much of the state preserved at this stage -- you only know which register was corrupted. Another possible approach is to add some code that compares the values of the register upon an exception entry and exit and wait for it to trigger -- for a single register it shouldn't be too tough and you have still much of the state available before an "rfe" or "eret". -- + 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 Aug 19 05:54:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JCsbRw006437 for ; Mon, 19 Aug 2002 05:54:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JCsbZh006436 for linux-mips-outgoing; Mon, 19 Aug 2002 05:54:37 -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.5/8.12.5) with SMTP id g7JCsXRw006398 for ; Mon, 19 Aug 2002 05:54:34 -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 g7JCv5u6019620; Mon, 19 Aug 2002 13:57:06 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g7JCv4RU019618; Mon, 19 Aug 2002 13:57:04 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: CVS Update@oss.sgi.com: linux From: Alan Cox To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Aug 2002 13:57:03 +0100 Message-Id: <1029761823.19375.16.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 507 Lines: 10 On Mon, 2002-08-19 at 13:35, Maciej W. Rozycki wrote: > Hmm, what's the intent of the change? IDE, or more properly ATA, was > originally an ISA-only device and is still only available as ISA-style > implementations, AFAIK. I'd prefer it to be available only if any of > CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set. We support ATA devices attached to arbitary busses. The newest ATA code supports arbitary mmio/pio addressing mechanisms. You don't need ISA or an ISA like bus. From owner-linux-mips@oss.sgi.com Mon Aug 19 06:19:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JDJMRw006928 for ; Mon, 19 Aug 2002 06:19:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JDJM61006927 for linux-mips-outgoing; Mon, 19 Aug 2002 06:19:22 -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.5/8.12.5) with SMTP id g7JDJFRw006918 for ; Mon, 19 Aug 2002 06:19:16 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA16512; Mon, 19 Aug 2002 15:22:22 +0200 (MET DST) Date: Mon, 19 Aug 2002 15:22:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Alan Cox cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <1029761823.19375.16.camel@irongate.swansea.linux.org.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 738 Lines: 17 On 19 Aug 2002, Alan Cox wrote: > We support ATA devices attached to arbitary busses. The newest ATA code > supports arbitary mmio/pio addressing mechanisms. You don't need ISA or > an ISA like bus. Hmm, does such hardware already exist? I don't think it's reasonable to make some code available to a user in a configuration that will never make use of it. E.g. a plain TURBOchannel box (or one with no I/O bus) won't ever see a native ATA device (SCSI to ATA bridges obviously don't count). I'll check if the code builds at all. -- + 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 Aug 19 06:48:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JDmHRw009147 for ; Mon, 19 Aug 2002 06:48:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JDmH7T009146 for linux-mips-outgoing; Mon, 19 Aug 2002 06:48: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 (ftp.mips.com [206.31.31.227]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7JDlTRw009134; Mon, 19 Aug 2002 06:47:29 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g7JDngXb027272; Mon, 19 Aug 2002 06:49:42 -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 GAA05276; Mon, 19 Aug 2002 06:49:41 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g7JDneb06492; Mon, 19 Aug 2002 15:49:40 +0200 (MEST) Message-ID: <3D60F773.3C64C13E@mips.com> Date: Mon, 19 Aug 2002 15:49:39 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: IPC syscall fixup (o32 conversion layer) References: <3D5131C7.17F9E00@mips.com> <20020813052324.A22438@linux-mips.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14355 Lines: 344 Ralf Baechle wrote: > Carsten, > > On Wed, Aug 07, 2002 at 04:42:15PM +0200, Carsten Langgaard wrote: > > > Here is a patch that fixes the ipc syscalls in the o32 > > wrapper/conversion routines. > > Needed when running a 64-bit kernel on an o32 userland. > > before I finally apply this one, can you do me a favour and check your > code is still working correctly even after I applied yesterdays fix > which changes struct msqid64_id to eleminate the mismatch of the kernel > and libc definitions? > It should be fine, I have this change in my local sources already. > > Thanks, > > Ralf > > > Index: arch/mips64/kernel/linux32.c > > =================================================================== > > RCS file: /cvs/linux/arch/mips64/kernel/linux32.c,v > > retrieving revision 1.42.2.9 > > diff -u -r1.42.2.9 linux32.c > > --- arch/mips64/kernel/linux32.c 2002/07/23 12:26:09 1.42.2.9 > > +++ arch/mips64/kernel/linux32.c 2002/08/07 14:28:03 > > @@ -35,8 +35,16 @@ > > #include > > #include > > > > - > > +/* Use this to get at 32-bit user passed pointers. */ > > +/* A() macro should be used for places where you e.g. > > + have some internal variable u32 and just want to get > > + rid of a compiler warning. AA() has to be used in > > + places where you want to convert a function argument > > + to 32bit pointer or when you e.g. access pt_regs > > + structure and want to consider 32bit registers only. > > + */ > > #define A(__x) ((unsigned long)(__x)) > > +#define AA(__x) ((unsigned long)((int)__x)) > > > > #ifdef __MIPSEB__ > > #define merge_64(r1,r2) ((((r1) & 0xffffffffUL) << 32) + ((r2) & 0xffffffffUL)) > > @@ -1494,6 +1502,19 @@ > > unsigned short seq; > > }; > > > > +struct ipc64_perm32 { > > + key_t key; > > + __kernel_uid_t32 uid; > > + __kernel_gid_t32 gid; > > + __kernel_uid_t32 cuid; > > + __kernel_gid_t32 cgid; > > + __kernel_mode_t32 mode; > > + unsigned short seq; > > + unsigned short __pad1; > > + unsigned int __unused1; > > + unsigned int __unused2; > > +}; > > + > > struct semid_ds32 { > > struct ipc_perm32 sem_perm; /* permissions .. see ipc.h */ > > __kernel_time_t32 sem_otime; /* last semop time */ > > @@ -1522,6 +1543,23 @@ > > __kernel_ipc_pid_t32 msg_lrpid; > > }; > > > > +struct msqid64_ds32 { > > + struct ipc64_perm32 msg_perm; > > + __kernel_time_t32 msg_stime; > > + unsigned int __unused1; > > + __kernel_time_t32 msg_rtime; > > + unsigned int __unused2; > > + __kernel_time_t32 msg_ctime; > > + unsigned int __unused3; > > + unsigned int msg_cbytes; > > + unsigned int msg_qnum; > > + unsigned int msg_qbytes; > > + __kernel_pid_t32 msg_lspid; > > + __kernel_pid_t32 msg_lrpid; > > + unsigned int __unused4; > > + unsigned int __unused5; > > +}; > > + > > struct shmid_ds32 { > > struct ipc_perm32 shm_perm; > > int shm_segsz; > > @@ -1533,9 +1571,25 @@ > > unsigned short shm_nattch; > > }; > > > > +struct ipc_kludge32 { > > + u32 msgp; > > + s32 msgtyp; > > +}; > > + > > #define IPCOP_MASK(__x) (1UL << (__x)) > > > > static int > > +ipc_parse_version32(int *cmd) > > +{ > > + if (*cmd & IPC_64) { > > + *cmd ^= IPC_64; > > + return IPC_64; > > + } else { > > + return IPC_OLD; > > + } > > +} > > + > > +static int > > do_sys32_semctl(int first, int second, int third, void *uptr) > > { > > union semun fourth; > > @@ -1603,12 +1657,15 @@ > > static int > > do_sys32_msgsnd (int first, int second, int third, void *uptr) > > { > > - struct msgbuf *p = kmalloc (second + sizeof (struct msgbuf) > > - + 4, GFP_USER); > > struct msgbuf32 *up = (struct msgbuf32 *)uptr; > > + struct msgbuf *p; > > mm_segment_t old_fs; > > int err; > > > > + if (second < 0) > > + return -EINVAL; > > + p = kmalloc (second + sizeof (struct msgbuf) > > + + 4, GFP_USER); > > if (!p) > > return -ENOMEM; > > err = get_user (p->mtype, &up->mtype); > > @@ -1636,18 +1693,21 @@ > > int err; > > > > if (!version) { > > - struct ipc_kludge *uipck = (struct ipc_kludge *)uptr; > > - struct ipc_kludge ipck; > > + struct ipc_kludge32 *uipck = (struct ipc_kludge32 *)uptr; > > + struct ipc_kludge32 ipck; > > > > err = -EINVAL; > > if (!uptr) > > goto out; > > err = -EFAULT; > > - if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge))) > > + if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge32))) > > goto out; > > - uptr = (void *)A(ipck.msgp); > > + uptr = (void *)AA(ipck.msgp); > > msgtyp = ipck.msgtyp; > > } > > + > > + if (second < 0) > > + return -EINVAL; > > err = -ENOMEM; > > p = kmalloc (second + sizeof (struct msgbuf) + 4, GFP_USER); > > if (!p) > > @@ -1673,9 +1733,10 @@ > > { > > int err = -EINVAL, err2; > > struct msqid_ds m; > > - struct msqid64_ds m64; > > - struct msqid_ds32 *up = (struct msqid_ds32 *)uptr; > > + struct msqid_ds32 *up32 = (struct msqid_ds32 *)uptr; > > + struct msqid64_ds32 *up64 = (struct msqid64_ds32 *)uptr; > > mm_segment_t old_fs; > > + int version = ipc_parse_version32(&second); > > > > switch (second) { > > > > @@ -1686,10 +1747,25 @@ > > break; > > > > case IPC_SET: > > - err = get_user (m.msg_perm.uid, &up->msg_perm.uid); > > - err |= __get_user (m.msg_perm.gid, &up->msg_perm.gid); > > - err |= __get_user (m.msg_perm.mode, &up->msg_perm.mode); > > - err |= __get_user (m.msg_qbytes, &up->msg_qbytes); > > + if (version == IPC_64) { > > + if (!access_ok(VERIFY_READ, up64, sizeof(*up64))) { > > + err = -EFAULT; > > + break; > > + } > > + err = __get_user(m.msg_perm.uid, &up64->msg_perm.uid); > > + err |= __get_user(m.msg_perm.gid, &up64->msg_perm.gid); > > + err |= __get_user(m.msg_perm.mode, &up64->msg_perm.mode); > > + err |= __get_user(m.msg_qbytes, &up64->msg_qbytes); > > + } else { > > + if (!access_ok(VERIFY_READ, up32, sizeof(*up32))) { > > + err = -EFAULT; > > + break; > > + } > > + err = __get_user(m.msg_perm.uid, &up32->msg_perm.uid); > > + err |= __get_user(m.msg_perm.gid, &up32->msg_perm.gid); > > + err |= __get_user(m.msg_perm.mode, &up32->msg_perm.mode); > > + err |= __get_user(m.msg_qbytes, &up32->msg_qbytes); > > + } > > if (err) > > break; > > old_fs = get_fs (); > > @@ -1702,27 +1778,54 @@ > > case MSG_STAT: > > old_fs = get_fs (); > > set_fs (KERNEL_DS); > > - err = sys_msgctl (first, second, (void *) &m64); > > + err = sys_msgctl (first, second, &m); > > set_fs (old_fs); > > - err2 = put_user (m64.msg_perm.key, &up->msg_perm.key); > > - err2 |= __put_user(m64.msg_perm.uid, &up->msg_perm.uid); > > - err2 |= __put_user(m64.msg_perm.gid, &up->msg_perm.gid); > > - err2 |= __put_user(m64.msg_perm.cuid, &up->msg_perm.cuid); > > - err2 |= __put_user(m64.msg_perm.cgid, &up->msg_perm.cgid); > > - err2 |= __put_user(m64.msg_perm.mode, &up->msg_perm.mode); > > - err2 |= __put_user(m64.msg_perm.seq, &up->msg_perm.seq); > > - err2 |= __put_user(m64.msg_stime, &up->msg_stime); > > - err2 |= __put_user(m64.msg_rtime, &up->msg_rtime); > > - err2 |= __put_user(m64.msg_ctime, &up->msg_ctime); > > - err2 |= __put_user(m64.msg_cbytes, &up->msg_cbytes); > > - err2 |= __put_user(m64.msg_qnum, &up->msg_qnum); > > - err2 |= __put_user(m64.msg_qbytes, &up->msg_qbytes); > > - err2 |= __put_user(m64.msg_lspid, &up->msg_lspid); > > - err2 |= __put_user(m64.msg_lrpid, &up->msg_lrpid); > > - if (err2) > > - err = -EFAULT; > > + if (version == IPC_64) { > > + if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) { > > + err = -EFAULT; > > + break; > > + } > > + err2 = __put_user(m.msg_perm.key, &up64->msg_perm.key); > > + err2 |= __put_user(m.msg_perm.uid, &up64->msg_perm.uid); > > + err2 |= __put_user(m.msg_perm.gid, &up64->msg_perm.gid); > > + err2 |= __put_user(m.msg_perm.cuid, &up64->msg_perm.cuid); > > + err2 |= __put_user(m.msg_perm.cgid, &up64->msg_perm.cgid); > > + err2 |= __put_user(m.msg_perm.mode, &up64->msg_perm.mode); > > + err2 |= __put_user(m.msg_perm.seq, &up64->msg_perm.seq); > > + err2 |= __put_user(m.msg_stime, &up64->msg_stime); > > + err2 |= __put_user(m.msg_rtime, &up64->msg_rtime); > > + err2 |= __put_user(m.msg_ctime, &up64->msg_ctime); > > + err2 |= __put_user(m.msg_cbytes, &up64->msg_cbytes); > > + err2 |= __put_user(m.msg_qnum, &up64->msg_qnum); > > + err2 |= __put_user(m.msg_qbytes, &up64->msg_qbytes); > > + err2 |= __put_user(m.msg_lspid, &up64->msg_lspid); > > + err2 |= __put_user(m.msg_lrpid, &up64->msg_lrpid); > > + if (err2) > > + err = -EFAULT; > > + } else { > > + if (!access_ok(VERIFY_WRITE, up32, sizeof(*up32))) { > > + err = -EFAULT; > > + break; > > + } > > + err2 = __put_user(m.msg_perm.key, &up32->msg_perm.key); > > + err2 |= __put_user(m.msg_perm.uid, &up32->msg_perm.uid); > > + err2 |= __put_user(m.msg_perm.gid, &up32->msg_perm.gid); > > + err2 |= __put_user(m.msg_perm.cuid, &up32->msg_perm.cuid); > > + err2 |= __put_user(m.msg_perm.cgid, &up32->msg_perm.cgid); > > + err2 |= __put_user(m.msg_perm.mode, &up32->msg_perm.mode); > > + err2 |= __put_user(m.msg_perm.seq, &up32->msg_perm.seq); > > + err2 |= __put_user(m.msg_stime, &up32->msg_stime); > > + err2 |= __put_user(m.msg_rtime, &up32->msg_rtime); > > + err2 |= __put_user(m.msg_ctime, &up32->msg_ctime); > > + err2 |= __put_user(m.msg_cbytes, &up32->msg_cbytes); > > + err2 |= __put_user(m.msg_qnum, &up32->msg_qnum); > > + err2 |= __put_user(m.msg_qbytes, &up32->msg_qbytes); > > + err2 |= __put_user(m.msg_lspid, &up32->msg_lspid); > > + err2 |= __put_user(m.msg_lrpid, &up32->msg_lrpid); > > + if (err2) > > + err = -EFAULT; > > + } > > break; > > - > > } > > > > return err; > > @@ -1845,7 +1948,7 @@ > > > > case SEMOP: > > /* struct sembuf is the same on 32 and 64bit :)) */ > > - err = sys_semop (first, (struct sembuf *)A(ptr), > > + err = sys_semop (first, (struct sembuf *)AA(ptr), > > second); > > break; > > case SEMGET: > > @@ -1853,36 +1956,36 @@ > > break; > > case SEMCTL: > > err = do_sys32_semctl (first, second, third, > > - (void *)A(ptr)); > > + (void *)AA(ptr)); > > break; > > > > case MSGSND: > > err = do_sys32_msgsnd (first, second, third, > > - (void *)A(ptr)); > > + (void *)AA(ptr)); > > break; > > case MSGRCV: > > err = do_sys32_msgrcv (first, second, fifth, third, > > - version, (void *)A(ptr)); > > + version, (void *)AA(ptr)); > > break; > > case MSGGET: > > err = sys_msgget ((key_t) first, second); > > break; > > case MSGCTL: > > - err = do_sys32_msgctl (first, second, (void *)A(ptr)); > > + err = do_sys32_msgctl (first, second, (void *)AA(ptr)); > > break; > > > > case SHMAT: > > err = do_sys32_shmat (first, second, third, > > - version, (void *)A(ptr)); > > + version, (void *)AA(ptr)); > > break; > > case SHMDT: > > - err = sys_shmdt ((char *)A(ptr)); > > + err = sys_shmdt ((char *)AA(ptr)); > > break; > > case SHMGET: > > err = sys_shmget (first, second, third); > > break; > > case SHMCTL: > > - err = do_sys32_shmctl (first, second, (void *)A(ptr)); > > + err = do_sys32_shmctl (first, second, (void *)AA(ptr)); > > break; > > default: > > err = -EINVAL; -- _ _ ____ ___ 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 Aug 19 06:53:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7JDrtRw010319 for ; Mon, 19 Aug 2002 06:53:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7JDrt73010318 for linux-mips-outgoing; Mon, 19 Aug 2002 06:53:55 -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.5/8.12.5) with SMTP id g7JDroRw010308 for ; Mon, 19 Aug 2002 06:53:51 -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 g7JDuPu6019757; Mon, 19 Aug 2002 14:56:26 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.2/8.12.2/Submit) id g7JDuOxe019755; Mon, 19 Aug 2002 14:56:24 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: CVS Update@oss.sgi.com: linux From: Alan Cox To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Aug 2002 14:56:23 +0100 Message-Id: <1029765383.19375.25.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Status: RO Content-Length: 601 Lines: 13 On Mon, 2002-08-19 at 14:22, Maciej W. Rozycki wrote: > Hmm, does such hardware already exist? I don't think it's reasonable to > make some code available to a user in a configuration that will never make > use of it. E.g. a plain TURBOchannel box (or one with no I/O bus) won't > ever see a native ATA device (SCSI to ATA bridges obviously don't count). > I'll check if the code builds at all. Sure. There are embedded devices with onboard IDE controller logic. I don't know about in mipsdom but certainly elsewhere. I'm not aware of turdochannel IDE but there is a homebrew QBUS IDE project From owner-linux-mips@oss.sgi.com Tue Aug 20 04:30:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KBUjEC024265 for ; Tue, 20 Aug 2002 04:30:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KBUjwI024264 for linux-mips-outgoing; Tue, 20 Aug 2002 04:30:45 -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.5/8.12.5) with SMTP id g7KBUXEC024231; Tue, 20 Aug 2002 04:30:34 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 706CC12FF6; Tue, 20 Aug 2002 13:33:29 +0200 (CEST) Date: Tue, 20 Aug 2002 13:33:29 +0200 From: Jan-Benedict Glaw To: Ralf Baechle Cc: SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support Message-ID: <20020820113329.GZ10730@lug-owl.de> Mail-Followup-To: Ralf Baechle , SGI MIPS list References: <20020818002834.GQ10730@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hch1Uz/zGPcHFdv8" Content-Disposition: inline In-Reply-To: <20020818002834.GQ10730@lug-owl.de> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1008 Lines: 40 --Hch1Uz/zGPcHFdv8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 2002-08-18 02:28:34 +0200, Jan-Benedict Glaw wrote in message <20020818002834.GQ10730@lug-owl.de>: > Hi! >=20 > Here's my current patch to bring back R4600 V1.7 support. [snip] Hi Ralf! Please accept the patch (from my previous mail). I'm using it now for two days, and I've got one mail telling me that it works for its sender. No mails about crashed systems so far... 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/ --Hch1Uz/zGPcHFdv8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9YikJHb1edYOZ4bsRAngDAJ9rNyJC+A0tlVJCVRXpqw/0/KgIAwCdFPnL 7ibJGU6DW6mct9A8HFsJJTo= =RmnF -----END PGP SIGNATURE----- --Hch1Uz/zGPcHFdv8-- From owner-linux-mips@oss.sgi.com Tue Aug 20 05:00:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KC0NEC024990 for ; Tue, 20 Aug 2002 05:00:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KC0NVc024989 for linux-mips-outgoing; Tue, 20 Aug 2002 05:00:23 -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.5/8.12.5) with SMTP id g7KC0HEC024980 for ; Tue, 20 Aug 2002 05:00:18 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA10473; Tue, 20 Aug 2002 14:03:42 +0200 (MET DST) Date: Tue, 20 Aug 2002 14:03:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@oss.sgi.com Subject: Re: Linux on RM600 In-Reply-To: <20020816092912.GF10730@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 999 Lines: 22 On Fri, 16 Aug 2002, Jan-Benedict Glaw wrote: > Flo has got EB, you've got EL. I once again think about an archive of > EPROM, EEPROM and flash contents... That would especially also help > those broken /240 with MOP-only firmware... Well, MOP actually works reasonably and is overall better supported by DEC hardware (consider non-working ARP). Then there is a legal problem -- the license doesn't permit redistribution. That said, I have snapshots of: KN03-AA V5.1b (TFTP broken), KN03-AA V5.2b (OK) and KN05 V2.1k (OK), as well as of PMAG-CA V5.3a. I have images of the host accessible areas of: PMAF-AA 5.2 (ROM rev. 1.0, firmware rev. 1.1) and PMAGB-BA V1.1, but they are flashable and the layout may be incorrect for the respective flashers, especially the former lacks m68k firmware. -- + 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 Aug 20 05:27:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KCRlEC025427 for ; Tue, 20 Aug 2002 05:27:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KCRlJn025426 for linux-mips-outgoing; Tue, 20 Aug 2002 05:27: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 (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KCReEC025414 for ; Tue, 20 Aug 2002 05:27:41 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7JDSHS21246; Mon, 19 Aug 2002 15:28:17 +0200 Date: Mon, 19 Aug 2002 15:28:17 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: a really really weird crash on swarm Message-ID: <20020819152817.A14266@linux-mips.org> References: <20020811185138.A2133@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, Aug 19, 2002 at 02:57:14PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1285 Lines: 27 On Mon, Aug 19, 2002 at 02:57:14PM +0200, Maciej W. Rozycki wrote: > > Really odd because the register only lost the upper 16 bits; the lower 16 > > bits still have their expected value. > > It is a typical symptom of a register being corrupted between a "lui" and > an "addiu" -- an exception must have done it in the immediately preceding > code. You might be able to track a reason down by carefully studying > possible exception paths at the place of the problem. Unfortunately you > don't have much of the state preserved at this stage -- you only know > which register was corrupted. Little exception potencial in this case as the interrupts got disabled and the addresses used were rsp. should all be in KSEG0. > Another possible approach is to add some code that compares the values of > the register upon an exception entry and exit and wait for it to trigger > -- for a single register it shouldn't be too tough and you have still much > of the state available before an "rfe" or "eret". Don't try to think too deterministic - Jun was working on first silicon, so not necessarily on a deterministic platform as we'd like. Fortunately as you may have seen in the kernel code there's already newer silicon so I'd simply file this one to /dev/null for now. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 05:27:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KCRbEC025409 for ; Tue, 20 Aug 2002 05:27:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KCRbiB025408 for linux-mips-outgoing; Tue, 20 Aug 2002 05:27:37 -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 (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KCRSEC025399 for ; Tue, 20 Aug 2002 05:27:30 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7JDgGG21374; Mon, 19 Aug 2002 15:42:16 +0200 Date: Mon, 19 Aug 2002 15:42:15 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20020819154215.B14266@linux-mips.org> References: <200208130138.g7D1cYk3010974@oss.sgi.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, Aug 19, 2002 at 02:35:19PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1531 Lines: 32 On Mon, Aug 19, 2002 at 02:35:19PM +0200, Maciej W. Rozycki wrote: > > Modified files: > > arch/mips : config-shared.in defconfig defconfig-decstation > > defconfig-ip22 defconfig-nino defconfig-osprey > > defconfig-sb1250-swarm defconfig-sead > > arch/mips64 : defconfig-ip22 defconfig-sb1250-swarm > > defconfig-sead > > > > Log message: > > Make CONFIG_IDE selectable independant of the bus type. > > Hmm, what's the intent of the change? IDE, or more properly ATA, was > originally an ISA-only device and is still only available as ISA-style > implementations, AFAIK. I'd prefer it to be available only if any of > CONFIG_ISA, CONFIG_EISA, CONFIG_PCI (unsure about CONFIG_MCA) is set. > > That said, the place for such decisions seems to be inappropriate > currently. It'd be much more elegant just to source all relevant drivers, > net, etc. Config.in scripts unconditionally and make global enable/disable > decisions at the top of the relevant script, like e.g. > drivers/message/i2o/Config.in already does. Even before the changes Alan mentioned we had a bunch of machines like the SWARM which had PCI but it's PIO IDE adapter wasn't living on the PCI bus. So disabling PCI on that machine would disable IDE also. Other machines had IDE on PCMCIA with the PCMCIA bridge not hanging off an (E)ISA or PCI bridge. Basically I could have changed that if statement into an increasingly obscure and braindamagedly complex if statement. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 06:27:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KDR4EC026792 for ; Tue, 20 Aug 2002 06:27:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KDR4wl026791 for linux-mips-outgoing; Tue, 20 Aug 2002 06:27:04 -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.5/8.12.5) with SMTP id g7KDQuEC026781; Tue, 20 Aug 2002 06:26:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11971; Tue, 20 Aug 2002 15:30:22 +0200 (MET DST) Date: Tue, 20 Aug 2002 15:30:22 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: Ralf Baechle , SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support In-Reply-To: <20020820113329.GZ10730@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 901 Lines: 18 On Tue, 20 Aug 2002, Jan-Benedict Glaw wrote: > Please accept the patch (from my previous mail). I'm using it now for > two days, and I've got one mail telling me that it works for its sender. Ugh, this should be a separate set of functions selected at the run time. It should be fairly trivial to rewrite it this way (best done with processor-specific functions expanded from common templates for ease of maintenance), but the size of the resulting interrupt masking window is unacceptable. A more finegrained implementation is really desireable, with an interrupt enable window every page or so, but your proposal should be fair enough for the sake of usability once rewritten as I suggested. -- + 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 Aug 20 06:52:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KDqHEC027204 for ; Tue, 20 Aug 2002 06:52:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KDqHn2027203 for linux-mips-outgoing; Tue, 20 Aug 2002 06:52: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.5/8.12.5) with SMTP id g7KDq8EC027192; Tue, 20 Aug 2002 06:52:09 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA12523; Tue, 20 Aug 2002 15:55:35 +0200 (MET DST) Date: Tue, 20 Aug 2002 15:55:34 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: Ralf Baechle , SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1628 Lines: 29 On Tue, 20 Aug 2002, Maciej W. Rozycki wrote: > > Please accept the patch (from my previous mail). I'm using it now for > > two days, and I've got one mail telling me that it works for its sender. > > Ugh, this should be a separate set of functions selected at the run time. > It should be fairly trivial to rewrite it this way (best done with > processor-specific functions expanded from common templates for ease of > maintenance), but the size of the resulting interrupt masking window is > unacceptable. A more finegrained implementation is really desireable, > with an interrupt enable window every page or so, but your proposal should > be fair enough for the sake of usability once rewritten as I suggested. An additional thought that just came to my mind: it might be possible to avoid masking interrupts with a dummy ll/sc pair only checking if an interrupt happened within the critical code. It should be easy to validate since only a single mask of a processor would make use of the code. The real question is: "Do the affected cache operations corrupt any state or do they only work on wrong lines?" If the latter, the approach should work for all operations except from "Hit_Invalidate_D" that corrupts state by definition (but it isn't used by any R4k processor, so it may simply be replaced with a panic()). Unfortunately, the knowledge does no longer exist within IDT, but maybe someone else knows? -- + 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 Aug 20 07:07:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KE7YEC027535 for ; Tue, 20 Aug 2002 07:07:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KE7YEL027534 for linux-mips-outgoing; Tue, 20 Aug 2002 07:07:34 -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.5/8.12.5) with SMTP id g7KE7TEC027516 for ; Tue, 20 Aug 2002 07:07:30 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA12807; Tue, 20 Aug 2002 16:10:48 +0200 (MET DST) Date: Tue, 20 Aug 2002 16:10:48 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@oss.sgi.com Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20020819154215.B14266@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 579 Lines: 14 On Mon, 19 Aug 2002, Ralf Baechle wrote: > So disabling PCI on that machine would disable IDE also. Other machines > had IDE on PCMCIA with the PCMCIA bridge not hanging off an (E)ISA or PCI > bridge. Basically I could have changed that if statement into an > increasingly obscure and braindamagedly complex if statement. Well, that would be of questional benefit, indeed. -- + 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 Aug 20 07:07:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KE7XEC027529 for ; Tue, 20 Aug 2002 07:07:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KE7XIA027528 for linux-mips-outgoing; Tue, 20 Aug 2002 07:07:33 -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.5/8.12.5) with SMTP id g7KE7JEC027503 for ; Tue, 20 Aug 2002 07:07:19 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id CF6E31339C; Tue, 20 Aug 2002 16:10:13 +0200 (CEST) Date: Tue, 20 Aug 2002 16:10:13 +0200 From: Jan-Benedict Glaw To: SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support Message-ID: <20020820141013.GC10730@lug-owl.de> Mail-Followup-To: SGI MIPS list References: <20020820113329.GZ10730@lug-owl.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="80KdhljSN0pKc7w4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3010 Lines: 93 --80KdhljSN0pKc7w4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 2002-08-20 15:30:22 +0200, Maciej W. Rozycki wrote in message : > On Tue, 20 Aug 2002, Jan-Benedict Glaw wrote: >=20 > > Please accept the patch (from my previous mail). I'm using it now for > > two days, and I've got one mail telling me that it works for its sender. >=20 > Ugh, this should be a separate set of functions selected at the run time= .=20 > It should be fairly trivial to rewrite it this way (best done with > processor-specific functions expanded from common templates for ease of Actually, I had written all that using separate functions before, but neither I nor Ralf liked this approach (because it adds hundreds LOC to =2E../c-r4k.c). Ralf then suggested writing it using macros, so I did. -*- Proposal -*- There are IMHO two goals, one for near future, one for following day (after first goal has reached): 1. There are many (equally looking) functions in c-r4k.c . It would be nice to not have the (more-or-less) function body 10 times there. 2. it would be nice to not have like 50 functions around, but to better have a flexible way to do what needs to be done. Something like an (initdata) array containing PRId and function pointers (or other info) on "what needs to be done". The first one seems quite easy. Looking eg. at Alphas, they have a macro defining a whole function (which inserts a correct function name by supplied arguments etc.). This way,=20 static inline void r4k_flush_cache_all_s128d16i16(void) static inline void r4k_flush_cache_all_s32d32i32(void) static inline void r4k_flush_cache_all_s64d32i32(void) =2E. could go away by: (there _will_ be bugs. 100% untested, and I'm a bad preprocessor coder:-) #define FUNC_R4K_FLUSH_CACHE_ALL(NAME, SC, DC, IC) \ static inline void \ r4k_flush_cache_all_##NAME(void) \ { \ blast_dcache##DC(); \ blast_icache##IC(); \ blase_scache##SC(); \ } and then writing: FUNC_R4K_FLUSH_CACHE_ALL(s128d16i16, 128, 16, 16) FUNC_R4K_FLUSH_CACHE_ALL(s32d32i32, 32, 32, 32) FUNC_R4K_FLUSH_CACHE_ALL(s64d32i32, 64, 32, 32) =2E.. instead. The __save_and_cli()/__restore_flags() functions could be done as well as all the remaining others. That would pollute namespace like it does today, but the .c file will be 80% smaller or so: $ wc -l c-r4k.c=20 2422 c-r4k.c 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/ --80KdhljSN0pKc7w4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Yk3FHb1edYOZ4bsRAjMHAJ9n5L+w82+67jTGSpBbLdf3PDN9lgCff6DL ajHt9ZDyUlQJTh6Vb0M2DjY= =A53v -----END PGP SIGNATURE----- --80KdhljSN0pKc7w4-- From owner-linux-mips@oss.sgi.com Tue Aug 20 07:11:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEBDEC027721 for ; Tue, 20 Aug 2002 07:11:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEBDka027720 for linux-mips-outgoing; Tue, 20 Aug 2002 07:11:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KEB1EC027710 for ; Tue, 20 Aug 2002 07:11:03 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7KE3BE26998; Tue, 20 Aug 2002 16:03:11 +0200 Date: Tue, 20 Aug 2002 16:03:11 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jan-Benedict Glaw , SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support Message-ID: <20020820160311.A26912@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Tue, Aug 20, 2002 at 03:55:34PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1123 Lines: 21 On Tue, Aug 20, 2002 at 03:55:34PM +0200, Maciej W. Rozycki wrote: > An additional thought that just came to my mind: it might be possible to > avoid masking interrupts with a dummy ll/sc pair only checking if an > interrupt happened within the critical code. It should be easy to > validate since only a single mask of a processor would make use of the > code. The real question is: "Do the affected cache operations corrupt any > state or do they only work on wrong lines?" If the latter, the approach > should work for all operations except from "Hit_Invalidate_D" that > corrupts state by definition (but it isn't used by any R4k processor, so > it may simply be replaced with a panic()). Unfortunately, the knowledge > does no longer exist within IDT, but maybe someone else knows? I was thinking about that already but the erratas don't provide enough details. The only problem I can see is that ll/sc are fairly slow on some architectures. They're supposed to be quite light according to the docs but in reality I benchmarked ~ 13 cycles for a spinlock on a R10000 and ~ 44 on a more recent chip. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 07:33:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEXkEC028065 for ; Tue, 20 Aug 2002 07:33:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEXklr028064 for linux-mips-outgoing; Tue, 20 Aug 2002 07:33:46 -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.5/8.12.5) with SMTP id g7KEXeEC028055 for ; Tue, 20 Aug 2002 07:33:42 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA13322; Tue, 20 Aug 2002 16:36:56 +0200 (MET DST) Date: Tue, 20 Aug 2002 16:36:55 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jan-Benedict Glaw , SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support In-Reply-To: <20020820160311.A26912@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 793 Lines: 20 On Tue, 20 Aug 2002, Ralf Baechle wrote: > I was thinking about that already but the erratas don't provide enough > details. The only problem I can see is that ll/sc are fairly slow on some Well, IDT didn't seem much mobilized with my single query. Maybe if there was more interest expressed, someone would go digging through old resources for real. > architectures. They're supposed to be quite light according to the docs > but in reality I benchmarked ~ 13 cycles for a spinlock on a R10000 and > ~ 44 on a more recent chip. Well, the code would only execute on an R4600 V1.7... -- + 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 Aug 20 07:41:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEf5EC028292 for ; Tue, 20 Aug 2002 07:41:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEf4Qg028291 for linux-mips-outgoing; Tue, 20 Aug 2002 07:41:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from dea.linux-mips.net (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KEesEC028282 for ; Tue, 20 Aug 2002 07:40:58 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7KETxC31273; Tue, 20 Aug 2002 16:29:59 +0200 Date: Tue, 20 Aug 2002 16:29:59 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com Cc: "Maciej W. Rozycki" Subject: New binutils for kernel Message-ID: <20020820162959.A26852@linux-mips.org> References: <20020819171238.A7457@linux-mips.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: ; from macro@ds2.pg.gda.pl on Tue, Aug 20, 2002 at 04:19:35PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1069 Lines: 28 On Tue, Aug 20, 2002 at 04:19:35PM +0200, Maciej W. Rozycki wrote: > On Mon, 19 Aug 2002, Ralf Baechle wrote: > > > > Are you sure? I believe the patch effectively forces everyone to use > > > binutils 2.13 for mips64. Is it really acceptable now? > > > > In the past week I ended up more and more kludging around binutils bugs. > > We need something newer and distributions seem to be all at ~ 2.12 at least. > > While 2.12 may be OK from the file format point of view, there are > serious bugs leading to bad code. So bad the kernel doesn't work. It's > really 2.13 that is needed. I have another less important fix that will > hopefully go in to 2.13.1 and all gcc versions are broken without yet > another fix (it bites in mm/mmap.c; not sure if fatally). > > > So I guess it's time to bite the bullet? > > Since I'm using 2.13 anyway, it's alike to me. But it should be > discussed at the list, IMO. Yep. It won't hurt most of us kernel hackers very much but in particular the distribution people may want to comment. So any comments? Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 07:43:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEhJEC028434 for ; Tue, 20 Aug 2002 07:43:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEhJ65028433 for linux-mips-outgoing; Tue, 20 Aug 2002 07: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.5/8.12.5) with SMTP id g7KEh7EC028422 for ; Tue, 20 Aug 2002 07:43:09 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA13559; Tue, 20 Aug 2002 16:46:34 +0200 (MET DST) Date: Tue, 20 Aug 2002 16:46:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: SGI MIPS list Subject: Re: [PATCH] Bring back R4600 V1.7 support In-Reply-To: <20020820141013.GC10730@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1654 Lines: 38 On Tue, 20 Aug 2002, Jan-Benedict Glaw wrote: > Actually, I had written all that using separate functions before, but > neither I nor Ralf liked this approach (because it adds hundreds LOC to > .../c-r4k.c). Ralf then suggested writing it using macros, so I did. Obviously you'd put all the R4600 stuff in a separate file (the second and the third being the regular R4k stuff and the template macros sourced by the first and the second one). That would aid diffing as well. > -*- Proposal -*- > There are IMHO two goals, one for near future, one for following day > (after first goal has reached): > > 1. There are many (equally looking) functions in c-r4k.c . It > would be nice to not have the (more-or-less) function body 10 > times there. > 2. it would be nice to not have like 50 functions around, but to > better have a flexible way to do what needs to be done. > Something like an (initdata) array containing PRId and > function pointers (or other info) on "what needs to be > done". > > The first one seems quite easy. Looking eg. at Alphas, they have a macro > defining a whole function (which inserts a correct function name by > supplied arguments etc.). This way, [...] Definitely. The other one is done by Alphas as well since RTH wrote generic kernel support. I consider such a feature one of goals for MIPS as well, so such a rewrite would be a necessary part of the design sooner or later anyway. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Aug 20 07:47:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KElYEC028599 for ; Tue, 20 Aug 2002 07:47:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KElYmD028598 for linux-mips-outgoing; Tue, 20 Aug 2002 07:47:34 -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.5/8.12.5) with SMTP id g7KElSEC028589 for ; Tue, 20 Aug 2002 07:47:28 -0700 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17hAKm-0005KB-00; Tue, 20 Aug 2002 09:50:16 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17hALL-0004Xw-00; Tue, 20 Aug 2002 10:50:51 -0400 Date: Tue, 20 Aug 2002 10:50:51 -0400 From: Daniel Jacobowitz To: Ralf Baechle Cc: linux-mips@oss.sgi.com, "Maciej W. Rozycki" Subject: Re: New binutils for kernel Message-ID: <20020820145051.GA17311@nevyn.them.org> References: <20020819171238.A7457@linux-mips.org> <20020820162959.A26852@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820162959.A26852@linux-mips.org> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1408 Lines: 34 On Tue, Aug 20, 2002 at 04:29:59PM +0200, Ralf Baechle wrote: > On Tue, Aug 20, 2002 at 04:19:35PM +0200, Maciej W. Rozycki wrote: > > > On Mon, 19 Aug 2002, Ralf Baechle wrote: > > > > > > Are you sure? I believe the patch effectively forces everyone to use > > > > binutils 2.13 for mips64. Is it really acceptable now? > > > > > > In the past week I ended up more and more kludging around binutils bugs. > > > We need something newer and distributions seem to be all at ~ 2.12 at least. > > > > While 2.12 may be OK from the file format point of view, there are > > serious bugs leading to bad code. So bad the kernel doesn't work. It's > > really 2.13 that is needed. I have another less important fix that will > > hopefully go in to 2.13.1 and all gcc versions are broken without yet > > another fix (it bites in mm/mmap.c; not sure if fatally). > > > > > So I guess it's time to bite the bullet? > > > > Since I'm using 2.13 anyway, it's alike to me. But it should be > > discussed at the list, IMO. > > Yep. It won't hurt most of us kernel hackers very much but in particular > the distribution people may want to comment. > > So any comments? Well, I think 2.13's a good idea, but it's very new. I'd say that was acceptable as long as you're looking at MIPS64 only, not at MIPS32. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 20 07:56:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEuFEC029325 for ; Tue, 20 Aug 2002 07:56:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEuF70029324 for linux-mips-outgoing; Tue, 20 Aug 2002 07:56:15 -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 (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KEu1EC029311 for ; Tue, 20 Aug 2002 07:56:06 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7KEwZl24726; Tue, 20 Aug 2002 16:58:35 +0200 Date: Tue, 20 Aug 2002 16:58:35 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: linux-mips@oss.sgi.com, "Maciej W. Rozycki" Subject: Re: New binutils for kernel Message-ID: <20020820165835.B26852@linux-mips.org> References: <20020819171238.A7457@linux-mips.org> <20020820162959.A26852@linux-mips.org> <20020820145051.GA17311@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020820145051.GA17311@nevyn.them.org>; from dan@debian.org on Tue, Aug 20, 2002 at 10:50:51AM -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 411 Lines: 13 On Tue, Aug 20, 2002 at 10:50:51AM -0400, Daniel Jacobowitz wrote: > > So any comments? > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > acceptable as long as you're looking at MIPS64 only, not at MIPS32. Such considerations have kept us back at antique levels of binutils. And juggling with several different versions for userland, and two kernel flavours is evil ... Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 07:58:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KEwcEC029473 for ; Tue, 20 Aug 2002 07:58:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KEwcaM029472 for linux-mips-outgoing; Tue, 20 Aug 2002 07:58:38 -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.5/8.12.5) with SMTP id g7KEwXEC029460 for ; Tue, 20 Aug 2002 07:58:34 -0700 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17hAVd-0005LG-00; Tue, 20 Aug 2002 10:01:29 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17hAWD-00071q-00; Tue, 20 Aug 2002 11:02:05 -0400 Date: Tue, 20 Aug 2002 11:02:05 -0400 From: Daniel Jacobowitz To: Ralf Baechle Cc: linux-mips@oss.sgi.com, "Maciej W. Rozycki" Subject: Re: New binutils for kernel Message-ID: <20020820150204.GA16542@nevyn.them.org> References: <20020819171238.A7457@linux-mips.org> <20020820162959.A26852@linux-mips.org> <20020820145051.GA17311@nevyn.them.org> <20020820165835.B26852@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820165835.B26852@linux-mips.org> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 761 Lines: 20 On Tue, Aug 20, 2002 at 04:58:35PM +0200, Ralf Baechle wrote: > On Tue, Aug 20, 2002 at 10:50:51AM -0400, Daniel Jacobowitz wrote: > > > > So any comments? > > > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > > acceptable as long as you're looking at MIPS64 only, not at MIPS32. > > Such considerations have kept us back at antique levels of binutils. And > juggling with several different versions for userland, and two kernel > flavours is evil ... Please keep in mind that 2.13's been out for all of half a month now. Almost no one's using it yet for significant development... if you decide to require it, we can cope, though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 20 08:05:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KF5DEC029678 for ; Tue, 20 Aug 2002 08:05:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KF5DUQ029677 for linux-mips-outgoing; Tue, 20 Aug 2002 08:05:13 -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.5/8.12.5) with SMTP id g7KF54EC029666 for ; Tue, 20 Aug 2002 08:05:06 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA13956; Tue, 20 Aug 2002 17:08:20 +0200 (MET DST) Date: Tue, 20 Aug 2002 17:08:20 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Daniel Jacobowitz , linux-mips@oss.sgi.com Subject: Re: New binutils for kernel In-Reply-To: <20020820165835.B26852@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 932 Lines: 21 On Tue, 20 Aug 2002, Ralf Baechle wrote: > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > > acceptable as long as you're looking at MIPS64 only, not at MIPS32. > > Such considerations have kept us back at antique levels of binutils. And > juggling with several different versions for userland, and two kernel > flavours is evil ... Any version since 2.11, possibly older, should work just fine for 32-bit MIPS. I don't think there are any significant interface changes between 2.11 and 2.13, so if 2.13 works then 2.11 will not bail out either. Thus there is no need to force 2.13 for 32-bit MIPS, but I think it is acceptable to stop caring about versions older than 2.11 in the nearby future. -- + 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 Aug 20 08:08:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KF8NEC029901 for ; Tue, 20 Aug 2002 08:08:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KF8NnT029900 for linux-mips-outgoing; Tue, 20 Aug 2002 08:08:23 -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.5/8.12.5) with SMTP id g7KF8GEC029790 for ; Tue, 20 Aug 2002 08:08:16 -0700 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17hAeq-0005Ma-00; Tue, 20 Aug 2002 10:11:00 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17hAfP-0006Qf-00; Tue, 20 Aug 2002 11:11:35 -0400 Date: Tue, 20 Aug 2002 11:11:35 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: New binutils for kernel Message-ID: <20020820151135.GA23807@nevyn.them.org> References: <20020820165835.B26852@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 930 Lines: 23 On Tue, Aug 20, 2002 at 05:08:20PM +0200, Maciej W. Rozycki wrote: > On Tue, 20 Aug 2002, Ralf Baechle wrote: > > > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > > > acceptable as long as you're looking at MIPS64 only, not at MIPS32. > > > > Such considerations have kept us back at antique levels of binutils. And > > juggling with several different versions for userland, and two kernel > > flavours is evil ... > > Any version since 2.11, possibly older, should work just fine for 32-bit > MIPS. I don't think there are any significant interface changes between > 2.11 and 2.13, so if 2.13 works then 2.11 will not bail out either. Thus > there is no need to force 2.13 for 32-bit MIPS, but I think it is > acceptable to stop caring about versions older than 2.11 in the nearby > future. Sure. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 20 08:13:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFDlEC030170 for ; Tue, 20 Aug 2002 08:13:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFDl85030169 for linux-mips-outgoing; Tue, 20 Aug 2002 08:13:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from webmail24.rediffmail.com (webmail24.rediffmail.com [203.199.83.146] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFDeEC030159 for ; Tue, 20 Aug 2002 08:13:41 -0700 Received: (qmail 6014 invoked by uid 510); 20 Aug 2002 15:15:20 -0000 Date: 20 Aug 2002 15:15:20 -0000 Message-ID: <20020820151520.6013.qmail@webmail24.rediffmail.com> Received: from unknown (202.93.132.3) by rediffmail.com via HTTP; 20 Aug 2002 15:15:20 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@oss.sgi.com Subject: cross tool problem.. Content-type: text/plain; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 624 Lines: 22 Hello everybody, can anybody tell from where to get a Big Endian cross tool chain for compiling a ramdisk source for mips(idt).. on linux/intel host environment. i have downloaded one from net but that is not working and saying mips-linux-gcc: installaton problem cannot exec cc1.. alternatively if i can get a precompiled big endian elf format ramdisk...? any pointer would be much helpful.. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-linux-mips@oss.sgi.com Tue Aug 20 08:20:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFKfEC030326 for ; Tue, 20 Aug 2002 08:20:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFKfIt030325 for linux-mips-outgoing; Tue, 20 Aug 2002 08:20:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from webmail22.rediffmail.com (webmail22.rediffmail.com [203.199.83.144] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFKXEC030316 for ; Tue, 20 Aug 2002 08:20:34 -0700 Received: (qmail 6132 invoked by uid 510); 20 Aug 2002 15:21:47 -0000 Date: 20 Aug 2002 15:21:47 -0000 Message-ID: <20020820152147.6131.qmail@webmail22.rediffmail.com> Received: from unknown (202.93.132.3) by rediffmail.com via HTTP; 20 Aug 2002 15:21:47 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@oss.sgi.com Subject: cross tool problem.. Content-type: text/plain; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 624 Lines: 22 Hello everybody, can anybody tell from where to get a Big Endian cross tool chain for compiling a ramdisk source for mips(idt).. on linux/intel host environment. i have downloaded one from net but that is not working and saying mips-linux-gcc: installaton problem cannot exec cc1.. alternatively if i can get a precompiled big endian elf format ramdisk...? any pointer would be much helpful.. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-linux-mips@oss.sgi.com Tue Aug 20 08:26:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFQOEC030520 for ; Tue, 20 Aug 2002 08:26:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFQOj0030519 for linux-mips-outgoing; Tue, 20 Aug 2002 08:26: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 (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFQ7EC030499 for ; Tue, 20 Aug 2002 08:26:17 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7KFHZv24966; Tue, 20 Aug 2002 17:17:35 +0200 Date: Tue, 20 Aug 2002 17:17:35 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com Subject: Re: New binutils for kernel Message-ID: <20020820171735.A24832@linux-mips.org> References: <20020820165835.B26852@linux-mips.org> <20020820151135.GA23807@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020820151135.GA23807@nevyn.them.org>; from dan@debian.org on Tue, Aug 20, 2002 at 11:11:35AM -0400 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 936 Lines: 23 On Tue, Aug 20, 2002 at 11:11:35AM -0400, Daniel Jacobowitz wrote: > > > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > > > > acceptable as long as you're looking at MIPS64 only, not at MIPS32. > > > > > > Such considerations have kept us back at antique levels of binutils. And > > > juggling with several different versions for userland, and two kernel > > > flavours is evil ... > > > > Any version since 2.11, possibly older, should work just fine for 32-bit > > MIPS. I don't think there are any significant interface changes between > > 2.11 and 2.13, so if 2.13 works then 2.11 will not bail out either. Thus > > there is no need to force 2.13 for 32-bit MIPS, but I think it is > > acceptable to stop caring about versions older than 2.11 in the nearby > > future. > > Sure. Sounds like we'll then recommend 2.13 for the fearless and 64-bit developers and 2.11 for everybody else. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 08:47:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFldEC031103 for ; Tue, 20 Aug 2002 08:47:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFldKf031102 for linux-mips-outgoing; Tue, 20 Aug 2002 08:47:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from marjan.installco.com (marjan.installco.com [65.39.69.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFlNEC031090 for ; Tue, 20 Aug 2002 08:47:24 -0700 Received: (qmail 21966 invoked by uid 504); 20 Aug 2002 08:36:20 -0000 Received: from tom@tomlogic.com by marjan.installco.com by uid 507 with qmail-scanner-1.12 (spamassassin: 2.30. . Clear:. Processed in 0.326205 secs); 20 Aug 2002 08:36:20 -0000 Received: from unknown (HELO Tom) (130.13.171.182) by marjan.installco.com with DES-CBC3-SHA encrypted SMTP; 20 Aug 2002 08:36:19 -0000 Date: Tue, 20 Aug 2002 08:50:18 -0700 Mime-Version: 1.0 (Apple Message framework v482) Content-Type: multipart/alternative; boundary=Apple-Mail-1-11810748 Subject: CONFIG_MIPS_IVR change for arch/mips/config.in From: Tom Collins To: linux-mips@oss.sgi.com Message-Id: <869DF7E0-B454-11D6-8E42-000393B3D1D0@tomlogic.com> X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3227 Lines: 107 --Apple-Mail-1-11810748 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I'm not a subscriber to the list, so if anyone has questions or responses, please email me directly. I have a machine based on the Globespan IVR board, and just got done fighting through an upgrade from 2.4.2 to 2.4.19. In the process, I determined that (at least for my configuration), CONFIG_PCI_AUTO should not be set. When set, the I/O mappings for my devices (USB) were out of whack, and I was unable to use one of the on-board USB chips. Here's the configuration as it stands on my machine now: if [ "$CONFIG_MIPS_IVR" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_PC_KEYB y define_bool CONFIG_NEW_PCI y define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO n define_bool CONFIG_IT8172_CIR y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y fi I am still working on a problem with a PCI card on the unit though. It's a USB 2.0 interface which appears to the kernel as two OHCI (1.0) interfaces and one EHCI (2.0) interface. Right now, the kernel doesn't find the EHCI interface. If I find that changing other settings (like CONFIG_NEW_PCI) results in that interface showing up (without blowing up the others), I'll be sure to tell the list. Can someone here please make sure this change gets into the 2.4.20 kernel? I haven't been using the 2.5 kernels because the last one I tried (2.5.25) wouldn't compile on my platform. -- Tom Collins tom@tomlogic.com --Apple-Mail-1-11810748 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII I'm not a subscriber to the list, so if anyone has questions or responses, please email me directly. I have a machine based on the Globespan IVR board, and just got done fighting through an upgrade from 2.4.2 to 2.4.19. In the process, I determined that (at least for my configuration), CONFIG_PCI_AUTO should not be set. When set, the I/O mappings for my devices (USB) were out of whack, and I was unable to use one of the on-board USB chips. Here's the configuration as it stands on my machine now: 0000,0000,DEDEif [ "$CONFIG_MIPS_IVR" = "y" ]; then define_bool CONFIG_PCI y define_bool CONFIG_PC_KEYB y define_bool CONFIG_NEW_PCI y define_bool CONFIG_NONCOHERENT_IO y define_bool CONFIG_PCI_AUTO n define_bool CONFIG_IT8172_CIR y define_bool CONFIG_NEW_IRQ y define_bool CONFIG_NEW_TIME_C y fi I am still working on a problem with a PCI card on the unit though. It's a USB 2.0 interface which appears to the kernel as two OHCI (1.0) interfaces and one EHCI (2.0) interface. Right now, the kernel doesn't find the EHCI interface. If I find that changing other settings (like CONFIG_NEW_PCI) results in that interface showing up (without blowing up the others), I'll be sure to tell the list. Can someone here please make sure this change gets into the 2.4.20 kernel? I haven't been using the 2.5 kernels because the last one I tried (2.5.25) wouldn't compile on my platform. -- Tom Collins tom@tomlogic.com --Apple-Mail-1-11810748-- From owner-linux-mips@oss.sgi.com Tue Aug 20 08:55:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFtKEC031426 for ; Tue, 20 Aug 2002 08:55:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFtKhM031425 for linux-mips-outgoing; Tue, 20 Aug 2002 08:55:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from postman.medtronic.com (postman.medtronic.COM [144.15.157.121]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFtFEC031415 for ; Tue, 20 Aug 2002 08:55:16 -0700 Received: from RADIUM (localhost [127.0.0.1]) by postman.medtronic.com (8.10.1/8.10.1) with SMTP id g7KFwDL18844 for ; Tue, 20 Aug 2002 10:58:13 -0500 (CDT) From: "Lyle Bainbridge" To: Subject: Mips cross toolchain Date: Tue, 20 Aug 2002 10:58:13 -0500 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 V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 635 Lines: 18 Hi, I'm a linux kernel newbie, and this is my first linux-mips posting. I have built a big endian, elf, cross toolchain for mips32 (I'm using an Alchemy Au1500 SOC) based on the GCC 3.0.4, Binutils 2.11.2 and Newlib 1.9.0. My intention is to now use it to compile the 2.4.19 kernel. I am still figuring out how to cross compile the kernel, but I was wondering if I had used the correct versions of GCC and Binutils to succesfully build a stable kernel. Also, are there any patches I would need? So far I've used the stock distributions from gnu.org. Any advice would be most appreciated. Thanks, Lyle Bainbridge Minneapolis, MN From owner-linux-mips@oss.sgi.com Tue Aug 20 08:57:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KFvnEC031557 for ; Tue, 20 Aug 2002 08:57:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KFvnJk031556 for linux-mips-outgoing; Tue, 20 Aug 2002 08:57:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KFvfEC031547 for ; Tue, 20 Aug 2002 08:57:41 -0700 Received: from [10.2.2.62] ([63.194.214.47]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H1500LKGGH2WW@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Tue, 20 Aug 2002 09:00:39 -0700 (PDT) Date: Tue, 20 Aug 2002 08:51:42 -0700 From: Pete Popov Subject: Re: CONFIG_MIPS_IVR change for arch/mips/config.in In-reply-to: <869DF7E0-B454-11D6-8E42-000393B3D1D0@tomlogic.com> To: Tom Collins Cc: linux-mips Message-id: <1029858703.13478.18.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7bit References: <869DF7E0-B454-11D6-8E42-000393B3D1D0@tomlogic.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2219 Lines: 51 Without PCI_AUTO none of the pci devices will be configured properly, unless the boot code sets them up. The pmon version you have does that, I believe, but I'm not sure everyone can count on using the same boot code. I think we fixed the problem you describe by skipping the system controller (IT8172) config and leaving its default map. The small patch which affects it8172_pci.c is in the source forge tree but I don't know if it made it to oss, probably not since the interest in that board is small in the community itself. In general, I think the IVR board support in the sourceforge kernel is more up to date than oss. Pete On Tue, 2002-08-20 at 08:50, Tom Collins wrote: > I'm not a subscriber to the list, so if anyone has questions or > responses, please email me directly. > > I have a machine based on the Globespan IVR board, and just got done > fighting through an upgrade from 2.4.2 to 2.4.19. In the process, I > determined that (at least for my configuration), CONFIG_PCI_AUTO should > not be set. When set, the I/O mappings for my devices (USB) were out of > whack, and I was unable to use one of the on-board USB chips. > > Here's the configuration as it stands on my machine now: > > if [ "$CONFIG_MIPS_IVR" = "y" ]; then > define_bool CONFIG_PCI y > define_bool CONFIG_PC_KEYB y > define_bool CONFIG_NEW_PCI y > define_bool CONFIG_NONCOHERENT_IO y > define_bool CONFIG_PCI_AUTO n > define_bool CONFIG_IT8172_CIR y > define_bool CONFIG_NEW_IRQ y > define_bool CONFIG_NEW_TIME_C y > fi > > I am still working on a problem with a PCI card on the unit though. > It's a USB 2.0 interface which appears to the kernel as two OHCI (1.0) > interfaces and one EHCI (2.0) interface. Right now, the kernel doesn't > find the EHCI interface. If I find that changing other settings (like > CONFIG_NEW_PCI) results in that interface showing up (without blowing up > the others), I'll be sure to tell the list. > > Can someone here please make sure this change gets into the 2.4.20 > kernel? I haven't been using the 2.5 kernels because the last one I > tried (2.5.25) wouldn't compile on my platform. > > -- > Tom Collins > tom@tomlogic.com From owner-linux-mips@oss.sgi.com Tue Aug 20 09:01:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KG17EC031756 for ; Tue, 20 Aug 2002 09:01:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KG17Yj031755 for linux-mips-outgoing; Tue, 20 Aug 2002 09:01:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KG12EC031738 for ; Tue, 20 Aug 2002 09:01:02 -0700 Received: from localhost ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H15006E7GM1ON@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Tue, 20 Aug 2002 09:03:38 -0700 (PDT) Date: Tue, 20 Aug 2002 08:54:41 -0700 From: Pete Popov Subject: Re: Mips cross toolchain In-reply-to: To: Lyle Bainbridge Cc: linux-mips Message-id: <1029858882.13494.22.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7bit References: X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1180 Lines: 32 Just FYI, the oss code for the Alchemy boards is out of date. The latest code is in the sourceforge.net mips tree. I meant to create patches and send them to Ralf but I'm doing less and less dev work these days and haven't been able to find the time. As far as your toolchain, the last MontaVista release which included the Alchemy boards was 2.95.3 based. I can also tell you that gcc 3.2 works fine, but I'm not sure if we needed any patches. Pete On Tue, 2002-08-20 at 08:58, Lyle Bainbridge wrote: > Hi, > > I'm a linux kernel newbie, and this is my first linux-mips posting. > I have built a big endian, elf, cross toolchain for mips32 (I'm using > an Alchemy Au1500 SOC) based on the GCC 3.0.4, Binutils 2.11.2 and > Newlib 1.9.0. My intention is to now use it to compile the 2.4.19 kernel. > > I am still figuring out how to cross compile the kernel, but I was > wondering if I had used the correct versions of GCC and Binutils to > succesfully build a stable kernel. Also, are there any patches I would > need? So far I've used the stock distributions from gnu.org. > > Any advice would be most appreciated. > > Thanks, > Lyle Bainbridge > Minneapolis, MN > From owner-linux-mips@oss.sgi.com Tue Aug 20 09:02:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KG27EC031946 for ; Tue, 20 Aug 2002 09:02:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KG27ai031945 for linux-mips-outgoing; Tue, 20 Aug 2002 09:02:07 -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.5/8.12.5) with SMTP id g7KG22EC031919 for ; Tue, 20 Aug 2002 09:02:02 -0700 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17hBV3-0005QS-00; Tue, 20 Aug 2002 11:04:57 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17hBVc-0006lY-00; Tue, 20 Aug 2002 12:05:32 -0400 Date: Tue, 20 Aug 2002 12:05:32 -0400 From: Daniel Jacobowitz To: Lyle Bainbridge Cc: linux-mips@oss.sgi.com Subject: Re: Mips cross toolchain Message-ID: <20020820160532.GA25800@nevyn.them.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 927 Lines: 23 On Tue, Aug 20, 2002 at 10:58:13AM -0500, Lyle Bainbridge wrote: > Hi, > > I'm a linux kernel newbie, and this is my first linux-mips posting. > I have built a big endian, elf, cross toolchain for mips32 (I'm using > an Alchemy Au1500 SOC) based on the GCC 3.0.4, Binutils 2.11.2 and > Newlib 1.9.0. My intention is to now use it to compile the 2.4.19 kernel. > > I am still figuring out how to cross compile the kernel, but I was > wondering if I had used the correct versions of GCC and Binutils to > succesfully build a stable kernel. Also, are there any patches I would > need? So far I've used the stock distributions from gnu.org. > > Any advice would be most appreciated. You'll have better luck if you use the current releases. That's 3.2 and 2.13 and (I think) 1.10.0. Not sure if newlib 1.10.0 is released or not. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Aug 20 09:11:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KGBEEC032189 for ; Tue, 20 Aug 2002 09:11:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KGBEpp032188 for linux-mips-outgoing; Tue, 20 Aug 2002 09:11: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 (shaft16-f39.dialo.tiscali.de [62.246.16.39]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KGB3EC032179 for ; Tue, 20 Aug 2002 09:11:07 -0700 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7KG2NT25481; Tue, 20 Aug 2002 18:02:23 +0200 Date: Tue, 20 Aug 2002 18:02:23 +0200 From: Ralf Baechle To: Lyle Bainbridge Cc: linux-mips@oss.sgi.com Subject: Re: Mips cross toolchain Message-ID: <20020820180223.A24985@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from lyle@zevion.com on Tue, Aug 20, 2002 at 10:58:13AM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 773 Lines: 19 On Tue, Aug 20, 2002 at 10:58:13AM -0500, Lyle Bainbridge wrote: > I'm a linux kernel newbie, and this is my first linux-mips posting. > I have built a big endian, elf, cross toolchain for mips32 (I'm using > an Alchemy Au1500 SOC) based on the GCC 3.0.4, Binutils 2.11.2 and > Newlib 1.9.0. My intention is to now use it to compile the 2.4.19 kernel. > > I am still figuring out how to cross compile the kernel, but I was > wondering if I had used the correct versions of GCC and Binutils to > succesfully build a stable kernel. Also, are there any patches I would > need? So far I've used the stock distributions from gnu.org. > > Any advice would be most appreciated. Looks like you installed the toolchain in a different directory that it was built for. Ralf From owner-linux-mips@oss.sgi.com Tue Aug 20 09:26:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KGQWEC032375 for ; Tue, 20 Aug 2002 09:26:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KGQW2b032374 for linux-mips-outgoing; Tue, 20 Aug 2002 09:26:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from clearcore.com (clrsrv@[208.141.182.168]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KGQSEC032362 for ; Tue, 20 Aug 2002 09:26:28 -0700 Received: (qmail 10472 invoked from network); 20 Aug 2002 16:29:21 -0000 Received: from clrsrv.clearcore.com (HELO clearcore.net) (192.168.1.1) by clrsrv.clearcore.com with SMTP; 20 Aug 2002 16:29:21 -0000 Message-ID: <3D626E61.3010505@clearcore.net> Date: Tue, 20 Aug 2002 10:29:21 -0600 From: Joe George Organization: ClearCore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Lyle Bainbridge CC: linux-mips@oss.sgi.com Subject: Re: Mips cross toolchain References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 606 Lines: 17 I don't know of anyone using big endian with Alchemy at this point. There may be some and I'd like to hear from them. The OSS tree is actually not that far out of date now. I have been submitting patches and the basics work now (at least on my board). I am currently working on the 36-bit support. The 36-bit support only works for little endian currently afaics. I'm working to solve the endian problems now. Check out the howto at http://www.linux-mips.org/. There are 3 of us doing Alchemy work who hang out on the #mipslinux irc channel on irc.openprojects.net you're welcome to join us. Joe From owner-linux-mips@oss.sgi.com Tue Aug 20 09:58:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KGwaEC000405 for ; Tue, 20 Aug 2002 09:58:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KGwa2r000404 for linux-mips-outgoing; Tue, 20 Aug 2002 09:58: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.5/8.12.5) with SMTP id g7KGwREC000395 for ; Tue, 20 Aug 2002 09:58:28 -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 KAA04591 for ; Tue, 20 Aug 2002 10:02:11 -0700 (PDT) mail_from (ppopov@mvista.com) Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA03936; Tue, 20 Aug 2002 09:56:08 -0700 Subject: Re: Mips cross toolchain From: Pete Popov To: Joe George Cc: Lyle Bainbridge , linux-mips In-Reply-To: <3D626E61.3010505@clearcore.net> References: <3D626E61.3010505@clearcore.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 20 Aug 2002 09:57:45 -0700 Message-Id: <1029862665.11391.5.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1515 Lines: 37 On Tue, 2002-08-20 at 09:29, Joe George wrote: > I don't know of anyone using big endian with Alchemy at this point. > There may be some and I'd like to hear from them. > The OSS tree is actually not that far out of date now. I have been > submitting patches and the basics work now (at least on my board). Where those patches created from the sourceforge tree or you created them independently? I would hate to see the two ports diverge. > I am currently working on the 36-bit support. I already sent Ralf a patch for the 36bit support. He told me the patch looks fine but it doesn't seem like he's had time to merge it in. The code is in sourceforge.net > The 36-bit support only > works for little endian currently afaics. I'm working to solve the endian > problems now. Again, I've done some work for big endian support and pushed it out in sourceforge.net because I have write access there. Most drivers work just fine in BE mode. The exception right now is the epson 1356/1386 video controller. There might be some others but I don't remember. Certainly all the SOC peripherals work fine. > Check out the howto at http://www.linux-mips.org/. There are 3 of > us doing Alchemy work who hang out on the #mipslinux irc channel > on irc.openprojects.net you're welcome to join us. If you're submitting patches in oss, please take the latest work in sourceforge.net first to sync up the two. First, you might save yourself some work. Second, it will keep the two ports from diverging. Pete From owner-linux-mips@oss.sgi.com Tue Aug 20 10:20:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KHK4EC003385 for ; Tue, 20 Aug 2002 10:20:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KHK4TA003384 for linux-mips-outgoing; Tue, 20 Aug 2002 10:20:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from clearcore.com (clrsrv@[208.141.182.168]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KHJxEC003369 for ; Tue, 20 Aug 2002 10:19:59 -0700 Received: (qmail 10728 invoked from network); 20 Aug 2002 17:22:51 -0000 Received: from clrsrv.clearcore.com (HELO clearcore.net) (192.168.1.1) by clrsrv.clearcore.com with SMTP; 20 Aug 2002 17:22:51 -0000 Message-ID: <3D627AEB.5010003@clearcore.net> Date: Tue, 20 Aug 2002 11:22:51 -0600 From: Joe George Organization: ClearCore User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Pete Popov CC: linux-mips Subject: Re: Mips cross toolchain References: <3D626E61.3010505@clearcore.net> <1029862665.11391.5.camel@zeus.mvista.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1127 Lines: 28 > Where those patches created from the sourceforge tree or you created > them independently? I would hate to see the two ports diverge. I've been syncing the sf tree. > I already sent Ralf a patch for the 36bit support. He told me the patch > looks fine but it doesn't seem like he's had time to merge it in. The > code is in sourceforge.net My initial patches on this came from the sf tree. Ralf called out the endian problem. > Again, I've done some work for big endian support and pushed it out in > sourceforge.net because I have write access there. Most drivers work > just fine in BE mode. The exception right now is the epson 1356/1386 > video controller. There might be some others but I don't remember. > Certainly all the SOC peripherals work fine. The problems I'm working on are in your tlbex-mips32.S. > If you're submitting patches in oss, please take the latest work in > sourceforge.net first to sync up the two. First, you might save > yourself some work. Second, it will keep the two ports from diverging. Couldn't of done it without your work, I really appreciate the work you have done. Joe From owner-linux-mips@oss.sgi.com Tue Aug 20 10:24:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KHOwEC003491 for ; Tue, 20 Aug 2002 10:24:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KHOwTp003490 for linux-mips-outgoing; Tue, 20 Aug 2002 10:24:58 -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.5/8.12.5) with SMTP id g7KHOqEC003481 for ; Tue, 20 Aug 2002 10:24:52 -0700 Received: from excalibur.cologne.de (p50850BF8.dip.t-dialin.net [80.133.11.248]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id TAA06291 for ; Tue, 20 Aug 2002 19:27:42 +0200 (MEST) Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 17hCmq-0000JV-00 for ; Tue, 20 Aug 2002 19:27:24 +0200 Date: Tue, 20 Aug 2002 19:27:24 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com Subject: Re: New binutils for kernel Message-ID: <20020820172724.GA599@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com References: <20020819171238.A7457@linux-mips.org> <20020820162959.A26852@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820162959.A26852@linux-mips.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1463 Lines: 33 On Tue, Aug 20, 2002 at 04:29:59PM +0200, Ralf Baechle wrote: [requiring binutils 2.13]] > Yep. It won't hurt most of us kernel hackers very much but in particular > the distribution people may want to comment. Well, I guess that covers me :-). Debian Woody, the current stable Debian release (AFAIK the only full-blown distribution for Linux/mips that targets at "normal users" and not only at developers) ships with binutils 2.12.90.0.1. As the Debian policy requires that no new program versions are to be introduced for the stable release, Debian will not be able to switch to binutils 2.13 there. Bugfixes for packages in the release are accepted, but not new upstream versions; so to get any fixes in, they would need to be backported to binutils 2.12. For the unstable distribution (currently binutils 2.12.90.0.15), switching to binutils 2.13 should IMHO be possible in a reasonable timeframe, if it does not break other things. Caveat: as Debian requires all 11 released architectures to be in sync, any new version would have to work properly on _all_ supported platforms. The decision about introducing a new version of a package into Debian is taken by the package maintainer, so I am going to ask him about his plans. 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 Tue Aug 20 10:37:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KHbIEC003710 for ; Tue, 20 Aug 2002 10:37:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KHbH2F003709 for linux-mips-outgoing; Tue, 20 Aug 2002 10:37:17 -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.5/8.12.5) with SMTP id g7KHbAEC003696 for ; Tue, 20 Aug 2002 10:37:10 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA10635; Tue, 20 Aug 2002 10:40:03 -0700 Subject: Re: Mips cross toolchain From: Pete Popov To: Joe George Cc: linux-mips In-Reply-To: <3D627AEB.5010003@clearcore.net> References: <3D626E61.3010505@clearcore.net> <1029862665.11391.5.camel@zeus.mvista.com> <3D627AEB.5010003@clearcore.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 20 Aug 2002 10:41:40 -0700 Message-Id: <1029865300.11781.22.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1657 Lines: 38 On Tue, 2002-08-20 at 10:22, Joe George wrote: > > Where those patches created from the sourceforge tree or you created > > them independently? I would hate to see the two ports diverge. > > I've been syncing the sf tree. > > > I already sent Ralf a patch for the 36bit support. He told me the patch > > looks fine but it doesn't seem like he's had time to merge it in. The > > code is in sourceforge.net > > My initial patches on this came from the sf tree. Ralf called out the > endian problem. > > Again, I've done some work for big endian support and pushed it out in > > sourceforge.net because I have write access there. Most drivers work > > just fine in BE mode. The exception right now is the epson 1356/1386 > > video controller. There might be some others but I don't remember. > > Certainly all the SOC peripherals work fine. > > The problems I'm working on are in your tlbex-mips32.S. I see of the 36 bit patch in oss now, but not the whole thing. Is Ralf waiting for you to fix the problems in tlbex-mips32.S? Are those problems endian related or something else? I tested the pcmcia driver in BE mode, and that driver uses the 36 bit code, so I thought it's endian safe ... > > If you're submitting patches in oss, please take the latest work in > > sourceforge.net first to sync up the two. First, you might save > > yourself some work. Second, it will keep the two ports from diverging. > > Couldn't of done it without your work, I really appreciate the work > you have done. Thanks for syncing up the oss tree! I was afraid that if you're sending independent patches some of the sourceforge work would get lost. Pete From owner-linux-mips@oss.sgi.com Tue Aug 20 11:44:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KIiDEC005383 for ; Tue, 20 Aug 2002 11:44:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KIiDdJ005382 for linux-mips-outgoing; Tue, 20 Aug 2002 11:44:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from medtron.medtronic.com (medtron.medtronic.COM [144.15.157.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7KIi7EC005366 for ; Tue, 20 Aug 2002 11:44:07 -0700 Received: from RADIUM (localhost [127.0.0.1]) by medtron.medtronic.com (8.10.1/8.10.1) with SMTP id g7KIl1x07008; Tue, 20 Aug 2002 13:47:01 -0500 (CDT) From: "Lyle Bainbridge" To: "Joe George" Cc: Subject: RE: Mips cross toolchain Date: Tue, 20 Aug 2002 13:47:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: <3D626E61.3010505@clearcore.net> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 579 Lines: 23 -----Original Message----- From: Joe George [mailto:joeg@clearcore.net] Sent: Tuesday, August 20, 2002 11:29 AM To: Lyle Bainbridge Cc: linux-mips@oss.sgi.com Subject: Re: Mips cross toolchain >>I don't know of anyone using big endian with Alchemy at this point. >>There may be some and I'd like to hear from them. Firstly, thanks to everyone for the advice. Ideally I'd use big endian. Is there any reason the toolchain wouldn't support this. I'm only using the Au1500 on-chip peripherals with the addition of an external Highpoint HPT371 ATA controller. Thanks Lyle From owner-linux-mips@oss.sgi.com Tue Aug 20 11:59:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7KIxmEC005786 for ; Tue, 20 Aug 2002 11:59:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7KIxmG7005785 for linux-mips-outgoing; Tue, 20 Aug 2002 11:59:48 -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.5/8.12.5) with SMTP id g7KIxfEC005769 for ; Tue, 20 Aug 2002 11:59:41 -0700 Received: from zeus.mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA14053; Tue, 20 Aug 2002 12:02:28 -0700 Subject: RE: Mips cross toolchain From: Pete Popov To: Lyle Bainbridge Cc: Joe George , linux-mips In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 20 Aug 2002 12:04:06 -0700 Message-Id: <1029870249.11781.88.camel@zeus.mvista.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 950 Lines: 34 On Tue, 2002-08-20 at 11:47, Lyle Bainbridge wrote: > > > -----Original Message----- > From: Joe George [mailto:joeg@clearcore.net] > Sent: Tuesday, August 20, 2002 11:29 AM > To: Lyle Bainbridge > Cc: linux-mips@oss.sgi.com > Subject: Re: Mips cross toolchain > > > >>I don't know of anyone using big endian with Alchemy at this point. > >>There may be some and I'd like to hear from them. > > > Firstly, thanks to everyone for the advice. > > Ideally I'd use big endian. Is there any reason the toolchain > wouldn't support this. No. > I'm only using the Au1500 on-chip peripherals > with the addition of an external Highpoint HPT371 ATA controller. Any of the PCI peripherals on the Pb1500 would require the 36 bit code support. I ... think I tested the PCI bus support using the 36 bit patch and BE mode and it worked fine. Looks like Joe is working on some bug fixes though so the 36 bit code is not complete yet in oss. Pete From owner-linux-mips@oss.sgi.com Tue Aug 20 17:00:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g7L00wEC013428 for ; Tue, 20 Aug 2002 17:00:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id g7L00wVD013427 for linux-mips-outgoing; Tue, 20 Aug 2002 17:00:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-mips@oss.sgi.com using -f Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g7L00qEC013418 for ; Tue, 20 Aug 2002 17:00:53 -0700 Received: from ocean.lucon.org ([12.234.143.38]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020820151102.HKPN13899.sccrmhc02.attbi.com@ocean.lucon.org>; Tue, 20 Aug 2002 15:11:02 +0000 Received: by ocean.lucon.org (Postfix, from userid 1000) id BA40F125D9; Tue, 20 Aug 2002 08:10:58 -0700 (PDT) Date: Tue, 20 Aug 2002 08:10:58 -0700 From: "H. J. Lu" To: Ralf Baechle Cc: Daniel Jacobowitz , linux-mips@oss.sgi.com, "Maciej W. Rozycki" Subject: Re: New binutils for kernel Message-ID: <20020820081058.A29182@lucon.org> References: <20020819171238.A7457@linux-mips.org> <20020820162959.A26852@linux-mips.org> <20020820145051.GA17311@nevyn.them.org> <20020820165835.B26852@linux-mips.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: <20020820165835.B26852@linux-mips.org>; from ralf@linux-mips.org on Tue, Aug 20, 2002 at 04:58:35PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 645 Lines: 19 On Tue, Aug 20, 2002 at 04:58:35PM +0200, Ralf Baechle wrote: > On Tue, Aug 20, 2002 at 10:50:51AM -0400, Daniel Jacobowitz wrote: > > > > So any comments? > > > > Well, I think 2.13's a good idea, but it's very new. I'd say that was > > acceptable as long as you're looking at MIPS64 only, not at MIPS32. > > Such considerations have kept us back at antique levels of binutils. And > juggling with several different versions for userland, and two kernel > flavours is evil ... I have no problems with binutils 2.13.90.0.4 on Linux/mips. I rebuild everything, from kernel to rpms, for Linux/mipsel with it. They seem to run fine. H.J. From ralf@linux-mips.org Thu Aug 22 21:26:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Aug 2002 21:26:58 +0200 (CEST) Received: from shaft19-f237.dialo.tiscali.de ([62.246.19.237]:33253 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 22 Aug 2002 21:26:57 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g7MJQlF19035 for linux-mips@linux-mips.org; Thu, 22 Aug 2002 21:26:47 +0200 Date: Thu, 22 Aug 2002 21:26:47 +0200 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: ADMIN: linux-mips list move Message-ID: <20020822212647.A19026@linux-mips.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org Content-Transfer-Encoding: 8bit X-archive-position: 1 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 403 Lines: 9 I've moved the linux-mips mailing list from oss.sgi.com to linux-mips.org. Linux-mips.org is running zmailer at the MTA and Ecartis as the list manager. Therefore from now subscription is handled via ecartis@linux-mips.org; ecartis recognizes Majordomo commands including a help command so not much of a big change here. In addition Ecartis also support a digest mode and a few other gadgets. Ralf From jbglaw@dvmwest.gt.owl.de Fri Aug 23 12:13:18 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Aug 2002 12:13:18 +0200 (CEST) Received: from dvmwest.gt.owl.de ([62.52.24.140]:21767 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Fri, 23 Aug 2002 12:13:18 +0200 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 2877F13363; Fri, 23 Aug 2002 12:13:11 +0200 (CEST) Date: Fri, 23 Aug 2002 12:13:10 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: CVS Update@oss.sgi.com: linux Message-ID: <20020823101310.GN12007@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: <200208230950.g7N9o0fq016617@oss.sgi.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <200208230950.g7N9o0fq016617@oss.sgi.com> User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org Content-Transfer-Encoding: 8bit X-archive-position: 2 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips Content-Length: 1075 Lines: 36 On Fri, 2002-08-23 02:50:00 -0700, Maciej W. Rozycki wrote in message <200208230950.g7N9o0fq016617@oss.sgi.com>: > CVSROOT: /oss/CVS/cvs > Module name: linux > Changes by: macro@oss.sgi.com 02/08/23 02:50:00 > > Modified files: > drivers/scsi : Tag: linux_2_4 dec_esp.c > include/asm-mips: Tag: linux_2_4 scatterlist.h > include/asm-mips64: Tag: linux_2_4 scatterlist.h > > Log message: > More mmu_sglist and dec_esp.c fixes, sigh... Cool. Fixed now. I had send a similar patch around about a week or two ago on whitch Karsten and I had worked on. Nobody responded, nobody checked it in... Not to talk about the R4600 issues... MfG, JBG -- Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9Zgq2Hb1edYOZ4bsRAhoEAKCRs8dxZSlradXTi2RPodBabHr9ewCgi/7Q 7N6mgModfQ78u+ljaRk52Bs= =JA+S -----END PGP SIGNATURE----- From macro@ds2.pg.gda.pl Fri Aug 23 12:40:45 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Aug 2002 12:40:46 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:37266 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 23 Aug 2002 12:40:45 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA16129; Fri, 23 Aug 2002 12:41:10 +0200 (MET DST) Date: Fri, 23 Aug 2002 12:41:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: linux-mips@linux-mips.org Subject: Re: CVS Update@oss.sgi.com: linux In-Reply-To: <20020823101310.GN12007@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org Content-Transfer-Encoding: 8bit X-archive-position: 3 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Content-Length: 1281 Lines: 35 On Fri, 23 Aug 2002, Jan-Benedict Glaw wrote: > > Modified files: > > drivers/scsi : Tag: linux_2_4 dec_esp.c > > include/asm-mips: Tag: linux_2_4 scatterlist.h > > include/asm-mips64: Tag: linux_2_4 scatterlist.h > > > > Log message: > > More mmu_sglist and dec_esp.c fixes, sigh... > > Cool. Fixed now. I had send a similar patch around about a week or two > ago on whitch Karsten and I had worked on. Nobody responded, nobody I've seen the report. Since changes involved trivial string substitutions and your patch worked for you I have considered it obvious enough not to add any comments. I apologize if you have found this annoying. I've done the changes a bit differently to keep the obsolete mmu_sglist interface unchanged -- it was my fault it got changed by an accident. > checked it in... Not to talk about the R4600 issues... Hmm, haven't you got my suggestions? I hope they were clear, at least nobody complained. If you'd like to test an ll/sc variant, I may try to provide you some aid if needed. Also, have you contacted IDT? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From mdharm@momenco.com Fri Aug 23 21:46:29 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Aug 2002 21:46:30 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:14 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 23 Aug 2002 21:46:29 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g7NJkJ604119; Fri, 23 Aug 2002 12:46:20 -0700 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: PATCH: support new PROM for Ocelot boards Date: Fri, 23 Aug 2002 12:46:19 -0700 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 4 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Content-Length: 650 Lines: 18 The attached patch updates the startup code in the kernel to properly interface to the new version 2 PROMs for the Ocelot boards. They actually aren't that new. A version of this patch was submitted several months ago, but has yet to appear in the tree. This patch is against the 2.4 branch. Will someone with CVS commit access please apply it to the tree? Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From mdharm@momenco.com Fri Aug 23 21:50:08 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Aug 2002 21:50:09 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:1294 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 23 Aug 2002 21:50:08 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g7NJo1604170; Fri, 23 Aug 2002 12:50:01 -0700 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: RE: PATCH: support new PROM for Ocelot boards Date: Fri, 23 Aug 2002 12:50:01 -0700 Message-ID: MIME-Version: 1.0 Content-type: text/plain X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org Content-Transfer-Encoding: 8bit X-archive-position: 5 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Content-Length: 1433 Lines: 49 Grumble.... of course, I would forget to attach the patch. Here's the actual patch. 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: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Matthew Dharm > Sent: Friday, August 23, 2002 12:46 PM > To: Linux-MIPS; Ralf Baechle > Subject: PATCH: support new PROM for Ocelot boards > > > > The attached patch updates the startup code in the kernel > to properly > interface to the new version 2 PROMs for the Ocelot boards. > > They actually aren't that new. A version of this patch was > submitted > several months ago, but has yet to appear in the tree. > > This patch is against the 2.4 branch. Will someone with CVS commit > access please apply it to the tree? > > Matthew Dharm > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. > Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > -- Binary/unsupported file stripped by Ecartis -- -- Type: application/octet-stream -- File: patch20020823a