From nemoto@toshiba-tops.co.jp Mon Aug 6 09:40:55 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id JAA16365; Mon, 6 Aug 2001 09:40:55 +0200 (MET DST) Received-Date: Mon, 6 Aug 2001 09:40:55 +0200 (MET DST) Received: from UNKNOWN(202.230.225.5), claiming to be "topsns.toshiba-tops.co.jp" via SMTP by guadalquivir.fnet.fr, id smtpd016362; Mon Aug 6 09:40:43 2001 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [193.104.112.133]) with SMTP; 6 Aug 2001 07:40:37 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id QAA77377; Mon, 6 Aug 2001 16:40:22 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id QAA46216; Mon, 6 Aug 2001 16:40:22 +0900 (JST) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Subject: SysV IPC shared memory and virtual alising From: Atsushi Nemoto To: linux-mips@oss.sgi.com, linux-mips@fnet.fr X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug__6_16:44:05_2001_756)--" Content-Transfer-Encoding: 7bit Message-Id: <20010806164452D.nemoto@toshiba-tops.co.jp> Date: Mon, 06 Aug 2001 16:44:52 +0900 X-Dispatcher: imput version 20000228(IM140) Content-Length: 2859 Lines: 94 ----Next_Part(Mon_Aug__6_16:44:05_2001_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is an patch to fix virtual aliasing problem with SysV IPC shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. If D-cache is smaller than PAGE_SIZE this patch is not needed at all, but I think it is not so bad unconditionally forcing alignment to SHMLBA. --- Atsushi Nemoto ----Next_Part(Mon_Aug__6_16:44:05_2001_756)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="unmapped_area.patch" diff -ur linux.sgi/arch/mips/kernel/syscall.c linux/arch/mips/kernel/syscall.c --- linux.sgi/arch/mips/kernel/syscall.c Thu Apr 5 13:56:09 2001 +++ linux/arch/mips/kernel/syscall.c Mon Aug 6 16:16:36 2001 @@ -30,6 +30,7 @@ #include #include #include +#include extern asmlinkage void syscall_trace(void); typedef asmlinkage int (*syscall_t)(void *a0,...); @@ -91,6 +92,47 @@ { return do_mmap2(addr, len, prot, flags, fd, pgoff); } + +#ifdef HAVE_ARCH_UNMAPPED_AREA +/* solve cache aliasing problem (see Documentation/cache.txt and + arch/sparc64/kernel/sys_sparc.c */ +#define COLOUR_ALIGN(addr) (((addr)+SHMLBA-1)&~(SHMLBA-1)) + +unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) +{ + struct vm_area_struct * vmm; + + if (flags & MAP_FIXED) { + /* We do not accept a shared mapping if it would violate + * cache aliasing constraints. + */ + if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1))) + return -EINVAL; + return addr; + } + + if (len > TASK_SIZE) + return -ENOMEM; + if (!addr) + addr = TASK_UNMAPPED_BASE; + + if (flags & MAP_SHARED) + addr = COLOUR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + + for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { + /* At this point: (!vmm || addr < vmm->vm_end). */ + if (TASK_SIZE - len < addr) + return -ENOMEM; + if (!vmm || addr + len <= vmm->vm_start) + return addr; + addr = vmm->vm_end; + if (flags & MAP_SHARED) + addr = COLOUR_ALIGN(addr); + } +} +#endif /* HAVE_ARCH_UNMAPPED_AREA */ save_static_function(sys_fork); static_unused int _sys_fork(struct pt_regs regs) diff -ur linux.sgi/include/asm-mips/pgtable.h linux/include/asm-mips/pgtable.h --- linux.sgi/include/asm-mips/pgtable.h Sun Aug 5 23:41:28 2001 +++ linux/include/asm-mips/pgtable.h Mon Aug 6 16:17:11 2001 @@ -740,6 +740,9 @@ #include +/* We provide our own get_unmapped_area to cope with VA holes for userland */ +#define HAVE_ARCH_UNMAPPED_AREA + #endif /* !defined (_LANGUAGE_ASSEMBLY) */ #define io_remap_page_range remap_page_range ----Next_Part(Mon_Aug__6_16:44:05_2001_756)---- From dom@algor.co.uk Mon Aug 6 10:51:25 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA16712; Mon, 6 Aug 2001 10:51:25 +0200 (MET DST) Received-Date: Mon, 6 Aug 2001 10:51:25 +0200 (MET DST) Received: from smtp.algor.co.uk(62.254.210.199), claiming to be "kenton.algor.co.uk" via SMTP by guadalquivir.fnet.fr, id smtpd016710; Mon Aug 6 10:51:12 2001 Received: from gladsmuir.algor.co.uk (IDENT:root@gladsmuir.algor.co.uk [192.168.5.75]) by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id JAA16147; Mon, 6 Aug 2001 09:50:15 +0100 (GMT/BST) Received: (from dom@localhost) by gladsmuir.algor.co.uk (8.11.0/8.8.7) id f768oEX01106; Mon, 6 Aug 2001 09:50:14 +0100 From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15214.23110.345236.934305@gladsmuir.algor.co.uk> Date: Mon, 6 Aug 2001 09:50:14 +0100 (BST) To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising In-Reply-To: <20010806164452D.nemoto@toshiba-tops.co.jp> References: <20010806164452D.nemoto@toshiba-tops.co.jp> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Content-Length: 460 Lines: 15 Atsushi Nemoto (nemoto@toshiba-tops.co.jp) writes: > Here is an patch to fix virtual aliasing problem with SysV IPC > shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > If D-cache is smaller than PAGE_SIZE this patch is not needed at > all... More precisely, if the size of a D-cache "set" is smaller than PAGE_SIZE. So a CPU with a 16Kbyte 4-way set-associative cache and 4Kbyte PAGE_SIZE is safe. Dominic Sweetman Algorithmics Ltd From ralf@dea.waldorf-gmbh.de Fri Aug 10 13:22:37 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA20963; Fri, 10 Aug 2001 13:22:37 +0200 (MET DST) Received-Date: Fri, 10 Aug 2001 13:22:37 +0200 (MET DST) Received: from u-187-21.karlsruhe.ipdial.viaginterkom.de(62.180.21.187), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd020961; Fri Aug 10 13:22:29 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7ABKul24055; Fri, 10 Aug 2001 13:20:56 +0200 Date: Fri, 10 Aug 2001 13:20:56 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010810132056.D23866@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Fri, Aug 10, 2001 at 01:59:59PM +1000 X-Accept-Language: de,en,fr Content-Length: 718 Lines: 17 On Fri, Aug 10, 2001 at 01:59:59PM +1000, Salisbury, Roger wrote: > how would I update /usr/bin/file ?? > ./configure spits this out > > *** Warning: the command libtool uses to detect shared libraries, > *** /usr/bin/file, produces output that libtool cannot recognize. > *** The result is that libtool may fail to recognize shared libraries > *** as such. This will affect the creation of libtool libraries that > *** depend on shared libraries, but programs linked with such libtool > *** libraries will work regardless of this problem. Nevertheless, you > *** may want to report the problem to your system manager and/or to > *** bug-libtool@gnu.org That's a libtool bug. My RH 7.0 port has the fix. Ralf From macro@ds2.pg.gda.pl Fri Aug 10 15:36:57 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA21990; Fri, 10 Aug 2001 15:36:57 +0200 (MET DST) Received-Date: Fri, 10 Aug 2001 15:36:57 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd021988; Fri Aug 10 15:36:51 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA07315; Fri, 10 Aug 2001 15:37:58 +0200 (MET DST) Date: Fri, 10 Aug 2001 15:37:58 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010810132056.D23866@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 492 Lines: 12 On Fri, 10 Aug 2001, Ralf Baechle wrote: > That's a libtool bug. My RH 7.0 port has the fix. Libtool doesn't really need the file program for decent shared library systems. Linux/ELF is one of them and the current CVS version of libtool shouldn't depend on file for MIPS/Linux anymore. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Fri Aug 10 16:52:06 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA22361; Fri, 10 Aug 2001 16:52:06 +0200 (MET DST) Received-Date: Fri, 10 Aug 2001 16:52:06 +0200 (MET DST) Received: from u-65-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.65), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd022359; Fri Aug 10 16:51:59 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7AEnjo24938; Fri, 10 Aug 2001 16:49:45 +0200 Date: Fri, 10 Aug 2001 16:49:45 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010810164945.B24889@bacchus.dhis.org> References: <20010810132056.D23866@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Fri, Aug 10, 2001 at 03:37:58PM +0200 X-Accept-Language: de,en,fr Content-Length: 472 Lines: 13 On Fri, Aug 10, 2001 at 03:37:58PM +0200, Maciej W. Rozycki wrote: > Libtool doesn't really need the file program for decent shared library > systems. Linux/ELF is one of them and the current CVS version of libtool > shouldn't depend on file for MIPS/Linux anymore. We're talking about old code here. The fact that each package based on libtool is carrying it's own copy of libtool around doesn't exactly help to eleminate old libtool copies quickly either. Ralf From macro@ds2.pg.gda.pl Mon Aug 13 13:31:37 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA17462; Mon, 13 Aug 2001 13:31:37 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 13:31:37 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd017460; Mon Aug 13 13:31:26 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA19681; Mon, 13 Aug 2001 13:32:19 +0200 (MET DST) Date: Mon, 13 Aug 2001 13:32:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010810164945.B24889@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 489 Lines: 13 On Fri, 10 Aug 2001, Ralf Baechle wrote: > The fact that each package based on libtool is carrying it's own copy of > libtool around doesn't exactly help to eleminate old libtool copies > quickly either. It's worth to run `libtoolize -c -f' before building any libtool-based software. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Aug 13 15:22:27 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA18877; Mon, 13 Aug 2001 15:22:27 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 15:22:27 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd018875; Mon Aug 13 15:22:23 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21183; Mon, 13 Aug 2001 15:24:25 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:24:25 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Additional DEC memory configuration macros Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1565 Lines: 39 Hi, The following patch adds a few macros for memory configuration for DECstation 5000/2x0 systems. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-dec_memory-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn02.h linux-mips-2.4.5-20010704/include/asm-mips/dec/kn02.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn02.h Wed Jun 27 22:35:33 2001 +++ linux-mips-2.4.5-20010704/include/asm-mips/dec/kn02.h Sun Aug 12 01:26:09 2001 @@ -28,6 +28,8 @@ #define KN02_RTC_BASE KSEG1ADDR(0x1fe80000) #define KN02_DZ11_BASE KSEG1ADDR(0x1fe00000) +#define KN02_CSR_BNK32M (1<<10) /* 32M stride */ + /* * Interrupt enable Bits */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn03.h linux-mips-2.4.5-20010704/include/asm-mips/dec/kn03.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/dec/kn03.h Wed Jun 27 22:35:33 2001 +++ linux-mips-2.4.5-20010704/include/asm-mips/dec/kn03.h Sun Aug 12 01:23:20 2001 @@ -24,6 +24,10 @@ */ #define KN03_IOASIC_BASE KSEG1ADDR(0x1f840000) /* I/O ASIC */ #define KN03_RTC_BASE KSEG1ADDR(0x1fa00000) /* RTC */ +#define KN03_MCR_BASE KSEG1ADDR(0x1fac0000) /* MCR */ + +#define KN03_MCR_BNK32M (1<<10) /* 32M stride */ +#define KN03_MCR_ECCEN (1<<13) /* ECC enabled */ #define KN03_IOASIC_REG(r) (KN03_IOASIC_BASE+(r)) From macro@ds2.pg.gda.pl Mon Aug 13 15:24:08 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA18920; Mon, 13 Aug 2001 15:24:08 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 15:24:08 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd018917; Mon Aug 13 15:24:03 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21203; Mon, 13 Aug 2001 15:26:24 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:26:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Export mips_machtype Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1042 Lines: 31 Hi, The following patch exports mips_machtype to modules. Please apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-machtype-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c Thu Jun 14 04:26:19 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c Sat Aug 11 21:02:38 2001 @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -40,6 +41,7 @@ extern long __strlen_user_asm(const char extern long __strnlen_user_nocheck_asm(const char *s); extern long __strnlen_user_asm(const char *s); +EXPORT_SYMBOL(mips_machtype); EXPORT_SYMBOL(EISA_bus); /* From macro@ds2.pg.gda.pl Mon Aug 13 15:37:48 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA19512; Mon, 13 Aug 2001 15:37:48 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 15:37:48 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019508; Mon Aug 13 15:37:37 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21352; Mon, 13 Aug 2001 15:38:36 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:38:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen , Keith Owens cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: Make __dbe_table available to modules Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 5854 Lines: 165 Hi, Unlike most architectures which only handle memory faults/privilege violations via __ex_table, the MIPS port allows to handle bus error exceptions via __dbe_table. Unfortunately, the latter table is not exported to modules, so if a modularized driver needs to probe the address space for a device it's out of luck. The following patch implements the kernel part of __dbe_table support. A separate patch is needed for modutils. A side effect of the patch is a fix to unhandled bus error exceptions which happen in the kernel mode. Currently they cause the faulting code to be reexecuted which results in a hang in an infinite loop. With the patch applied, the kernel's response is an "Oops" similar to the one printed when a memory fault happens. I hope it's fine 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.5-20010704-dbe-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c Fri Jun 15 04:27:07 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c Sun Aug 12 17:34:55 2001 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -254,23 +255,59 @@ search_one_table(const struct exception_ return (first == last && first->insn == value) ? first->nextinsn : 0; } -#define search_dbe_table(addr) \ - search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr)) +extern spinlock_t modlist_lock; + +static unsigned long +search_dbe_table(unsigned long addr) +{ + unsigned long ret = 0; + +#ifndef CONFIG_MODULES + /* There is only the kernel to search. */ + ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (mp->dbe_table_start == NULL || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING))) + continue; + ret = search_one_table(mp->dbe_table_start, + mp->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif +} static void default_be_board_handler(struct pt_regs *regs) { unsigned long new_epc; - unsigned long fixup = search_dbe_table(regs->cp0_epc); + unsigned long fixup; - if (fixup) { - new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); - regs->cp0_epc = new_epc; - return; + if (!user_mode(regs)) { + fixup = search_dbe_table(regs->cp0_epc); + if (fixup) { + new_epc = fixup_exception(dpf_reg, fixup, + regs->cp0_epc); + regs->cp0_epc = new_epc; + return; + } } /* * Assume it would be too dangerous to continue ... */ + printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n", + (regs->cp0_cause & 4) ? "Data" : "Instruction", + regs->cp0_epc, regs->regs[31]); + die_if_kernel("Oops", regs); force_sig(SIGBUS, current); } diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/linux/module.h linux-mips-2.4.5-20010704/include/linux/module.h --- linux-mips-2.4.5-20010704.macro/include/linux/module.h Mon Jul 16 02:13:58 2001 +++ linux-mips-2.4.5-20010704/include/linux/module.h Sun Aug 12 11:22:09 2001 @@ -75,6 +75,10 @@ struct module void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; +#ifdef __mips__ + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +#endif #ifdef __alpha__ unsigned long gp; #endif diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/kernel/module.c linux-mips-2.4.5-20010704/kernel/module.c --- linux-mips-2.4.5-20010704.macro/kernel/module.c Thu Jun 14 04:28:48 2001 +++ linux-mips-2.4.5-20010704/kernel/module.c Sun Aug 12 11:24:53 2001 @@ -36,6 +36,11 @@ extern struct module_symbol __stop___ksy extern const struct exception_table_entry __start___ex_table[]; extern const struct exception_table_entry __stop___ex_table[]; +#ifdef __mips__ +extern const struct exception_table_entry __start___dbe_table[]; +extern const struct exception_table_entry __stop___dbe_table[]; +#endif + extern const char __start___kallsyms[] __attribute__ ((weak)); extern const char __stop___kallsyms[] __attribute__ ((weak)); @@ -48,6 +53,10 @@ static struct module kernel_module = syms: __start___ksymtab, ex_table_start: __start___ex_table, ex_table_end: __stop___ex_table, +#ifdef __mips__ + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, +#endif kallsyms_start: __start___kallsyms, kallsyms_end: __stop___kallsyms, }; @@ -436,6 +445,19 @@ sys_init_module(const char *name_user, s printk(KERN_ERR "init_module: mod->ex_table_* invalid.\n"); goto err2; } +#ifdef __mips__ + if (mod->dbe_table_start > mod->dbe_table_end + || (mod->dbe_table_start && + !((unsigned long)mod->dbe_table_start >= ((unsigned long)mod + mod->size_of_struct) + && ((unsigned long)mod->dbe_table_end + < (unsigned long)mod + mod->size))) + || (((unsigned long)mod->dbe_table_start + - (unsigned long)mod->dbe_table_end) + % sizeof(struct exception_table_entry))) { + printk(KERN_ERR "init_module: mod->dbe_table_* invalid.\n"); + goto err2; + } +#endif if (mod->flags & ~MOD_AUTOCLEAN) { printk(KERN_ERR "init_module: mod->flags invalid.\n"); goto err2; From macro@ds2.pg.gda.pl Mon Aug 13 15:42:17 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA20023; Mon, 13 Aug 2001 15:42:17 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 15:42:17 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd020017; Mon Aug 13 15:42:06 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA21444; Mon, 13 Aug 2001 15:43:56 +0200 (MET DST) Date: Mon, 13 Aug 2001 15:43:56 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Keith Owens , Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] modutils 2.4.6: Make __dbe_table available to modules Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2141 Lines: 61 Hi, The following patch is needed for modutils to initialize __dbe_table table pointers appropriately for modules that want to handle bus error exceptions on MIPS. A separate patch is needed for the kernel. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + modutils-2.4.6-mips-dbe.patch diff -up --recursive --new-file modutils-2.4.6.macro/include/module.h modutils-2.4.6/include/module.h --- modutils-2.4.6.macro/include/module.h Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/include/module.h Sun Aug 12 13:16:13 2001 @@ -153,6 +153,10 @@ struct module unsigned tgt_long cleanup; unsigned tgt_long ex_table_start; unsigned tgt_long ex_table_end; +#ifdef __mips__ + unsigned tgt_long dbe_table_start; + unsigned tgt_long dbe_table_end; +#endif #ifdef __alpha__ unsigned tgt_long gp; #endif diff -up --recursive --new-file modutils-2.4.6.macro/man/init_module.2 modutils-2.4.6/man/init_module.2 --- modutils-2.4.6.macro/man/init_module.2 Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/man/init_module.2 Sun Aug 12 13:17:14 2001 @@ -39,6 +39,10 @@ struct module void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; +#ifdef __mips__ + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +#endif #ifdef __alpha__ unsigned long gp; #endif diff -up --recursive --new-file modutils-2.4.6.macro/obj/obj_mips.c modutils-2.4.6/obj/obj_mips.c --- modutils-2.4.6.macro/obj/obj_mips.c Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/obj/obj_mips.c Sun Aug 12 16:16:26 2001 @@ -217,6 +217,15 @@ arch_create_got (struct obj_file *f) int arch_init_module (struct obj_file *f, struct module *mod) { + struct obj_section *sec; + + sec = obj_find_section(f, "__dbe_table"); + if (sec) + { + mod->dbe_table_start = sec->header.sh_addr; + mod->dbe_table_end = sec->header.sh_addr + sec->header.sh_size; + } + return 1; } From kaos@ocs.com.au Mon Aug 13 16:19:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA21239; Mon, 13 Aug 2001 16:19:38 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 16:19:38 +0200 (MET DST) Received: from ppp0.ocs.com.au(203.34.97.3), claiming to be "mail.ocs.com.au" via SMTP by guadalquivir.fnet.fr, id smtpd021233; Mon Aug 13 16:19:34 2001 Received: (qmail 23285 invoked from network); 13 Aug 2001 14:19:18 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Aug 2001 14:19:18 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-reply-to: Your message of "Mon, 13 Aug 2001 15:43:56 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 00:19:17 +1000 Message-ID: <15497.997712357@ocs3.ocs-net> Content-Length: 3359 Lines: 67 On Mon, 13 Aug 2001 15:43:56 +0200 (MET DST), "Maciej W. Rozycki" wrote: > The following patch is needed for modutils to initialize __dbe_table >table pointers appropriately for modules that want to handle bus error >exceptions on MIPS. A separate patch is needed for the kernel. > >modutils-2.4.6-mips-dbe.patch >diff -up --recursive --new-file modutils-2.4.6.macro/include/module.h modutils-2.4.6/include/module.h >--- modutils-2.4.6.macro/include/module.h Fri Jan 5 01:45:19 2001 >+++ modutils-2.4.6/include/module.h Sun Aug 12 13:16:13 2001 >@@ -153,6 +153,10 @@ struct module > unsigned tgt_long cleanup; > unsigned tgt_long ex_table_start; > unsigned tgt_long ex_table_end; >+#ifdef __mips__ >+ unsigned tgt_long dbe_table_start; >+ unsigned tgt_long dbe_table_end; >+#endif > #ifdef __alpha__ > unsigned tgt_long gp; > #endif Checking dbe table is fine but where you placed the table in struct modules is wrong. You must not insert fields in the middle of struct module, it introduces version skew between kernel and user space. At the very least you have moved the can_unload which will break IPv6 plus a few other modules. I understand why you placed it before gp, it looks like the place for arch dependent code. The alpha specific data is a hangover that should never have been there. modutils 2.3.16 added the archdata_start and archdata_end fields specifically so each architecture did not have to keep adding fields and causing size mismatch between kernel and modutils. IA64 uses those fields for its unwind data, MIPS can use archdata for whatever it needs in a module. In modutils, there is an arch_archdata routine for each architecture. Most just return but obj/obj_ia64.c::arch_archdata actually does something. Copy that routine and create a structure containing two fields, the start and end of the dbe table. insmod then sets archdata_start and archdata_end to point to the structure that points to the dbe table. Do not put the dbe table directly in archdata_{start,end} in case you want to add more mips data later. In the kernel, module.c verifies that archdata_{start,end} are valid, if present. It later calls module_arch_init to handle archdata. include/asm-$(ARCH)/module.h defines macros module_map, module_unmap and module_arch_init. MIPS needs to define the last two. module_arch_init is passed the struct module so it can find the arch specific data, decode it and do what it likes with the contents. module_unmap does any arch specific cleanup, such as removing extra tables. For dbe tables, define a mips module_arch_init that validates the format of the arch specific data. Probably all you need to do is check that dbe start and end are inside the module. Unless you copy the dbe data elsewhere, module_unmap can be left as vfree. When you want to verify the dbe table, you run the module list. If archdata_end >= archdata_start+2*sizeof(struct exception_table_entry *) then archdata contains the dbe data. If dbe_table_end > dbe_table_start then run the table. Checking > ignores NULL pointers. The only other change you have to make is to init_modules(). For mips you create pointers to the kernel dbe tables and fill in archdata start and end in kernel_module. Since init_module is called before kmalloc is ready, make the kernel dbe table a static variable. From macro@ds2.pg.gda.pl Mon Aug 13 16:18:07 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA21194; Mon, 13 Aug 2001 16:18:07 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 16:18:07 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd021190; Mon Aug 13 16:17:56 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA22347; Mon, 13 Aug 2001 16:20:12 +0200 (MET DST) Date: Mon, 13 Aug 2001 16:20:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Harald Koerfgen cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: CFT: A DECstation 5000/2x0 NVRAM module driver Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 14640 Lines: 464 Hi, This is a call for testers for a DECstation 5000/2x0 NVRAM module driver. The module is a special memory board, electrically and mechanically compatible with the MS02-AA 8MB and MS02-CA 32MB DRAM memory modules as used in DECstation 5000/2x0 and DECsystem 5900 systems. It contains 1MB of SRAM backed by a lithium battery. The board used to be manufactured and sold by DEC as an NFS accelerator. Following is a patch that implements an MTD driver for the module. The driver supports any number of NVRAM boards, which means up to 14 in practice (as you need to place some real memory into the first slot). Unfortunately the firmware only initializes a single module in the last (15th) slot. Since the current version of the driver depends on the firmware to detect NVRAM boards, modules placed in other slots might get improperly detected. I'm thinking on getting rid of the dependency but as the board is completely undocumented I need to dig deeper into the firmware to find out how the boards get detected. The basic functionality is pretty much complete -- the driver registers as a MTD properly and provides functions for reading and writing. This is sufficient for upper layer drivers -- I tested the driver with the character and the block MTD drivers. I've been able to create and mount a filesystem using the latter (a patch is needed for mtdblock.c, though). The driver missess mapping support, but adding it is trivial and I'll do it in a few days. What's more important, it misses battery status and control. The generic MTD layer does not support such operations, so I need to think a bit how to implement them. The driver depends on other patches -- I've sent them to the list today. I've made all the patches available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/drivers/ms02-nv/'. The patch should be fine to apply. Comments, suggestions are welcomed. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-ms02-nv-67 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/Documentation/Configure.help linux-mips-2.4.5-20010704/Documentation/Configure.help --- linux-mips-2.4.5-20010704.macro/Documentation/Configure.help Thu Jun 14 04:25:51 2001 +++ linux-mips-2.4.5-20010704/Documentation/Configure.help Sun Aug 12 22:18:32 2001 @@ -10262,6 +10262,19 @@ CONFIG_MTD_PMC551_DEBUG only really useful if you are developing on this driver or suspect a possible hardware or driver bug. If unsure say N. +DEC MS02-NV NVRAM module support +CONFIG_MTD_MS02NV + This is a MTD driver for the DEC's MS02-type battery backed-up NVRAM + module. The module was originally meant as an NFS accelerator. Say Y + here if you have a DECstation 5000/2x0 equipped with such a module. + The driver should support the DECsystem 5900's onboard NVRAM module as + well. + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read Documentation/modules.txt. The module will be + called ms02-nv.o. + Debugging RAM test driver CONFIG_MTD_MTDRAM This enables a test MTD device driver which uses vmalloc() to diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/Config.in linux-mips-2.4.5-20010704/drivers/mtd/Config.in --- linux-mips-2.4.5-20010704.macro/drivers/mtd/Config.in Wed Jan 10 14:06:27 2001 +++ linux-mips-2.4.5-20010704/drivers/mtd/Config.in Sat Aug 11 18:22:23 2001 @@ -38,6 +38,7 @@ comment 'RAM/ROM Device Drivers' bool ' PMC551 256M DRAM Bugfix' CONFIG_MTD_PMC551_BUGFIX bool ' PMC551 Debugging' CONFIG_MTD_PMC551_DEBUG fi + dep_tristate ' DEC MS02-NV NVRAM module support' CONFIG_MTD_MS02NV $CONFIG_MTD $CONFIG_DECSTATION dep_tristate ' Debugging RAM test driver' CONFIG_MTD_MTDRAM $CONFIG_MTD if [ "$CONFIG_MTD_MTDRAM" != "n" ]; then int 'Device size in kB' CONFIG_MTDRAM_TOTAL_SIZE 4096 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/Makefile linux-mips-2.4.5-20010704/drivers/mtd/Makefile --- linux-mips-2.4.5-20010704.macro/drivers/mtd/Makefile Thu Jan 11 05:26:08 2001 +++ linux-mips-2.4.5-20010704/drivers/mtd/Makefile Sat Aug 11 18:23:46 2001 @@ -33,6 +33,7 @@ obj-$(CONFIG_MTD_DOC2001) += doc2001.o obj-$(CONFIG_MTD_DOCPROBE) += docprobe.o docecc.o obj-$(CONFIG_MTD_SLRAM) += slram.o obj-$(CONFIG_MTD_PMC551) += pmc551.o +obj-$(CONFIG_MTD_MS02NV) += ms02-nv.o obj-$(CONFIG_MTD_MTDRAM) += mtdram.o # Chip drivers diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.c linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.c --- linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.c Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.c Mon Aug 13 07:04:49 2001 @@ -0,0 +1,322 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "ms02-nv.h" + + +static char version[] __initdata = + "ms02-nv.c: v.1.0.0 13 Aug 2001 Maciej W. Rozycki.\n"; + +MODULE_AUTHOR("Maciej W. Rozycki "); +MODULE_DESCRIPTION("DEC MS02-NV NVRAM module driver"); + + +/* + * Addresses we probe for an MS02-NV at. Modules may be located + * at any 8MB boundary within a 0MB up to 112MB range or at any 32MB + * boundary within a 0MB up to 448MB range. We don't support a module + * at 0MB, though. + */ +static ulong ms02nv_addrs[] __initdata = { + 0x07000000, 0x06800000, 0x06000000, 0x05800000, 0x05000000, + 0x04800000, 0x04000000, 0x03800000, 0x03000000, 0x02800000, + 0x02000000, 0x01800000, 0x01000000, 0x00800000 +}; + +static const char ms02nv_name[] = "DEC MS02-NV NVRAM"; +static const char ms02nv_res_diag_ram[] = "Diagnostic RAM"; +static const char ms02nv_res_user_ram[] = "General-purpose RAM"; +static const char ms02nv_res_csr[] = "Control and status register"; + +static struct mtd_info *root_ms02nv_mtd; + + +static int ms02nv_read(struct mtd_info *mtd, loff_t from, + size_t len, size_t *retlen, u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (from + len > mtd->size) + return -EINVAL; + + memcpy(buf, mp->uaddr + from, len); + *retlen = len; + + return 0; +} + +static int ms02nv_write(struct mtd_info *mtd, loff_t to, + size_t len, size_t *retlen, const u_char *buf) +{ + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + if (to + len > mtd->size) + return -EINVAL; + + memcpy(mp->uaddr + to, buf, len); + *retlen = len; + + return 0; +} + + +static inline uint ms02nv_probe_one(ulong addr) +{ + ms02nv_uint *ms02nv_diagp; + ms02nv_uint *ms02nv_magicp; + uint ms02nv_diag; + uint ms02nv_magic; + size_t size; + + int err; + + /* + * The firmware writes MS02NV_ID at MS02NV_MAGIC and also + * a diagnostic status at MS02NV_DIAG. + */ + ms02nv_diagp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_DIAG)); + ms02nv_magicp = (ms02nv_uint *)(KSEG1ADDR(addr + MS02NV_MAGIC)); + err = get_dbe(ms02nv_magic, ms02nv_magicp); + if (err) + return 0; + if (ms02nv_magic != MS02NV_ID) + return 0; + + ms02nv_diag = *ms02nv_diagp; + size = (ms02nv_diag & MS02NV_DIAG_SIZE_MASK) << MS02NV_DIAG_SIZE_SHIFT; + if (size > MS02NV_CSR) + size = MS02NV_CSR; + + return size; +} + +static int __init ms02nv_init_one(ulong addr) +{ + struct mtd_info *mtd; + struct ms02nv_private *mp; + struct resource *mod_res; + struct resource *diag_res; + struct resource *user_res; + struct resource *csr_res; + ulong fixaddr; + size_t size, fixsize; + + static int version_printed; + + int ret = -ENODEV; + + /* The module decodes 8MB of address space. */ + mod_res = kmalloc(sizeof(*mod_res), GFP_KERNEL); + if (!mod_res) + return -ENOMEM; + + memset(mod_res, 0, sizeof(*mod_res)); + mod_res->name = ms02nv_name; + mod_res->start = addr; + mod_res->end = addr + MS02NV_SLOT_SIZE - 1; + mod_res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + if (request_resource(&iomem_resource, mod_res) < 0) + goto err_out_mod_res; + + size = ms02nv_probe_one(addr); + if (!size) + goto err_out_mod_res_rel; + + if (!version_printed) { + printk(KERN_INFO "%s", version); + version_printed = 1; + } + + ret = -ENOMEM; + mtd = kmalloc(sizeof(*mtd), GFP_KERNEL); + if (!mtd) + goto err_out_mod_res_rel; + memset(mtd, 0, sizeof(*mtd)); + mp = kmalloc(sizeof(*mp), GFP_KERNEL); + if (!mp) + goto err_out_mtd; + memset(mp, 0, sizeof(*mp)); + + mtd->priv = mp; + mp->resource.module = mod_res; + + /* Firmware's diagnostic NVRAM area. */ + diag_res = kmalloc(sizeof(*diag_res), GFP_KERNEL); + if (!diag_res) + goto err_out_mp; + + memset(diag_res, 0, sizeof(*diag_res)); + diag_res->name = ms02nv_res_diag_ram; + diag_res->start = addr; + diag_res->end = addr + MS02NV_RAM - 1; + diag_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, diag_res); + + mp->resource.diag_ram = diag_res; + + /* User-available general-purpose NVRAM area. */ + user_res = kmalloc(sizeof(*user_res), GFP_KERNEL); + if (!user_res) + goto err_out_diag_res; + + memset(user_res, 0, sizeof(*user_res)); + user_res->name = ms02nv_res_user_ram; + user_res->start = addr + MS02NV_RAM; + user_res->end = addr + size - 1; + user_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, user_res); + + mp->resource.user_ram = user_res; + + /* Control and status register. */ + csr_res = kmalloc(sizeof(*csr_res), GFP_KERNEL); + if (!csr_res) + goto err_out_user_res; + + memset(csr_res, 0, sizeof(*csr_res)); + csr_res->name = ms02nv_res_csr; + csr_res->start = addr + MS02NV_CSR; + csr_res->end = addr + MS02NV_CSR + 3; + csr_res->flags = IORESOURCE_BUSY; + request_resource(mod_res, csr_res); + + mp->resource.csr = csr_res; + + mp->addr = phys_to_virt(addr); + mp->size = size; + + /* + * Hide the firmware's diagnostic area. It may get destroyed + * upon a reboot. Take paging into account for mapping support. + */ + fixaddr = (addr + MS02NV_RAM + PAGE_SIZE - 1) & ~(PAGE_SIZE - 1); + fixsize = (size - (fixaddr - addr)) & ~(PAGE_SIZE - 1); + mp->uaddr = phys_to_virt(fixaddr); + + mtd->type = MTD_RAM; + mtd->flags = MTD_CAP_RAM | MTD_XIP; + mtd->size = fixsize; + mtd->name = (char *)ms02nv_name; + mtd->module = THIS_MODULE; + mtd->read = ms02nv_read; + mtd->write = ms02nv_write; + + ret = -EIO; + if (add_mtd_device(mtd)) { + printk(KERN_ERR + "ms02-nv: Unable to register MTD device, aborting!\n"); + goto err_out_csr_res; + } + + printk(KERN_INFO "mtd%d: %s at 0x%08lx, size %uMB.\n", + mtd->index, ms02nv_name, addr, size >> 20); + + mp->next = root_ms02nv_mtd; + root_ms02nv_mtd = mtd; + + return 0; + + +err_out_csr_res: + release_resource(csr_res); + kfree(csr_res); +err_out_user_res: + release_resource(user_res); + kfree(user_res); +err_out_diag_res: + release_resource(diag_res); + kfree(diag_res); +err_out_mp: + kfree(mp); +err_out_mtd: + kfree(mtd); +err_out_mod_res_rel: + release_resource(mod_res); +err_out_mod_res: + kfree(mod_res); + return ret; +} + +static void __exit ms02nv_remove_one(void) +{ + struct mtd_info *mtd = root_ms02nv_mtd; + struct ms02nv_private *mp = (struct ms02nv_private *)mtd->priv; + + root_ms02nv_mtd = mp->next; + + del_mtd_device(mtd); + + release_resource(mp->resource.csr); + kfree(mp->resource.csr); + release_resource(mp->resource.user_ram); + kfree(mp->resource.user_ram); + release_resource(mp->resource.diag_ram); + kfree(mp->resource.diag_ram); + release_resource(mp->resource.module); + kfree(mp->resource.module); + kfree(mp); + kfree(mtd); +} + + +static int __init ms02nv_init(void) +{ + volatile u32 *csr; + uint stride = 0; + int count = 0; + int i; + + switch (mips_machtype) { + case MACH_DS5000_200: + csr = (volatile u32 *)KN02_CSR_ADDR; + if (*csr & KN02_CSR_BNK32M) + stride = 2; + break; + case MACH_DS5000_2X0: + csr = (volatile u32 *)KN03_MCR_BASE; + if (*csr & KN03_MCR_BNK32M) + stride = 2; + break; + default: + return -ENODEV; + break; + } + + for (i = 0; i < (sizeof(ms02nv_addrs) / sizeof(*ms02nv_addrs)); i++) + if (!ms02nv_init_one(ms02nv_addrs[i] << stride)) + count++; + + return (count > 0) ? 0 : -ENODEV; +} + +static void __exit ms02nv_cleanup(void) +{ + while (root_ms02nv_mtd) + ms02nv_remove_one(); +} + + +module_init(ms02nv_init); +module_exit(ms02nv_cleanup); diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.h linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.h --- linux-mips-2.4.5-20010704.macro/drivers/mtd/ms02-nv.h Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.5-20010704/drivers/mtd/ms02-nv.h Sun Aug 12 20:10:10 2001 @@ -0,0 +1,43 @@ +/* + * Copyright (c) 2001 Maciej W. Rozycki + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#include +#include + +/* MS02-NV iomem register offsets. */ +#define MS02NV_CSR 0x400000 /* control & status register */ + +/* MS02-NV memory offsets. */ +#define MS02NV_DIAG 0x0003f8 /* diagnostic status */ +#define MS02NV_MAGIC 0x0003fc /* MS02-NV magic ID */ +#define MS02NV_RAM 0x000400 /* general-purpose RAM start */ + +/* MS02-NV diagnostic status constants. */ +#define MS02NV_DIAG_SIZE_MASK 0xf0 /* RAM size mask */ +#define MS02NV_DIAG_SIZE_SHIFT 0x10 /* RAM size shift (left) */ + +/* MS02-NV general constants. */ +#define MS02NV_ID 0x03021966 /* MS02-NV magic ID value */ +#define MS02NV_SLOT_SIZE 0x800000 /* size of the address space + decoded by the module */ + +typedef volatile u32 ms02nv_uint; + +struct ms02nv_private { + struct mtd_info *next; + struct { + struct resource *module; + struct resource *diag_ram; + struct resource *user_ram; + struct resource *csr; + } resource; + u_char *addr; + size_t size; + u_char *uaddr; +}; From macro@ds2.pg.gda.pl Mon Aug 13 16:47:27 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA23231; Mon, 13 Aug 2001 16:47:27 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 16:47:27 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd023229; Mon Aug 13 16:47:17 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA23031; Mon, 13 Aug 2001 16:49:22 +0200 (MET DST) Date: Mon, 13 Aug 2001 16:49:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-Reply-To: <15497.997712357@ocs3.ocs-net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1177 Lines: 28 On Tue, 14 Aug 2001, Keith Owens wrote: > Checking dbe table is fine but where you placed the table in struct > modules is wrong. You must not insert fields in the middle of struct > module, it introduces version skew between kernel and user space. At > the very least you have moved the can_unload which will break IPv6 plus > a few other modules. [...] Thanks a lot for the detailed explanation. I'll cook an improvement soon. > The only other change you have to make is to init_modules(). For mips > you create pointers to the kernel dbe tables and fill in archdata start > and end in kernel_module. Since init_module is called before kmalloc > is ready, make the kernel dbe table a static variable. __dbe_table is initialized exactly like __ex_table, i.e. it's a separate ELF section with pointers to the start and the end computed in a linker script. Thus it is fine. The table has actually been present in the kernel for quite some time already. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kaos@ocs.com.au Mon Aug 13 17:14:18 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA24384; Mon, 13 Aug 2001 17:14:18 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 17:14:18 +0200 (MET DST) Received: from ppp0.ocs.com.au(203.34.97.3), claiming to be "mail.ocs.com.au" via SMTP by guadalquivir.fnet.fr, id smtpd024382; Mon Aug 13 17:14:08 2001 Received: (qmail 23825 invoked from network); 13 Aug 2001 15:14:03 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Aug 2001 15:14:03 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] modutils 2.4.6: Make __dbe_table available to modules In-reply-to: Your message of "Mon, 13 Aug 2001 16:49:22 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 01:14:02 +1000 Message-ID: <16145.997715642@ocs3.ocs-net> Content-Length: 1421 Lines: 37 On Mon, 13 Aug 2001 16:49:22 +0200 (MET DST), "Maciej W. Rozycki" wrote: >On Tue, 14 Aug 2001, Keith Owens wrote: >> The only other change you have to make is to init_modules(). For mips >> you create pointers to the kernel dbe tables and fill in archdata start >> and end in kernel_module. Since init_module is called before kmalloc >> is ready, make the kernel dbe table a static variable. > > __dbe_table is initialized exactly like __ex_table, i.e. it's a separate >ELF section with pointers to the start and the end computed in a linker >script. Thus it is fine. The table has actually been present in the >kernel for quite some time already. You still need this: struct archdata { const struct exception_table_entry *dbe_table_start; const struct exception_table_entry *dbe_table_end; }; In init_module: #ifdef __mips__ { extern const struct exception_table_entry __start___dbe_table[]; extern const struct exception_table_entry __stop___dbe_table[]; static struct archdata archdata_mips = { __start___dbe_table, __end___dbe_table }; kernel_module.archdata_start = (char *)&archdata_mips; kernel_module.archdata_end = kernel_module.archdata_start + sizeof(archdata_mips); } #endif I really need to add an arch specific init_module routine as well, instead of conditional code in init_module, but that means changing all architectures. Not today. From ralf@dea.waldorf-gmbh.de Mon Aug 13 17:53:18 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA25976; Mon, 13 Aug 2001 17:53:18 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 17:53:18 +0200 (MET DST) Received: from u-86-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.86), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd025974; Mon Aug 13 17:53:08 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFogR02275; Mon, 13 Aug 2001 17:50:42 +0200 Date: Mon, 13 Aug 2001 17:50:42 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules Message-ID: <20010813175042.C2228@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 03:38:36PM +0200 X-Accept-Language: de,en,fr Content-Length: 1192 Lines: 28 On Mon, Aug 13, 2001 at 03:38:36PM +0200, Maciej W. Rozycki wrote: > Unlike most architectures which only handle memory faults/privilege > violations via __ex_table, the MIPS port allows to handle bus error > exceptions via __dbe_table. Unfortunately, the latter table is not > exported to modules, so if a modularized driver needs to probe the address > space for a device it's out of luck. > > The following patch implements the kernel part of __dbe_table support. A > separate patch is needed for modutils. > > A side effect of the patch is a fix to unhandled bus error exceptions > which happen in the kernel mode. Currently they cause the faulting code > to be reexecuted which results in a hang in an infinite loop. With the > patch applied, the kernel's response is an "Oops" similar to the one > printed when a memory fault happens. > > I hope it's fine to apply. Looks fine at the first view. I'll apply it but duplicate it for mips64 also. The whole mechanism has it's problems though. On the Origin certain accesses like an attempt to write to a non-existant serial interface take down the machine though. I don't have an explanation nor did Kanoj seem to. Ralf From ralf@dea.waldorf-gmbh.de Mon Aug 13 17:54:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA26010; Mon, 13 Aug 2001 17:54:38 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 17:54:38 +0200 (MET DST) Received: from u-86-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.86), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd026007; Mon Aug 13 17:54:27 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFqQW02284; Mon, 13 Aug 2001 17:52:26 +0200 Date: Mon, 13 Aug 2001 17:52:26 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010813175226.D2228@bacchus.dhis.org> References: <20010810164945.B24889@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 01:32:19PM +0200 X-Accept-Language: de,en,fr Content-Length: 441 Lines: 13 On Mon, Aug 13, 2001 at 01:32:19PM +0200, Maciej W. Rozycki wrote: > > The fact that each package based on libtool is carrying it's own copy of > > libtool around doesn't exactly help to eleminate old libtool copies > > quickly either. > > It's worth to run `libtoolize -c -f' before building any libtool-based > software. That results in build failures for a few rpms. Many packages already do that but unfortunately not all. Ralf From ralf@dea.waldorf-gmbh.de Mon Aug 13 17:55:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA26093; Mon, 13 Aug 2001 17:55:38 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 17:55:38 +0200 (MET DST) Received: from u-86-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.86), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd026090; Mon Aug 13 17:55:33 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7DFrvD02291; Mon, 13 Aug 2001 17:53:57 +0200 Date: Mon, 13 Aug 2001 17:53:57 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype Message-ID: <20010813175357.E2228@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Aug 13, 2001 at 03:26:23PM +0200 X-Accept-Language: de,en,fr Content-Length: 308 Lines: 9 On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote: > The following patch exports mips_machtype to modules. Please apply. Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To messy and requires a central authority to allocate machine types. What do you think? Ralf From macro@ds2.pg.gda.pl Mon Aug 13 18:22:48 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA28077; Mon, 13 Aug 2001 18:22:48 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 18:22:48 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd028075; Mon Aug 13 18:22:32 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24704; Mon, 13 Aug 2001 18:24:20 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:24:19 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules In-Reply-To: <20010813175042.C2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1136 Lines: 26 On Mon, 13 Aug 2001, Ralf Baechle wrote: > Looks fine at the first view. I'll apply it but duplicate it for mips64 > also. Please wait for a while, until I resolve modutils interoperability as pointed out by Keith. > The whole mechanism has it's problems though. On the Origin certain > accesses like an attempt to write to a non-existant serial interface > take down the machine though. I don't have an explanation nor did Kanoj > seem to. The MIPS architecture defines the bus error exception event for data reads and instruction fetches only. Writes are asynchronous so errors on them cannot be reported exactly -- some MIPS documentation recommends using a general-purpose interrupt line for such events. Both bus error exceptions and error interrupts are system-specific and might not work unless designed to. The Origin might be an example. Does it crash for reads/fetches from the affected address space, either? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Aug 13 18:25:58 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA28143; Mon, 13 Aug 2001 18:25:58 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 18:25:58 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd028141; Mon Aug 13 18:25:49 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24793; Mon, 13 Aug 2001 18:27:37 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:27:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: "Salisbury, Roger" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file In-Reply-To: <20010813175226.D2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 662 Lines: 17 On Mon, 13 Aug 2001, Ralf Baechle wrote: > > It's worth to run `libtoolize -c -f' before building any libtool-based > > software. > > That results in build failures for a few rpms. Many packages already do > that but unfortunately not all. Well, libtool is pretty self-contained, but you may try to regenerate scripts as well. If that fails, too, the software needs to be fixed sooner or later. Look at my packages for a number of updates in this area. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Aug 13 18:34:28 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA28691; Mon, 13 Aug 2001 18:34:28 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 18:34:28 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd028686; Mon Aug 13 18:34:25 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA24957; Mon, 13 Aug 2001 18:36:35 +0200 (MET DST) Date: Mon, 13 Aug 2001 18:36:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <20010813175357.E2228@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 951 Lines: 21 On Mon, 13 Aug 2001, Ralf Baechle wrote: > > The following patch exports mips_machtype to modules. Please apply. > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > messy and requires a central authority to allocate machine types. What > do you think? No idea at the moment. For DECs things are pretty easy. The firmware returns a unique system ID for each different kind of hardware. It can be used instead (actually mips_machtype is initialized bazed on what firmware reports). The ID is mostly useful for system-specific stuff, e.g. onboard devices that cannot be identified or probed in another way. Note that for PCI-based systems, there is usually no problem -- PCI IDs can be used instead in most cases. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From raiko@niisi.msk.ru Mon Aug 13 20:15:58 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA04643; Mon, 13 Aug 2001 20:15:58 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 20:15:58 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd004634; Mon Aug 13 20:15:43 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA05475; Mon, 13 Aug 2001 22:12:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id VAA01383; Mon, 13 Aug 2001 21:55:58 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA08024; Mon, 13 Aug 2001 22:08:59 +0400 (MSD) Message-ID: <3B781837.33B9E438@niisi.msk.ru> Date: Mon, 13 Aug 2001 22:11:03 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 413 Lines: 14 "Maciej W. Rozycki" wrote: > The MIPS architecture defines the bus error exception event for data > reads and instruction fetches only. Writes are asynchronous so errors on > them cannot be reported exactly -- some MIPS documentation recommends > using a general-purpose interrupt line for such events. > DBE is treated as ACK* on write. Some HW design manuals advise to use this fact even. Regards, Gleb. From raiko@niisi.msk.ru Mon Aug 13 20:35:48 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA06175; Mon, 13 Aug 2001 20:35:48 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 20:35:48 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd006161; Mon Aug 13 20:35:43 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id WAA05730; Mon, 13 Aug 2001 22:32:55 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id WAA01452; Mon, 13 Aug 2001 22:13:38 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id WAA08135; Mon, 13 Aug 2001 22:24:56 +0400 (MSD) Message-ID: <3B781BF5.9FF57CF8@niisi.msk.ru> Date: Mon, 13 Aug 2001 22:27:01 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 1260 Lines: 33 "Maciej W. Rozycki" wrote: > > On Mon, 13 Aug 2001, Ralf Baechle wrote: > > > > The following patch exports mips_machtype to modules. Please apply. > > > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > > messy and requires a central authority to allocate machine types. What > > do you think? > > No idea at the moment. For DECs things are pretty easy. The firmware > returns a unique system ID for each different kind of hardware. It can be > used instead (actually mips_machtype is initialized bazed on what firmware > reports). The ID is mostly useful for system-specific stuff, e.g. onboard > devices that cannot be identified or probed in another way. > > Note that for PCI-based systems, there is usually no problem -- PCI IDs > can be used instead in most cases. > How? In fact, I've got two different boards with the same Ethernet chip. Moreover, mach type shall be known as early as possible, early than pci init for sure. Just imagine, I need a way to identify PCI controller by mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I miss something in your proposal? BTW, in my Baget case, I just need a number for mach type. I can ask to change my prom in worst case. Regards, Gleb. From hkoerfg@web.de Mon Aug 13 21:35:39 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA09398; Mon, 13 Aug 2001 21:35:39 +0200 (MET DST) Received-Date: Mon, 13 Aug 2001 21:35:39 +0200 (MET DST) Received: from mailgate3.cinetic.de(212.227.116.80) via SMTP by guadalquivir.fnet.fr, id smtpd009396; Mon Aug 13 21:35:33 2001 Received: from smtp.web.de (smtp01.web.de [194.45.170.210]) by mailgate3.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id f7DJZS608675; Mon, 13 Aug 2001 21:35:29 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.2 #11) id m15WNUm-007oYqC; Mon, 13 Aug 2001 21:35 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: Ralf Baechle , "Maciej W. Rozycki" Subject: Re: [patch] linux 2.4.5: Export mips_machtype Date: Mon, 13 Aug 2001 21:39:11 +0200 X-Mailer: KMail [version 1.2] Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com References: <20010813175357.E2228@bacchus.dhis.org> In-Reply-To: <20010813175357.E2228@bacchus.dhis.org> MIME-Version: 1.0 Message-Id: <01081321391100.09809@intel> Content-Transfer-Encoding: 8bit Content-Length: 504 Lines: 12 On Monday 13 August 2001 17:53, Ralf Baechle wrote: > On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote: > > The following patch exports mips_machtype to modules. Please apply. > > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5. To > messy and requires a central authority to allocate machine types. What > do you think? Well, it doesn't neccessarily have to be called mips_machtype, but, yes, we would need something similar at least for DECstations. Harald From ralf@dea.waldorf-gmbh.de Tue Aug 14 07:28:09 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id HAA23769; Tue, 14 Aug 2001 07:28:09 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 07:28:09 +0200 (MET DST) Received: from u-197-21.karlsruhe.ipdial.viaginterkom.de(62.180.21.197), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd023767; Tue Aug 14 07:28:01 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E5Q2l05681; Tue, 14 Aug 2001 07:26:02 +0200 Date: Tue, 14 Aug 2001 07:26:02 +0200 From: Ralf Baechle To: "Salisbury, Roger" Cc: "'Maciej W. Rozycki'" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file Message-ID: <20010814072602.A5665@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roger.Salisbury@team.telstra.com on Tue, Aug 14, 2001 at 11:40:48AM +1000 X-Accept-Language: de,en,fr Content-Length: 449 Lines: 17 On Tue, Aug 14, 2001 at 11:40:48AM +1000, Salisbury, Roger wrote: > where do I get "libtoolize" GNU libtools. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) > gcc-3.0 needs rectification in [libgcc_s.so] & [libgcc.a] it seems (see > make error below!) linker problem. If you still run gcc 1.2 then your ld is probably to antique anyway. Ralf From aj@suse.de Tue Aug 14 09:19:49 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id JAA25221; Tue, 14 Aug 2001 09:19:49 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 09:19:49 +0200 (MET DST) Received: from ns.suse.de(213.95.15.193), claiming to be "Cantor.suse.de" via SMTP by guadalquivir.fnet.fr, id smtpd025217; Tue Aug 14 09:19:39 2001 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 353AF1E225; Tue, 14 Aug 2001 09:16:48 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f Sender: aj@suse.de Mail-Copies-To: never To: "Salisbury, Roger" Cc: "'Maciej W. Rozycki'" , Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: /usr/bin/file References: From: Andreas Jaeger Date: Tue, 14 Aug 2001 09:16:36 +0200 In-Reply-To: ("Salisbury, Roger"'s message of "Tue, 14 Aug 2001 11:40:48 +1000") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 788 Lines: 26 "Salisbury, Roger" writes: > where do I get "libtoolize" > > Still trying to update everything. > > binutils-2.9.5.0.37 seems ok. although runtest not found.( needs testsuite, > which needs DejaGnu from ftp ://gcc.gnu.org/pub/gcc/infrastructure BUT the > site is currently down. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) > > gcc-3.0 needs rectification in [libgcc_s.so] & [libgcc.a] it seems (see > make error below!) GCC 3.0 will not compile a correct glibc at all, wait for GCC 3.0.1 and glibc 2.2.5 and read the glibc announcements, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From ralf@dea.waldorf-gmbh.de Tue Aug 14 11:00:59 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id LAA26299; Tue, 14 Aug 2001 11:00:59 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 11:00:59 +0200 (MET DST) Received: from u-198-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.198), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd026295; Tue Aug 14 11:00:47 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E8Orm06319; Tue, 14 Aug 2001 10:24:53 +0200 Date: Tue, 14 Aug 2001 10:24:52 +0200 From: Ralf Baechle To: Dominic Sweetman Cc: Atsushi Nemoto , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising Message-ID: <20010814102452.E5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.co.jp> <15214.23110.345236.934305@gladsmuir.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15214.23110.345236.934305@gladsmuir.algor.co.uk>; from dom@algor.co.uk on Mon, Aug 06, 2001 at 09:50:14AM +0100 X-Accept-Language: de,en,fr Content-Length: 616 Lines: 17 On Mon, Aug 06, 2001 at 09:50:14AM +0100, Dominic Sweetman wrote: > > Here is an patch to fix virtual aliasing problem with SysV IPC > > shared memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > > > If D-cache is smaller than PAGE_SIZE this patch is not needed at > > all... > > More precisely, if the size of a D-cache "set" is smaller than > PAGE_SIZE. So a CPU with a 16Kbyte 4-way set-associative cache and > 4Kbyte PAGE_SIZE is safe. Or is physically indexed and physically tagged or magically deals with aliasing such as R4000 / R4400 SC and MC versions or R10000, R12000 or R14000. Ralf From ralf@dea.waldorf-gmbh.de Tue Aug 14 10:58:29 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA26244; Tue, 14 Aug 2001 10:58:29 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 10:58:29 +0200 (MET DST) Received: from u-198-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.198), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd026242; Tue Aug 14 10:58:18 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7E8nfU06453; Tue, 14 Aug 2001 10:49:41 +0200 Date: Tue, 14 Aug 2001 10:49:41 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising Message-ID: <20010814104941.F5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010806164452D.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Aug 06, 2001 at 04:44:52PM +0900 X-Accept-Language: de,en,fr Content-Length: 1204 Lines: 27 On Mon, Aug 06, 2001 at 04:44:52PM +0900, Atsushi Nemoto wrote: > Here is an patch to fix virtual aliasing problem with SysV IPC shared > memory. I tested this patch on a r4k cpu with 32Kb D-cache. > > If D-cache is smaller than PAGE_SIZE this patch is not needed at all, > but I think it is not so bad unconditionally forcing alignment to > SHMLBA. It's wasting huge amounts of address space. That can be prohibitive if you want to run something such as electric fence. Technically the worst case of any CPU that's required is 32kb on R4000 / R4400 SC and MC versions, so I don't want to go beyond that. What does this patch have to do with SysV shared mem? Shmat(2) does proper alignment checking and aligning and doesn't call arch_get_unmapped_area. We do have an alignment problem with mmap(2); somebody already has a correct patch for this already pending to be merged by Alan and Linus as it affects all architectures. I assume your patch was actually intended to fix this problem; it' doesn't correctly properly deal with anonymous mappings which have no extra alignment constraints nor correctly factor in the file offset so with just two mmap calls I can still create aliases. Ralf From macro@ds2.pg.gda.pl Tue Aug 14 19:33:58 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA03903; Tue, 14 Aug 2001 19:33:58 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 19:33:58 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd003901; Tue Aug 14 19:33:51 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA05576; Tue, 14 Aug 2001 19:34:45 +0200 (MET DST) Date: Tue, 14 Aug 2001 19:34:44 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules In-Reply-To: <3B781837.33B9E438@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 659 Lines: 17 On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > DBE is treated as ACK* on write. Some HW design manuals advise to use > this fact even. And what is the use of ACK*? Note that that the state of the CPU at the moment of a write is completely unrelated to the action that triggered the write. Therefore any reporting of a write failure is hardly useful -- possibly as a kind of an MCE only, i.e. report the event and kill the current process or panic if none. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Tue Aug 14 19:41:59 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA04005; Tue, 14 Aug 2001 19:41:59 +0200 (MET DST) Received-Date: Tue, 14 Aug 2001 19:41:59 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd003999; Tue Aug 14 19:41:52 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA05695; Tue, 14 Aug 2001 19:43:23 +0200 (MET DST) Date: Tue, 14 Aug 2001 19:43:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B781BF5.9FF57CF8@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1320 Lines: 28 On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > > Note that for PCI-based systems, there is usually no problem -- PCI IDs > > can be used instead in most cases. > > How? In fact, I've got two different boards with the same Ethernet chip. > Moreover, mach type shall be known as early as possible, early than pci > init for sure. Just imagine, I need a way to identify PCI controller by > mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I > miss something in your proposal? The PCI ID of a host bridge is usually sufficient to differentiate most systems for onboard devices that are not reported on PCI. If it is not for your one, you just fall outside of the scope of "most cases" and you need a different way to identify a system. Note I do not promote mips_machtype removal. > BTW, in my Baget case, I just need a number for mach type. I can ask to > change my prom in worst case. How do you set up mips_machtype on your system in the first place? At kernel_entry the code does not know what machine it's running on anyway, so it has to set mips_machtype based on a detection algorithm. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From nemoto@toshiba-tops.co.jp Thu Aug 16 05:00:00 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA03340; Thu, 16 Aug 2001 05:00:00 +0200 (MET DST) Received-Date: Thu, 16 Aug 2001 05:00:00 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd003338; Thu Aug 16 04:59:52 2001 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 16 Aug 2001 02:59:46 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 25ACD54C0E; Thu, 16 Aug 2001 11:59:28 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id LAA69534; Thu, 16 Aug 2001 11:59:27 +0900 (JST) To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: SysV IPC shared memory and virtual alising From: Atsushi Nemoto In-Reply-To: <20010814104941.F5928@bacchus.dhis.org> References: <20010806164452D.nemoto@toshiba-tops.co.jp> <20010814104941.F5928@bacchus.dhis.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010816120401V.nemoto@toshiba-tops.co.jp> Date: Thu, 16 Aug 2001 12:04:01 +0900 X-Dispatcher: imput version 20000228(IM140) Content-Length: 1111 Lines: 27 >>>>> On Tue, 14 Aug 2001 10:49:41 +0200, Ralf Baechle said: ralf> It's wasting huge amounts of address space. That can be ralf> prohibitive if you want to run something such as electric fence. ralf> Technically the worst case of any CPU that's required is 32kb on ralf> R4000 / R4400 SC and MC versions, so I don't want to go beyond ralf> that. Yes. My patch is wasting address space. I did not know reasonable size for alignment, so I used SHMLBA value. It may be better to calculate proper alignment size on run-time or compile-time. ralf> What does this patch have to do with SysV shared mem? Shmat(2) ralf> does proper alignment checking and aligning and doesn't call ralf> arch_get_unmapped_area. I tried with this code (Xshm extention in Xserver use shm like this) : shmid = shmget(IPC_PRIVATE, 0x1000, IPC_CREAT | 0777); data = shmat(shmid, 0, 0); data2 = shmat(shmid, 0, 0); In this case, get_unmapped_area() is called with a file structure does not have 'get_unmapped_area' operation ('shmem_file_operations') so arch_get_unmapped_area() is called. --- Atsushi Nemoto From macro@ds2.pg.gda.pl Thu Aug 16 09:54:50 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id JAA05076; Thu, 16 Aug 2001 09:54:50 +0200 (MET DST) Received-Date: Thu, 16 Aug 2001 09:54:50 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd005074; Thu Aug 16 09:54:41 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA01484; Thu, 16 Aug 2001 09:56:50 +0200 (MET DST) Date: Thu, 16 Aug 2001 09:56:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Salisbury, Roger" cc: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: RE: /usr/bin/file In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 512 Lines: 16 On Tue, 14 Aug 2001, Salisbury, Roger wrote: > where do I get "libtoolize" It's included in the libtool distribution. > glibc-2.2.3 needs gcc-3.0 it seems. (checking version of gcc... > egcs-2.91.66, bad ...*** Some critical program is missing or too old > ) Gcc 2.95.3 is fine if patched appropriately. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From zoon974@yahoo.com Thu Aug 16 10:04:20 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA05204; Thu, 16 Aug 2001 10:04:20 +0200 (MET DST) Received-Date: Thu, 16 Aug 2001 10:04:20 +0200 (MET DST) Received: from web13402.mail.yahoo.com(216.136.175.60) via SMTP by guadalquivir.fnet.fr, id smtpd005200; Thu Aug 16 10:04:19 2001 Message-ID: <20010816080404.58868.qmail@web13402.mail.yahoo.com> Received: from [194.201.166.113] by web13402.mail.yahoo.com; Thu, 16 Aug 2001 09:04:04 BST Date: Thu, 16 Aug 2001 09:04:04 +0100 (BST) From: =?iso-8859-1?q?Zoon?= Subject: Soft-Float emulation with gcc - pr3900 To: linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1185 Lines: 39 Hello, Although this message is more about gcc, I post here, since I got no answer from gcc mailing lists. I use egcs-2.91.66(Algorithmics tools) configured as a cross-compiler on a i386 host. I got the binary version, so didn't configured it myself. I'm working with a PR3900 type MIPS core. Those core don't have a Floating Point Unit, nor floating point registers. When using -msoft-float, I am supposed to use the libgcc soft floating point emulation. However, I cannot prevent gcc from using fp registers. When looking at gcc specs: $ mips-linux-gcc -dumpspecs | grep r3900 .. %{m3900:-mips1 -mcpu=r3900 -mfp32 -mgp32}... The option -mfp32 is defined as the default, which means gcc assume 32 bit fp registers are available. I am aware of two soft-float emulation libraries: Gofast and libgcc. However I can't figure out how emulation can be achieved if gcc keeps using fp registers. I must miss something about it, could someone help me with this matter ? Many thanks, Alain ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie From nemoto@toshiba-tops.co.jp Fri Aug 17 05:09:19 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA14012; Fri, 17 Aug 2001 05:09:19 +0200 (MET DST) Received-Date: Fri, 17 Aug 2001 05:09:19 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd014010; Fri Aug 17 05:09:11 2001 Received: from no.name.available by topsns.toshiba-tops.co.jp via smtpd (for [193.104.112.133]) with SMTP; 17 Aug 2001 03:09:09 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 52C1354CDB; Fri, 17 Aug 2001 12:09:01 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id MAA72165; Fri, 17 Aug 2001 12:09:01 +0900 (JST) Date: Fri, 17 Aug 2001 12:13:34 +0900 (JST) Message-Id: <20010817.121334.41627251.nemoto@toshiba-tops.co.jp> To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: patch for ide_init_hwif_ports From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Aug_17_12:13:34_2001_424)--" Content-Transfer-Encoding: 7bit Content-Length: 1684 Lines: 54 ----Next_Part(Fri_Aug_17_12:13:34_2001_424)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is 'ide_init_hwif_ports' member in ide_ops structure but currently never used. This is a patch to use this (again). --- Atsushi Nemoto ----Next_Part(Fri_Aug_17_12:13:34_2001_424)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ide.patch" diff -ur linux.sgi/arch/mips/lib/ide-std.c linux/arch/mips/lib/ide-std.c --- linux.sgi/arch/mips/lib/ide-std.c Thu Jun 17 22:25:49 1999 +++ linux/arch/mips/lib/ide-std.c Fri Aug 17 11:55:49 2001 @@ -60,6 +60,7 @@ } if (irq != NULL) *irq = 0; + hw->io_ports[IDE_IRQ_OFFSET] = 0; } static int std_ide_request_irq(unsigned int irq, diff -ur linux.sgi/include/asm-mips/ide.h linux/include/asm-mips/ide.h --- linux.sgi/include/asm-mips/ide.h Tue Apr 24 02:46:11 2001 +++ linux/include/asm-mips/ide.h Fri Aug 17 11:54:36 2001 @@ -56,21 +56,7 @@ static inline void ide_init_hwif_ports(hw_regs_t *hw, ide_ioreg_t data_port, ide_ioreg_t ctrl_port, int *irq) { - ide_ioreg_t reg = data_port; - int i; - - for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; i++) { - hw->io_ports[i] = reg; - reg += 1; - } - if (ctrl_port) { - hw->io_ports[IDE_CONTROL_OFFSET] = ctrl_port; - } else { - hw->io_ports[IDE_CONTROL_OFFSET] = hw->io_ports[IDE_DATA_OFFSET] + 0x206; - } - if (irq != NULL) - *irq = 0; - hw->io_ports[IDE_IRQ_OFFSET] = 0; + ide_ops->ide_init_hwif_ports(hw, data_port, ctrl_port, irq); } static __inline__ void ide_init_default_hwifs(void) ----Next_Part(Fri_Aug_17_12:13:34_2001_424)---- From greeen@iii.org.tw Fri Aug 17 05:34:29 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA14182; Fri, 17 Aug 2001 05:34:29 +0200 (MET DST) Received-Date: Fri, 17 Aug 2001 05:34:29 +0200 (MET DST) Received: from h116-210-243-147.iii.org.tw(210.243.147.116), claiming to be "mta0.iii.org.tw" via SMTP by guadalquivir.fnet.fr, id smtpd014180; Fri Aug 17 05:34:20 2001 Received: from [140.92.66.45] (helo=iiidns.iii.org.tw) by mta0.iii.org.tw with esmtp (Exim 3.16 #1) id 15XaOg-0005Xc-00 for linux-mips@fnet.fr; Fri, 17 Aug 2001 11:34:10 +0800 Received: from Green ([140.92.12.76]) by iiidns.iii.org.tw (8.10.2/8.10.2) with SMTP id f7H3XOP17667 for ; Fri, 17 Aug 2001 11:33:25 +0800 (CST) Message-ID: <002a01c126cd$ed335500$4c0c5c8c@trd.iii.org.tw> From: "Green" To: "MipsMailList" Subject: Betty?? Date: Fri, 17 Aug 2001 11:37:21 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C12710.FA63F7A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 1760 Lines: 51 This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C12710.FA63F7A0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I write three drivers with betty, includes touch panel, sound, power. 1. Why system will become slower when I keep enabling the SIB Module?? 2. Could I use these drivers with betty at the same time? Thanks in advance, Green. ------=_NextPart_000_0027_01C12710.FA63F7A0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I write three drivers with = betty, includes touch panel,=20 sound, power.
 
