From macro@ds2.pg.gda.pl Mon Jul 2 17:05:36 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA03320; Mon, 2 Jul 2001 17:05:36 +0200 (MET DST) Received-Date: Mon, 2 Jul 2001 17:05:36 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd003308; Mon Jul 2 17:05:24 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA12148; Mon, 2 Jul 2001 17:06:44 +0200 (MET DST) Date: Mon, 2 Jul 2001 17:06:44 +0200 (MET DST) From: "Maciej W. Rozycki" To: Harald Koerfgen , Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: linux 2.4.5: A DECstation HALT interrupt handler Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 3942 Lines: 117 Hi, Following is a minimal implementation of a HALT interrupt handler for DECstations. The handler resets a system (invokes a warm restart) after the HALT button or, in case of the MAXINE, the HALT sequence of keys is pressed. The patch should be OK to apply. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010627-halt-basic-0 diff -up --recursive --new-file linux-mips-2.4.5-20010627.macro/arch/mips/dec/int-handler.S linux-mips-2.4.5-20010627/arch/mips/dec/int-handler.S --- linux-mips-2.4.5-20010627.macro/arch/mips/dec/int-handler.S Thu Jun 14 04:26:19 2001 +++ linux-mips-2.4.5-20010627/arch/mips/dec/int-handler.S Sun Jul 1 00:24:21 2001 @@ -230,14 +230,6 @@ spurious: dec_intr_fpu: PANIC("Unimplemented FPU interrupt handler") /* - * Halt interrupt - */ - EXPORT(intr_halt) -intr_halt: la k0,0xbc000000 - jr k0 - nop - -/* * Generic unimplemented interrupt routines - ivec_tbl is initialised to * point all interrupts here. The table is then filled in by machine-specific * initialisation in dec_setup(). diff -up --recursive --new-file linux-mips-2.4.5-20010627.macro/arch/mips/dec/reset.c linux-mips-2.4.5-20010627/arch/mips/dec/reset.c --- linux-mips-2.4.5-20010627.macro/arch/mips/dec/reset.c Tue Mar 28 04:26:06 2000 +++ linux-mips-2.4.5-20010627/arch/mips/dec/reset.c Sun Jul 1 00:27:53 2001 @@ -23,3 +23,7 @@ void dec_machine_power_off(void) back_to_prom(); } +void dec_intr_halt(int irq, void *dev_id, struct pt_regs *regs) +{ + dec_machine_halt(); +} diff -up --recursive --new-file linux-mips-2.4.5-20010627.macro/arch/mips/dec/setup.c linux-mips-2.4.5-20010627/arch/mips/dec/setup.c --- linux-mips-2.4.5-20010627.macro/arch/mips/dec/setup.c Tue Jun 5 04:26:20 2001 +++ linux-mips-2.4.5-20010627/arch/mips/dec/setup.c Sun Jul 1 00:32:55 2001 @@ -45,17 +45,18 @@ volatile unsigned int *imr = 0L; /* addr extern void dec_machine_restart(char *command); extern void dec_machine_halt(void); extern void dec_machine_power_off(void); +extern void dec_intr_halt(int irq, void *dev_id, struct pt_regs *regs); extern void wbflush_setup(void); extern struct rtc_ops dec_rtc_ops; -extern void intr_halt(void); - extern int setup_dec_irq(int, struct irqaction *); void (*board_time_init) (struct irqaction * irq); +static struct irqaction irq10 = {dec_intr_halt, 0, 0, "halt", NULL, NULL}; + /* * enable the periodic interrupts */ @@ -74,6 +75,14 @@ static void __init dec_time_init(struct setup_dec_irq(CLOCK, irq); } +/* + * Enable the halt interrupt. + */ +static void __init dec_halt_init(struct irqaction *irq) +{ + setup_dec_irq(HALT, irq); +} + void __init decstation_setup(void) { board_time_init = dec_time_init; @@ -311,6 +320,7 @@ void __init dec_init_kn02ba(void) cpu_mask_tbl[5] = IE_IRQ5; cpu_irq_nr[5] = FPU; + dec_halt_init(&irq10); } /* dec_init_kn02ba */ /* @@ -387,6 +397,7 @@ void __init dec_init_kn02ca(void) cpu_mask_tbl[4] = IE_IRQ5; cpu_irq_nr[4] = FPU; + dec_halt_init(&irq10); } /* dec_init_kn02ca */ /* @@ -468,4 +479,5 @@ void __init dec_init_kn03(void) cpu_mask_tbl[4] = IE_IRQ5; cpu_irq_nr[4] = FPU; + dec_halt_init(&irq10); } /* dec_init_kn03 */ diff -up --recursive --new-file linux-mips-2.4.5-20010627.macro/include/asm-mips/dec/interrupts.h linux-mips-2.4.5-20010627/include/asm-mips/dec/interrupts.h --- linux-mips-2.4.5-20010627.macro/include/asm-mips/dec/interrupts.h Sat Aug 26 04:26:45 2000 +++ linux-mips-2.4.5-20010627/include/asm-mips/dec/interrupts.h Sat Jun 2 22:09:53 2001 @@ -77,8 +77,6 @@ extern void kn02_io_int(void); extern void kn02xa_io_int(void); extern void kn03_io_int(void); -extern void intr_halt(void); - extern void asic_intr_unimplemented(void); #endif From ralf@dea.waldorf-gmbh.de Mon Jul 2 18:05:46 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA04230; Mon, 2 Jul 2001 18:05:46 +0200 (MET DST) Received-Date: Mon, 2 Jul 2001 18:05:46 +0200 (MET DST) Received: from u-80-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.80), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd004228; Mon Jul 2 18:05:43 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f62G5Ew07302; Mon, 2 Jul 2001 18:05:14 +0200 Date: Mon, 2 Jul 2001 18:05:14 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Harald Koerfgen , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: linux 2.4.5: A DECstation HALT interrupt handler Message-ID: <20010702180514.A7269@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, Jul 02, 2001 at 05:06:44PM +0200 X-Accept-Language: de,en,fr Content-Length: 353 Lines: 10 On Mon, Jul 02, 2001 at 05:06:44PM +0200, Maciej W. Rozycki wrote: > Following is a minimal implementation of a HALT interrupt handler for > DECstations. The handler resets a system (invokes a warm restart) after > the HALT button or, in case of the MAXINE, the HALT sequence of keys is > pressed. The patch should be OK to apply. Applied. Ralf From greeen@iii.org.tw Tue Jul 3 08:53:25 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id IAA12829; Tue, 3 Jul 2001 08:53:25 +0200 (MET DST) Received-Date: Tue, 3 Jul 2001 08:53:25 +0200 (MET DST) Received: from h180-210-243-135.iii.org.tw(210.243.135.180), claiming to be "mta0.iii.org.tw" via SMTP by guadalquivir.fnet.fr, id smtpd012827; Tue Jul 3 08:53:19 2001 Received: from [140.92.66.45] (helo=iiidns.iii.org.tw) by mta0.iii.org.tw with esmtp (Exim 3.16 #1) id 15HK3S-0007It-00; Tue, 03 Jul 2001 14:53:02 +0800 Received: from Green ([140.92.12.76]) by iiidns.iii.org.tw (8.10.2/8.10.2) with SMTP id f636qdm11437; Tue, 3 Jul 2001 14:52:39 +0800 (CST) Message-ID: <000e01c1038d$477c8720$4c0c5c8c@trd.iii.org.tw> From: "Green" To: "LinuxEmbeddedMailList" , "LinuxKernelMailList" , "MipsMailList" Subject: RF driver!! Date: Tue, 3 Jul 2001 14:56:21 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C103D0.526ADAE0" 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: 2833 Lines: 75 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C103D0.526ADAE0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I am porting a pcmcia rf driver (which worked on kernel 2.2.12) to kernel 2.4.0 on my MIPS machine. 1. I found there are some diffenence in netdevice.h. The structure device changed to net_device. 2. And the tbusy, start, interrupt were gone with=20 the use of the netif_start_queue, netif_stop_queue, netif_wake_queue and related functions. How do I use these functions to modify the 2.2.12 rf driver to 2.4.0 ?? Thanks, Green ------=_NextPart_000_000B_01C103D0.526ADAE0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I am porting a pcmcia rf driver = (which worked on kernel=20 2.2.12)
to kernel 2.4.0 on my MIPS = machine.
 
1. I found there are some = diffenence=20 in netdevice.h.
    The = structure device=20 changed to net_device.
 
2. And the = tbusy, start,=20 interrupt were gone with
    the use of = the=20 netif_start_queue, netif_stop_queue,
   =  netif_wake_queue and=20 related functions.
 
How do I use these functions to = modify the 2.2.12 rf driver=20 to 2.4.0 ??
 
Thanks,
 
Green
------=_NextPart_000_000B_01C103D0.526ADAE0-- From raiko@niisi.msk.ru Tue Jul 3 12:14:35 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA14705; Tue, 3 Jul 2001 12:14:35 +0200 (MET DST) Received-Date: Tue, 3 Jul 2001 12:14:35 +0200 (MET DST) Received: from t111.niisi.ras.ru(193.232.173.111) via SMTP by guadalquivir.fnet.fr, id smtpd014703; Tue Jul 3 12:14:28 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 OAA23965; Tue, 3 Jul 2001 14:14:44 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA29158; Tue, 3 Jul 2001 14:10:02 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA16882; Tue, 3 Jul 2001 14:07:24 +0400 (MSD) Message-ID: <3B419D7C.93D757BB@niisi.msk.ru> Date: Tue, 03 Jul 2001 14:25:00 +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: Green CC: LinuxEmbeddedMailList , LinuxKernelMailList , MipsMailList Subject: Re: RF driver!! References: <000e01c1038d$477c8720$4c0c5c8c@trd.iii.org.tw> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Length: 233 Lines: 8 > How do I use these functions to modify the 2.2.12 rf driver to 2.4.0 > ?? Look at 'New network driver interface changes, README' and '"softnet" drivers: an attempt to clarify' postings in lkml around 2.3.43-7 age. Regards, Gleb. From ralf@dea.waldorf-gmbh.de Wed Jul 4 23:27:13 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id XAA00202; Wed, 4 Jul 2001 23:27:13 +0200 (MET DST) Received-Date: Wed, 4 Jul 2001 23:27:13 +0200 (MET DST) Received: from u-207-21.karlsruhe.ipdial.viaginterkom.de(62.180.21.207), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd000200; Wed Jul 4 23:27:04 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f64LOH507233; Wed, 4 Jul 2001 23:24:17 +0200 Date: Wed, 4 Jul 2001 23:24:17 +0200 From: Ralf Baechle To: Green Cc: LinuxEmbeddedMailList , LinuxKernelMailList , MipsMailList Subject: Re: RF driver!! Message-ID: <20010704232417.A7161@bacchus.dhis.org> References: <000e01c1038d$477c8720$4c0c5c8c@trd.iii.org.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000e01c1038d$477c8720$4c0c5c8c@trd.iii.org.tw>; from greeen@iii.org.tw on Tue, Jul 03, 2001 at 02:56:21PM +0800 X-Accept-Language: de,en,fr Content-Length: 592 Lines: 18 On Tue, Jul 03, 2001 at 02:56:21PM +0800, Green wrote: > I am porting a pcmcia rf driver (which worked on kernel 2.2.12) > to kernel 2.4.0 on my MIPS machine. > > 1. I found there are some diffenence in netdevice.h. > The structure device changed to net_device. > > 2. And the tbusy, start, interrupt were gone with > the use of the netif_start_queue, netif_stop_queue, > netif_wake_queue and related functions. > > How do I use these functions to modify the 2.2.12 rf driver to 2.4.0 ?? Checkout the netdev archives at http://oss.sgi.com/projects/netdev/archives/. Ralf From macro@ds2.pg.gda.pl Thu Jul 5 13:12:33 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA07055; Thu, 5 Jul 2001 13:12:33 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 13:12:33 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd007053; Thu Jul 5 13:12:26 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA12022; Thu, 5 Jul 2001 13:14:17 +0200 (MET DST) Date: Thu, 5 Jul 2001 13:14:16 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...) Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2965 Lines: 97 Hi, Once again a sysmips() patch. This time the exception fixup code is broken -- it never returns (well, it probably returns *somewhere* via a following fixup entry). Also for whatever reason the R3k code is missing. The following patch fixes it. While I was at it, I modified contraints a bit and replaced some of embedded "\t" chars with tabs (the code was completely unreadable before -- now it should be a bit better, as much as embedded asm can be). The R3k variant works fine for me. I was unable to thest the ll/sc one, but the semantics should be unchanged, i.e. if it worked before, so it will now. The patch should go into Linus' tree as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010627-sysmips-1 diff -up --recursive --new-file linux-mips-2.4.5-20010627.macro/arch/mips/kernel/sysmips.c linux-mips-2.4.5-20010627/arch/mips/kernel/sysmips.c --- linux-mips-2.4.5-20010627.macro/arch/mips/kernel/sysmips.c Mon Apr 9 04:25:42 2001 +++ linux-mips-2.4.5-20010627/arch/mips/kernel/sysmips.c Wed Jul 4 22:07:30 2001 @@ -75,33 +75,41 @@ sys_sysmips(int cmd, int arg1, int arg2, } case MIPS_ATOMIC_SET: { -#ifdef CONFIG_CPU_HAS_LLSC - unsigned int tmp; + unsigned int tmp1; p = (int *) arg1; errno = verify_area(VERIFY_WRITE, p, sizeof(*p)); if (errno) return errno; - errno = 0; - __asm__(".set\tpush\t\t\t# sysmips(MIPS_ATOMIC, ...)\n\t" - ".set\tmips2\n\t" - ".set\tnoat\n\t" - "1:\tll\t%0, %4\n\t" - "move\t$1, %3\n\t" - "2:\tsc\t$1, %1\n\t" - "beqz\t$1, 1b\n\t" - ".set\tpop\n\t" - ".section\t.fixup,\"ax\"\n" - "3:\tli\t%2, 1\t\t\t# error\n\t" +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set push \t\t# sysmips(MIPS_ATOMIC, ...)\n\t" + ".set mips2\n" + "1:\n\t" + "ll %0, %5\n\t" + "move %3, %4\n" + "2:\n\t" + "sc %3, %1\n\t" + "beqz %3, 1b\n" + "3:\n\t" + ".set pop\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2, 1 \t\t# error\n\t" + "j 3b\n\t" ".previous\n\t" - ".section\t__ex_table,\"a\"\n\t" - ".word\t1b, 3b\n\t" - ".word\t2b, 3b\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b, 4b\n\t" + ".word 2b, 4b\n\t" ".previous\n\t" - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) - : "r" (arg2), "o" (* (u32 *) p), "2" (errno) - : "$1"); + : "=&r" (tmp), "=R" (*p), "=r" (errno), "=&r" (tmp1) + : "r" (arg2), "1" (*p), "2" (0)); +#else + save_and_cli(tmp1); + errno = __get_user(tmp, p); + errno |= __put_user(arg2, p); + restore_flags(tmp1); +#endif if (errno) return -EFAULT; @@ -119,9 +127,6 @@ sys_sysmips(int cmd, int arg1, int arg2, : /* No outputs */ : "r" (&cmd)); /* Unreached */ -#else - printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n"); -#endif } case MIPS_FIXADE: From flo@rfc822.org Thu Jul 5 16:27:13 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id QAA08536; Thu, 5 Jul 2001 16:27:13 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 16:27:13 +0200 (MET DST) Received: from noose.gt.owl.de(62.52.19.4) via SMTP by guadalquivir.fnet.fr, id smtpd008534; Thu Jul 5 16:27:05 2001 Received: by noose.gt.owl.de (Postfix, from userid 10) id 347037FA; Thu, 5 Jul 2001 16:26:55 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 107E43F18; Thu, 5 Jul 2001 16:27:05 +0200 (CEST) Date: Thu, 5 Jul 2001 16:27:05 +0200 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...) Message-ID: <20010705162705.B6963@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Jul 05, 2001 at 01:14:16PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 1024 Lines: 23 On Thu, Jul 05, 2001 at 01:14:16PM +0200, Maciej W. Rozycki wrote: > Hi, > > Once again a sysmips() patch. This time the exception fixup code is > broken -- it never returns (well, it probably returns *somewhere* via a > following fixup entry). Also for whatever reason the R3k code is missing. > > The following patch fixes it. While I was at it, I modified contraints a > bit and replaced some of embedded "\t" chars with tabs (the code was > completely unreadable before -- now it should be a bit better, as much as > embedded asm can be). > > The R3k variant works fine for me. I was unable to thest the ll/sc one, > but the semantics should be unchanged, i.e. if it worked before, so it > will now. The patch should go into Linus' tree as well. How is this patch supposed to work in the means of how does it come around the -MAXERRNO stuff in scall32 ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From macro@ds2.pg.gda.pl Thu Jul 5 17:09:03 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA09294; Thu, 5 Jul 2001 17:09:03 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 17:09:03 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd009292; Thu Jul 5 17:08:52 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA16850; Thu, 5 Jul 2001 17:08:36 +0200 (MET DST) Date: Thu, 5 Jul 2001 17:08:36 +0200 (MET DST) From: "Maciej W. Rozycki" To: Florian Lohoff cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...) In-Reply-To: <20010705162705.B6963@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1484 Lines: 30 On Thu, 5 Jul 2001, Florian Lohoff wrote: > > The R3k variant works fine for me. I was unable to thest the ll/sc one, > > but the semantics should be unchanged, i.e. if it worked before, so it > > will now. The patch should go into Linus' tree as well. > > How is this patch supposed to work in the means of how does it come around > the -MAXERRNO stuff in scall32 ? It works as far as sysmips(MIPS_ATOMIC_SET) can. It does not add anything new -- it merely fixes what is obviously broken (falling through to MIPS_FIXADE from MIPS_ATOMIC_SET for non-ll/sc CPUs, what is being currently done, is not the most brilliant idea, either). For better handling I encourage you to use the _test_and_set patch I've sent here recently. I'm using it exclusively for a few weeks now. I do not intend to maintain sysmips(MIPS_ATOMIC_SET) beyond fixing obviously broken stuff. I'm voting only to keep it until we have a replacement. It should go away in 2.5 for sure -- if you recall the recent discussion, the conclusion was it's not really needed if we can satisfy glibc differently. I'd like to see Linus' 2.4.x working on R3k, OTOH. It would be very unfortunate if the official 2.4.x didn't work on R3k, just like 2.2.x (and patches for 2.2.x were available at that time!). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ashu_joshi@ivivity.com Thu Jul 5 17:43:43 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA10457; Thu, 5 Jul 2001 17:43:43 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 17:43:43 +0200 (MET DST) Received: from user-vc8ftn3.biz.mindspring.com(216.135.246.227), claiming to be "mail.ivivity.com" via SMTP by guadalquivir.fnet.fr, id smtpd010455; Thu Jul 5 17:43:40 2001 Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id <3GNKVZNA>; Thu, 5 Jul 2001 11:43:15 -0400 Message-ID: <25369470B6F0D41194820002B328BDD2097644@ATLOPS> From: Ashu Joshi To: "'Linux MIPS FNET'" Subject: Kernel Version Question Date: Thu, 5 Jul 2001 11:43:09 -0400 Importance: high X-Priority: 1 Return-Receipt-To: Ashu Joshi MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 433 Lines: 12 We are about to embark on a project using MIPS Core with Linux as the OS. What is the recommendation of this group for the Kernel Version to be used. So far I have been successul in downloading the Kernel 2.4.1 from the MIPS Technologies FTP site and getting it to cross compile. However when I tried using the 2.4.5 Version from the SGI Site - I am getting compile errors complaining a bunch of missing routines. Regards Ashu From jsun@mvista.com Thu Jul 5 19:55:13 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA12472; Thu, 5 Jul 2001 19:55:13 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 19:55:13 +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 smtpd012448; Thu Jul 5 19:55:03 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 f65HsN006439; Thu, 5 Jul 2001 10:54:23 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3B44A91A.6AA110FC@mvista.com> Date: Thu, 05 Jul 2001 10:51:22 -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: Florian Lohoff , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1637 Lines: 36 "Maciej W. Rozycki" wrote: > > On Thu, 5 Jul 2001, Florian Lohoff wrote: > > > > The R3k variant works fine for me. I was unable to thest the ll/sc one, > > > but the semantics should be unchanged, i.e. if it worked before, so it > > > will now. The patch should go into Linus' tree as well. > > > > How is this patch supposed to work in the means of how does it come around > > the -MAXERRNO stuff in scall32 ? > > It works as far as sysmips(MIPS_ATOMIC_SET) can. It does not add > anything new -- it merely fixes what is obviously broken (falling through > to MIPS_FIXADE from MIPS_ATOMIC_SET for non-ll/sc CPUs, what is being > currently done, is not the most brilliant idea, either). For better > handling I encourage you to use the _test_and_set patch I've sent here > recently. I'm using it exclusively for a few weeks now. > > I do not intend to maintain sysmips(MIPS_ATOMIC_SET) beyond fixing > obviously broken stuff. I'm voting only to keep it until we have a > replacement. It should go away in 2.5 for sure -- if you recall the > recent discussion, the conclusion was it's not really needed if we can > satisfy glibc differently. > That was the conclusion, but did not make to the CVS tree, probably due to Ralf's unwillingness to take a overhead for "flawed" CPUs. In my last patch for Vr41xx, I have a patch for this. Basically, I will send a SIGSYS if the return value is a small negative. This will practically satify all the need while keep the change minimum. The small modification to the semantic is not too bad at all if you consider the original syscall semantic is already badly broken. Jun From macro@ds2.pg.gda.pl Thu Jul 5 20:22:03 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA13139; Thu, 5 Jul 2001 20:22:03 +0200 (MET DST) Received-Date: Thu, 5 Jul 2001 20:22:03 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd013137; Thu Jul 5 20:22:01 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA21759; Thu, 5 Jul 2001 20:23:33 +0200 (MET DST) Date: Thu, 5 Jul 2001 20:23:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Florian Lohoff , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...) In-Reply-To: <3B44A91A.6AA110FC@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1058 Lines: 25 On Thu, 5 Jul 2001, Jun Sun wrote: > That was the conclusion, but did not make to the CVS tree, probably due to > Ralf's unwillingness to take a overhead for "flawed" CPUs. What overhead? The code is conditional at the preprocessor level. > In my last patch for Vr41xx, I have a patch for this. Basically, I will send > a SIGSYS if the return value is a small negative. This will practically > satify all the need while keep the change minimum. The small modification to > the semantic is not too bad at all if you consider the original syscall > semantic is already badly broken. The default action for SIGSYS is to abort with a core dump, so it seems fine here -- I don't object. It allows us to use the normal return path, instead of that crude jump hack, too. Not that I particularly care about sysmips(MIPS_ATOMIC_SET) anymore... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Sat Jul 7 14:32:00 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA02446; Sat, 7 Jul 2001 14:32:00 +0200 (MET DST) Received-Date: Sat, 7 Jul 2001 14:32:00 +0200 (MET DST) Received: from u-6-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.6), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd002444; Sat Jul 7 14:31:50 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f67CVQb30649; Sat, 7 Jul 2001 14:31:26 +0200 Date: Sat, 7 Jul 2001 14:31:26 +0200 From: Ralf Baechle To: Ashu Joshi Cc: "'Linux MIPS FNET'" , linux-mips@oss.sgi.com Subject: Re: Kernel Version Question Message-ID: <20010707143126.A19642@bacchus.dhis.org> References: <25369470B6F0D41194820002B328BDD2097644@ATLOPS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25369470B6F0D41194820002B328BDD2097644@ATLOPS>; from ashu_joshi@ivivity.com on Thu, Jul 05, 2001 at 11:43:09AM -0400 X-Accept-Language: de,en,fr Content-Length: 875 Lines: 19 On Thu, Jul 05, 2001 at 11:43:09AM -0400, Ashu Joshi wrote: > We are about to embark on a project using MIPS Core with Linux as the OS. > > What is the recommendation of this group for the Kernel Version to be used. > > So far I have been successul in downloading the Kernel 2.4.1 from the MIPS > Technologies FTP site and getting it to cross compile. However when I tried > using the 2.4.5 Version from the SGI Site - I am getting compile errors > complaining a bunch of missing routines. Your report is lacking any details but I guess you were trying to build a kernel for a malta board, right? I still don't have a working Malta configuration but I'm trying to glue the support for this board. ATM I've made it compile again and converted it to use the new interrupt infrastructure, so give me a few more hours and I'll commit a hopefully working version. Ralf From greeen@iii.org.tw Mon Jul 9 10:51:59 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id KAA18374; Mon, 9 Jul 2001 10:51:59 +0200 (MET DST) Received-Date: Mon, 9 Jul 2001 10:51:59 +0200 (MET DST) Received: from h179-210-243-135.iii.org.tw(210.243.135.179), claiming to be "mta0.iii.org.tw" via SMTP by guadalquivir.fnet.fr, id smtpd018372; Mon Jul 9 10:51:47 2001 Received: from [140.92.66.45] (helo=iiidns.iii.org.tw) by mta0.iii.org.tw with esmtp (Exim 3.16 #1) id 15JWku-0001tw-00; Mon, 09 Jul 2001 16:51:01 +0800 Received: from Green ([140.92.12.76]) by iiidns.iii.org.tw (8.10.2/8.10.2) with SMTP id f698ofm15763; Mon, 9 Jul 2001 16:50:41 +0800 (CST) Message-ID: <000f01c10854$c86dd200$4c0c5c8c@trd.iii.org.tw> From: "Green" To: "MipsMailList" , "LinuxKernelMailList" , "LinuxEmbeddedMailList" Subject: Pcmcia RF driver again!! Date: Mon, 9 Jul 2001 16:54:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C10897.CBCBCEA0" 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: 2801 Lines: 79 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C10897.CBCBCEA0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear all, I am porting the pcmcia rf driver to the R39xx MIPS machine. The old version driver worked on the kernel 2.2.12 . As the following: /* kernel 2.2.12 */ wlandev->netdev->tbusy =3D 0; mark_bh(NET_BH); I modified it to be=20 /* kernel 2.4.0 */ netif_start_queue((struct net_device*)wlandev->netdev); netif_wake_queue((struct net_device*)wlandev->netdev); The kernel I downloaded from linux-vr didn't implement NET_BH bottom = half routine. So I can't use it. Is there anything wrong? Green ------=_NextPart_000_000C_01C10897.CBCBCEA0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I am porting the pcmcia rf = driver to the R39xx MIPS=20 machine.
The old version driver worked = on the kernel 2.2.12=20 .
As the following:
 
 /*=20 kernel 2.2.12 = */
 wlandev->netdev->tbusy =3D=20 0;
 mark_bh(NET_BH);
 