1. Why system will become = slower when I keep enabling=20 the SIB Module??
 
2. Could I use these drivers = with betty at the same=20 time?
 
Thanks in advance,
 
Green.
------=_NextPart_000_0027_01C12710.FA63F7A0-- From ralf@dea.waldorf-gmbh.de Fri Aug 17 13:51:19 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA18008; Fri, 17 Aug 2001 13:51:19 +0200 (MET DST) Received-Date: Fri, 17 Aug 2001 13:51:19 +0200 (MET DST) Received: from u-214-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.214), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd018006; Fri Aug 17 13:51:09 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f7HBmt805382; Fri, 17 Aug 2001 13:48:55 +0200 Date: Fri, 17 Aug 2001 13:48:55 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: patch for ide_init_hwif_ports Message-ID: <20010817134855.A5318@bacchus.dhis.org> References: <20010817.121334.41627251.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010817.121334.41627251.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Aug 17, 2001 at 12:13:34PM +0900 X-Accept-Language: de,en,fr Content-Length: 222 Lines: 8 On Fri, Aug 17, 2001 at 12:13:34PM +0900, Atsushi Nemoto wrote: > There is 'ide_init_hwif_ports' member in ide_ops structure but > currently never used. This is a patch to use this (again). Looks good, applied. Ralf From macro@ds2.pg.gda.pl Mon Aug 20 15:55:53 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA18748; Mon, 20 Aug 2001 15:55:53 +0200 (MET DST) Received-Date: Mon, 20 Aug 2001 15:55:53 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd018746; Mon Aug 20 15:55:41 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA11015; Mon, 20 Aug 2001 15:57:21 +0200 (MET DST) Date: Mon, 20 Aug 2001 15:57:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Keith Owens cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] linux 2.4.5: __dbe_table iteration #2 In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 19264 Lines: 543 Hi, After a bit of work, I have implemented all the suggestions. The following changes have been made to the previous version: - default_be_board_handler() in traps.c (mips) only searches __dbe_table for DBE faults and not IBE ones, - search_dbe_table() in ip2[27]-berr.c (mips64) is modified to work similarly to the traps.c (mips) one, - init_modules() now calls platform-specific arch_init_modules(), - module_arch_init() and arch_init_modules() are implemented for alpha (moving the conditional stuff from module.c), mips and mips64. The patch follows. It has been rougly tested on mips and has proved to be harmless on i386 as well. The alpha and mips64 changes have not been tested. I haven't modified DBE handlers for mips64 to make them work like the mips version since they don't return at all anyway. If we agree on the patch I'm going to submit it to mainline since it's not MIPS-specific anymore. The patch applies cleanly to 2.4.9. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-dbe-11 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c Fri Jun 15 04:27:07 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c Mon Aug 20 13:38:05 2001 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -25,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -254,23 +256,67 @@ search_one_table(const struct exception_ return (first == last && first->insn == value) ? first->nextinsn : 0; } -#define search_dbe_table(addr) \ - search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr)) +extern spinlock_t modlist_lock; + +static inline unsigned long +search_dbe_table(unsigned long addr) +{ + unsigned long ret = 0; + +#ifndef CONFIG_MODULES + /* There is only the kernel to search. */ + ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_start) || + !mp->archdata_start) + continue; + ap = (struct archdata *)(mp->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif +} static void default_be_board_handler(struct pt_regs *regs) { unsigned long new_epc; - unsigned long fixup = search_dbe_table(regs->cp0_epc); + unsigned long fixup; + int data = regs->cp0_cause & 4; - if (fixup) { - new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); - regs->cp0_epc = new_epc; - return; + if (data && !user_mode(regs)) { + fixup = search_dbe_table(regs->cp0_epc); + if (fixup) { + new_epc = fixup_exception(dpf_reg, fixup, + regs->cp0_epc); + regs->cp0_epc = new_epc; + return; + } } /* * Assume it would be too dangerous to continue ... */ + printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n", + data ? "Data" : "Instruction", + regs->cp0_epc, regs->regs[31]); + die_if_kernel("Oops", regs); force_sig(SIGBUS, current); } diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c --- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c Thu Feb 24 05:26:11 2000 +++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c Mon Aug 20 00:25:46 2001 @@ -9,6 +9,9 @@ */ #include #include +#include + +#include #include #include #include @@ -41,16 +44,42 @@ search_one_table(const struct exception_ return 0; } +extern spinlock_t modlist_lock; + static inline unsigned long search_dbe_table(unsigned long addr) { - unsigned long ret; + unsigned long ret = 0; +#ifndef CONFIG_MODULES /* There is only the kernel to search. */ ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); - if (ret) return ret; - - return 0; + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_start) || + !mp->archdata_start) + continue; + ap = (struct archdata *)(mod->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif } void do_ibe(struct pt_regs *regs) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c --- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c Sat Feb 24 05:26:18 2001 +++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c Mon Aug 20 13:39:45 2001 @@ -8,6 +8,9 @@ */ #include #include +#include + +#include #include #include #include @@ -43,16 +46,42 @@ search_one_table(const struct exception_ return 0; } +extern spinlock_t modlist_lock; + static inline unsigned long search_dbe_table(unsigned long addr) { unsigned long ret; +#ifndef CONFIG_MODULES /* There is only the kernel to search. */ ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); - if (ret) return ret; - - return 0; + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_start) || + !mp->archdata_start) + continue; + ap = (struct archdata *)(mod->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif } void do_ibe(struct pt_regs *regs) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h linux-mips-2.4.5-20010704/include/asm-alpha/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-alpha/module.h Sun Aug 19 20:07:45 2001 @@ -6,6 +6,23 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) alpha_module_init(x) +#define arch_init_modules(x) alpha_init_modules(x) + +static inline int +alpha_module_init(struct module *mod) +{ + if (!mod_bound(mod->gp - 0x8000, 0, mod)) { + printk(KERN_ERR "arch_init_module: mod->gp out of bounds.\n"); + return 1; + } + return 0; +} + +static inline void +alpha_init_modules(struct module *mod) +{ + __asm__("stq $29,%0" : "=m" (mod->gp)); +} #endif /* _ASM_ALPHA_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h linux-mips-2.4.5-20010704/include/asm-arm/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-arm/module.h Mon Aug 20 01:11:58 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_ARM_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h linux-mips-2.4.5-20010704/include/asm-cris/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h Fri Mar 9 20:34:43 2001 +++ linux-mips-2.4.5-20010704/include/asm-cris/module.h Mon Aug 20 01:12:04 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_CRIS_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h linux-mips-2.4.5-20010704/include/asm-i386/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-i386/module.h Mon Aug 20 01:12:08 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_I386_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h linux-mips-2.4.5-20010704/include/asm-ia64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h Thu Jun 14 04:28:30 2001 +++ linux-mips-2.4.5-20010704/include/asm-ia64/module.h Mon Aug 20 01:12:14 2001 @@ -14,6 +14,7 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) ia64_module_unmap(x) #define module_arch_init(x) ia64_module_init(x) +#define arch_init_modules(x) do { } while (0) /* * This must match in size and layout the data created by diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h linux-mips-2.4.5-20010704/include/asm-m68k/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-m68k/module.h Mon Aug 20 01:12:18 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_M68K_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h linux-mips-2.4.5-20010704/include/asm-mips/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-mips/module.h Mon Aug 20 00:18:19 2001 @@ -4,8 +4,61 @@ * This file contains the mips architecture specific module code. */ +#include +#include + #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) mips_module_init(x) +#define arch_init_modules(x) mips_init_modules(x) + +/* + * This must match in size and layout the data created by + * modutils/obj/obj-mips.c + */ +struct archdata { + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +}; + +static inline int +mips_module_init(struct module *mod) +{ + struct archdata *archdata; + + if (!mod_member_present(mod, archdata_start) || !mod->archdata_start) + return 0; + archdata = (struct archdata *)(mod->archdata_start); + + if (archdata->dbe_table_start > archdata->dbe_table_end || + (archdata->dbe_table_start && + !((unsigned long)archdata->dbe_table_start >= + ((unsigned long)mod + mod->size_of_struct) && + ((unsigned long)archdata->dbe_table_end < + (unsigned long)mod + mod->size))) || + (((unsigned long)archdata->dbe_table_start - + (unsigned long)archdata->dbe_table_end) % + sizeof(struct exception_table_entry))) { + printk(KERN_ERR + "arch_init_module: archdata->dbe_table_* invalid.\n"); + return 1; + } + + return 0; +} + +static inline void +mips_init_modules(struct module *mod) +{ + extern const struct exception_table_entry __start___dbe_table[]; + extern const struct exception_table_entry __stop___dbe_table[]; + static struct archdata archdata = { + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, + }; + + mod->archdata_start = (char *)&archdata; + mod->archdata_end = mod->archdata_start + sizeof(archdata); +} #endif /* _ASM_MIPS_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h linux-mips-2.4.5-20010704/include/asm-mips64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-mips64/module.h Mon Aug 20 00:18:32 2001 @@ -4,8 +4,61 @@ * This file contains the mips64 architecture specific module code. */ +#include +#include + #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) mips64_module_init(x) +#define arch_init_modules(x) mips64_init_modules(x) + +/* + * This must match in size and layout the data created by + * modutils/obj/obj-mips64.c + */ +struct archdata { + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +}; + +static inline int +mips64_module_init(struct module *mod) +{ + struct archdata *archdata; + + if (!mod_member_present(mod, archdata_start) || !mod->archdata_start) + return 0; + archdata = (struct archdata *)(mod->archdata_start); + + if (archdata->dbe_table_start > archdata->dbe_table_end || + (archdata->dbe_table_start && + !((unsigned long)archdata->dbe_table_start >= + ((unsigned long)mod + mod->size_of_struct) && + ((unsigned long)archdata->dbe_table_end < + (unsigned long)mod + mod->size))) || + (((unsigned long)archdata->dbe_table_start - + (unsigned long)archdata->dbe_table_end) % + sizeof(struct exception_table_entry))) { + printk(KERN_ERR + "arch_init_module: archdata->dbe_table_* invalid.\n"); + return 1; + } + + return 0; +} + +static inline void +mips64_init_modules(struct module *mod) +{ + extern const struct exception_table_entry __start___dbe_table[]; + extern const struct exception_table_entry __stop___dbe_table[]; + static struct archdata archdata = { + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, + }; + + mod->archdata_start = (char *)&archdata; + mod->archdata_end = mod->archdata_start + sizeof(archdata); +} #endif /* _ASM_MIPS64_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h linux-mips-2.4.5-20010704/include/asm-ppc/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h Thu Jun 14 04:28:38 2001 +++ linux-mips-2.4.5-20010704/include/asm-ppc/module.h Mon Aug 20 01:12:29 2001 @@ -10,5 +10,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_PPC_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h linux-mips-2.4.5-20010704/include/asm-s390/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-s390/module.h Mon Aug 20 01:12:37 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_S390_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h linux-mips-2.4.5-20010704/include/asm-s390x/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h Fri Mar 9 20:34:52 2001 +++ linux-mips-2.4.5-20010704/include/asm-s390x/module.h Mon Aug 20 01:12:53 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_S390_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h linux-mips-2.4.5-20010704/include/asm-sh/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sh/module.h Mon Aug 20 01:12:58 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SH_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h linux-mips-2.4.5-20010704/include/asm-sparc/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sparc/module.h Mon Aug 20 01:13:03 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SPARC_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h linux-mips-2.4.5-20010704/include/asm-sparc64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sparc64/module.h Mon Aug 20 01:13:19 2001 @@ -7,5 +7,6 @@ extern void * module_map (unsigned long size); extern void module_unmap (void *addr); #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SPARC64_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/kernel/module.c linux-mips-2.4.5-20010704/kernel/module.c --- linux-mips-2.4.5-20010704.macro/kernel/module.c Thu Jun 14 04:28:48 2001 +++ linux-mips-2.4.5-20010704/kernel/module.c Sun Aug 19 20:10:35 2001 @@ -246,9 +246,7 @@ void __init init_modules(void) { kernel_module.nsyms = __stop___ksymtab - __start___ksymtab; -#ifdef __alpha__ - __asm__("stq $29,%0" : "=m"(kernel_module.gp)); -#endif + arch_init_modules(&kernel_module); } /* @@ -440,12 +438,6 @@ sys_init_module(const char *name_user, s printk(KERN_ERR "init_module: mod->flags invalid.\n"); goto err2; } -#ifdef __alpha__ - if (!mod_bound(mod->gp - 0x8000, 0, mod)) { - printk(KERN_ERR "init_module: mod->gp out of bounds.\n"); - goto err2; - } -#endif if (mod_member_present(mod, can_unload) && mod->can_unload && !mod_bound(mod->can_unload, 0, mod)) { printk(KERN_ERR "init_module: mod->can_unload out of bounds.\n"); From macro@ds2.pg.gda.pl Mon Aug 20 16:02:23 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA18861; Mon, 20 Aug 2001 16:02:23 +0200 (MET DST) Received-Date: Mon, 20 Aug 2001 16:02:23 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd018857; Mon Aug 20 16:02:17 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA11482; Mon, 20 Aug 2001 16:04:18 +0200 (MET DST) Date: Mon, 20 Aug 2001 16:04:18 +0200 (MET DST) From: "Maciej W. Rozycki" To: Keith Owens , Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] modutils 2.4.6: __dbe_table iteration #2 In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1378 Lines: 44 Hi, Following is a modutils patch that complements __dbe_table handling for modules for mips. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + modutils-2.4.6-mips-dbe.patch diff -up --recursive --new-file modutils-2.4.6.macro/obj/obj_mips.c modutils-2.4.6/obj/obj_mips.c --- modutils-2.4.6.macro/obj/obj_mips.c Fri Jan 5 01:45:19 2001 +++ modutils-2.4.6/obj/obj_mips.c Mon Aug 20 03:47:36 2001 @@ -232,7 +232,26 @@ arch_finalize_section_address(struct obj } int -arch_archdata (struct obj_file *fin, struct obj_section *sec) +arch_archdata (struct obj_file *f, struct obj_section *archdata_sec) { + struct archdata { + unsigned tgt_long dbe_table_start; + unsigned tgt_long dbe_table_end; + } *ad; + struct obj_section *sec; + + free(archdata_sec->contents); + archdata_sec->contents = xmalloc(sizeof(struct archdata)); + memset(archdata_sec->contents, 0, sizeof(struct archdata)); + archdata_sec->header.sh_size = sizeof(struct archdata); + + ad = (struct archdata *)(archdata_sec->contents); + + sec = obj_find_section(f, "__dbe_table"); + if (sec) { + ad->dbe_table_start = sec->header.sh_addr; + ad->dbe_table_end = sec->header.sh_addr + sec->header.sh_size; + } + return 0; } From nemoto@toshiba-tops.co.jp Wed Aug 22 07:41:40 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id HAA08045; Wed, 22 Aug 2001 07:41:40 +0200 (MET DST) Received-Date: Wed, 22 Aug 2001 07:41:40 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd008043; Wed Aug 22 07:41:33 2001 Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [193.104.112.133]) with SMTP; 22 Aug 2001 05:41:31 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 30BA754C0E; Wed, 22 Aug 2001 14:41:13 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id OAA86356; Wed, 22 Aug 2001 14:41:12 +0900 (JST) Date: Wed, 22 Aug 2001 14:45:47 +0900 (JST) Message-Id: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp> To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: Magic numbers about stack layout From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Aug_22_14:45:47_2001_172)--" Content-Transfer-Encoding: 7bit Content-Length: 5896 Lines: 186 ----Next_Part(Wed_Aug_22_14:45:47_2001_172)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit There are some magic constant numbers about stack layout in thread_saved_pc() and get_wchan() function. I made a patch to eliminate these magic numbers. This patch analyzes some functions prologue codes in heuristic way at run-time. "ps -l" (and "MAGIC SYSRQ" feature) works fine with this patch. --- Atsushi Nemoto ----Next_Part(Wed_Aug_22_14:45:47_2001_172)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="get_wchan.patch" diff -ur linux.sgi/arch/mips/kernel/process.c linux/arch/mips/kernel/process.c --- linux.sgi/arch/mips/kernel/process.c Sun Aug 5 23:39:09 2001 +++ linux/arch/mips/kernel/process.c Wed Aug 22 14:14:29 2001 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -31,6 +32,7 @@ #include #include #include +#include void cpu_idle(void) { @@ -196,6 +198,59 @@ #define first_sched ((unsigned long) scheduling_functions_start_here) #define last_sched ((unsigned long) scheduling_functions_end_here) +struct mips_frame_info schedule_frame; +static struct mips_frame_info schedule_timeout_frame; +static struct mips_frame_info sleep_on_frame; +static struct mips_frame_info sleep_on_timeout_frame; +static int mips_frame_info_initialized; +static int __init get_frame_info(struct mips_frame_info *info, void *func) +{ + int i; + union mips_instruction *ip = (union mips_instruction *)func; + info->pc_offset = -1; + info->frame_offset = -1; + for (i = 0; i < 128; i++, ip++) { + /* if jal, jalr, jr, stop. */ + if (ip->j_format.opcode == jal_op || + (ip->r_format.opcode == spec_op && + (ip->r_format.func == jalr_op || + ip->r_format.func == jr_op))) + break; + if (ip->i_format.opcode == sw_op && + ip->i_format.rs == 29) { + /* sw $ra, offset($sp) */ + if (ip->i_format.rt == 31) { + if (info->pc_offset != -1) + break; + info->pc_offset = + ip->i_format.simmediate / sizeof(long); + } + /* sw $s8, offset($sp) */ + if (ip->i_format.rt == 30) { + if (info->frame_offset != -1) + break; + info->frame_offset = + ip->i_format.simmediate / sizeof(long); + } + } + } + if (info->pc_offset == -1 || info->frame_offset == -1) { + printk("Can't analize prologue code at %p\n", func); + info->pc_offset = -1; + info->frame_offset = -1; + return -1; + } + return 0; +} +void __init frame_info_init(void) +{ + mips_frame_info_initialized = + !get_frame_info(&schedule_frame, schedule) && + !get_frame_info(&schedule_timeout_frame, schedule_timeout) && + !get_frame_info(&sleep_on_frame, sleep_on) && + !get_frame_info(&sleep_on_timeout_frame, sleep_on_timeout); +} + /* get_wchan - a maintenance nightmare ... */ unsigned long get_wchan(struct task_struct *p) { @@ -204,6 +259,8 @@ if (!p || p == current || p->state == TASK_RUNNING) return 0; + if (!mips_frame_info_initialized) + return 0; pc = thread_saved_pc(&p->thread); if (pc < first_sched || pc >= last_sched) { return pc; @@ -220,23 +277,24 @@ goto schedule_timeout_caller; schedule_caller: - frame = ((unsigned long *)p->thread.reg30)[9]; - pc = ((unsigned long *)frame)[11]; + /* schedule_timeout called by interruptible_sleep_on or sleep_on */ + frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset]; + pc = ((unsigned long *)frame)[sleep_on_frame.pc_offset]; return pc; schedule_timeout_caller: /* Must be schedule_timeout ... */ - pc = ((unsigned long *)p->thread.reg30)[10]; - frame = ((unsigned long *)p->thread.reg30)[9]; + pc = ((unsigned long *)p->thread.reg30)[schedule_frame.pc_offset]; + frame = ((unsigned long *)p->thread.reg30)[schedule_frame.frame_offset]; /* The schedule_timeout frame ... */ - pc = ((unsigned long *)frame)[14]; - frame = ((unsigned long *)frame)[13]; + pc = ((unsigned long *)frame)[schedule_timeout_frame.pc_offset]; + frame = ((unsigned long *)frame)[schedule_timeout_frame.frame_offset]; if (pc >= first_sched && pc < last_sched) { /* schedule_timeout called by interruptible_sleep_on_timeout */ - pc = ((unsigned long *)frame)[11]; - frame = ((unsigned long *)frame)[10]; + pc = ((unsigned long *)frame)[sleep_on_timeout_frame.pc_offset]; + frame = ((unsigned long *)frame)[sleep_on_timeout_frame.frame_offset]; } return pc; diff -ur linux.sgi/arch/mips/kernel/setup.c linux/arch/mips/kernel/setup.c --- linux.sgi/arch/mips/kernel/setup.c Sun Aug 5 23:39:15 2001 +++ linux/arch/mips/kernel/setup.c Wed Aug 22 14:26:19 2001 @@ -518,12 +518,14 @@ void malta_setup(void); void momenco_ocelot_setup(void); void nino_setup(void); + void frame_info_init(void); unsigned long bootmap_size; unsigned long start_pfn, max_pfn, first_usable_pfn; int i; + frame_info_init(); #ifdef CONFIG_BLK_DEV_FD fd_ops = &no_fd_ops; #endif diff -ur linux.sgi/include/asm-mips/processor.h linux/include/asm-mips/processor.h --- linux.sgi/include/asm-mips/processor.h Sun Aug 5 23:41:29 2001 +++ linux/include/asm-mips/processor.h Wed Aug 22 14:14:59 2001 @@ -217,6 +217,11 @@ #define copy_segments(p, mm) do { } while(0) #define release_segments(mm) do { } while(0) +struct mips_frame_info { + int frame_offset; + int pc_offset; +}; +extern struct mips_frame_info schedule_frame; /* * Return saved PC of a blocked thread. */ @@ -228,7 +233,9 @@ if (t->reg31 == (unsigned long) ret_from_fork) return t->reg31; - return ((unsigned long *)t->reg29)[10]; + if (schedule_frame.pc_offset < 0) + return 0; + return ((unsigned long *)t->reg29)[schedule_frame.pc_offset]; } /* ----Next_Part(Wed_Aug_22_14:45:47_2001_172)---- From ralf@linux-mips.net Wed Aug 22 13:43:07 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA11848; Wed, 22 Aug 2001 13:43:07 +0200 (MET DST) Received-Date: Wed, 22 Aug 2001 13:43:07 +0200 (MET DST) Received: from u-250-21.karlsruhe.ipdial.viaginterkom.de(62.180.21.250), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd011846; Wed Aug 22 13:42:58 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7MBeHO18758; Wed, 22 Aug 2001 13:40:17 +0200 Date: Wed, 22 Aug 2001 13:40:17 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Magic numbers about stack layout Message-ID: <20010822134017.A18730@dea.linux-mips.net> References: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010822.144547.30190293.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Wed, Aug 22, 2001 at 02:45:47PM +0900 X-Accept-Language: de,en,fr Content-Length: 573 Lines: 16 On Wed, Aug 22, 2001 at 02:45:47PM +0900, Atsushi Nemoto wrote: > There are some magic constant numbers about stack layout in > thread_saved_pc() and get_wchan() function. > > I made a patch to eliminate these magic numbers. This patch analyzes > some functions prologue codes in heuristic way at run-time. "ps -l" > (and "MAGIC SYSRQ" feature) works fine with this patch. Very nice, this part of the kernel used to be rather fragile on all architectures; when wchan computation broke usually nobody complained and this looks like a major improvment! Thanks, Ralf From kaos@ocs.com.au Thu Aug 23 03:50:44 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id DAA20838; Thu, 23 Aug 2001 03:50:44 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 03:50:44 +0200 (MET DST) Received: from zok.SGI.COM(204.94.215.101) via SMTP by guadalquivir.fnet.fr, id smtpd020836; Thu Aug 23 03:50:38 2001 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7N1uba04748; Wed, 22 Aug 2001 18:56:37 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with SMTP id f7N1oEF25112889; Wed, 22 Aug 2001 18:50:14 -0700 (PDT) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06795; Thu, 23 Aug 2001 11:49:53 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 In-reply-to: Your message of "Mon, 20 Aug 2001 15:57:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Aug 2001 11:49:53 +1000 Message-ID: <19339.998531393@kao2.melbourne.sgi.com> Content-Length: 992 Lines: 25 On Mon, 20 Aug 2001 15:57:21 +0200 (MET DST), "Maciej W. Rozycki" wrote: >+ for (mp = module_list; mp != NULL; mp = mp->next) { >+ if (!mod_member_present(mp, archdata_start) || >+ !mp->archdata_start) >+ continue; >+ ap = (struct archdata *)(mp->archdata_start); The definition of struct archdata in kernel and modutils can be different, a new kernel layout with an old modutils is legal but fatal unless you code for it. The correct test for archdata is if (!mod_member_present(mp, archdata_start) || (mp->archdata_end - mp->archdata_start) <= offsetof(struct archdata, dbe_table_end)) continue; Do not use archdata unless it is at least large enough to contain dbe_table_end. That test also takes care of NULL pointers, end - start == 0 for NULL. The rest of the code looks OK, except it needs a global change of arch_init_module: to module_arch_init: to match the macro name. Do you have the corresponding modutils patch or shall I do it? From raiko@niisi.msk.ru Thu Aug 23 13:34:51 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA25437; Thu, 23 Aug 2001 13:34:51 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 13:34:51 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd025411; Thu Aug 23 13:34:45 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA19412; Thu, 23 Aug 2001 15:31:13 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA04309; Thu, 23 Aug 2001 15:08:55 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA20536; Thu, 23 Aug 2001 15:22:57 +0400 (MSD) Message-ID: <3B84E796.EF5E5F39@niisi.msk.ru> Date: Thu, 23 Aug 2001 15:23:02 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , Keith Owens , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 1356 Lines: 34 "Maciej W. Rozycki" wrote: > > On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > > > DBE is treated as ACK* on write. Some HW design manuals advise to use > > this fact even. > > And what is the use of ACK*? Acknowledge. It's used to indicate current transaction has been processed successfully. If you are interested in details, I would suggest you read a MIPS hardware manual, for example, IDT's one. The most intriguing feature is: "Write transactions terminated by BusError* do not require the assertion of Ack*. BusError* can be asserted at at any time the processor is looking for Ack* to be asserted, up to and including the cycle in which the memory system does signal Ack*." > > Note that that the state of the CPU at the moment of a write is > completely unrelated to the action that triggered the write. Therefore > any reporting of a write failure is hardly useful -- possibly as a kind of > an MCE only, i.e. report the event and kill the current process or panic > if none. I consider external signaling of write failures may be useful for kernel debugging purposes. I agree it's hard (or even impossible) to achieve proper behaviour on write failures for user space. There is a small chance to kill another process, for example, write transactions may delay due to write buffer. So, the kernel may only print something. Regards, Gleb. From raiko@niisi.msk.ru Thu Aug 23 13:44:21 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA26434; Thu, 23 Aug 2001 13:44:21 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 13:44:21 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd025538; Thu Aug 23 13:44:15 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA19507; Thu, 23 Aug 2001 15:41:13 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA04399; Thu, 23 Aug 2001 15:23:11 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id PAA20895; Thu, 23 Aug 2001 15:38:14 +0400 (MSD) Message-ID: <3B84EB2C.7643F00B@niisi.msk.ru> Date: Thu, 23 Aug 2001 15:38:20 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 1676 Lines: 41 "Maciej W. Rozycki" wrote: > > On Mon, 13 Aug 2001, Gleb O. Raiko wrote: > > > > Note that for PCI-based systems, there is usually no problem -- PCI IDs > > > can be used instead in most cases. > > > > How? In fact, I've got two different boards with the same Ethernet chip. > > Moreover, mach type shall be known as early as possible, early than pci > > init for sure. Just imagine, I need a way to identify PCI controller by > > mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I > > miss something in your proposal? > > The PCI ID of a host bridge is usually sufficient to differentiate most > systems for onboard devices that are not reported on PCI. If it is not > for your one, you just fall outside of the scope of "most cases" and you > need a different way to identify a system. Note I do not promote > mips_machtype removal. In order to read a PCI ID, you need to know how to do it. In pc world, you may rely on configuation access types, at least, ports are known. On other arches, you need to know where such "ports" are. Even if hardware supports, say, configuration type 1 accesses, developers are free to put port addresses anywhere. > > > BTW, in my Baget case, I just need a number for mach type. I can ask to > > change my prom in worst case. > > How do you set up mips_machtype on your system in the first place? At > kernel_entry the code does not know what machine it's running on anyway, > so it has to set mips_machtype based on a detection algorithm. > First, mips_machtype is accessed far later than kernel_entry is executed. Personally, I am lucky :-), I may read firmware environment variables. Regards, Gleb. From macro@ds2.pg.gda.pl Thu Aug 23 17:45:10 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA29125; Thu, 23 Aug 2001 17:45:10 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 17:45:10 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd029116; Thu Aug 23 17:45:02 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22772; Thu, 23 Aug 2001 17:46:57 +0200 (MET DST) Date: Thu, 23 Aug 2001 17:46:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Make __dbe_table available to modules In-Reply-To: <3B84E796.EF5E5F39@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2238 Lines: 42 On Thu, 23 Aug 2001, Gleb O. Raiko wrote: > Acknowledge. It's used to indicate current transaction has been > processed successfully. If you are interested in details, I would > suggest you read a MIPS hardware manual, for example, IDT's one. I see if I can find a suitable onein my archive. I have an IDT CD-ROM, but it's quite new -- dated 1997 -- and it lacks a lot of earlier stuff. There is an R5k hw manual there, though, I think. Too bad they got rid of end of line stuff -- there is only ~140MB of space consumed on the CD so there would be much room for reference docs for older parts... > The most intriguing feature is: > "Write transactions terminated by BusError* do not require the assertion > of Ack*. BusError* can be asserted at at any time the processor is > looking for Ack* to be asserted, up to and including the cycle in which > the memory system does signal Ack*." Interesting. So bus errors on write transactions seem to be somehow supported from the hardware's point of view. But software can't determine the type of a bus cycle that triggered an error. E.g. if you expect a load instruction to trigger a bus error in some cases and you indeed get one, you can't tell if the error was due to this instruction or due to a write cycle triggered by some antecedent code. I think that's the reason of the suggestion of not using this kind of reporting -- if you limit bus errors to read/fetch transactions in the ISA definition, you get rid of this ambiguity. > I consider external signaling of write failures may be useful for kernel > debugging purposes. I agree it's hard (or even impossible) to achieve > proper behaviour on write failures for user space. There is a small > chance to kill another process, for example, write transactions may > delay due to write buffer. So, the kernel may only print something. Or, more severly and importantly, a write-back cache. We provide such diagnostics but it's dubious for writes. You are right, it might be useful for debugging in some cases, though. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Aug 23 17:57:50 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA01598; Thu, 23 Aug 2001 17:57:50 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 17:57:50 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd001596; Thu Aug 23 17:57:40 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA22926; Thu, 23 Aug 2001 17:59:51 +0200 (MET DST) Date: Thu, 23 Aug 2001 17:59:51 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B84EB2C.7643F00B@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1503 Lines: 33 On Thu, 23 Aug 2001, Gleb O. Raiko wrote: > In order to read a PCI ID, you need to know how to do it. In pc world, > you may rely on configuation access types, at least, ports are known. On > other arches, you need to know where such "ports" are. Even if hardware > supports, say, configuration type 1 accesses, developers are free to put > port addresses anywhere. Yep, I see. MIPS is quite special here, because, unlike for Alphas, PowerPCs, SPARCs, etc. there is a couple of independend vendors making systems, so there is no single way of obtaining a system ID. So you need to know how to access chipset from elsewhere. > > How do you set up mips_machtype on your system in the first place? At > > kernel_entry the code does not know what machine it's running on anyway, > > so it has to set mips_machtype based on a detection algorithm. > > First, mips_machtype is accessed far later than kernel_entry is That's quite obvious -- nothing can be done in Linux earlier. ;-) But you need to initialize mips_machtype somehow. > executed. Personally, I am lucky :-), I may read firmware environment > variables. Well, other system might as well (e.g. DECstations can), but that doesn't solve the problem -- to access firmware variables you need to know which kind of firmware you are on. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Aug 23 18:51:09 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA03311; Thu, 23 Aug 2001 18:51:09 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 18:51:09 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd003305; Thu Aug 23 18:51:02 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA23857; Thu, 23 Aug 2001 18:52:45 +0200 (MET DST) Date: Thu, 23 Aug 2001 18:52:45 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Keith Owens cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 In-Reply-To: <19339.998531393@kao2.melbourne.sgi.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1803 Lines: 46 On Thu, 23 Aug 2001, Keith Owens wrote: > The definition of struct archdata in kernel and modutils can be > different, a new kernel layout with an old modutils is legal but fatal > unless you code for it. The correct test for archdata is > > if (!mod_member_present(mp, archdata_start) || > (mp->archdata_end - mp->archdata_start) <= > offsetof(struct archdata, dbe_table_end)) > continue; > > Do not use archdata unless it is at least large enough to contain > dbe_table_end. That test also takes care of NULL pointers, end - start > == 0 for NULL. Hmm, your suggested code checks if the passed struct is long enough for dbe_table_start only -- what about dbe_table_end? The following code: ap = (struct archdata *)(mod->archdata_start); if (!mod_member_present(mp, archdata_start) || (mp->archdata_end - mp->archdata_start) < offsetof(struct archdata, dbe_table_end) + sizeof(ap->dbe_table_end)) continue; should be stricter. While modutils as released won't ever pass a smaller struct, someone may modify them or use another program to invoke init_module(), so we need to protect the kernel against bogus data. > The rest of the code looks OK, except it needs a global change of > arch_init_module: to module_arch_init: to match the macro name. OK, I'll do it. It should have been done for ia64 in the first place. Or should it be changed into "_init_module" to match functions' real names? > Do you have the corresponding modutils patch or shall I do it? I've send it to you separately just after the kernel patch. Should I resend it? Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jsun@mvista.com Thu Aug 23 19:11:59 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA04395; Thu, 23 Aug 2001 19:11:59 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 19:11:59 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "hermes.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd004393; Thu Aug 23 19:11:57 2001 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7NHFfA26332; Thu, 23 Aug 2001 10:15:41 -0700 Sender: jsun@mvista.com Message-ID: <3B8537C2.E18E5125@mvista.com> Date: Thu, 23 Aug 2001 10:05:06 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: "Gleb O. Raiko" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2605 Lines: 59 "Maciej W. Rozycki" wrote: > > On Thu, 23 Aug 2001, Gleb O. Raiko wrote: > > > In order to read a PCI ID, you need to know how to do it. In pc world, > > you may rely on configuation access types, at least, ports are known. On > > other arches, you need to know where such "ports" are. Even if hardware > > supports, say, configuration type 1 accesses, developers are free to put > > port addresses anywhere. > > Yep, I see. MIPS is quite special here, because, unlike for Alphas, > PowerPCs, SPARCs, etc. there is a couple of independend vendors making > systems, so there is no single way of obtaining a system ID. So you need > to know how to access chipset from elsewhere. > > > > How do you set up mips_machtype on your system in the first place? At > > > kernel_entry the code does not know what machine it's running on anyway, > > > so it has to set mips_machtype based on a detection algorithm. > > > > First, mips_machtype is accessed far later than kernel_entry is > > That's quite obvious -- nothing can be done in Linux earlier. ;-) But > you need to initialize mips_machtype somehow. > > > executed. Personally, I am lucky :-), I may read firmware environment > > variables. > > Well, other system might as well (e.g. DECstations can), but that doesn't > solve the problem -- to access firmware variables you need to know which > kind of firmware you are on. > I talked about machine detection a while back. My idea is following: 0. all machines that are *configured* into the image will supply _detect() and _setup() functions. 1. at MIPS start up, we loop through all _detect(), which returns three values, a) run-time detection negative, b) run-time detection positive, and c) no run-time detection code, but I return positive because I am configured in. 2. the startup code resolves conflicts (which sometimes may panic); and decide on one machine. 3. then the startup code calls the right _setup() code which will set up the mach_type and other stuff. BTW, a side benenfit of doing this is that we can remove all the machine specific code in common files such as bootinfo.h, setup.c, etc, which are getting harder and harder to maintain as we are adding more and more embedded boards to the tree. If we push it to an extreme by using mechnism like do_initcalls(), we can achieve zero common source file modification when adding a new a machine. This will greatly facilitate embedded development as it allows more parallel development and allow people to maintain their own board code much easier before the code is submitted to the tree. Jun From macro@ds2.pg.gda.pl Thu Aug 23 19:29:29 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA05383; Thu, 23 Aug 2001 19:29:29 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 19:29:29 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd005381; Thu Aug 23 19:29:26 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA24561; Thu, 23 Aug 2001 19:31:46 +0200 (MET DST) Date: Thu, 23 Aug 2001 19:31:46 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B8537C2.E18E5125@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1007 Lines: 24 On Thu, 23 Aug 2001, Jun Sun wrote: > I talked about machine detection a while back. My idea is following: > > 0. all machines that are *configured* into the image will supply _detect() > and _setup() functions. > > 1. at MIPS start up, we loop through all _detect(), which returns three > values, a) run-time detection negative, b) run-time detection positive, and c) > no run-time detection code, but I return positive because I am configured in. > > 2. the startup code resolves conflicts (which sometimes may panic); and decide > on one machine. > > 3. then the startup code calls the right _setup() code which will set up > the mach_type and other stuff. It sounds reasonable. We may also check the Alpha port for solutions -- it supports multiple dissimilar systems as well. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From hiroo.hayashi@toshiba.co.jp Thu Aug 23 22:13:09 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA08439; Thu, 23 Aug 2001 22:13:09 +0200 (MET DST) Received-Date: Thu, 23 Aug 2001 22:13:09 +0200 (MET DST) Received: from inet-tsb.toshiba.co.jp(202.33.96.40) via SMTP by guadalquivir.fnet.fr, id smtpd008437; Thu Aug 23 22:12:58 2001 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id FAA14539; Fri, 24 Aug 2001 05:12:35 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id FAA10611; Fri, 24 Aug 2001 05:12:35 +0900 (JST) Received: from eecksm.sdel.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id FAA07209; Fri, 24 Aug 2001 05:12:34 +0900 (JST) Received: from HirooPC (kddlos0115.mobile.toshiba.co.jp [10.16.11.34]) by eecksm.sdel.toshiba.co.jp (Postfix) with SMTP id 848A0BAE3F; Fri, 24 Aug 2001 05:12:30 +0900 (JST) From: "Hiroo Hayashi" To: "Maciej W. Rozycki" , "Gleb O. Raiko" Cc: , Subject: bus error by write transaction (RE: [patch] linux 2.4.5: Make __dbe_table available to modules) Date: Thu, 23 Aug 2001 15:11:33 -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.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 1155 Lines: 27 Hi, > > I consider external signaling of write failures may be useful for kernel > > debugging purposes. I agree it's hard (or even impossible) to achieve > > proper behaviour on write failures for user space. There is a small > > chance to kill another process, for example, write transactions may > > delay due to write buffer. So, the kernel may only print something. > > Or, more severly and importantly, a write-back cache. We provide such > diagnostics but it's dubious for writes. You are right, it might be > useful for debugging in some cases, though. Yes, most MIPS CPU except very old one use writeback cache. Note that most MIPS documents use word 'load' and 'store' for instruction, and 'read' and 'write' for bus transaction. You have to distinguish them. On a system with writeback cache, a write bus transaction is issued when a modified cache line is replaced by a cache miss for either load instruction or store instruction. (Here I'm ignoring I/O access to make the point clear.) The data on a write bus transaction may be a data modified by a store instruction which was issued some years ago :-) What the OS can do? Hiro From kaos@ocs.com.au Fri Aug 24 01:11:28 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id BAA15117; Fri, 24 Aug 2001 01:11:28 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 01:11:28 +0200 (MET DST) Received: from ppp0.ocs.com.au(203.34.97.3), claiming to be "mail.ocs.com.au" via SMTP by guadalquivir.fnet.fr, id smtpd015115; Fri Aug 24 01:11:19 2001 Received: (qmail 24922 invoked from network); 23 Aug 2001 23:11:09 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 23 Aug 2001 23:11:09 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 In-reply-to: Your message of "Thu, 23 Aug 2001 18:52:45 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Aug 2001 09:11:09 +1000 Message-ID: <17182.998608269@ocs3.ocs-net> Content-Length: 2357 Lines: 53 On Thu, 23 Aug 2001 18:52:45 +0200 (MET DST), "Maciej W. Rozycki" wrote: >On Thu, 23 Aug 2001, Keith Owens wrote: >> The definition of struct archdata in kernel and modutils can be >> different, a new kernel layout with an old modutils is legal but fatal >> unless you code for it. The correct test for archdata is >> >> if (!mod_member_present(mp, archdata_start) || >> (mp->archdata_end - mp->archdata_start) <= >> offsetof(struct archdata, dbe_table_end)) >> continue; > Hmm, your suggested code checks if the passed struct is long enough for >dbe_table_start only -- what about dbe_table_end? The following code: If archdata_end-archdata_start <= offsetof(dbe_table_end) then archdata is too small to contain the first byte of dbe_table_end, skip the archdata. If archdata is large enough to contain the first byte of dbe_table_end, assume that it contains all of dbe_table_end. >While modutils as released won't ever pass a smaller >struct, someone may modify them or use another program to invoke >init_module(), so we need to protect the kernel against bogus data. You have to be root to call init_module() or run insmod, root can do a lot more damage than passing an invalid structure size. This type of test is not to catch malicious code, it is to detect that the user is running an old modutils with a smaller archdata than the kernel can handle. You are correct that modutils as released will never pass a smaller archdata struct for mips so strictly speaking this test is superfluous. However this type of code gets cut and pasted so I want size checking on all archdata, when it is copied the developer has to think about changing the test instead of forgetting to add a test. Your suggested code works just as well but is less readable. Go with either. >> The rest of the code looks OK, except it needs a global change of >> arch_init_module: to module_arch_init: to match the macro name. > > OK, I'll do it. It should have been done for ia64 in the first place. >Or should it be changed into "_init_module" to match functions' real >names? Leave it as module_arch_init, it tells us how the code was called. >> Do you have the corresponding modutils patch or shall I do it? > > I've send it to you separately just after the kernel patch. Should I >resend it? No thanks, I found it. From nemoto@toshiba-tops.co.jp Fri Aug 24 10:01:55 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA20083; Fri, 24 Aug 2001 10:01:55 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 10:01:55 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd020081; Fri Aug 24 10:01:52 2001 Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [193.104.112.133]) with SMTP; 24 Aug 2001 08:01:51 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 0C8B254C12; Fri, 24 Aug 2001 17:01:47 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id RAA91025; Fri, 24 Aug 2001 17:01:46 +0900 (JST) Date: Fri, 24 Aug 2001 17:06:21 +0900 (JST) Message-Id: <20010824.170621.85418510.nemoto@toshiba-tops.co.jp> To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: get_insn_opcode is broken (ll/sc emulation does not work) From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 367 Lines: 20 I found that get_insn_opcode(in traps.c) is broken. static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode) ... if (!get_user(opcode, epc)) This must be: static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode) ... if (!get_user(*opcode, epc)) Without this fix, ll/sc emulation might not work. --- Atsushi Nemoto From raiko@niisi.msk.ru Fri Aug 24 13:57:33 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA23852; Fri, 24 Aug 2001 13:57:33 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 13:57:33 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd023799; Fri Aug 24 13:57:31 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA29920; Fri, 24 Aug 2001 15:54:19 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA00514; Fri, 24 Aug 2001 15:30:14 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA20010; Fri, 24 Aug 2001 13:37:24 +0400 (MSD) Message-ID: <3B86206C.832A9801@niisi.msk.ru> Date: Fri, 24 Aug 2001 13:37:48 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Jun Sun , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 1022 Lines: 26 "Maciej W. Rozycki" wrote: > It sounds reasonable. We may also check the Alpha port for solutions -- > it supports multiple dissimilar systems as well. Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at fixed location anyway. In our case, almost every box has own location for kernel varying from 0x80000000 for brave people to 0x80100000 for people who doesn't care much about 1 MB :-). (Well, I clearly understand it's firmware requirements, not people's preferences. Almost.) Then, various binary formats of the kernel image... I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP stuff. However, I doubt whether we could support single kernel image for all MIPS boxes. MIPS is typical embedded platform, where standards are favourite because there are so many to choose from. BTW, I remember, Ralf tried to implement CPU type recognition at run-time, he dropped his efforts after he realized nobody could use this feature because boxes are so different. Regards, Gleb. From raiko@niisi.msk.ru Fri Aug 24 13:58:14 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA23881; Fri, 24 Aug 2001 13:58:14 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 13:58:14 +0200 (MET DST) Received: from UNKNOWN(193.232.173.111), claiming to be "t111.niisi.ras.ru" via SMTP by guadalquivir.fnet.fr, id smtpd023841; Fri Aug 24 13:58:08 2001 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA29917; Fri, 24 Aug 2001 15:54:18 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id PAA00515; Fri, 24 Aug 2001 15:30:15 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA20181; Fri, 24 Aug 2001 13:41:50 +0400 (MSD) Message-ID: <3B862174.435C0324@niisi.msk.ru> Date: Fri, 24 Aug 2001 13:42:12 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 348 Lines: 11 "Maciej W. Rozycki" wrote: > Well, other system might as well (e.g. DECstations can), but that doesn't > solve the problem -- to access firmware variables you need to know which > kind of firmware you are on. > No way at run-time. You have to choose the box during compilation in order to supply linker with proper load address. Regards, Gleb. From ralf@linux-mips.net Fri Aug 24 13:31:33 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA22336; Fri, 24 Aug 2001 13:31:33 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 13:31:33 +0200 (MET DST) Received: from u-138-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.138), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd022334; Fri Aug 24 13:31:24 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7OBSRo00426; Fri, 24 Aug 2001 13:28:27 +0200 Date: Fri, 24 Aug 2001 13:28:27 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: get_insn_opcode is broken (ll/sc emulation does not work) Message-ID: <20010824132827.B325@dea.linux-mips.net> References: <20010824.170621.85418510.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010824.170621.85418510.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Fri, Aug 24, 2001 at 05:06:21PM +0900 X-Accept-Language: de,en,fr Content-Length: 266 Lines: 12 On Fri, Aug 24, 2001 at 05:06:21PM +0900, Atsushi Nemoto wrote: > I found that get_insn_opcode(in traps.c) is broken. > > > static inline int get_insn_opcode(struct pt_regs *regs, unsigned int *opcode) > ... > if (!get_user(opcode, epc)) Thanks, fixed! Ralf From macro@ds2.pg.gda.pl Fri Aug 24 17:42:52 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA27908; Fri, 24 Aug 2001 17:42:52 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 17:42:52 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd027906; Fri Aug 24 17:42:46 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15682; Fri, 24 Aug 2001 17:44:09 +0200 (MET DST) Date: Fri, 24 Aug 2001 17:44:08 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Keith Owens cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 In-Reply-To: <17182.998608269@ocs3.ocs-net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 22086 Lines: 613 On Fri, 24 Aug 2001, Keith Owens wrote: > You have to be root to call init_module() or run insmod, root can do a > lot more damage than passing an invalid structure size. This type of > test is not to catch malicious code, it is to detect that the user is > running an old modutils with a smaller archdata than the kernel can > handle. I mean it as a test to catch buggy, not malicious code. For malicious code run by root there is not much to do. Besides, the code is not any longer nor slower. Adding a case-specific small constant instead of fixed one is achieved via the same processor's instructions -- only their operands differ. > You are correct that modutils as released will never pass a smaller > archdata struct for mips so strictly speaking this test is superfluous. > However this type of code gets cut and pasted so I want size checking > on all archdata, when it is copied the developer has to think about > changing the test instead of forgetting to add a test. Sure, agreed. For this reason the ia64 code need a bit of cleanup, too. > Your suggested code works just as well but is less readable. Go with > either. Ok, that's not much readable, indeed. Thus I've invented a macro. See a following patch hiding implementation details. > Leave it as module_arch_init, it tells us how the code was called. OK. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010704-dbe-13 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c --- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/traps.c Fri Jun 15 04:27:07 2001 +++ linux-mips-2.4.5-20010704/arch/mips/kernel/traps.c Fri Aug 24 00:58:00 2001 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -25,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -254,23 +256,68 @@ search_one_table(const struct exception_ return (first == last && first->insn == value) ? first->nextinsn : 0; } -#define search_dbe_table(addr) \ - search_one_table(__start___dbe_table, __stop___dbe_table - 1, (addr)) +extern spinlock_t modlist_lock; + +static inline unsigned long +search_dbe_table(unsigned long addr) +{ + unsigned long ret = 0; + +#ifndef CONFIG_MODULES + /* There is only the kernel to search. */ + ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_end) || + !mod_archdata_member_present(mp, struct archdata, + dbe_table_end)) + continue; + ap = (struct archdata *)(mp->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif +} static void default_be_board_handler(struct pt_regs *regs) { unsigned long new_epc; - unsigned long fixup = search_dbe_table(regs->cp0_epc); + unsigned long fixup; + int data = regs->cp0_cause & 4; - if (fixup) { - new_epc = fixup_exception(dpf_reg, fixup, regs->cp0_epc); - regs->cp0_epc = new_epc; - return; + if (data && !user_mode(regs)) { + fixup = search_dbe_table(regs->cp0_epc); + if (fixup) { + new_epc = fixup_exception(dpf_reg, fixup, + regs->cp0_epc); + regs->cp0_epc = new_epc; + return; + } } /* * Assume it would be too dangerous to continue ... */ + printk(KERN_ALERT "%s bus error, epc == %08lx, ra == %08lx\n", + data ? "Data" : "Instruction", + regs->cp0_epc, regs->regs[31]); + die_if_kernel("Oops", regs); force_sig(SIGBUS, current); } diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c --- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip22/ip22-berr.c Thu Feb 24 05:26:11 2000 +++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip22/ip22-berr.c Fri Aug 24 00:58:38 2001 @@ -9,6 +9,9 @@ */ #include #include +#include + +#include #include #include #include @@ -41,16 +44,43 @@ search_one_table(const struct exception_ return 0; } +extern spinlock_t modlist_lock; + static inline unsigned long search_dbe_table(unsigned long addr) { - unsigned long ret; + unsigned long ret = 0; +#ifndef CONFIG_MODULES /* There is only the kernel to search. */ ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); - if (ret) return ret; - - return 0; + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_end) || + !mod_archdata_member_present(mp, struct archdata, + dbe_table_end)) + continue; + ap = (struct archdata *)(mod->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif } void do_ibe(struct pt_regs *regs) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c --- linux-mips-2.4.5-20010704.macro/arch/mips64/sgi-ip27/ip27-berr.c Sat Feb 24 05:26:18 2001 +++ linux-mips-2.4.5-20010704/arch/mips64/sgi-ip27/ip27-berr.c Fri Aug 24 00:58:47 2001 @@ -8,6 +8,9 @@ */ #include #include +#include + +#include #include #include #include @@ -43,16 +46,43 @@ search_one_table(const struct exception_ return 0; } +extern spinlock_t modlist_lock; + static inline unsigned long search_dbe_table(unsigned long addr) { unsigned long ret; +#ifndef CONFIG_MODULES /* There is only the kernel to search. */ ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr); - if (ret) return ret; - - return 0; + return ret; +#else + unsigned long flags; + + /* The kernel is the last "module" -- no need to treat it special. */ + struct module *mp; + struct archdata *ap; + + spin_lock_irqsave(&modlist_lock, flags); + for (mp = module_list; mp != NULL; mp = mp->next) { + if (!mod_member_present(mp, archdata_end) || + !mod_archdata_member_present(mp, struct archdata, + dbe_table_end)) + continue; + ap = (struct archdata *)(mod->archdata_start); + + if (ap->dbe_table_start == NULL || + !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING))) + continue; + ret = search_one_table(ap->dbe_table_start, + ap->dbe_table_end - 1, addr); + if (ret) + break; + } + spin_unlock_irqrestore(&modlist_lock, flags); + return ret; +#endif } void do_ibe(struct pt_regs *regs) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h linux-mips-2.4.5-20010704/include/asm-alpha/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-alpha/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-alpha/module.h Fri Aug 24 00:59:47 2001 @@ -6,6 +6,23 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) alpha_module_init(x) +#define arch_init_modules(x) alpha_init_modules(x) + +static inline int +alpha_module_init(struct module *mod) +{ + if (!mod_bound(mod->gp - 0x8000, 0, mod)) { + printk(KERN_ERR "module_arch_init: mod->gp out of bounds.\n"); + return 1; + } + return 0; +} + +static inline void +alpha_init_modules(struct module *mod) +{ + __asm__("stq $29,%0" : "=m" (mod->gp)); +} #endif /* _ASM_ALPHA_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h linux-mips-2.4.5-20010704/include/asm-arm/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-arm/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-arm/module.h Mon Aug 20 01:11:58 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_ARM_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h linux-mips-2.4.5-20010704/include/asm-cris/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-cris/module.h Fri Mar 9 20:34:43 2001 +++ linux-mips-2.4.5-20010704/include/asm-cris/module.h Mon Aug 20 01:12:04 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_CRIS_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h linux-mips-2.4.5-20010704/include/asm-i386/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-i386/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-i386/module.h Mon Aug 20 01:12:08 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_I386_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h linux-mips-2.4.5-20010704/include/asm-ia64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-ia64/module.h Thu Jun 14 04:28:30 2001 +++ linux-mips-2.4.5-20010704/include/asm-ia64/module.h Fri Aug 24 01:03:17 2001 @@ -14,6 +14,7 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) ia64_module_unmap(x) #define module_arch_init(x) ia64_module_init(x) +#define ia64_module_inits(x) do { } while (0) /* * This must match in size and layout the data created by @@ -46,27 +47,27 @@ ia64_module_init(struct module *mod) if (archdata->unw_table) { - printk(KERN_ERR "arch_init_module: archdata->unw_table must be zero.\n"); + printk(KERN_ERR "module_arch_init: archdata->unw_table must be zero.\n"); return 1; } if (!mod_bound(archdata->gp, 0, mod)) { - printk(KERN_ERR "arch_init_module: archdata->gp out of bounds.\n"); + printk(KERN_ERR "module_arch_init: archdata->gp out of bounds.\n"); return 1; } if (!mod_bound(archdata->unw_start, 0, mod)) { - printk(KERN_ERR "arch_init_module: archdata->unw_start out of bounds.\n"); + printk(KERN_ERR "module_arch_init: archdata->unw_start out of bounds.\n"); return 1; } if (!mod_bound(archdata->unw_end, 0, mod)) { - printk(KERN_ERR "arch_init_module: archdata->unw_end out of bounds.\n"); + printk(KERN_ERR "module_arch_init: archdata->unw_end out of bounds.\n"); return 1; } if (!mod_bound(archdata->segment_base, 0, mod)) { - printk(KERN_ERR "arch_init_module: archdata->unw_table out of bounds.\n"); + printk(KERN_ERR "module_arch_init: archdata->unw_table out of bounds.\n"); return 1; } diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h linux-mips-2.4.5-20010704/include/asm-m68k/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-m68k/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-m68k/module.h Mon Aug 20 01:12:18 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_M68K_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h linux-mips-2.4.5-20010704/include/asm-mips/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-mips/module.h Fri Aug 24 00:54:50 2001 @@ -4,8 +4,64 @@ * This file contains the mips architecture specific module code. */ +#include +#include + #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) mips_module_init(x) +#define arch_init_modules(x) mips_init_modules(x) + +/* + * This must match in size and layout the data created by + * modutils/obj/obj-mips.c + */ +struct archdata { + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +}; + +static inline int +mips_module_init(struct module *mod) +{ + struct archdata *archdata; + + if (!mod_member_present(mod, archdata_end)) + return 0; + + archdata = (struct archdata *)(mod->archdata_start); + if (!mod_archdata_member_present(mod, struct archdata, dbe_table_end)) + return 0; + + if (archdata->dbe_table_start > archdata->dbe_table_end || + (archdata->dbe_table_start && + !((unsigned long)archdata->dbe_table_start >= + ((unsigned long)mod + mod->size_of_struct) && + ((unsigned long)archdata->dbe_table_end < + (unsigned long)mod + mod->size))) || + (((unsigned long)archdata->dbe_table_start - + (unsigned long)archdata->dbe_table_end) % + sizeof(struct exception_table_entry))) { + printk(KERN_ERR + "module_arch_init: archdata->dbe_table_* invalid.\n"); + return 1; + } + + return 0; +} + +static inline void +mips_init_modules(struct module *mod) +{ + extern const struct exception_table_entry __start___dbe_table[]; + extern const struct exception_table_entry __stop___dbe_table[]; + static struct archdata archdata = { + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, + }; + + mod->archdata_start = (char *)&archdata; + mod->archdata_end = mod->archdata_start + sizeof(archdata); +} #endif /* _ASM_MIPS_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h linux-mips-2.4.5-20010704/include/asm-mips64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips64/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-mips64/module.h Fri Aug 24 00:55:00 2001 @@ -4,8 +4,64 @@ * This file contains the mips64 architecture specific module code. */ +#include +#include + #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) -#define module_arch_init(x) (0) +#define module_arch_init(x) mips64_module_init(x) +#define arch_init_modules(x) mips64_init_modules(x) + +/* + * This must match in size and layout the data created by + * modutils/obj/obj-mips64.c + */ +struct archdata { + const struct exception_table_entry *dbe_table_start; + const struct exception_table_entry *dbe_table_end; +}; + +static inline int +mips64_module_init(struct module *mod) +{ + struct archdata *archdata; + + if (!mod_member_present(mod, archdata_end)) + return 0; + + archdata = (struct archdata *)(mod->archdata_start); + if (!mod_archdata_member_present(mod, struct archdata, dbe_table_end)) + return 0; + + if (archdata->dbe_table_start > archdata->dbe_table_end || + (archdata->dbe_table_start && + !((unsigned long)archdata->dbe_table_start >= + ((unsigned long)mod + mod->size_of_struct) && + ((unsigned long)archdata->dbe_table_end < + (unsigned long)mod + mod->size))) || + (((unsigned long)archdata->dbe_table_start - + (unsigned long)archdata->dbe_table_end) % + sizeof(struct exception_table_entry))) { + printk(KERN_ERR + "module_arch_init: archdata->dbe_table_* invalid.\n"); + return 1; + } + + return 0; +} + +static inline void +mips64_init_modules(struct module *mod) +{ + extern const struct exception_table_entry __start___dbe_table[]; + extern const struct exception_table_entry __stop___dbe_table[]; + static struct archdata archdata = { + dbe_table_start: __start___dbe_table, + dbe_table_end: __stop___dbe_table, + }; + + mod->archdata_start = (char *)&archdata; + mod->archdata_end = mod->archdata_start + sizeof(archdata); +} #endif /* _ASM_MIPS64_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h linux-mips-2.4.5-20010704/include/asm-ppc/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-ppc/module.h Thu Jun 14 04:28:38 2001 +++ linux-mips-2.4.5-20010704/include/asm-ppc/module.h Mon Aug 20 01:12:29 2001 @@ -10,5 +10,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_PPC_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h linux-mips-2.4.5-20010704/include/asm-s390/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-s390/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-s390/module.h Mon Aug 20 01:12:37 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_S390_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h linux-mips-2.4.5-20010704/include/asm-s390x/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-s390x/module.h Fri Mar 9 20:34:52 2001 +++ linux-mips-2.4.5-20010704/include/asm-s390x/module.h Mon Aug 20 01:12:53 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_S390_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h linux-mips-2.4.5-20010704/include/asm-sh/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sh/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sh/module.h Mon Aug 20 01:12:58 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SH_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h linux-mips-2.4.5-20010704/include/asm-sparc/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sparc/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sparc/module.h Mon Aug 20 01:13:03 2001 @@ -7,5 +7,6 @@ #define module_map(x) vmalloc(x) #define module_unmap(x) vfree(x) #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SPARC_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h linux-mips-2.4.5-20010704/include/asm-sparc64/module.h --- linux-mips-2.4.5-20010704.macro/include/asm-sparc64/module.h Tue Nov 28 03:59:03 2000 +++ linux-mips-2.4.5-20010704/include/asm-sparc64/module.h Mon Aug 20 01:13:19 2001 @@ -7,5 +7,6 @@ extern void * module_map (unsigned long size); extern void module_unmap (void *addr); #define module_arch_init(x) (0) +#define arch_init_modules(x) do { } while (0) #endif /* _ASM_SPARC64_MODULE_H */ diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/linux/module.h linux-mips-2.4.5-20010704/include/linux/module.h --- linux-mips-2.4.5-20010704.macro/include/linux/module.h Mon Jul 16 02:13:58 2001 +++ linux-mips-2.4.5-20010704/include/linux/module.h Fri Aug 24 00:50:22 2001 @@ -130,6 +130,16 @@ struct module_info ((unsigned long)(&((struct module *)0L)->member + 1) \ <= (mod)->size_of_struct) +/* + * Ditto for archdata. Assumes mod->archdata_start and mod->archdata_end + * are validated elsewhere. + */ +#define mod_archdata_member_present(mod, type, member) \ + (((unsigned long)(&((type *)0L)->member) + \ + sizeof(((type *)0L)->member)) <= \ + ((mod)->archdata_end - (mod)->archdata_start)) + + /* Check if an address p with number of entries n is within the body of module m */ #define mod_bound(p, n, m) ((unsigned long)(p) >= ((unsigned long)(m) + ((m)->size_of_struct)) && \ (unsigned long)((p)+(n)) <= (unsigned long)(m) + (m)->size) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/kernel/module.c linux-mips-2.4.5-20010704/kernel/module.c --- linux-mips-2.4.5-20010704.macro/kernel/module.c Thu Jun 14 04:28:48 2001 +++ linux-mips-2.4.5-20010704/kernel/module.c Sun Aug 19 20:10:35 2001 @@ -246,9 +246,7 @@ void __init init_modules(void) { kernel_module.nsyms = __stop___ksymtab - __start___ksymtab; -#ifdef __alpha__ - __asm__("stq $29,%0" : "=m"(kernel_module.gp)); -#endif + arch_init_modules(&kernel_module); } /* @@ -440,12 +438,6 @@ sys_init_module(const char *name_user, s printk(KERN_ERR "init_module: mod->flags invalid.\n"); goto err2; } -#ifdef __alpha__ - if (!mod_bound(mod->gp - 0x8000, 0, mod)) { - printk(KERN_ERR "init_module: mod->gp out of bounds.\n"); - goto err2; - } -#endif if (mod_member_present(mod, can_unload) && mod->can_unload && !mod_bound(mod->can_unload, 0, mod)) { printk(KERN_ERR "init_module: mod->can_unload out of bounds.\n"); From macro@ds2.pg.gda.pl Fri Aug 24 17:55:52 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA28513; Fri, 24 Aug 2001 17:55:52 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 17:55:52 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd028511; Fri Aug 24 17:55:47 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15866; Fri, 24 Aug 2001 17:57:59 +0200 (MET DST) Date: Fri, 24 Aug 2001 17:57:59 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: Jun Sun , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B86206C.832A9801@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2567 Lines: 56 On Fri, 24 Aug 2001, Gleb O. Raiko wrote: > Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at > fixed location anyway. I mean the way platform-specific backends get installed, not the way each of the family members get detected. The firmware is not used beyond the initial setup stage -- hardware is addressed directly at run time. > In our case, almost every box has own location for kernel varying from > 0x80000000 for brave people to 0x80100000 for people who doesn't care > much about 1 MB :-). (Well, I clearly understand it's firmware > requirements, not people's preferences. Almost.) Then, various binary > formats of the kernel image... But due to the MIPS design there MUST be RAM starting from the physical address 0x00000000 as exception vectors are installed at virtual addresses starting from 0x80000000. So except for twisted systems that only map a few kilobytes of memory at 0x00000000 (SGI systems do, I'm told) there exists an address, say 0x80100000 as you quoted or maybe a different one which yet needs to be determined, which would suit most if not all platforms. Such a kernel would not be meant to be run as the best one. It would be useful for end users to bootstrap a distribution installation at least for the workstation/server class of MIPS hardware (ditto for MIPS64), but possibly for certain dedicated one, too. Given a lot of kernel images it's not always obvious to the user which one to choose -- remember mid nineties (pre-modules) whan you had a bunch of distribution kernel images with different SCSI controllers and possibly network interfaces (think NFS install) on the i386? It wasn't nice at all... > I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP > stuff. I'm just quoting Alpha since I know it best beside i386 and MIPS. > However, I doubt whether we could support single kernel image for all > MIPS boxes. MIPS is typical embedded platform, where standards are > favourite because there are so many to choose from. We could try our best, though. > BTW, I remember, Ralf tried to implement CPU type recognition at > run-time, he dropped his efforts after he realized nobody could use this > feature because boxes are so different. I think Jun's proposal is promising -- just let each vendor provide an own function to detect own hardware. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Fri Aug 24 18:08:02 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA29125; Fri, 24 Aug 2001 18:08:02 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 18:08:02 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd029123; Fri Aug 24 18:07:54 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA16031; Fri, 24 Aug 2001 18:10:09 +0200 (MET DST) Date: Fri, 24 Aug 2001 18:10:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Gleb O. Raiko" cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype In-Reply-To: <3B862174.435C0324@niisi.msk.ru> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1192 Lines: 25 On Fri, 24 Aug 2001, Gleb O. Raiko wrote: > > Well, other system might as well (e.g. DECstations can), but that doesn't > > solve the problem -- to access firmware variables you need to know which > > kind of firmware you are on. > > No way at run-time. You have to choose the box during compilation in > order to supply linker with proper load address. Does your firmware have a fixed load or entry address? If so, it begs for a position-independent boot loader (but not PIC in the ELF sense) -- something like aboot for Alpha that can interpret ELF and optionally unzip an image beforehand (aboot can't probably execute anywhere, though, as I don't think gcc is able to emit such code). Workstation/server class firmware can usually deal with arbitrary load and entry addresses, but it requires defining an interface to pass these values to the firmware and certainly you don't have to put a kitchen sink into every piece of firmware, especially for lightweight systems. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Fri Aug 24 18:16:02 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA00783; Fri, 24 Aug 2001 18:16:02 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 18:16:02 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd000781; Fri Aug 24 18:15:51 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA16170; Fri, 24 Aug 2001 18:18:03 +0200 (MET DST) Date: Fri, 24 Aug 2001 18:18:02 +0200 (MET DST) From: "Maciej W. Rozycki" To: Hiroo Hayashi cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: bus error by write transaction (RE: [patch] linux 2.4.5: Make __dbe_table available to modules) In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1218 Lines: 29 On Thu, 23 Aug 2001, Hiroo Hayashi wrote: > Note that most MIPS documents use word 'load' and 'store' for instruction, > and 'read' and 'write' for bus transaction. You have to distinguish them. Don't I? > (Here I'm ignoring I/O access to make the point clear.) How do you define an I/O access for MIPS? > The data on a write bus transaction may be a data modified by a store > instruction which was issued some years ago :-) What the OS can do? Report it and panic. The problem with bus errors on MIPS is that one can't distinguish between errors on reads and writes. The former are exact and are not fatal -- i.e. you can terminate if there is a guilty process and try to continue; otherwise panic. The latter are always fatal as they are inexact and a panic is the most reasonable way to recover. With no way to distinguish between the two cases, it's hard to decide if to go the strict way and panic in all cases or to hope a possible failing write will not make the system inconsistent. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From jsun@mvista.com Fri Aug 24 19:30:51 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA01638; Fri, 24 Aug 2001 19:30:51 +0200 (MET DST) Received-Date: Fri, 24 Aug 2001 19:30:51 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "hermes.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd001636; Fri Aug 24 19:30:44 2001 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f7OHYBA26253; Fri, 24 Aug 2001 10:34:11 -0700 Sender: jsun@mvista.com Message-ID: <3B868D96.18520607@mvista.com> Date: Fri, 24 Aug 2001 10:23:34 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gleb O. Raiko" CC: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: Export mips_machtype References: <3B86206C.832A9801@niisi.msk.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2212 Lines: 53 "Gleb O. Raiko" wrote: > > "Maciej W. Rozycki" wrote: > > It sounds reasonable. We may also check the Alpha port for solutions -- > > it supports multiple dissimilar systems as well. > > Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at > fixed location anyway. > > In our case, almost every box has own location for kernel varying from > 0x80000000 for brave people to 0x80100000 for people who doesn't care > much about 1 MB :-). (Well, I clearly understand it's firmware > requirements, not people's preferences. Almost.) Then, various binary > formats of the kernel image... > > I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP > stuff. > > However, I doubt whether we could support single kernel image for all > MIPS boxes. MIPS is typical embedded platform, where standards are > favourite because there are so many to choose from. > No way to support all MIPS machines with a single kernel image - you have the difference of BE and LE at least. :-) Seriously, I found two cases where we do like to have one image supporting multiple boards: 1) several CPU daughter boards plugging into one base baord - in the case we really need to configure a kernel with multipe CPUs. 2) A reference design board is modified slightly and used in other products. - A typicaly change might be in interrupt routing, or some base address shift, or removing some IOs. In this case, we just need a slightly different board setuo() function for each board. I don't think it is fruitful trying to go to the extreme by having a single image serving as many boxes as possible. > BTW, I remember, Ralf tried to implement CPU type recognition at > run-time, he dropped his efforts after he realized nobody could use this > feature because boxes are so different. > CPU code is getting more crowded and uglier these days too, because more vendors are adding their own CPUs. Each CPU, in most cases, has its unique hazards, which requires a separate low-level routines. Even with the coming MIPS32 and MIPS64 standard, we cannot count on vendors have totally conforming CPUs. I think it is about time to create a CPU abstraction which allows more individualism. Jun From ralf@linux-mips.net Sun Aug 26 01:12:23 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id BAA16323; Sun, 26 Aug 2001 01:12:23 +0200 (MET DST) Received-Date: Sun, 26 Aug 2001 01:12:23 +0200 (MET DST) Received: from u-22-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.22), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd016321; Sun Aug 26 01:12:22 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7PN9X508512; Sun, 26 Aug 2001 01:09:33 +0200 Date: Sun, 26 Aug 2001 01:09:33 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Patch again ac11 Message-ID: <20010826010933.A8466@dea.linux-mips.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Accept-Language: de,en,fr Content-Length: 215 Lines: 5 For those who want to stay on the bleeding edge or maybe just want one of the features not yet merged into Linus' codebase I've uploaded a patch against 2.4.8-ac11 to oss.sgi.com:/pub/linux/mips/kernel/ac/. Ralf From ralf@linux-mips.net Sun Aug 26 02:47:43 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id CAA17331; Sun, 26 Aug 2001 02:47:43 +0200 (MET DST) Received-Date: Sun, 26 Aug 2001 02:47:43 +0200 (MET DST) Received: from u-22-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.22), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd017329; Sun Aug 26 02:47:41 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7Q0ix608943; Sun, 26 Aug 2001 02:44:59 +0200 Date: Sun, 26 Aug 2001 02:44:59 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: Patch against ac11 Message-ID: <20010826024459.A8915@dea.linux-mips.net> References: <20010826010933.A8466@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: <20010826010933.A8466@dea.linux-mips.net>; from ralf@oss.sgi.com on Sun, Aug 26, 2001 at 01:09:33AM +0200 X-Accept-Language: de,en,fr Content-Length: 488 Lines: 11 On Sun, Aug 26, 2001 at 01:09:33AM +0200, Ralf Baechle wrote: > For those who want to stay on the bleeding edge or maybe just want one of > the features not yet merged into Linus' codebase I've uploaded a patch > against 2.4.8-ac11 to oss.sgi.com:/pub/linux/mips/kernel/ac/. The patch was generated on a corrupt XFS filesystem which did a few minutes after. I'll re-create the patch once I finally fixed the fs problem and that looks tricky, IRIX keeps kernel core dumping ... Ralf From ralf@linux-mips.net Sun Aug 26 15:06:58 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA22068; Sun, 26 Aug 2001 15:06:58 +0200 (MET DST) Received-Date: Sun, 26 Aug 2001 15:06:58 +0200 (MET DST) Received: from u-168-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.168), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd022066; Sun Aug 26 15:06:48 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7QD43w15016; Sun, 26 Aug 2001 15:04:03 +0200 Date: Sun, 26 Aug 2001 15:04:03 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: Patch against ac11 Message-ID: <20010826150403.A14665@dea.linux-mips.net> References: <20010826010933.A8466@dea.linux-mips.net> <20010826024459.A8915@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: <20010826024459.A8915@dea.linux-mips.net>; from ralf@oss.sgi.com on Sun, Aug 26, 2001 at 02:44:59AM +0200 X-Accept-Language: de,en,fr Content-Length: 869 Lines: 21 On Sun, Aug 26, 2001 at 02:44:59AM +0200, Ralf Baechle wrote: > > For those who want to stay on the bleeding edge or maybe just want one of > > the features not yet merged into Linus' codebase I've uploaded a patch > > against 2.4.8-ac11 to oss.sgi.com:/pub/linux/mips/kernel/ac/. > > The patch was generated on a corrupt XFS filesystem which did a few minutes > after. I'll re-create the patch once I finally fixed the fs problem > and that looks tricky, IRIX keeps kernel core dumping ... Turned out to be more fun than I initially though, reproducably crashing IRIX and corrupting XFS at the price of just one cvs update command. The correct patch is 3829168 bytes long and has the following md5sum: 15b4d1c08d981326cf1490f35a810541 linux-2.4.8-ac11-rb1.diff.gz The patch is meant to be applied on top of the current CVS kernel, not on top of ac11. Ralf From nemoto@toshiba-tops.co.jp Mon Aug 27 03:09:24 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id DAA28875; Mon, 27 Aug 2001 03:09:24 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 03:09:24 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd028873; Mon Aug 27 03:09:13 2001 Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for [193.104.112.133]) with SMTP; 27 Aug 2001 01:09:11 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id EDBE354C12; Mon, 27 Aug 2001 10:09:03 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA99094; Mon, 27 Aug 2001 10:09:02 +0900 (JST) Date: Mon, 27 Aug 2001 10:13:40 +0900 (JST) Message-Id: <20010827.101340.74756473.nemoto@toshiba-tops.co.jp> To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: scall_o32.S in 2.4.6 (or later) From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 429 Lines: 16 After merging with 2.4.6, it seems that syscall destroy static registers. Isnt't this needed? diff -ur linux.sgi/arch/mips/kernel/scall_o32.S linux/arch/mips/kernel/scall_o32.S --- linux.sgi/arch/mips/kernel/scall_o32.S Mon Aug 27 10:03:56 2001 +++ linux/arch/mips/kernel/scall_o32.S Mon Aug 27 10:04:21 2001 @@ -88,6 +88,7 @@ move a0, zero move a1, sp + SAVE_STATIC jal do_signal b restore_all --- Atsushi Nemoto From kaos@ocs.com.au Mon Aug 27 05:09:43 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA00517; Mon, 27 Aug 2001 05:09:43 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 05:09:43 +0200 (MET DST) Received: from zok.SGI.COM(204.94.215.101) via SMTP by guadalquivir.fnet.fr, id smtpd000515; Mon Aug 27 05:09:37 2001 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.11.4/8.11.4/linux-outbound_gateway-1.0) with ESMTP id f7R3Fna17855; Sun, 26 Aug 2001 20:15:49 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.2/nodin-1.0) with SMTP id f7R39EF35577534; Sun, 26 Aug 2001 20:09:15 -0700 (PDT) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA23885; Mon, 27 Aug 2001 14:09:08 +1100 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: "Maciej W. Rozycki" cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 In-reply-to: Your message of "Fri, 24 Aug 2001 17:44:08 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2001 13:09:08 +1000 Message-ID: <21302.998881748@kao2.melbourne.sgi.com> Content-Length: 352 Lines: 7 On Fri, 24 Aug 2001 17:44:08 +0200 (MET DST), "Maciej W. Rozycki" wrote: > Ok, that's not much readable, indeed. Thus I've invented a macro. See >a following patch hiding implementation details. Patch looks good, please send it to Alan Cox. 2.4.8-ac12 introduced another case of arch specific module data, this time for PPC. From ralf@linux-mips.net Mon Aug 27 08:23:42 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id IAA03676; Mon, 27 Aug 2001 08:23:42 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 08:23:42 +0200 (MET DST) Received: from u-161-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.161), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd003674; Mon Aug 27 08:23:34 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7R6KBY02645; Mon, 27 Aug 2001 08:20:11 +0200 Date: Mon, 27 Aug 2001 08:20:11 +0200 From: Ralf Baechle To: Keith Owens Cc: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] linux 2.4.5: __dbe_table iteration #2 Message-ID: <20010827082011.A2622@dea.linux-mips.net> References: <21302.998881748@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <21302.998881748@kao2.melbourne.sgi.com>; from kaos@ocs.com.au on Mon, Aug 27, 2001 at 01:09:08PM +1000 X-Accept-Language: de,en,fr Content-Length: 306 Lines: 9 On Mon, Aug 27, 2001 at 01:09:08PM +1000, Keith Owens wrote: > Patch looks good, please send it to Alan Cox. 2.4.8-ac12 introduced > another case of arch specific module data, this time for PPC. Maciej, jfyi - yesterday I've sent a large pile of patches to Alan so the MIPS bits are already in. Ralf From ralf@linux-mips.net Mon Aug 27 08:33:22 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id IAA04650; Mon, 27 Aug 2001 08:33:22 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 08:33:22 +0200 (MET DST) Received: from u-161-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.161), claiming to be "dea.linux-mips.net" via SMTP by guadalquivir.fnet.fr, id smtpd004648; Mon Aug 27 08:33:16 2001 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.1/8.11.1) id f7R6UHo02719; Mon, 27 Aug 2001 08:30:17 +0200 Date: Mon, 27 Aug 2001 08:30:17 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: scall_o32.S in 2.4.6 (or later) Message-ID: <20010827083017.A2689@dea.linux-mips.net> References: <20010827.101340.74756473.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827.101340.74756473.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Aug 27, 2001 at 10:13:40AM +0900 X-Accept-Language: de,en,fr Content-Length: 859 Lines: 34 On Mon, Aug 27, 2001 at 10:13:40AM +0900, Atsushi Nemoto wrote: > After merging with 2.4.6, it seems that syscall destroy static > registers. Isnt't this needed? Only if you insist on keeping register contents ;-) The SAVE_STATIC was actually there, just at the wrong place, so the correct patch is below. Index: arch/mips/kernel/scall_o32.S =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/kernel/scall_o32.S,v retrieving revision 1.16 diff -u -r1.16 scall_o32.S --- arch/mips/kernel/scall_o32.S 2001/08/22 03:23:59 1.16 +++ arch/mips/kernel/scall_o32.S 2001/08/27 06:31:46 @@ -86,13 +86,13 @@ ori t0, t0, 1 mtc0 t0, CP0_STATUS + SAVE_STATIC move a0, zero move a1, sp jal do_signal b restore_all o32_reschedule: - SAVE_STATIC jal schedule b o32_ret_from_sys_call Ralf From nemoto@toshiba-tops.co.jp Mon Aug 27 10:08:11 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA06957; Mon, 27 Aug 2001 10:08:11 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 10:08:11 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd006955; Mon Aug 27 10:08:10 2001 Received: from inside-ms2.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 27 Aug 2001 08:08:08 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms2.toshiba-tops.co.jp (Postfix) with ESMTP id 508BB54C12; Mon, 27 Aug 2001 17:08:06 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id RAA99917; Mon, 27 Aug 2001 17:08:04 +0900 (JST) Date: Mon, 27 Aug 2001 17:12:41 +0900 (JST) Message-Id: <20010827.171241.71082478.nemoto@toshiba-tops.co.jp> To: linux-mips@fnet.fr, linux-mips@oss.sgi.com Cc: Ralf Baechle Subject: to_tm() function in arch/mips/kernel/time.c From: Atsushi Nemoto X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.1 (AOI) X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 470 Lines: 20 Now new function to_tm() becomes available in arch/mips/kernel/time.c, the calculation for tm_wday looks incorrect. /* Days are what is left over (+1) from all that. */ tm->tm_mday = day + 1; /* * Determine the day of week */ tm->tm_wday = (day + 3) % 7; This code say that a first day of any month is Wednesday :-) Isn't this what you expected? gday = day = tim / SECDAY; ... tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */ --- Atsushi Nemoto From hiroo.hayashi@toshiba.co.jp Mon Aug 27 18:51:18 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA12947; Mon, 27 Aug 2001 18:51:18 +0200 (MET DST) Received-Date: Mon, 27 Aug 2001 18:51:18 +0200 (MET DST) Received: from inet-tsb.toshiba.co.jp(202.33.96.40) via SMTP by guadalquivir.fnet.fr, id smtpd012945; Mon Aug 27 18:51:09 2001 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id BAA23320; Tue, 28 Aug 2001 01:50:13 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id BAA13191; Tue, 28 Aug 2001 01:50:12 +0900 (JST) Received: from eecksm.sdel.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id BAA20244; Tue, 28 Aug 2001 01:50:12 +0900 (JST) Received: from HirooPC (kddlos0144.mobile.toshiba.co.jp [10.16.11.63]) by eecksm.sdel.toshiba.co.jp (Postfix) with SMTP id 6E630BAE3F; Tue, 28 Aug 2001 01:50:08 +0900 (JST) From: "Hiroo Hayashi" To: "Maciej W. Rozycki" Cc: , Subject: RE: bus error by write transaction (RE: [patch] linux 2.4.5: Make __dbe_table available to modules) Date: Mon, 27 Aug 2001 11:49:15 -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.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 980 Lines: 30 Hi, > > Note that most MIPS documents use word 'load' and 'store' for instruction, > > and 'read' and 'write' for bus transaction. You have to distinguish them. > > Don't I? I understood that (singular) you distinguish them. I thought someone misunderstood in this thread. > > (Here I'm ignoring I/O access to make the point clear.) > > How do you define an I/O access for MIPS? uncached access. Off cource there can be exception. > > The data on a write bus transaction may be a data modified by a store > > instruction which was issued some years ago :-) What the OS can do? > > Report it and panic. I agree with you. > The problem with bus errors on MIPS is that one > can't distinguish between errors on reads and writes. But I did not understand that there is MIPS CPU which cause Bus Error Exception as a result of a bus error for a write bus transaction or a read bus transaction which caused by cache miss for a store instruction. It's messy... Hiroo