I modified it to be =
 
 /* kernel 2.4.0=20 */
 netif_start_queue((struct=20 net_device*)wlandev->netdev);
 netif_wake_queue((struct=20 net_device*)wlandev->netdev);
 
The kernel I downloaded from = linux-vr didn't implement=20 NET_BH bottom half routine.
So I can't use it.
Is there anything = wrong?
 
Green
------=_NextPart_000_000C_01C10897.CBCBCEA0-- From ralf@dea.waldorf-gmbh.de Thu Jul 12 22:46:08 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA01746; Thu, 12 Jul 2001 22:46:08 +0200 (MET DST) Received-Date: Thu, 12 Jul 2001 22:46:08 +0200 (MET DST) Received: from u-43-18.karlsruhe.ipdial.viaginterkom.de(62.180.18.43), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd001736; Thu Jul 12 22:45:57 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6CKjKA24015; Thu, 12 Jul 2001 22:45:20 +0200 Date: Thu, 12 Jul 2001 22:45:20 +0200 From: Ralf Baechle To: Jan-Benedict Glaw Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010712224520.C23062@bacchus.dhis.org> References: <20010712203727.A18294@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010712203727.A18294@lug-owl.de>; from jbglaw@lug-owl.de on Thu, Jul 12, 2001 at 08:37:27PM +0200 X-Accept-Language: de,en,fr Content-Length: 530 Lines: 12 On Thu, Jul 12, 2001 at 08:37:27PM +0200, Jan-Benedict Glaw wrote: > At Linuxtag 2001 in Stuttgart/Germany, I was talking to Karsten about > completing userspace. He mentioned a patch for ll/sc emulation in > kernel which was mentioned to be sent some days ago to l-k. I searched > the archives, but couldn't find it. Any pointers? There is a bunch of patches for ll/sc and MIPS_ATOMIC_SET floating around. I came to the conclusion that I don't like any of them so I'm just working on fixing the thing once and for all. Ralf From macro@ds2.pg.gda.pl Fri Jul 13 12:51:58 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA08205; Fri, 13 Jul 2001 12:51:58 +0200 (MET DST) Received-Date: Fri, 13 Jul 2001 12:51:58 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd008203; Fri Jul 13 12:51:48 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA03973; Fri, 13 Jul 2001 12:52:56 +0200 (MET DST) Date: Fri, 13 Jul 2001 12:52:55 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010712224520.C23062@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 616 Lines: 14 On Thu, 12 Jul 2001, Ralf Baechle wrote: > There is a bunch of patches for ll/sc and MIPS_ATOMIC_SET floating around. > I came to the conclusion that I don't like any of them so I'm just working > on fixing the thing once and for all. What about the _test_and_set syscall? Having it implemented we could get rid of the MIPS_ATOMIC_SET hack for post-2.4. Glibc may be made ready for the transition any time now. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Sat Jul 14 12:53:48 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA18015; Sat, 14 Jul 2001 12:53:48 +0200 (MET DST) Received-Date: Sat, 14 Jul 2001 12:53:48 +0200 (MET DST) Received: from u-121-21.karlsruhe.ipdial.viaginterkom.de(62.180.21.121), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd018013; Sat Jul 14 12:53:44 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6EArC906073; Sat, 14 Jul 2001 12:53:12 +0200 Date: Sat, 14 Jul 2001 12:53:12 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010714125312.A6713@bacchus.dhis.org> References: <20010712224520.C23062@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, Jul 13, 2001 at 12:52:55PM +0200 X-Accept-Language: de,en,fr Content-Length: 810 Lines: 18 On Fri, Jul 13, 2001 at 12:52:55PM +0200, Maciej W. Rozycki wrote: > > There is a bunch of patches for ll/sc and MIPS_ATOMIC_SET floating around. > > I came to the conclusion that I don't like any of them so I'm just working > > on fixing the thing once and for all. > > What about the _test_and_set syscall? Having it implemented we could get > rid of the MIPS_ATOMIC_SET hack for post-2.4. Glibc may be made ready for > the transition any time now. I'm just making an attempt to re-implement the ll/sc emulation as light as possible. I hope to get the overhead down to the point were we don't need _test_and_set anymore - in any case below the overhead of a syscall. Have you ever profiled the number of calls to MIPS_ATOMIC_SET or _test_and_set? They'll be the other factor in a decission. Ralf From hkoerfg@web.de Sat Jul 14 19:16:48 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA22114; Sat, 14 Jul 2001 19:16:48 +0200 (MET DST) Received-Date: Sat, 14 Jul 2001 19:16:48 +0200 (MET DST) Received: from mailgate3.cinetic.de(212.227.116.80) via SMTP by guadalquivir.fnet.fr, id smtpd022112; Sat Jul 14 19:16:39 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 f6EHGYg23799; Sat, 14 Jul 2001 19:16:34 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.2 #11) id m15LT1t-007oGwC; Sat, 14 Jul 2001 19:16 +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: ll/sc emulation patch Date: Sat, 14 Jul 2001 19:19:37 +0200 X-Mailer: KMail [version 1.2] Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr References: <20010712224520.C23062@bacchus.dhis.org> <20010714125312.A6713@bacchus.dhis.org> In-Reply-To: <20010714125312.A6713@bacchus.dhis.org> MIME-Version: 1.0 Message-Id: <01071419193700.00504@intel> Content-Transfer-Encoding: 8bit Content-Length: 445 Lines: 13 On Saturday 14 July 2001 12:53, Ralf Baechle wrote: > I'm just making an attempt to re-implement the ll/sc emulation as light > as possible. I hope to get the overhead down to the point were we don't > need _test_and_set anymore - in any case below the overhead of a syscall. I'd love to see something like that. What 's your idea? Greetings, Harald -- There is no distinctly native American criminal class except Congress. -- Mark Twain From jsun@orion.mvista.com Mon Jul 16 06:36:27 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id GAA06338; Mon, 16 Jul 2001 06:36:27 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 06:36:27 +0200 (MET DST) Received: from UNKNOWN(12.44.186.158), claiming to be "orion.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd006336; Mon Jul 16 06:36:26 2001 Received: (from jsun@localhost) by orion.mvista.com (8.9.3/8.9.3) id VAA19673; Sun, 15 Jul 2001 21:32:24 -0700 Date: Sun, 15 Jul 2001 21:32:24 -0700 From: Jun Sun To: Ralf Baechle Cc: "Maciej W. Rozycki" , Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010715213224.A19636@mvista.com> References: <20010712224520.C23062@bacchus.dhis.org> <20010714125312.A6713@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: <20010714125312.A6713@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 14, 2001 at 12:53:12PM +0200 Content-Length: 1067 Lines: 24 On Sat, Jul 14, 2001 at 12:53:12PM +0200, Ralf Baechle wrote: > On Fri, Jul 13, 2001 at 12:52:55PM +0200, Maciej W. Rozycki wrote: > > > > There is a bunch of patches for ll/sc and MIPS_ATOMIC_SET floating around. > > > I came to the conclusion that I don't like any of them so I'm just working > > > on fixing the thing once and for all. > > > > What about the _test_and_set syscall? Having it implemented we could get > > rid of the MIPS_ATOMIC_SET hack for post-2.4. Glibc may be made ready for > > the transition any time now. > > I'm just making an attempt to re-implement the ll/sc emulation as light > as possible. I hope to get the overhead down to the point were we don't > need _test_and_set anymore - in any case below the overhead of a syscall. > That is really cool. For compatibility reasons, I assume we still keep sysmips() around for a while, right? And if that is yes, we better take either flo's or my fix (derived from Maceij's new syscall) to get rid of the illegal instruction bug, which really becomes an untolerable FAQ now. Jun From ralf@dea.waldorf-gmbh.de Mon Jul 16 06:53:17 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id GAA06960; Mon, 16 Jul 2001 06:53:17 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 06:53:17 +0200 (MET DST) Received: from pD956F5FD.dip.t-dialin.net(217.86.245.253), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd006958; Mon Jul 16 06:53:11 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6G4pqo04660; Mon, 16 Jul 2001 06:51:52 +0200 Date: Mon, 16 Jul 2001 06:51:52 +0200 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010716065151.A1333@bacchus.dhis.org> References: <20010712224520.C23062@bacchus.dhis.org> <20010714125312.A6713@bacchus.dhis.org> <20010715213224.A19636@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010715213224.A19636@mvista.com>; from jsun@mvista.com on Sun, Jul 15, 2001 at 09:32:24PM -0700 X-Accept-Language: de,en,fr Content-Length: 374 Lines: 10 On Sun, Jul 15, 2001 at 09:32:24PM -0700, Jun Sun wrote: > For compatibility reasons, I assume we still keep sysmips() around > for a while, right? And if that is yes, we better take either flo's or > my fix (derived from Maceij's new syscall) to get rid of the illegal > instruction bug, which really becomes an untolerable FAQ now. I've also debugged sysmips. Ralf From flo@rfc822.org Mon Jul 16 13:00:27 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id NAA12037; Mon, 16 Jul 2001 13:00:27 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 13:00:27 +0200 (MET DST) Received: from noose.gt.owl.de(62.52.19.4) via SMTP by guadalquivir.fnet.fr, id smtpd012035; Mon Jul 16 13:00:18 2001 Received: by noose.gt.owl.de (Postfix, from userid 10) id E293E802; Mon, 16 Jul 2001 13:00:09 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3CDDE4626; Mon, 16 Jul 2001 12:03:47 +0200 (CEST) Date: Mon, 16 Jul 2001 12:03:47 +0200 From: Florian Lohoff To: Ralf Baechle Cc: "Maciej W. Rozycki" , Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010716120347.B13023@paradigm.rfc822.org> References: <20010712224520.C23062@bacchus.dhis.org> <20010714125312.A6713@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010714125312.A6713@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 14, 2001 at 12:53:12PM +0200 Organization: rfc822 - pure communication Sender: flo@rfc822.org Content-Length: 502 Lines: 12 On Sat, Jul 14, 2001 at 12:53:12PM +0200, Ralf Baechle wrote: > Have you ever profiled the number of calls to MIPS_ATOMIC_SET or > _test_and_set? They'll be the other factor in a decission. Against glibc 2.2 compiled bins do it 20-30 times on startup ... Just try an strace and you'll astonished ... Even sleep (What on earth is atomic in sleep ?) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From macro@ds2.pg.gda.pl Mon Jul 16 18:06:45 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA16027; Mon, 16 Jul 2001 18:06:45 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 18:06:45 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd016025; Mon Jul 16 18:06:44 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA13581; Mon, 16 Jul 2001 14:03:31 +0200 (MET DST) Date: Mon, 16 Jul 2001 14:03:30 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010714125312.A6713@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1231 Lines: 25 On Sat, 14 Jul 2001, Ralf Baechle wrote: > I'm just making an attempt to re-implement the ll/sc emulation as light > as possible. I hope to get the overhead down to the point were we don't > need _test_and_set anymore - in any case below the overhead of a syscall. > > Have you ever profiled the number of calls to MIPS_ATOMIC_SET or > _test_and_set? They'll be the other factor in a decission. I didn't profile it very extensively, yet when stracing `ls /usr/lib' (fileutils 4.1 linked against glibc 2.2.3) on my system once I yielded ~4500 syscalls of which ~4000 were _test_and_set() (or MIPS_ATOMIC_SET, depending on my kernel/glibc configuration) invocations. Yes, libpthread appears to assume atomic operations are cheap, which is justifiable as they are indeed, for almost every other CPU type. Also I feel having ll and sc opcodes in a pure MIPS I binary is somewhat ugly (e.g. `objdump' won't disassemble them unless a MIPS II+ CPU is specified), but I could probably live with it if performance was not worse. -- + 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 Jul 16 18:07:05 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id SAA16058; Mon, 16 Jul 2001 18:07:05 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 18:07:05 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd016056; Mon Jul 16 18:07:04 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA13591; Mon, 16 Jul 2001 14:04:44 +0200 (MET DST) Date: Mon, 16 Jul 2001 14:04:44 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010715213224.A19636@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 587 Lines: 13 On Sun, 15 Jul 2001, Jun Sun wrote: > For compatibility reasons, I assume we still keep sysmips() around > for a while, right? And if that is yes, we better take either flo's or > my fix (derived from Maceij's new syscall) to get rid of the illegal > instruction bug, which really becomes an untolerable FAQ now. I don't think it would be wise to remove MIPS_ATOMIC_SET before 2.5. -- + 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 Jul 16 20:41:54 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id UAA18848; Mon, 16 Jul 2001 20:41:54 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 20:41:54 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd018846; Mon Jul 16 20:41:47 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA20939; Mon, 16 Jul 2001 20:43:23 +0200 (MET DST) Date: Mon, 16 Jul 2001 20:43:23 +0200 (MET DST) From: "Maciej W. Rozycki" To: Harald Koerfgen , Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.5: DECstation LK201 keyboard non-functional Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 7195 Lines: 261 Hi, Since 2.4.5 there is a problem with the LK201 driver. The driver gets never registered. It happens because chr_dev_init() got converted to __initcall() and is no longer invoked before rs_init() for the DECstation (chr_dev_init() calls tty_init() which registers the LK201 hook via kbd_init()). The following patch fixes the problem. It makes the DECstation's object file that provides rs_init() be included in the DRIVERS list as SERIAL. It is on the CORE_FILES list of Makefile targets now. The patch looks bigger than it really is -- apart from trivial Makefile changes, it's merely an arch/mips/dec/serial.c to drivers/char/decserial.c rename. Note while putting a file away from an arch-specific tree into a generic driver one might seem a bad move, it really is the right thing in this case. The point is the decserial.c device is not arch-specific at all, i.e. no more than the 8250 serial.c device is. DEC used the devices in a number of their systems, including DECstations (onboard SCC and DZ11 and TURBOchannel PMAC-A DZ11 devices), DEC 3000 Alpha systems (onboard SCC and PMAC-A devices) and VAXstations (onboard DZ11 and PMAC-A devices). Thus I believe they should be treated as generic devices, especially as the VAX and the DEC 3000 Alpha (to some extent) Linux ports are underway. Please apply the patch. 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-decserial-0 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/dec/Makefile linux-mips-2.4.5-20010704/arch/mips/dec/Makefile --- linux-mips-2.4.5-20010704.macro/arch/mips/dec/Makefile Sat Jan 13 05:26:23 2001 +++ linux-mips-2.4.5-20010704/arch/mips/dec/Makefile Mon Jul 16 01:05:06 2001 @@ -19,7 +19,6 @@ export-objs := wbflush.o obj-y := int-handler.o setup.o irq.o time.o reset.o rtc-dec.o wbflush.o obj-$(CONFIG_PROM_CONSOLE) += promcon.o -obj-$(CONFIG_SERIAL) += serial.o int-handler.o: int-handler.S diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/dec/serial.c linux-mips-2.4.5-20010704/arch/mips/dec/serial.c --- linux-mips-2.4.5-20010704.macro/arch/mips/dec/serial.c Wed Mar 29 04:27:14 2000 +++ linux-mips-2.4.5-20010704/arch/mips/dec/serial.c Thu Jan 1 00:00:00 1970 @@ -1,98 +0,0 @@ -/* - * sercons.c - * choose the right serial device at boot time - * - * triemer 6-SEP-1998 - * sercons.c is designed to allow the three different kinds - * of serial devices under the decstation world to co-exist - * in the same kernel. The idea here is to abstract - * the pieces of the drivers that are common to this file - * so that they do not clash at compile time and runtime. - * - * HK 16-SEP-1998 v0.002 - * removed the PROM console as this is not a real serial - * device. Added support for PROM console in drivers/char/tty_io.c - * instead. Although it may work to enable more than one - * console device I strongly recommend to use only one. - */ - -#include -#include -#include - -#ifdef CONFIG_ZS -extern int zs_init(void); -#endif - -#ifdef CONFIG_DZ -extern int dz_init(void); -#endif - -#ifdef CONFIG_SERIAL_CONSOLE - -#ifdef CONFIG_ZS -extern void zs_serial_console_init(void); -#endif - -#ifdef CONFIG_DZ -extern void dz_serial_console_init(void); -#endif - -#endif - -/* rs_init - starts up the serial interface - - handle normal case of starting up the serial interface */ - -#ifdef CONFIG_SERIAL - -int __init rs_init(void) -{ - -#if defined(CONFIG_ZS) && defined(CONFIG_DZ) - if (IOASIC) - return zs_init(); - else - return dz_init(); -#else - -#ifdef CONFIG_ZS - return zs_init(); -#endif - -#ifdef CONFIG_DZ - return dz_init(); -#endif - -#endif -} - -__initcall(rs_init); - -#endif - -#ifdef CONFIG_SERIAL_CONSOLE - -/* serial_console_init handles the special case of starting - * up the console on the serial port - */ -void __init serial_console_init(void) -{ -#if defined(CONFIG_ZS) && defined(CONFIG_DZ) - if (IOASIC) - zs_serial_console_init(); - else - dz_serial_console_init(); -#else - -#ifdef CONFIG_ZS - zs_serial_console_init(); -#endif - -#ifdef CONFIG_DZ - dz_serial_console_init(); -#endif - -#endif -} - -#endif diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/char/Makefile linux-mips-2.4.5-20010704/drivers/char/Makefile --- linux-mips-2.4.5-20010704.macro/drivers/char/Makefile Thu Jun 14 04:26:44 2001 +++ linux-mips-2.4.5-20010704/drivers/char/Makefile Mon Jul 16 01:04:12 2001 @@ -103,7 +103,7 @@ endif ifeq ($(CONFIG_DECSTATION),y) KEYMAP = KEYBD = - SERIAL = + SERIAL = decserial.o endif ifeq ($(CONFIG_BAGET_MIPS),y) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/drivers/char/decserial.c linux-mips-2.4.5-20010704/drivers/char/decserial.c --- linux-mips-2.4.5-20010704.macro/drivers/char/decserial.c Thu Jan 1 00:00:00 1970 +++ linux-mips-2.4.5-20010704/drivers/char/decserial.c Wed Mar 29 04:27:14 2000 @@ -0,0 +1,98 @@ +/* + * sercons.c + * choose the right serial device at boot time + * + * triemer 6-SEP-1998 + * sercons.c is designed to allow the three different kinds + * of serial devices under the decstation world to co-exist + * in the same kernel. The idea here is to abstract + * the pieces of the drivers that are common to this file + * so that they do not clash at compile time and runtime. + * + * HK 16-SEP-1998 v0.002 + * removed the PROM console as this is not a real serial + * device. Added support for PROM console in drivers/char/tty_io.c + * instead. Although it may work to enable more than one + * console device I strongly recommend to use only one. + */ + +#include +#include +#include + +#ifdef CONFIG_ZS +extern int zs_init(void); +#endif + +#ifdef CONFIG_DZ +extern int dz_init(void); +#endif + +#ifdef CONFIG_SERIAL_CONSOLE + +#ifdef CONFIG_ZS +extern void zs_serial_console_init(void); +#endif + +#ifdef CONFIG_DZ +extern void dz_serial_console_init(void); +#endif + +#endif + +/* rs_init - starts up the serial interface - + handle normal case of starting up the serial interface */ + +#ifdef CONFIG_SERIAL + +int __init rs_init(void) +{ + +#if defined(CONFIG_ZS) && defined(CONFIG_DZ) + if (IOASIC) + return zs_init(); + else + return dz_init(); +#else + +#ifdef CONFIG_ZS + return zs_init(); +#endif + +#ifdef CONFIG_DZ + return dz_init(); +#endif + +#endif +} + +__initcall(rs_init); + +#endif + +#ifdef CONFIG_SERIAL_CONSOLE + +/* serial_console_init handles the special case of starting + * up the console on the serial port + */ +void __init serial_console_init(void) +{ +#if defined(CONFIG_ZS) && defined(CONFIG_DZ) + if (IOASIC) + zs_serial_console_init(); + else + dz_serial_console_init(); +#else + +#ifdef CONFIG_ZS + zs_serial_console_init(); +#endif + +#ifdef CONFIG_DZ + dz_serial_console_init(); +#endif + +#endif +} + +#endif From macro@ds2.pg.gda.pl Mon Jul 16 21:26:24 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA19789; Mon, 16 Jul 2001 21:26:24 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 21:26:24 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019787; Mon Jul 16 21:26:18 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA21713; Mon, 16 Jul 2001 21:28:39 +0200 (MET DST) Date: Mon, 16 Jul 2001 21:28:39 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.5: R3k cache line sizing + minor bits Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 4270 Lines: 124 Hi, The following patch implements real cache line sizing for R3k processors instead of the current hardcoded single word (4 bytes). Having a true cache line size available will enable the possibility to tune cache flushing functions making them perform better if the line size is bigger than a word. The patch includes minor corrections as well (sorry -- splitting them up would be difficult due to overlapping areas). They should be mostly obvious. One that probably needs a comment is the change to the low bound of the cache size check. It's now 128 words, as the IDT sw development manual states in the portability section that the minimal size of the cache for their chips is 512 bytes each (two extraneous executions of the loops shouldn't hurt here anyway, even if we never meet such a CPU). I've successfully tested the patch on my hardware, but since DECstation 5000/240 features single-word-wide cache lines, it doesn't really bring anything new to my system apart from being more correct. ;-) I'd be pleased to hear from people having a different cache layout. 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-cacheline-6 diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/mm/r2300.c linux-mips-2.4.5-20010704/arch/mips/mm/r2300.c --- linux-mips-2.4.5-20010704.macro/arch/mips/mm/r2300.c Thu Jun 28 04:27:03 2001 +++ linux-mips-2.4.5-20010704/arch/mips/mm/r2300.c Sun Jul 15 23:24:16 2001 @@ -33,7 +33,7 @@ /* For R3000 cores with R4000 style caches */ static unsigned long icache_size, dcache_size; /* Size in bytes */ static unsigned long icache_lsize, dcache_lsize; /* Size in bytes */ -static unsigned long scache_size = 0; +static unsigned long scache_size; #include #include @@ -134,31 +134,64 @@ unsigned long __init r3k_cache_size(unsi dummy = *p; status = read_32bit_cp0_register(CP0_STATUS); - if (dummy != 0xa5a55a5a || (status & (1<<19))) { + if (dummy != 0xa5a55a5a || (status & ST0_CM)) { size = 0; } else { - for (size = 512; size <= 0x40000; size <<= 1) + for (size = 128; size <= 0x40000; size <<= 1) *(p + size) = 0; *p = -1; - for (size = 512; + for (size = 128; (size <= 0x40000) && (*(p + size) == 0); size <<= 1) ; if (size > 0x40000) size = 0; } + write_32bit_cp0_register(CP0_STATUS, flags); return size * sizeof(*p); } +unsigned long __init r3k_cache_lsize(unsigned long ca_flags) +{ + unsigned long flags, status, lsize, i, j; + volatile unsigned long *p; + + p = (volatile unsigned long *) KSEG0; + + flags = read_32bit_cp0_register(CP0_STATUS); + + /* isolate cache space */ + write_32bit_cp0_register(CP0_STATUS, (ca_flags|flags)&~ST0_IEC); + + for (i = 0; i < 128; i++) + *(p + i) = 0; + *(volatile unsigned char *)p = 0; + for (lsize = 1; lsize < 128; lsize <<= 1) { + *(p + lsize); + status = read_32bit_cp0_register(CP0_STATUS); + if (!(status & ST0_CM)) + break; + } + for (i = 0; i < 128; i += lsize) + *(volatile unsigned char *)(p + i) = 0; + + write_32bit_cp0_register(CP0_STATUS, flags); + + return lsize * sizeof(*p); +} + static void __init r3k_probe_cache(void) { dcache_size = r3k_cache_size(ST0_ISC); - dcache_lsize = 4; + if (dcache_size) + dcache_lsize = r3k_cache_lsize(ST0_ISC); + icache_size = r3k_cache_size(ST0_ISC|ST0_SWC); - icache_lsize = 4; + if (icache_size) + icache_lsize = r3k_cache_lsize(ST0_ISC|ST0_SWC); } static void r3k_flush_icache_range(unsigned long start, unsigned long end) diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/include/asm-mips/mipsregs.h linux-mips-2.4.5-20010704/include/asm-mips/mipsregs.h --- linux-mips-2.4.5-20010704.macro/include/asm-mips/mipsregs.h Thu Jul 5 01:19:13 2001 +++ linux-mips-2.4.5-20010704/include/asm-mips/mipsregs.h Sun Jul 15 21:45:28 2001 @@ -331,6 +331,7 @@ __BUILD_SET_CP0(config,CP0_CONFIG) /* bits 6 & 7 are reserved on R[23]000 */ #define ST0_ISC 0x00010000 #define ST0_SWC 0x00020000 +#define ST0_CM 0x00080000 /* * Bits specific to the R4640/R4650 From macro@ds2.pg.gda.pl Mon Jul 16 21:38:04 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA19960; Mon, 16 Jul 2001 21:38:04 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 21:38:04 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019958; Mon Jul 16 21:37:56 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA21956; Mon, 16 Jul 2001 21:40:01 +0200 (MET DST) Date: Mon, 16 Jul 2001 21:40:01 +0200 (MET DST) From: "Maciej W. Rozycki" To: Mike McDonald cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <200107161847.LAA09164@saturn.mikemac.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 503 Lines: 14 On Mon, 16 Jul 2001, Mike McDonald wrote: > Not knowing anything about the glibc architecture, I have a dumb > question: why is 'ls' doing anything at all with pthreads? A short answer: clock_gettime(). A long one: clock_gettime(), which is defined by librt, which in turn depends on libpthread. -- + 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 Jul 16 21:49:24 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA20055; Mon, 16 Jul 2001 21:49:24 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 21:49:24 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd020053; Mon Jul 16 21:49:20 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA22184; Mon, 16 Jul 2001 21:51:12 +0200 (MET DST) Date: Mon, 16 Jul 2001 21:51:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Mike McDonald , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010716115012.A32434@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 913 Lines: 26 On Mon, 16 Jul 2001, H . J . Lu wrote: > You must be using a broken Linux. /bin/ls in my RedHat 7.1/mips doesn't > use pthreads. Which version of ls? Versions up to 4.0 did not, indeed. Of course, you may force version 4.1 not to make use libpthreads, either. Just convince the configure script in the usual way not to use clock_gettime(). I just checked ls 4.1 compiled for i386-linux in a glibc 2.2.3 environment: $ LD_TRACE_LOADED_OBJECTS=1 ls librt.so.1 => /lib/librt.so.1 (0x40020000) libc.so.6 => /lib/libc.so.6 (0x40032000) libpthread.so.0 => /lib/libpthread.so.0 (0x4015a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) so it's not MIPS-specific at all... Why would it, anyway? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From hkoerfg@web.de Mon Jul 16 22:25:34 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA22163; Mon, 16 Jul 2001 22:25:34 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 22:25:34 +0200 (MET DST) Received: from mailgate3.cinetic.de(212.227.116.80) via SMTP by guadalquivir.fnet.fr, id smtpd022161; Mon Jul 16 22:25:26 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 f6GKPFg22166; Mon, 16 Jul 2001 22:25:16 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.2 #11) id m15MEva-007oM9C; Mon, 16 Jul 2001 22:25 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: "Maciej W. Rozycki" , Ralf Baechle Subject: Re: [patch] 2.4.5: DECstation LK201 keyboard non-functional Date: Mon, 16 Jul 2001 22:28:14 +0200 X-Mailer: KMail [version 1.2] Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01071622281400.00525@intel> Content-Transfer-Encoding: 8bit Content-Length: 1045 Lines: 22 On Monday 16 July 2001 20:43, Maciej W. Rozycki wrote: [DECstation Keyboard] > Note while putting a file away from an arch-specific tree into a generic > driver one might seem a bad move, it really is the right thing in this > case. The point is the decserial.c device is not arch-specific at all, > i.e. no more than the 8250 serial.c device is. DEC used the devices in a > number of their systems, including DECstations (onboard SCC and DZ11 and > TURBOchannel PMAC-A DZ11 devices), DEC 3000 Alpha systems (onboard SCC and > PMAC-A devices) and VAXstations (onboard DZ11 and PMAC-A devices). Thus I > believe they should be treated as generic devices, especially as the VAX > and the DEC 3000 Alpha (to some extent) Linux ports are underway. I tend to agree, but maybe I'm biased. On the other hand, it would prpbably be better to modularize the dz and zs drivers. However, if nobody has any objections I'll commit this for the 2.4 series. Greetings, Harald -- Don't look now, but there is a multi-legged creature on your shoulder. From macro@ds2.pg.gda.pl Mon Jul 16 22:31:34 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA22254; Mon, 16 Jul 2001 22:31:34 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 22:31:34 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd022252; Mon Jul 16 22:31:30 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA23178; Mon, 16 Jul 2001 22:33:43 +0200 (MET DST) Date: Mon, 16 Jul 2001 22:33:42 +0200 (MET DST) From: "Maciej W. Rozycki" To: "H . J . Lu" cc: Mike McDonald , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010716130913.A1412@lucon.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 853 Lines: 18 On Mon, 16 Jul 2001, H . J . Lu wrote: > ls shouldn't bother with clock_gettime, which is in librt and librt > needs libpthreads. RedHat 7.1 has a similar patch to make 3.79.1 to > get around it. Otherwise, make won't work right due to the 2MB stack > limit imposed by libpthreads. ls.c contains an explicit reference to clock_gettime() in its get_current_time() function. The reference was added quite recently but ChangeLog does not contain a relevant entry. In any case clock_gettime() provides a better resolution than gettimeofday() does. Did you or someone else contacted the maintainer to clarify the issue? RedHat isn't the whole world. -- + 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 Jul 16 22:43:04 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA22372; Mon, 16 Jul 2001 22:43:04 +0200 (MET DST) Received-Date: Mon, 16 Jul 2001 22:43:04 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd022370; Mon Jul 16 22:43:00 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA23268; Mon, 16 Jul 2001 22:38:41 +0200 (MET DST) Date: Mon, 16 Jul 2001 22:38:41 +0200 (MET DST) From: "Maciej W. Rozycki" To: Harald Koerfgen cc: Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.5: DECstation LK201 keyboard non-functional In-Reply-To: <01071622281400.00525@intel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 565 Lines: 15 On Mon, 16 Jul 2001, Harald Koerfgen wrote: > I tend to agree, but maybe I'm biased. On the other hand, it would prpbably > be better to modularize the dz and zs drivers. They should get modularized one day anyway, but for the console purpose this is irrelevant. Also Linus plans a driver tree redesign in 2.5, IIRC. The current tree is messed up indeed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From airlied@csn.ul.ie Tue Jul 17 22:05:47 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA12552; Tue, 17 Jul 2001 22:05:47 +0200 (MET DST) Received-Date: Tue, 17 Jul 2001 22:05:47 +0200 (MET DST) Received: from holly.csn.ul.ie(136.201.105.4) via SMTP by guadalquivir.fnet.fr, id smtpd012547; Tue Jul 17 22:05:39 2001 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id D5B7D2B6F4; Tue, 17 Jul 2001 21:05:34 +0100 (IST) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 9501DA8A5; Tue, 17 Jul 2001 21:05:33 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 8E9FCA8A4; Tue, 17 Jul 2001 21:05:33 +0100 (IST) Date: Tue, 17 Jul 2001 21:05:33 +0100 (IST) From: Dave Airlie X-X-Sender: To: "Maciej W. Rozycki" Cc: Harald Koerfgen , Ralf Baechle , , Subject: Re: [patch] 2.4.5: DECstation LK201 keyboard non-functional In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1974 Lines: 50 Well that file you've moved is still a DEC specific file .. all the arch non-specific stuff is in drivers/char/dz.c and drivers/tc/zs.c already.. the decserial.c file does nothing for any other arch but the DECstation.. I'd rather it was fixed with the serial.c file in the old place... but hey I'm not exactly contributing a fix here so feel free to ignore this rant :-) Dave. On Mon, 16 Jul 2001, Maciej W. Rozycki wrote: > Hi, > > Since 2.4.5 there is a problem with the LK201 driver. The driver gets > never registered. It happens because chr_dev_init() got converted to > __initcall() and is no longer invoked before rs_init() for the DECstation > (chr_dev_init() calls tty_init() which registers the LK201 hook via > kbd_init()). > > The following patch fixes the problem. It makes the DECstation's object > file that provides rs_init() be included in the DRIVERS list as SERIAL. > It is on the CORE_FILES list of Makefile targets now. The patch looks > bigger than it really is -- apart from trivial Makefile changes, it's > merely an arch/mips/dec/serial.c to drivers/char/decserial.c rename. > > Note while putting a file away from an arch-specific tree into a generic > driver one might seem a bad move, it really is the right thing in this > case. The point is the decserial.c device is not arch-specific at all, > i.e. no more than the 8250 serial.c device is. DEC used the devices in a > number of their systems, including DECstations (onboard SCC and DZ11 and > TURBOchannel PMAC-A DZ11 devices), DEC 3000 Alpha systems (onboard SCC and > PMAC-A devices) and VAXstations (onboard DZ11 and PMAC-A devices). Thus I > believe they should be treated as generic devices, especially as the VAX > and the DEC 3000 Alpha (to some extent) Linux ports are underway. > > Please apply the patch. > > Maciej > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From macro@ds2.pg.gda.pl Wed Jul 18 15:31:30 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id PAA19163; Wed, 18 Jul 2001 15:31:30 +0200 (MET DST) Received-Date: Wed, 18 Jul 2001 15:31:30 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019161; Wed Jul 18 15:31:19 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA10555; Wed, 18 Jul 2001 15:33:18 +0200 (MET DST) Date: Wed, 18 Jul 2001 15:33:17 +0200 (MET DST) From: "Maciej W. Rozycki" To: Dave Airlie cc: Harald Koerfgen , Ralf Baechle , linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.5: DECstation LK201 keyboard non-functional In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1044 Lines: 21 On Tue, 17 Jul 2001, Dave Airlie wrote: > Well that file you've moved is still a DEC specific file .. all the arch > non-specific stuff is in drivers/char/dz.c and drivers/tc/zs.c already.. > the decserial.c file does nothing for any other arch but the DECstation.. > > I'd rather it was fixed with the serial.c file in the old place... but > hey I'm not exactly contributing a fix here so feel free to ignore this > rant :-) I think the file can (and should) be removed altogether one day. Especially as it's not flexible enough, considering PMAC-A. The stuff in tty_io.c should handle a console on both kinds of serial chips fine, just like it handles a number of other chips already, but it needs careful checking of both drivers to handle all cases fine. Improving the serial drivers is on my to-do list, but don't hold your breath. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Thu Jul 19 11:26:44 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id LAA27935; Thu, 19 Jul 2001 11:26:44 +0200 (MET DST) Received-Date: Thu, 19 Jul 2001 11:26:44 +0200 (MET DST) Received: from u-243-10.karlsruhe.ipdial.viaginterkom.de(62.180.10.243), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd027933; Thu Jul 19 11:26:38 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6J0IJX02419; Thu, 19 Jul 2001 02:18:19 +0200 Date: Thu, 19 Jul 2001 02:18:19 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Jan-Benedict Glaw , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010719021819.D1888@bacchus.dhis.org> References: <20010714125312.A6713@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, Jul 16, 2001 at 02:03:30PM +0200 X-Accept-Language: de,en,fr Content-Length: 1152 Lines: 24 On Mon, Jul 16, 2001 at 02:03:30PM +0200, Maciej W. Rozycki wrote: > I didn't profile it very extensively, yet when stracing `ls /usr/lib' > (fileutils 4.1 linked against glibc 2.2.3) on my system once I yielded > ~4500 syscalls of which ~4000 were _test_and_set() (or MIPS_ATOMIC_SET, > depending on my kernel/glibc configuration) invocations. Yes, libpthread > appears to assume atomic operations are cheap, which is justifiable as > they are indeed, for almost every other CPU type. On a fast Indy those 4000 syscalls would cost about 3.2ms of CPU which is a noticable fraction of the total execution time. > Also I feel having ll and sc opcodes in a pure MIPS I binary is somewhat > ugly (e.g. `objdump' won't disassemble them unless a MIPS II+ CPU is > specified), but I could probably live with it if performance was not > worse. This behaviour of objdump sucks rocks anyway. There are MIPS I CPUs which have ll but no branch likely and many other MIPS ISA perversions. Objdump also will only hexdump anything that hasn't been marked as code with .type. Seems objdump's behaviour was choosen to be the most annoying possible. Ralf From macro@ds2.pg.gda.pl Thu Jul 19 14:54:12 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA29026; Thu, 19 Jul 2001 14:54:12 +0200 (MET DST) Received-Date: Thu, 19 Jul 2001 14:54:12 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd029024; Thu Jul 19 14:54:01 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA05400; Thu, 19 Jul 2001 14:56:14 +0200 (MET DST) Date: Thu, 19 Jul 2001 14:56:12 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: <20010719021819.D1888@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1051 Lines: 21 On Thu, 19 Jul 2001, Ralf Baechle wrote: > This behaviour of objdump sucks rocks anyway. There are MIPS I CPUs which > have ll but no branch likely and many other MIPS ISA perversions. Objdump > also will only hexdump anything that hasn't been marked as code with > .type. Seems objdump's behaviour was choosen to be the most annoying > possible. Well, actually I disagree. I like this very much, since looking at the output it's immediately obvious if some code contains opcodes unrecognizable by a selected CPU (due to a bad compiler option or an inline asm error). And you can always select a desired CPU type with the "-m mips:" option (e.g. "-m mips:3000"). If there are MIPS I CPUs which have have ll but no branch likely, etc. then their descriptions should be appropriately set in objdump. Otherwise, it's a bug in binutils. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From greeen@iii.org.tw Fri Jul 20 07:57:57 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id HAA10454; Fri, 20 Jul 2001 07:57:57 +0200 (MET DST) Received-Date: Fri, 20 Jul 2001 07:57:57 +0200 (MET DST) Received: from h180-210-243-135.iii.org.tw(210.243.135.180), claiming to be "mta0.iii.org.tw" via SMTP by guadalquivir.fnet.fr, id smtpd010452; Fri Jul 20 07:57:53 2001 Received: from [140.92.66.45] (helo=iiidns.iii.org.tw) by mta0.iii.org.tw with esmtp (Exim 3.16 #1) id 15NTHi-0003sR-01; Fri, 20 Jul 2001 13:57:10 +0800 Received: from Green ([140.92.12.76]) by iiidns.iii.org.tw (8.10.2/8.10.2) with SMTP id f6K5unt10930; Fri, 20 Jul 2001 13:56:50 +0800 (CST) Message-ID: <000a01c110e1$54424600$4c0c5c8c@trd.iii.org.tw> From: "Green" To: "MipsMailList" , "LinuxKernelMailList" , "LinuxEmbeddedMailList" Subject: Sound Driver!! Date: Fri, 20 Jul 2001 14:00:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C11124.60B11F40" 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: 1417 Lines: 43 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C11124.60B11F40 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear all, I have one r3912 Mips machine. I want to porting the sound driver on my MIPS machine. Where can I find the driver for r3912? Thanks in advance. Green ------=_NextPart_000_0007_01C11124.60B11F40 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I have one r3912 Mips = machine.
I want to porting the sound = driver on my MIPS=20 machine.
Where can I find the driver for = r3912?
 
Thanks in advance.
Green
------=_NextPart_000_0007_01C11124.60B11F40-- From nemoto@toshiba-tops.co.jp Mon Jul 23 12:01:47 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA17510; Mon, 23 Jul 2001 12:01:47 +0200 (MET DST) Received-Date: Mon, 23 Jul 2001 12:01:47 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd017508; Mon Jul 23 12:01:40 2001 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 23 Jul 2001 10:01:40 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 TAA58671; Mon, 23 Jul 2001 19:01:21 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA08890; Mon, 23 Jul 2001 19:01:21 +0900 (JST) To: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: time_init() enables interrupt. From: Atsushi Nemoto 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: <20010723190544N.nemoto@toshiba-tops.co.jp> Date: Mon, 23 Jul 2001 19:05:44 +0900 X-Dispatcher: imput version 20000228(IM140) Content-Length: 455 Lines: 16 arch/mips/kernel/time.c:time_init() in current CVS contains following codes: /* setup xtime */ write_lock_irq(&xtime_lock); xtime.tv_sec = rtc_get_time(); xtime.tv_usec = 0; write_unlock_irq(&xtime_lock); The write_unlock_irq() macro calls __sti(), but it is too early to enable interrupts. I think this write_lock_irq/write_unlock_irq pair should be removed (or replaced with write_lock_irqsave/write_unlock_irqrestore pair). --- Atsushi Nemoto From nemoto@toshiba-tops.co.jp Mon Jul 23 12:08:07 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA17589; Mon, 23 Jul 2001 12:08:07 +0200 (MET DST) Received-Date: Mon, 23 Jul 2001 12:08:07 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd017586; Mon Jul 23 12:08:04 2001 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 23 Jul 2001 10:08:04 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 TAA58750; Mon, 23 Jul 2001 19:08:02 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA08909; Mon, 23 Jul 2001 19:08:02 +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: time_init() enables interrupt. 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: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010723191226D.nemoto@toshiba-tops.co.jp> Date: Mon, 23 Jul 2001 19:12:26 +0900 X-Dispatcher: imput version 20000228(IM140) Content-Length: 161 Lines: 9 There is conflict in cputype values. in include/asm-mips/bootinfo.h: #define CPU_AU1000 37 #define CPU_4KEC 37 --- Atsushi Nemoto From nemoto@toshiba-tops.co.jp Mon Jul 23 12:22:17 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id MAA18582; Mon, 23 Jul 2001 12:22:17 +0200 (MET DST) Received-Date: Mon, 23 Jul 2001 12:22:17 +0200 (MET DST) Received: from topsns.toshiba-tops.co.jp(202.230.225.5) via SMTP by guadalquivir.fnet.fr, id smtpd018580; Mon Jul 23 12:22:10 2001 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for guadalquivir.fnet.fr [193.104.112.133]) with SMTP; 23 Jul 2001 10:22:10 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id TAA59019; Mon, 23 Jul 2001 19:22:08 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id TAA08955; Mon, 23 Jul 2001 19:22:08 +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: conflict in bootinfo.h 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: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010723192632I.nemoto@toshiba-tops.co.jp> Date: Mon, 23 Jul 2001 19:26:32 +0900 X-Dispatcher: imput version 20000228(IM140) Content-Length: 229 Lines: 11 # Sorry to resend this message. My previous post has bad subject. There is conflict in cputype values. in include/asm-mips/bootinfo.h: #define CPU_AU1000 37 #define CPU_4KEC 37 --- Atsushi Nemoto From ralf@dea.waldorf-gmbh.de Mon Jul 23 19:26:34 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA24856; Mon, 23 Jul 2001 19:26:34 +0200 (MET DST) Received-Date: Mon, 23 Jul 2001 19:26:34 +0200 (MET DST) Received: from u-223-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.223), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd024854; Mon Jul 23 19:26:29 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6NEiOm02121; Mon, 23 Jul 2001 16:44:24 +0200 Date: Mon, 23 Jul 2001 16:44:24 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: time_init() enables interrupt. Message-ID: <20010723164424.A1245@bacchus.dhis.org> References: <20010723191226D.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: <20010723191226D.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Jul 23, 2001 at 07:12:26PM +0900 X-Accept-Language: de,en,fr Content-Length: 242 Lines: 12 On Mon, Jul 23, 2001 at 07:12:26PM +0900, Atsushi Nemoto wrote: > There is conflict in cputype values. > > in include/asm-mips/bootinfo.h: > > #define CPU_AU1000 37 > #define CPU_4KEC 37 Thanks, fixed. Ralf From ralf@dea.waldorf-gmbh.de Mon Jul 23 19:26:54 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA24886; Mon, 23 Jul 2001 19:26:54 +0200 (MET DST) Received-Date: Mon, 23 Jul 2001 19:26:54 +0200 (MET DST) Received: from u-223-19.karlsruhe.ipdial.viaginterkom.de(62.180.19.223), claiming to be "dea.waldorf-gmbh.de" via SMTP by guadalquivir.fnet.fr, id smtpd024881; Mon Jul 23 19:26:45 2001 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6NEnG302140; Mon, 23 Jul 2001 16:49:16 +0200 Date: Mon, 23 Jul 2001 16:49:16 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: time_init() enables interrupt. Message-ID: <20010723164916.B1245@bacchus.dhis.org> References: <20010723190544N.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: <20010723190544N.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Jul 23, 2001 at 07:05:44PM +0900 X-Accept-Language: de,en,fr Content-Length: 685 Lines: 20 On Mon, Jul 23, 2001 at 07:05:44PM +0900, Atsushi Nemoto wrote: > arch/mips/kernel/time.c:time_init() in current CVS contains following codes: > > /* setup xtime */ > write_lock_irq(&xtime_lock); > xtime.tv_sec = rtc_get_time(); > xtime.tv_usec = 0; > write_unlock_irq(&xtime_lock); > > The write_unlock_irq() macro calls __sti(), but it is too early to > enable interrupts. > > I think this write_lock_irq/write_unlock_irq pair should be removed > (or replaced with write_lock_irqsave/write_unlock_irqrestore pair). There is no point in locking there. This code is executed with interrupts disabled on the boot cpu only. I've removed the lock with no replacement. Ralf