From owner-linux-mips@oss.sgi.com Sun Jul 1 17:45:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f620j0N29082 for linux-mips-outgoing; Sun, 1 Jul 2001 17:45:00 -0700 Received: from dsic.co.kr ([210.221.126.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f620isV29070 for ; Sun, 1 Jul 2001 17:44:55 -0700 Received: from astonlinux.com [192.168.2.173] by dsic.co.kr [210.221.126.1] with SMTP (MDaemon.v3.5.6.R) for ; Mon, 02 Jul 2001 09:43:07 +0900 Message-ID: <3B407B8C.C18C839C@astonlinux.com> Date: Mon, 02 Jul 2001 09:47:56 -0400 From: =?EUC-KR?B?sK29xbHU?= Organization: astonlinux X-Mailer: Mozilla 4.75 [ko] (X11; U; Linux 2.2.16-21hl i686) X-Accept-Language: ko MIME-Version: 1.0 To: Ralph Metzler CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: Help me. References: <3B3B9C29.6898DC59@astonlinux.com> <15163.24240.316758.268911@valen.metzler> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-MDRemoteIP: 192.168.2.173 X-Return-Path: cosmos@astonlinux.com X-MDaemon-Deliver-To: linux-mips@oss.sgi.com Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Ralph Metzler wrote: > Hi, > > =?EUC-KR?B?sK29xbHU?= writes: > > I am trying to port a linux 2.4 to R3000 based system (LSI LOGIC > > SC2000). > > SC2000 have caches. one is Two-way set associative or direct mapped > > Instruction cache (16K) and another is Direct-mapped data cache(8K). > > I also spent one or two weeks with Linux on an SC2000 a while ago > but had to stop due to other more important projects. I also ran > into problems with the caching. Without caching I got it to boot > via NFS. Anyway, at least one mistake is in this part: > > > ---------------lsi-cache.S-------------------------------- > > > > /* void flush_icache(void) */ > > LEAF(flush_icache) > > .set noreorder > > > > la a3, icache_size # 8Kbyte > > lw t4, 0(a3) > > > > mfc0 t7, CP0_STATUS # save SR > > nop > > nop > > > > and t0, t7, ~ST0_IEC # disable interrupts > > mtc0 t0, CP0_STATUS > > nop > > nop > > > > li t3, CBSYS # BBCC configuration register > > lw t8, 0(t3) # save config. register > > nop > > > > li t0, KSEG0 > > or t4, t4, t0 # end of I-cache > > > > move t5, t0 > > > > 2: la t0, 3f # switch to Kseg1 > > or t0, KSEG1 > > jr t0 > > nop > > > > # > > # flush I-cache set 0 > > # > > 3: > > li t0, (CFG_DCEN | CFG_ICEN) > > or t0, CFG_CMODE_ITEST # I-cache set1 enable > > # D-cache enable, I-cache set0 > > enable > > # I-cache software test > > sw t0, 0(t3) > > lw zero, 0(t3) > > addi zero, zero, 1 > > > > move t0, t5 > > 4: sw zero, (t0) > > nop > > lw zero, (t0) > > addu t0, t6 > > bltu t0, t4, 4b > > nop > > Where does t6 get set? > This bug already is in the LSI sample code. > I think they just copied the loop code from the cache invalidation > functions (where they actually do determine t6 from the cache > line size) and forgot to adjust it. > > Best regards, > Ralph > > -- > /--------------------------------------------------------------------\ > | Dr. Ralph J.K. Metzler | Convergence integrated media | > |--------------------------------|-----------------------------------| > | rjkm@convergence.de | http://www.convergence.de/ | > \--------------------------------------------------------------------/ Thank you. I modified the bug. but problem is same. Regards, Shinkyu. From owner-linux-mips@oss.sgi.com Mon Jul 2 08:05:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f62F5sr17429 for linux-mips-outgoing; Mon, 2 Jul 2001 08:05:54 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f62F5oV17426 for ; Mon, 2 Jul 2001 08:05:50 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 2 09:05:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f62G5nt20394 for linux-mips-outgoing; Mon, 2 Jul 2001 09:05:49 -0700 Received: from dea.waldorf-gmbh.de (u-80-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f62G5lV20390 for ; Mon, 2 Jul 2001 09:05:47 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Tue Jul 3 04:10:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f63BADU25044 for linux-mips-outgoing; Tue, 3 Jul 2001 04:10:13 -0700 Received: from dea.waldorf-gmbh.de (u-238-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.238]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f63B8cV24796 for ; Tue, 3 Jul 2001 04:09:02 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f63B5VG15216; Tue, 3 Jul 2001 13:05:31 +0200 Date: Tue, 3 Jul 2001 13:05:31 +0200 From: Ralf Baechle To: Raghav P Cc: linux-mips@oss.sgi.com Subject: Re: Are page tables allocated in KSEG0 or in KSEG2? Message-ID: <20010703130531.C14665@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 raghav@ishoni.com on Sat, Jun 30, 2001 at 02:51:17PM +0530 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1672 Lines: 45 On Sat, Jun 30, 2001 at 02:51:17PM +0530, Raghav P wrote: > I was going thru the TLB exception for R2300 and had the following doubts > which I hope someone can help me out with. ( am sorry if this is a newbie > question but since this is MIPS specific I am posting here) > > The code is in arch/mips/kernel/head.S for user TLB: > > /* TLB refill, EXL == 0, R[23]00 version */ > LEAF(except_vec0_r2300) > .set noat > .set mips1 > mfc0 k0, CP0_BADVADDR > lw k1, current_pgd # get pgd pointer > srl k0, k0, 22 > sll k0, k0, 2 > addu k1, k1, k0 > mfc0 k0, CP0_CONTEXT > lw k1, (k1) > and k0, k0, 0xffc > addu k1, k1, k0 > lw k0, (k1) > nop > mtc0 k0, CP0_ENTRYLO0 > mfc0 k1, CP0_EPC > tlbwr > jr k1 > rfe > END(except_vec0_r2300) > > My linux book says that pgd and pte entries are not setup by the kernel > until a pagefault exception occurs. > The above code will work only if the pgd and pte tables are stored in kseg2; > if they were stored in kseg0 then if a pgd has an invalid pte entry the > above code will index into an invalid pte page and get a wrong physical > address. > But the pgd_alloc() and pte_alloc() routines seem to be allocating physical > pages from kseg0 for pgd and pte tables. > Am I missing something here??? We avoid having to deal with the special case of a non-existant parts of the page table except the actual ptes themselfes by having making those pgd pointers point to invalid_pte_table. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 4 00:16:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f647G9M29485 for linux-mips-outgoing; Wed, 4 Jul 2001 00:16:09 -0700 Received: from ex2k.pcs.psdc.com ([209.125.203.85]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f647G8V29480 for ; Wed, 4 Jul 2001 00:16:08 -0700 content-class: urn:content-classes:message Subject: sti() does not work. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 3 Jul 2001 15:48:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <84CE342693F11946B9F54B18C1AB837B05CE09@ex2k.pcs.psdc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sti() does not work. Thread-Index: AcEEEjekGV8jj/u2RbiXlO7KL288IQ== From: "Steven Liu" To: Cc: "stevenliu@psdc.com" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f647G8V29481 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 843 Lines: 37 Hi All: I am working on the porting Linux to mips R3000 and have a problem about sti( ) which is called in start_kernel( ). As we know, sti() is defined as __sti( ) in the include/asm-mips/system.h: extern __inline__ void __sti(void) { __asm__ __volatile__( ".set\tnoreorder\n\t" ".set\tnoat\n\t" "mfc0\t$1,$12\n\t" "ori\t$1,0x1f\n\t" "xori\t$1,0x1e\n\t" "mtc0\t$1,$12\n\t" /* <----- problem here ! */ ".set\tat\n\t" ".set\treorder" : /* no outputs */ : /* no inputs */ : "$1", "memory"); } Before calling this function, status_register = 0x1000fc00 and cause_register=0x00008000. Clearly, this is an interrupt of the CPU timer. When mtc0 instruction above is executed, the system hangs and the control does not go to the timer handler. Any help is greatly appreciated. Thank you. Steven liu From owner-linux-mips@oss.sgi.com Wed Jul 4 04:08:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f64B8VR12521 for linux-mips-outgoing; Wed, 4 Jul 2001 04:08:31 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f64B8UV12518 for ; Wed, 4 Jul 2001 04:08:30 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA06569 for ; Wed, 4 Jul 2001 03:23:33 -0700 (PDT) mail_from (ica2_ts@csv.ica.uni-stuttgart.de) Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id MAA148363 for ; Wed, 4 Jul 2001 12:23:31 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Hjof-00084W-00 for ; Wed, 04 Jul 2001 12:23:29 +0200 Date: Wed, 4 Jul 2001 12:23:29 +0200 To: linux-mips@oss.sgi.com Subject: Re: sti() does not work. Message-ID: <20010704122329.B30713@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84CE342693F11946B9F54B18C1AB837B05CE09@ex2k.pcs.psdc.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 724 Lines: 32 Steven Liu wrote: > Hi All: > > I am working on the porting Linux to mips R3000 and have a problem > about sti( ) which is called in start_kernel( ). > > As we know, sti() is defined as __sti( ) in the > include/asm-mips/system.h: > > extern __inline__ void __sti(void) > { > __asm__ __volatile__( > ".set\tnoreorder\n\t" > ".set\tnoat\n\t" > "mfc0\t$1,$12\n\t" > "ori\t$1,0x1f\n\t" > "xori\t$1,0x1e\n\t" > "mtc0\t$1,$12\n\t" /* <----- problem here > ! */ Here should follow some nop's on a MIPS I system to make sure $12 is written (why is noreorder used here?). > ".set\tat\n\t" > ".set\treorder" > : /* no outputs */ > : /* no inputs */ > : "$1", "memory"); > } HTH, Thiemo From owner-linux-mips@oss.sgi.com Wed Jul 4 05:22:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f64CMEw14346 for linux-mips-outgoing; Wed, 4 Jul 2001 05:22:14 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f64CMDV14343 for ; Wed, 4 Jul 2001 05:22:13 -0700 Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA09452 for ; Wed, 4 Jul 2001 05:22:04 -0700 (PDT) mail_from (raiko@niisi.msk.ru) 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 QAA03222; Wed, 4 Jul 2001 16:09:19 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id QAA01776; Wed, 4 Jul 2001 16:05:28 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id QAA21772; Wed, 4 Jul 2001 16:06:27 +0400 (MSD) Message-ID: <3B430AC6.6F8F6DD1@niisi.msk.ru> Date: Wed, 04 Jul 2001 16:23:34 +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: Thiemo Seufer CC: linux-mips@oss.sgi.com Subject: Re: sti() does not work. References: <20010704122329.B30713@rembrandt.csv.ica.uni-stuttgart.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 572 Lines: 20 Thiemo Seufer wrote: > > extern __inline__ void __sti(void) > > { > > __asm__ __volatile__( > > ".set\tnoreorder\n\t" > > ".set\tnoat\n\t" > > "mfc0\t$1,$12\n\t" > > "ori\t$1,0x1f\n\t" > > "xori\t$1,0x1e\n\t" > > "mtc0\t$1,$12\n\t" /* <----- problem here > > ! */ > > Here should follow some nop's on a MIPS I system to make sure $12 > is written (why is noreorder used here?). > Support for r3k in 2.2 is broken for a long time. Use 2.4 instead. Regards, Gleb. From owner-linux-mips@oss.sgi.com Wed Jul 4 17:32:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f650WNC02871 for linux-mips-outgoing; Wed, 4 Jul 2001 17:32:23 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f650WMV02852 for ; Wed, 4 Jul 2001 17:32:22 -0700 Received: from dea.waldorf-gmbh.de (u-157-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.157]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA00252 for ; Wed, 4 Jul 2001 06:44:21 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f64DTuG04889; Wed, 4 Jul 2001 15:29:56 +0200 Date: Wed, 4 Jul 2001 15:29:56 +0200 From: Ralf Baechle To: Steven Liu Cc: linux-mips@oss.sgi.com, "stevenliu@psdc.com" Subject: Re: sti() does not work. Message-ID: <20010704152956.F3829@bacchus.dhis.org> References: <84CE342693F11946B9F54B18C1AB837B05CE09@ex2k.pcs.psdc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <84CE342693F11946B9F54B18C1AB837B05CE09@ex2k.pcs.psdc.com>; from stevenliu@psdc.com on Tue, Jul 03, 2001 at 03:48:04PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 772 Lines: 20 On Tue, Jul 03, 2001 at 03:48:04PM -0700, Steven Liu wrote: > I am working on the porting Linux to mips R3000 and have a problem > about sti( ) which is called in start_kernel( ). > Before calling this function, status_register = 0x1000fc00 and > cause_register=0x00008000. > Clearly, this is an interrupt of the CPU timer. R3000 doesn't have a CPU timer, so either you're porting to something else than the R3000 or you don't have a CPU timer. > When mtc0 instruction above is executed, the system hangs and the > control does not go to the timer handler. When the mtc0 gets executed you take the pending interrupt which goes to the general exception vector at 0x80000180. That's magic done in hardware. So it looks like your interrupt handler is buggy. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 4 17:32:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f650WPp02898 for linux-mips-outgoing; Wed, 4 Jul 2001 17:32:25 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f650WNV02879 for ; Wed, 4 Jul 2001 17:32:23 -0700 Received: from dea.waldorf-gmbh.de (u-157-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.157]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id GAA01162 for ; Wed, 4 Jul 2001 06:44:21 -0700 (PDT) mail_from (ralf@dea.waldorf-gmbh.de) Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f64DQJP04877; Wed, 4 Jul 2001 15:26:19 +0200 Date: Wed, 4 Jul 2001 15:26:19 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: sti() does not work. Message-ID: <20010704152619.E3829@bacchus.dhis.org> References: <84CE342693F11946B9F54B18C1AB837B05CE09@ex2k.pcs.psdc.com> <20010704122329.B30713@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010704122329.B30713@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Wed, Jul 04, 2001 at 12:23:29PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1009 Lines: 28 On Wed, Jul 04, 2001 at 12:23:29PM +0200, Thiemo Seufer wrote: > > extern __inline__ void __sti(void) > > { > > __asm__ __volatile__( > > ".set\tnoreorder\n\t" > > ".set\tnoat\n\t" > > "mfc0\t$1,$12\n\t" > > "ori\t$1,0x1f\n\t" > > "xori\t$1,0x1e\n\t" > > "mtc0\t$1,$12\n\t" /* <----- problem here! */ > > Here should follow some nop's on a MIPS I system to make sure $12 > is written There are no nops there since we simply don't care how how many cycles after the mtc0 the interrupts actually get enabled. Worst case is the R4000's 8 stage pipeline where we have a latency of 3 cycles, clearly nothing that justifies wasting memory and cycles for nops. > (why is noreorder used here?). Without the .set noreorder the assembler would be free to do arbitrary reordering of the object code generated. Gas doesn't do that but there are other assemblers that do flow analysis and may generate object code that doesn't look very much like the source they were fed with. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 4 19:02:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65223T04324 for linux-mips-outgoing; Wed, 4 Jul 2001 19:02:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65221V04321 for ; Wed, 4 Jul 2001 19:02:01 -0700 Received: from viditec-netmedia.com.tw (61-220-240-70.HINET-IP.hinet.net [61.220.240.70]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA03600 for ; Wed, 4 Jul 2001 19:01:35 -0700 (PDT) mail_from (kj.lin@viditec-netmedia.com.tw) Received: from kjlin ([61.220.240.66]) by viditec-netmedia.com.tw (8.10.0/8.10.0) with SMTP id f653j4224457 for ; Thu, 5 Jul 2001 11:45:04 +0800 Message-ID: <013801c104f4$a807cf60$056aaac0@kjlin> From: "kjlin" To: Subject: Kernel panic: Attempted to kill init! Date: Thu, 5 Jul 2001 09:48:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0135_01C10537.B60055E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1690 Lines: 54 This is a multi-part message in MIME format. ------=_NextPart_000_0135_01C10537.B60055E0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi, When the kernel boots up and mounts the root file system,=20 the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a = AP. But in my case, it panics when kernel tries to do the = "execve("/sbin/AP",argv_init,envp_init)". The kernel panic message shows " Kernel panic: Attempted to kill init! = ". What situation will trigger such kernel panic? Thanks, KJ ------=_NextPart_000_0135_01C10537.B60055E0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi,
 
When the kernel boots up and mounts the root file = system,=20
the kernel start to do=20 "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do = the=20 "execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: = Attempted to=20 kill init! ".
What situation will trigger such kernel = panic?
 
Thanks,
KJ
------=_NextPart_000_0135_01C10537.B60055E0-- From owner-linux-mips@oss.sgi.com Wed Jul 4 20:16:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f653Gej05465 for linux-mips-outgoing; Wed, 4 Jul 2001 20:16:40 -0700 Received: from smtp.huawei.com ([202.96.135.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f653FfV05460 for ; Wed, 4 Jul 2001 20:15:56 -0700 Received: from z15805 ([10.105.34.205]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GFZCQQ00.U0X for ; Thu, 5 Jul 2001 11:08:50 +0800 Message-ID: <004301c10500$be67d820$cd22690a@huawei.com> From: "Shaolin Zhang" <1&2@oss.sgi.com> To: Subject: RTLinux for Mips Date: Thu, 5 Jul 2001 11:15:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id f653GeV05463 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 55 Lines: 4 Hi, anyone have experience of rtlinux from fsmlabs ? From owner-linux-mips@oss.sgi.com Thu Jul 5 02:04:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6594BT11823 for linux-mips-outgoing; Thu, 5 Jul 2001 02:04:11 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6594AV11820 for ; Thu, 5 Jul 2001 02:04:10 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA29010; Thu, 5 Jul 2001 02:04:04 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA28354; Thu, 5 Jul 2001 02:04:01 -0700 (PDT) Message-ID: <006a01c10532$13d4c760$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "kjlin" , References: <013801c104f4$a807cf60$056aaac0@kjlin> Subject: Re: Kernel panic: Attempted to kill init! Date: Thu, 5 Jul 2001 11:08:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01C10542.D60F6C80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2177 Lines: 60 This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C10542.D60F6C80 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable When the kernel boots up and mounts the root file system,=20 the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run = a AP. But in my case, it panics when kernel tries to do the = "execve("/sbin/AP",argv_init,envp_init)". The kernel panic message shows " Kernel panic: Attempted to kill init! = ". What situation will trigger such kernel panic? Well, bogus values for argv_init and envp_init would be the first thing = I would check... Kevin K. ------=_NextPart_000_0067_01C10542.D60F6C80 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
When the kernel boots up and mounts the root file = system,=20
the kernel start to do=20 "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do = the=20 "execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: = Attempted to=20 kill init! ".
What situation will trigger such kernel=20 panic?
Well, bogus values for argv_init and = envp_init would=20 be the first thing I would check...
 
       =20     Kevin K.
------=_NextPart_000_0067_01C10542.D60F6C80-- From owner-linux-mips@oss.sgi.com Thu Jul 5 02:10:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f659AYd11980 for linux-mips-outgoing; Thu, 5 Jul 2001 02:10:34 -0700 Received: from animal.pace.co.uk (gateway.pace.co.uk [195.44.197.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f659AWV11977 for ; Thu, 5 Jul 2001 02:10:33 -0700 Received: from exchange1.cam.pace.co.uk (exchange1.cam.pace.co.uk [136.170.131.80]) by animal.pace.co.uk (8.10.2/8.10.2) with ESMTP id f659AQS20819 for ; Thu, 5 Jul 2001 10:10:26 +0100 Received: by exchange1.cam.pace.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Jul 2001 10:09:51 +0100 Message-ID: <54045BFDAD47D5118A850002A5095CC30AC542@exchange1.cam.pace.co.uk> From: Phil Thompson To: "'linux-mips@oss.sgi.com'" Subject: OSS CVS Tree and 2.5.x Date: Thu, 5 Jul 2001 10:09:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 251 Lines: 9 I wasn't around the last time this would have happened... What happens to the OSS tree when 2.5.x gets started? Will 2.4.x and 2.5.x both be maintained on separate branches? (Personally I won't be interested in 2.5.x for a long time.) Thanks, Phil From owner-linux-mips@oss.sgi.com Thu Jul 5 04:13:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65BDAI14274 for linux-mips-outgoing; Thu, 5 Jul 2001 04:13:10 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65BCiV14261 for ; Thu, 5 Jul 2001 04:12:45 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2966 Lines: 98 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 owner-linux-mips@oss.sgi.com Thu Jul 5 04:33:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65BX0i14725 for linux-mips-outgoing; Thu, 5 Jul 2001 04:33:00 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65BWoV14719; Thu, 5 Jul 2001 04:32:54 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA12430; Thu, 5 Jul 2001 13:35:12 +0200 (MET DST) Date: Thu, 5 Jul 2001 13:35:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: sti() does not work. In-Reply-To: <20010704152619.E3829@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1578 Lines: 39 On Wed, 4 Jul 2001, Ralf Baechle wrote: > > > extern __inline__ void __sti(void) > > > { > > > __asm__ __volatile__( > > > ".set\tnoreorder\n\t" > > > ".set\tnoat\n\t" > > > "mfc0\t$1,$12\n\t" > > > "ori\t$1,0x1f\n\t" > > > "xori\t$1,0x1e\n\t" > > > "mtc0\t$1,$12\n\t" /* <----- problem here! */ > > > > Here should follow some nop's on a MIPS I system to make sure $12 > > is written > > There are no nops there since we simply don't care how how many cycles > after the mtc0 the interrupts actually get enabled. Worst case is the > R4000's 8 stage pipeline where we have a latency of 3 cycles, clearly > nothing that justifies wasting memory and cycles for nops. Still there is a nop missing after mfc0 if this is to be executed on a MIPS I CPU. The 2.4.x code is fine, though, so nothing to worry about. > > (why is noreorder used here?). > > Without the .set noreorder the assembler would be free to do arbitrary > reordering of the object code generated. Gas doesn't do that but there > are other assemblers that do flow analysis and may generate object code > that doesn't look very much like the source they were fed with. Hmm, I would consider that a bug in such an assembler. The mtc0 and possibly the mfc0 opcode should be treated as reordering barriers as they may involve side effects an assembler might not be aware of. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Thu Jul 5 07:16:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65EGPb18016 for linux-mips-outgoing; Thu, 5 Jul 2001 07:16:25 -0700 Received: from arianne.in.ishoni.com ([164.164.83.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65EGKV18013 for ; Thu, 5 Jul 2001 07:16:21 -0700 Received: from deepak ([192.168.1.197]) by arianne.in.ishoni.com (8.11.1/8.11.4/Ishonir2) with SMTP id f65EGvD13257; Thu, 5 Jul 2001 19:46:57 +0530 Reply-To: From: "Deepak Shenoy" To: "'kjlin'" , Subject: RE: Kernel panic: Attempted to kill init! Date: Thu, 5 Jul 2001 19:50:43 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C1058D.04322F90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3277 Lines: 94 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C1058D.04322F90 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit "init" is started with pid 1. If this process is killed you get this message. it could be possible that your init kernel thread is returning, exiting etc. deepak -----Original Message----- From: owner-linux-mips@oss.sgi.com [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of kjlin Sent: Thursday, July 05, 2001 7:19 AM To: linux-mips@oss.sgi.com Subject: Kernel panic: Attempted to kill init! Hi, When the kernel boots up and mounts the root file system, the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP. But in my case, it panics when kernel tries to do the "execve("/sbin/AP",argv_init,envp_init)". The kernel panic message shows " Kernel panic: Attempted to kill init! ". What situation will trigger such kernel panic? Thanks, KJ ------=_NextPart_000_001D_01C1058D.04322F90 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
"init" is started with pid 1. If this process = is killed=20 you get this message.
it could be possible that your init kernel = thread is=20 returning, exiting etc.
 
deepak
-----Original Message-----
From: = owner-linux-mips@oss.sgi.com=20 [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of = kjlin
Sent:=20 Thursday, July 05, 2001 7:19 AM
To:=20 linux-mips@oss.sgi.com
Subject: Kernel panic: Attempted to = kill=20 init!

Hi,
 
When the kernel boots up and mounts the root file = system,=20
the kernel start to do=20 "execve("/sbin/AP",argv_init,envp_init)" to run a AP.
But in my case, it panics when kernel tries to do = the=20 "execve("/sbin/AP",argv_init,envp_init)".
The kernel panic message shows " Kernel panic: = Attempted to=20 kill init! ".
What situation will trigger such kernel = panic?
 
Thanks,
KJ
------=_NextPart_000_001D_01C1058D.04322F90-- From owner-linux-mips@oss.sgi.com Thu Jul 5 07:26:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65EQwW18320 for linux-mips-outgoing; Thu, 5 Jul 2001 07:26:58 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65EQvV18317 for ; Thu, 5 Jul 2001 07:26:57 -0700 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: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1025 Lines: 24 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 owner-linux-mips@oss.sgi.com Thu Jul 5 08:09:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65F9Ap19128 for linux-mips-outgoing; Thu, 5 Jul 2001 08:09:10 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65F91V19124 for ; Thu, 5 Jul 2001 08:09:06 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1485 Lines: 31 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 owner-linux-mips@oss.sgi.com Thu Jul 5 10:55:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65HtCm23420 for linux-mips-outgoing; Thu, 5 Jul 2001 10:55:12 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65HtBV23417 for ; Thu, 5 Jul 2001 10:55:11 -0700 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 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Thu Jul 5 11:22:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f65IMC423906 for linux-mips-outgoing; Thu, 5 Jul 2001 11:22:12 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f65IM7V23902 for ; Thu, 5 Jul 2001 11:22:08 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1059 Lines: 26 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 owner-linux-mips@oss.sgi.com Fri Jul 6 01:17:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f668HJ930626 for linux-mips-outgoing; Fri, 6 Jul 2001 01:17:19 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f668HIV30622 for ; Fri, 6 Jul 2001 01:17:18 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA08815; Fri, 6 Jul 2001 01:17:01 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA06224; Fri, 6 Jul 2001 01:16:59 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f668Fra13194; Fri, 6 Jul 2001 10:15:54 +0200 (MEST) Message-ID: <3B4573B8.9F89022B@mips.com> Date: Fri, 06 Jul 2001 10:15:52 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Illegal instruction Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 675 Lines: 23 Hi Karel, I have tried the root-images tar-files: mipselroot-rh7-20010606 and mipsroot-rh7. The mipsroot-rh7 (bigendian) root image seem to work fine, but when I use the mipselroot-rh7-20010606 (littleendian) I get an illegal instruction. [cat:179] Illegal instruction 7c010001 at 2ac8b20c ra=00000000. I'm using a 2.4.3 kernel. Anyone got an idea ? /Carsten -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Fri Jul 6 02:27:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f669R8X02207 for linux-mips-outgoing; Fri, 6 Jul 2001 02:27:08 -0700 Received: from pandora.research.kpn.com (IDENT:root@pandora.research.kpn.com [139.63.192.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f669R6V02198 for ; Fri, 6 Jul 2001 02:27:06 -0700 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by pandora.research.kpn.com (8.9.3/8.9.3) with ESMTP id LAA12355; Fri, 6 Jul 2001 11:27:04 +0200 Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6]) by sparta.research.kpn.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10388; Fri, 6 Jul 2001 11:27:03 +0200 (MET DST) Message-Id: <200107060927.LAA10388@sparta.research.kpn.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Carsten Langgaard cc: vhouten@kpn.com, linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: Illegal instruction In-reply-to: Your message of "Fri, 06 Jul 2001 10:15:52 +0200." <3B4573B8.9F89022B@mips.com> Reply-to: vhouten@kpn.com X-Face: ";:TzQQC{mTp~$W,'m4@Lu1Lu$rtG_~5kvYO~F:C'KExk9o1X"iRz[0%{bq?6Aj#>VhSD?v 1W9`.Qsf+P&*iQEL8&y,RDj&U.]!(R-?c-h5h%Iw%r$|%6+Jc>GTJe!_1&A0o'lC[`I#={2BzOXT1P q366I$WL=;[+SDo1RoIT+a}_y68Y:jQ^xp4=*4-ryiymi>hy Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Jul 2001 11:27:03 +0200 From: "Houten K.H.C. van (Karel)" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 842 Lines: 26 Carsten Langgaard wrote: > I have tried the root-images tar-files: mipselroot-rh7-20010606 and > mipsroot-rh7. > The mipsroot-rh7 (bigendian) root image seem to work fine, but when > I use the mipselroot-rh7-20010606 (littleendian) I get an illegal > instruction. > [cat:179] Illegal instruction 7c010001 at 2ac8b20c ra=00000000. > > I'm using a 2.4.3 kernel. > Anyone got an idea ? I'm still using 2.4.0-test9 on mipsel, because I've problems with the newer kernels too. I hope to test H.J. Lu's toolchain/glibc, but currently it is much to hot to switch on extra computers :-) Regards, -- Karel van Houten ---------------------------------------------------------- The box said "Requires Windows 95 or better." I can't understand why it won't work on my Linux computer. ---------------------------------------------------------- From owner-linux-mips@oss.sgi.com Fri Jul 6 04:41:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66BfFK16218 for linux-mips-outgoing; Fri, 6 Jul 2001 04:41:15 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66Bf8V16188 for ; Fri, 6 Jul 2001 04:41:12 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA07545; Fri, 6 Jul 2001 13:42:31 +0200 (MET DST) Date: Fri, 6 Jul 2001 13:42:31 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Houten K.H.C. van (Karel)" cc: Carsten Langgaard , linux-mips@oss.sgi.com, karel@sparta.research.kpn.com Subject: Re: Illegal instruction In-Reply-To: <200107060927.LAA10388@sparta.research.kpn.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 605 Lines: 14 On Fri, 6 Jul 2001, Houten K.H.C. van (Karel) wrote: > I'm still using 2.4.0-test9 on mipsel, because I've problems with the > newer kernels too. I hope to test H.J. Lu's toolchain/glibc, but > currently it is much to hot to switch on extra computers :-) Weird, I'm using 2.4.5 for more than a week now on my /240 and it appears to work fine. I've built it with my old tools which I'm still using. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jul 6 06:25:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66DPSi29796 for linux-mips-outgoing; Fri, 6 Jul 2001 06:25:28 -0700 Received: from relay ([207.81.96.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66DPRV29785 for ; Fri, 6 Jul 2001 06:25:27 -0700 Received: from vcubed.com ([207.81.96.153]) by relay (8.8.7/8.8.7) with ESMTP id JAA00539; Fri, 6 Jul 2001 09:57:32 -0400 Message-ID: <3B45BC99.E7135DD3@vcubed.com> Date: Fri, 06 Jul 2001 09:26:49 -0400 From: Dan Aizenstros Organization: V3 Semiconductor Corp. X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Carsten Langgaard CC: vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Illegal instruction References: <3B4573B8.9F89022B@mips.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 869 Lines: 30 Hello Carsten, I have seen the same thing on the same kernel version. Dan Aizenstros Software Engineer V3 Semiconductor Corp. Carsten Langgaard wrote: > > Hi Karel, > > I have tried the root-images tar-files: mipselroot-rh7-20010606 and > mipsroot-rh7. > The mipsroot-rh7 (bigendian) root image seem to work fine, but when > I use the mipselroot-rh7-20010606 (littleendian) I get an illegal > instruction. > [cat:179] Illegal instruction 7c010001 at 2ac8b20c ra=00000000. > > I'm using a 2.4.3 kernel. > Anyone got an idea ? > > /Carsten > > -- > _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com > |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 > | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 > TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 > Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Fri Jul 6 11:17:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66IHCr13266 for linux-mips-outgoing; Fri, 6 Jul 2001 11:17:12 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66IHBV13263; Fri, 6 Jul 2001 11:17:11 -0700 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 f66IH6021938; Fri, 6 Jul 2001 11:17:06 -0700 Message-ID: <3B45FFEA.F8D95F0B@mvista.com> Date: Fri, 06 Jul 2001 11:14:02 -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: Shaolin Zhang <1&2@oss.sgi.com> CC: linux-mips@oss.sgi.com Subject: Re: RTLinux for Mips References: <004301c10500$be67d820$cd22690a@huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 378 Lines: 13 Shaolin Zhang wrote: > > Hi, > anyone have experience of rtlinux from fsmlabs ? Not rtlinux, but I have got the Nigel Gamble's preemptable kernel patch ported to MIPS. This patch shrinks the maximum preemption delay of a process to single digit of milliseconds. Unless absolutely necessary, I would think preemptable kernel is a better real-time approach than rtlinux. Jun From owner-linux-mips@oss.sgi.com Fri Jul 6 11:25:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66IP8113469 for linux-mips-outgoing; Fri, 6 Jul 2001 11:25:08 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66IP7V13466 for ; Fri, 6 Jul 2001 11:25:07 -0700 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 f66INg022312; Fri, 6 Jul 2001 11:23:42 -0700 Message-ID: <3B460176.37CD992D@mvista.com> Date: Fri, 06 Jul 2001 11:20:38 -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: kjlin CC: linux-mips@oss.sgi.com Subject: Re: Kernel panic: Attempted to kill init! References: <013801c104f4$a807cf60$056aaac0@kjlin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 636 Lines: 19 > kjlin wrote: > > Hi, > > When the kernel boots up and mounts the root file system, > the kernel start to do "execve("/sbin/AP",argv_init,envp_init)" to run a AP. > But in my case, it panics when kernel tries to do the > "execve("/sbin/AP",argv_init,envp_init)". > The kernel panic message shows " Kernel panic: Attempted to kill init! ". > What situation will trigger such kernel panic? > > Thanks, > KJ A common reason is that /sbin/AP has a seg fault or some other faults. I would debug AP program in a stable environment and then make sure I can see the first "printf" from AP. From there, you can debug AP with printf. Jun From owner-linux-mips@oss.sgi.com Fri Jul 6 11:45:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66IjIp14051 for linux-mips-outgoing; Fri, 6 Jul 2001 11:45:18 -0700 Received: from thud.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66IjHV14048; Fri, 6 Jul 2001 11:45:17 -0700 Received: (from pmundt@localhost) by thud.mvista.com (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id f66ImjW29905; Fri, 6 Jul 2001 11:48:45 -0700 Date: Fri, 6 Jul 2001 11:48:45 -0700 From: Paul Mundt To: Shaolin Zhang <1&2@oss.sgi.com> Cc: linux-mips@oss.sgi.com Subject: Re: RTLinux for Mips Message-ID: <20010706114845.C29684@mvista.com> References: <004301c10500$be67d820$cd22690a@huawei.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <004301c10500$be67d820$cd22690a@huawei.com>; from 1&2@oss.sgi.com on Thu, Jul 05, 2001 at 11:15:29AM +0800 Organization: MontaVista Software, Inc. Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 781 Lines: 33 --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 05, 2001 at 11:15:29AM +0800, Shaolin Zhang wrote: > anyone have experience of rtlinux from fsmlabs ? >=20 RTL hasn't been ported to MIPS. It only runs on x86/PPC/Alpha and only supports SMP on x86 and PPC. Regards, --=20 Paul Mundt MontaVista Software, Inc. --cQXOx3fnlpmgJsTP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtGCA0ACgkQYLvqhoOEA4FmJwCdGumKFY6qHHGr9Xoy79ehq3yg mokAn0MUGy/vwCF00NJWtQULE8p9nU3z =HsuL -----END PGP SIGNATURE----- --cQXOx3fnlpmgJsTP-- From owner-linux-mips@oss.sgi.com Fri Jul 6 15:13:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f66MD3H18938 for linux-mips-outgoing; Fri, 6 Jul 2001 15:13:03 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f66MCtV18934; Fri, 6 Jul 2001 15:12:55 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02422; Fri, 6 Jul 2001 15:13:07 -0700 (PDT) mail_from (jsun@mvista.com) 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 f66M7l004332; Fri, 6 Jul 2001 15:07:47 -0700 Message-ID: <3B4635FB.1ED5D222@mvista.com> Date: Fri, 06 Jul 2001 15:04:43 -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: Carsten Langgaard , ralf@oss.sgi.com CC: vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Illegal instruction References: <3B4573B8.9F89022B@mips.com> Content-Type: multipart/mixed; boundary="------------DC8F502FDCB345276A852AE0" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 10184 Lines: 331 This is a multi-part message in MIME format. --------------DC8F502FDCB345276A852AE0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carsten Langgaard wrote: > > Hi Karel, > > I have tried the root-images tar-files: mipselroot-rh7-20010606 and > mipsroot-rh7. > The mipsroot-rh7 (bigendian) root image seem to work fine, but when > I use the mipselroot-rh7-20010606 (littleendian) I get an illegal > instruction. > [cat:179] Illegal instruction 7c010001 at 2ac8b20c ra=00000000. > > I'm using a 2.4.3 kernel. > Anyone got an idea ? > > /Carsten > Is the userland compiled with MIPS I option? I bet this is the same nasty MIPS_ATOMIC_SET bug. Currently, there are three fixes. One is from Florian, which only takes care of CPUs with ll/sc. Another is from Maceij, which introduces a new syscall, and some changes in glibc. The thrid is mine, a compromising one. It takes care of both ll/sc case and non-llsc case, has minimum change, and practically makes all programs happy. Ralf, please take at least one of the fixes. Even a not-so-good fix is better than no fix. Jun --------------DC8F502FDCB345276A852AE0 Content-Type: text/plain; charset=us-ascii; name="MIPS_ATOMIC_SET-compromising-fix.010626.010626.pathc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="MIPS_ATOMIC_SET-compromising-fix.010626.010626.pathc" This is a compromising fix for sysmips(MIPS_ATOMIC_SET, ...). It forces SIGSYS when the return value is a small negative value. This limit is OK for glibc. Jun diff -Nru linux/arch/mips/kernel/sysmips.c.orig linux/arch/mips/kernel/sysmips.c --- linux/arch/mips/kernel/sysmips.c.orig Mon Apr 23 11:32:54 2001 +++ linux/arch/mips/kernel/sysmips.c Tue Jun 26 11:50:48 2001 @@ -16,7 +16,7 @@ #include #include #include - +#include #include #include #include @@ -75,53 +75,83 @@ } case MIPS_ATOMIC_SET: { -#ifdef CONFIG_CPU_HAS_LLSC - unsigned int tmp; + int *ptr, val, ret, err, tmp; + struct siginfo info; - 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" - ".previous\n\t" - ".section\t__ex_table,\"a\"\n\t" - ".word\t1b, 3b\n\t" - ".word\t2b, 3b\n\t" - ".previous\n\t" - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) - : "r" (arg2), "o" (* (u32 *) p), "2" (errno) - : "$1"); + ptr = (int *)arg1; + val = (int)arg2; - if (errno) - return -EFAULT; + /* Don't emulate unaligned accesses. */ + if ((int)ptr & 3) { + info.si_signo = SIGBUS; + info.si_code = BUS_ADRALN; + goto fault; + } + + /* A zero here saves us three instructions. */ + err = verify_area(VERIFY_WRITE, ptr, 0); + if (err) { + info.si_signo = SIGSEGV; + info.si_code = SEGV_ACCERR; + goto fault; + } - /* We're skipping error handling etc. */ - if (current->ptrace & PT_TRACESYS) - syscall_trace(); - - ((struct pt_regs *)&cmd)->regs[2] = tmp; - ((struct pt_regs *)&cmd)->regs[7] = 0; - - __asm__ __volatile__( - "move\t$29, %0\n\t" - "j\to32_ret_from_sys_call" - : /* No outputs */ - : "r" (&cmd)); - /* Unreached */ +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set mips2\n\t" + "1:\n\t" + "ll %0,%5\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beq %0,%4,3f\n\t" + " move %3,%4\n" + ".set pop\n\t" + "2:\n\t" + "sc %3,%1\n\t" + "beqz %3,1b\n\t" + "3:\n\t" + ".set mips0\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2,%7\n\t" + "j 3b\n\t" + ".previous\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b,4b\n\t" + ".word 2b,4b\n\t" + ".previous" + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); #else - printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n"); + save_and_cli(tmp); + err = __get_user(ret, ptr); + if (ret != val) + err |= __put_user(val, ptr); /* No fault + unless unwriteable. */ + restore_flags(tmp); #endif + + if (err) { + info.si_signo = SIGSEGV; + info.si_code = SEGV_MAPERR; + goto fault; + } + + if ( (ret < 0) && (ret >= -EMAXERRNO) ) { + info.si_signo = SIGSYS; + info.si_code = 0; + goto fault; + } + + return ret; + +fault: + /* Go back to SYSCALL. */ + ((struct pt_regs *)&cmd)->cp0_epc -= 4; + + info.si_addr = (void *)((struct pt_regs *)&cmd)->cp0_epc; + force_sig_info(info.si_signo, &info, current); + + return 0; } case MIPS_FIXADE: --------------DC8F502FDCB345276A852AE0 Content-Type: text/plain; charset=us-ascii; name="flo-fast-sysmips.0105X.X.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="flo-fast-sysmips.0105X.X.patch" diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile --- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 +++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 @@ -20,7 +20,7 @@ obj-y += branch.o process.o signal.o entry.o \ traps.o ptrace.o vm86.o ioport.o reset.o \ semaphore.o setup.o syscall.o sysmips.o \ - ipc.o scall_o32.o unaligned.o + ipc.o scall_o32.o unaligned.o fast-sysmips.o obj-$(CONFIG_MODULES) += mips_ksyms.o ifdef CONFIG_CPU_R3000 @@ -69,5 +69,6 @@ entry.o: entry.S head.o: head.S +fast-sysmips.o: fast-sysmips.S include $(TOPDIR)/Rules.make diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S --- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 @@ -0,0 +1,85 @@ +/* + * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2001 Florian Lohoff + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PT_TRACESYS 0x00000002 + + EXPORT(fast_sysmips) + + .set noreorder + + li t0, MIPS_ATOMIC_SET + beq a0, t0, 1f + nop + j sys_sysmips + nop + +1: + + # a0 - MIPS_ATOMIC_SET + # a1 - mem ptr + # a2 - value + + addiu sp, sp, -8 # Reserve space + sw a0, (sp) # Save arg0 + + addiu a0, a1, 4 # addr+size + ori v0, a1, 4 # addr | size + lw v1, THREAD_CURDS(gp) # current->thread.current_ds + or v0, v0, a0 # addr | size | (addr+size) + and v1, v1, v0 # (mask)&(addr | size | (addr+size) + bltz v1, 5f + nop + +2: + ll v0, (a1) + move t0, a2 + sc t0, (a1) + beqz t0, 2b + nop + + sw v0, PT_R2+8(sp) # Result value + sw zero, PT_R7+8(sp) # Success indicator + + lw t0, TASK_PTRACE(gp) # syscall tracing enabled? + andi t0, PT_TRACESYS + bnez t0, 3f + nop + +4: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + + j o32_ret_from_sys_call + nop + +3: + sw ra, 4(sp) + jal syscall_trace + nop + lw ra, 4(sp) + j 4b + nop + +5: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + j ra + li v0, -EFAULT + diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h --- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 +++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 @@ -69,7 +69,7 @@ SYS(irix_getgid, 0) /* 1047 getgid() V*/ SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ -SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ +SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h --- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 +++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 @@ -163,7 +163,7 @@ SYS(sys_writev, 3) SYS(sys_cacheflush, 3) SYS(sys_cachectl, 3) -SYS(sys_sysmips, 4) +SYS(fast_sysmips, 4) SYS(sys_ni_syscall, 0) /* 4150 */ SYS(sys_getsid, 1) SYS(sys_fdatasync, 0) --------------DC8F502FDCB345276A852AE0-- From owner-linux-mips@oss.sgi.com Sat Jul 7 05:32:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67CW1403893 for linux-mips-outgoing; Sat, 7 Jul 2001 05:32:01 -0700 Received: from dea.waldorf-gmbh.de (u-6-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.6]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67CVuV03882 for ; Sat, 7 Jul 2001 05:31:56 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Sat Jul 7 09:42:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67Ggoa30121 for linux-mips-outgoing; Sat, 7 Jul 2001 09:42:50 -0700 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67GgnV30118 for ; Sat, 7 Jul 2001 09:42:49 -0700 Received: from real.realitydiluted.com ([208.242.241.164] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15IvAI-0001kK-00 for ; Sat, 07 Jul 2001 11:42:42 -0500 Message-ID: <3B473ABF.F2444CEE@cotw.com> Date: Sat, 07 Jul 2001 11:37:19 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Documentation on MIPS kernel options... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 778 Lines: 28 Greetings. I have been having some correspondance with Eric Raymond (ESR) concerning MIPS configuration options. I have already sent him a fairly good sized list of descriptions for some MIPS options that will be utilized in the CML2 build system for the 2.5.x and 2.6.x series kernels. He sent me another list of items and I decided to ask those of you on the list to provide the descriptions. Please send me the descriptions and at the end of next week I will compile the results and send them off to Eric. Thanks. -Steve CONFIG_ARC_CONSOLE CONFIG_AU1000_UART CONFIG_EVB_PCI1 CONFIG_FORWARD_KEYBOARD CONFIG_GDB_CONSOLE CONFIG_IT8172_REVC CONFIG_IT8172_SCR0 CONFIG_IT8172_SCR1 CONFIG_SYSCLK_100 CONFIG_SYSCLK_75 CONFIG_SYSCLK_83 -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Sat Jul 7 11:58:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67IwZh03362 for linux-mips-outgoing; Sat, 7 Jul 2001 11:58:35 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67IwXV03358 for ; Sat, 7 Jul 2001 11:58:34 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 9370F3E90; Sat, 7 Jul 2001 11:51:32 -0700 (PDT) Date: Sat, 7 Jul 2001 11:51:32 -0700 From: Keith M Wesolowski To: "Steven J. Hill" Cc: linux-mips@oss.sgi.com Subject: Re: Documentation on MIPS kernel options... Message-ID: <20010707115132.A452@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B473ABF.F2444CEE@cotw.com> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 852 Lines: 23 On Sat, Jul 07, 2001 at 11:37:19AM -0500, Steven J. Hill wrote: > CONFIG_ARC_CONSOLE This arguably belongs to the Kernel Hacking section (or its CML2 equivalent). It isn't useful (and in fact will be highly frustrating) for anyone else. ---cut here--- The ARC console is a low-level console device using the ARC firmware for output. This is useful for debugging, especially if there is no driver for the serial ports. You cannot use the ARC console as a general serial device. Unless you have a specific requirement for this functionality, you should not select this option. ---cut here--- -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Sat Jul 7 12:24:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67JOgn05924 for linux-mips-outgoing; Sat, 7 Jul 2001 12:24:42 -0700 Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67JOfV05913 for ; Sat, 7 Jul 2001 12:24:41 -0700 Received: from pacbell.net ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GG400EYZB948K@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Sat, 07 Jul 2001 12:24:40 -0700 (PDT) Date: Sat, 07 Jul 2001 12:23:26 -0700 From: Pete Popov Subject: Re: Documentation on MIPS kernel options... To: sjhill@cotw.com Cc: linux-mips@oss.sgi.com Reply-to: ppopov@pacbell.net Message-id: <3B4761AE.3040601@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <3B473ABF.F2444CEE@cotw.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1377 Lines: 61 Steven J. Hill wrote: > Greetings. > > I have been having some correspondance with Eric Raymond (ESR) > concerning MIPS configuration options. I have already sent him > a fairly good sized list of descriptions for some MIPS options > that will be utilized in the CML2 build system for the 2.5.x > and 2.6.x series kernels. He sent me another list of items and > I decided to ask those of you on the list to provide the > descriptions. Please send me the descriptions and at the end of > next week I will compile the results and send them off to > Eric. Thanks. > > -Steve > CONFIG_ARC_CONSOLE > CONFIG_AU1000_UART The uart on the Alchemy Au1000 is almost a 16550 but not quite. I've added support for that uart in the non-standard uart section in drivers/char/Config.in. This option is needed if you want uart support for debug and/or serial console. > CONFIG_EVB_PCI1 > CONFIG_FORWARD_KEYBOARD > CONFIG_GDB_CONSOLE > CONFIG_IT8172_REVC An older version of the IT8172 system controller what has slightly different pci mem windows. However, I don't think we need to support this anymore so I plan on dumping this asap. > CONFIG_IT8172_SCR0 > CONFIG_IT8172_SCR1 On the IT8172 system controller, Smart Card Reader 0 and 1. > CONFIG_SYSCLK_100 > CONFIG_SYSCLK_75 > CONFIG_SYSCLK_83 Let me know if you need additional information. Thanks, Pete From owner-linux-mips@oss.sgi.com Sat Jul 7 16:47:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f67NlGA09544 for linux-mips-outgoing; Sat, 7 Jul 2001 16:47:16 -0700 Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com [216.136.175.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f67NlFV09539 for ; Sat, 7 Jul 2001 16:47:15 -0700 Message-ID: <20010707234715.80453.qmail@web13903.mail.yahoo.com> Received: from [61.187.63.15] by web13903.mail.yahoo.com via HTTP; Sat, 07 Jul 2001 16:47:15 PDT Date: Sat, 7 Jul 2001 16:47:15 -0700 (PDT) From: Barry Wu Subject: Can mipsel linux support module? To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 564 Lines: 21 Hi, all, I just port mipsel linux 2.2.12 to our hardware evaluation board. I want to modify a module to a character device driver. But I do not know how to do and which files to update. Can mipsel linux support module? If so, which rpm do I have to download and where can I find them? If not, how can I change a module to a character device driver? If someone knows, please help me. Thanks in advance! Barry __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Sun Jul 8 10:15:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f68HFGj11473 for linux-mips-outgoing; Sun, 8 Jul 2001 10:15:16 -0700 Received: from bug.ucw.cz (root@[194.213.32.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f68HF8V11469 for ; Sun, 8 Jul 2001 10:15:09 -0700 Received: (from root@localhost) by bug.ucw.cz (8.9.3/8.8.5) id SAA00277; Sun, 8 Jul 2001 18:31:14 +0200 Date: Sat, 30 Jun 2001 14:57:33 +0000 From: Pavel Machek To: James Simmons Cc: Linux Kernel Mailing List , linux-mips@oss.sgi.com Subject: Re: [ANNOUNCE] Secondary mips tree. Message-ID: <20010630145732.E255@toy.ucw.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jsimmons@transvirtual.com on Fri, Jun 22, 2001 at 01:57:38PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1006 Lines: 29 Hi! > We have started a secondary tree for linux mips. This tree will > be to SGI mips tree as Alan Cox's tree is to linus branch. We will test > and play with "experimental patches" and then in time hand them off to the > main branch Ralf Baechle maintains. Also one of the main reasons for this > branch was to unite several of the mips trees into one place. Anyones > patches (if good) are welcomed. The site is Do you want to "eat" linux-vr tree? linux-vr list is dead and there's no (or not much) development in its CVS (at 240t7 :-() > http://www.sf.net/projects/linux-mips Is this sourceforge? > We also have a mailing list which instructions are on the SF page on how > to join. Thank you. Is it ok to be used as linux-vr list? > P.S > If anyone has the mips cobalt working with 2.4.X I really like those > patches. Thank you. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From owner-linux-mips@oss.sgi.com Sun Jul 8 11:32:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f68IWgr12402 for linux-mips-outgoing; Sun, 8 Jul 2001 11:32:42 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f68IWdV12399 for ; Sun, 8 Jul 2001 11:32:39 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f68IWVbp023410; Sun, 8 Jul 2001 11:32:31 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f68IWV6a023406; Sun, 8 Jul 2001 11:32:31 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Sun, 8 Jul 2001 11:32:31 -0700 (PDT) From: James Simmons To: Pavel Machek cc: Linux Kernel Mailing List , linux-mips@oss.sgi.com Subject: Re: [ANNOUNCE] Secondary mips tree. In-Reply-To: <20010630145732.E255@toy.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1151 Lines: 30 > > We have started a secondary tree for linux mips. This tree will > > be to SGI mips tree as Alan Cox's tree is to linus branch. We will test > > and play with "experimental patches" and then in time hand them off to the > > main branch Ralf Baechle maintains. Also one of the main reasons for this > > branch was to unite several of the mips trees into one place. Anyones > > patches (if good) are welcomed. The site is > > Do you want to "eat" linux-vr tree? linux-vr list is dead and there's no > (or not much) development in its CVS (at 240t7 :-() Yes. We are reworking the VR code and placing it into our tree. > > http://www.sf.net/projects/linux-mips > > Is this sourceforge? Yep. > > We also have a mailing list which instructions are on the SF page on how > > to join. Thank you. > > Is it ok to be used as linux-vr list? I have no problem with it. VR is apart of the mips developement we are doing. Also we do alot of IT 8172 and au1000 devleopement as well. Plus some early work for the cobalt cube is being done. I will finish the cube now that we have a pretty generic pci code layer that is shared amoung many boards. From owner-linux-mips@oss.sgi.com Tue Jul 10 04:16:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ABGrG09084 for linux-mips-outgoing; Tue, 10 Jul 2001 04:16:53 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ABGbV09079; Tue, 10 Jul 2001 04:16:38 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA19205; Tue, 10 Jul 2001 04:15:26 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA15669; Tue, 10 Jul 2001 04:15:23 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6ABECa04995; Tue, 10 Jul 2001 13:14:13 +0200 (MEST) Message-ID: <3B4AE384.52049D47@mips.com> Date: Tue, 10 Jul 2001 13:14:12 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com, "H . J . Lu" Subject: Re: Illegal instruction References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 12535 Lines: 337 Thanks, that did the trick. Now I would like to try to install H.J. Lu's RedHat7.1 RPM packages. If I just do a: rpm -Uvh --root /mnt/harddisk *.rpm then it fails on a lot of dependencies. If I try to force the install like this: rpm -Uvh --nodeps --force --root /mnt/harddisk *.rpm then it actually install a lot of the RPMs, but still some fails, because it actually need then dependencies. If I try to redo the above it seems to go better the second time, because a lot of the dependencies is solved (installed). Is this really the way to install a set of RPMs like this or is there a better way? /Carsten Jun Sun wrote: > Carsten Langgaard wrote: > > > > Hi Karel, > > > > I have tried the root-images tar-files: mipselroot-rh7-20010606 and > > mipsroot-rh7. > > The mipsroot-rh7 (bigendian) root image seem to work fine, but when > > I use the mipselroot-rh7-20010606 (littleendian) I get an illegal > > instruction. > > [cat:179] Illegal instruction 7c010001 at 2ac8b20c ra=00000000. > > > > I'm using a 2.4.3 kernel. > > Anyone got an idea ? > > > > /Carsten > > > > Is the userland compiled with MIPS I option? I bet this is the same nasty > MIPS_ATOMIC_SET bug. > > Currently, there are three fixes. One is from Florian, which only takes care > of CPUs with ll/sc. Another is from Maceij, which introduces a new syscall, > and some changes in glibc. The thrid is mine, a compromising one. It takes > care of both ll/sc case and non-llsc case, has minimum change, and practically > makes all programs happy. > > Ralf, please take at least one of the fixes. Even a not-so-good fix is better > than no fix. > > Jun > > ------------------------------------------------------------------------ > > This is a compromising fix for sysmips(MIPS_ATOMIC_SET, ...). It > forces SIGSYS when the return value is a small negative value. This > limit is OK for glibc. > > Jun > > diff -Nru linux/arch/mips/kernel/sysmips.c.orig linux/arch/mips/kernel/sysmips.c > --- linux/arch/mips/kernel/sysmips.c.orig Mon Apr 23 11:32:54 2001 > +++ linux/arch/mips/kernel/sysmips.c Tue Jun 26 11:50:48 2001 > @@ -16,7 +16,7 @@ > #include > #include > #include > - > +#include > #include > #include > #include > @@ -75,53 +75,83 @@ > } > > case MIPS_ATOMIC_SET: { > -#ifdef CONFIG_CPU_HAS_LLSC > - unsigned int tmp; > + int *ptr, val, ret, err, tmp; > + struct siginfo info; > > - 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" > - ".previous\n\t" > - ".section\t__ex_table,\"a\"\n\t" > - ".word\t1b, 3b\n\t" > - ".word\t2b, 3b\n\t" > - ".previous\n\t" > - : "=&r" (tmp), "=o" (* (u32 *) p), "=r" (errno) > - : "r" (arg2), "o" (* (u32 *) p), "2" (errno) > - : "$1"); > + ptr = (int *)arg1; > + val = (int)arg2; > > - if (errno) > - return -EFAULT; > + /* Don't emulate unaligned accesses. */ > + if ((int)ptr & 3) { > + info.si_signo = SIGBUS; > + info.si_code = BUS_ADRALN; > + goto fault; > + } > + > + /* A zero here saves us three instructions. */ > + err = verify_area(VERIFY_WRITE, ptr, 0); > + if (err) { > + info.si_signo = SIGSEGV; > + info.si_code = SEGV_ACCERR; > + goto fault; > + } > > - /* We're skipping error handling etc. */ > - if (current->ptrace & PT_TRACESYS) > - syscall_trace(); > - > - ((struct pt_regs *)&cmd)->regs[2] = tmp; > - ((struct pt_regs *)&cmd)->regs[7] = 0; > - > - __asm__ __volatile__( > - "move\t$29, %0\n\t" > - "j\to32_ret_from_sys_call" > - : /* No outputs */ > - : "r" (&cmd)); > - /* Unreached */ > +#ifdef CONFIG_CPU_HAS_LLSC > + __asm__(".set mips2\n\t" > + "1:\n\t" > + "ll %0,%5\n\t" > + ".set push\n\t" > + ".set noreorder\n\t" > + "beq %0,%4,3f\n\t" > + " move %3,%4\n" > + ".set pop\n\t" > + "2:\n\t" > + "sc %3,%1\n\t" > + "beqz %3,1b\n\t" > + "3:\n\t" > + ".set mips0\n\t" > + ".section .fixup,\"ax\"\n" > + "4:\n\t" > + "li %2,%7\n\t" > + "j 3b\n\t" > + ".previous\n\t" > + ".section __ex_table,\"a\"\n\t" > + ".word 1b,4b\n\t" > + ".word 2b,4b\n\t" > + ".previous" > + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) > + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); > #else > - printk("sys_sysmips(MIPS_ATOMIC_SET, ...) not ready for !CONFIG_CPU_HAS_LLSC\n"); > + save_and_cli(tmp); > + err = __get_user(ret, ptr); > + if (ret != val) > + err |= __put_user(val, ptr); /* No fault > + unless unwriteable. */ > + restore_flags(tmp); > #endif > + > + if (err) { > + info.si_signo = SIGSEGV; > + info.si_code = SEGV_MAPERR; > + goto fault; > + } > + > + if ( (ret < 0) && (ret >= -EMAXERRNO) ) { > + info.si_signo = SIGSYS; > + info.si_code = 0; > + goto fault; > + } > + > + return ret; > + > +fault: > + /* Go back to SYSCALL. */ > + ((struct pt_regs *)&cmd)->cp0_epc -= 4; > + > + info.si_addr = (void *)((struct pt_regs *)&cmd)->cp0_epc; > + force_sig_info(info.si_signo, &info, current); > + > + return 0; > } > > case MIPS_FIXADE: > > ------------------------------------------------------------------------ > diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile > --- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 > +++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 > @@ -20,7 +20,7 @@ > obj-y += branch.o process.o signal.o entry.o \ > traps.o ptrace.o vm86.o ioport.o reset.o \ > semaphore.o setup.o syscall.o sysmips.o \ > - ipc.o scall_o32.o unaligned.o > + ipc.o scall_o32.o unaligned.o fast-sysmips.o > obj-$(CONFIG_MODULES) += mips_ksyms.o > > ifdef CONFIG_CPU_R3000 > @@ -69,5 +69,6 @@ > > entry.o: entry.S > head.o: head.S > +fast-sysmips.o: fast-sysmips.S > > include $(TOPDIR)/Rules.make > diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S > --- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 > +++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 > @@ -0,0 +1,85 @@ > +/* > + * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus > + * > + * This file is subject to the terms and conditions of the GNU General Public > + * License. See the file "COPYING" in the main directory of this archive > + * for more details. > + * > + * Copyright (C) 2001 Florian Lohoff > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define PT_TRACESYS 0x00000002 > + > + EXPORT(fast_sysmips) > + > + .set noreorder > + > + li t0, MIPS_ATOMIC_SET > + beq a0, t0, 1f > + nop > + j sys_sysmips > + nop > + > +1: > + > + # a0 - MIPS_ATOMIC_SET > + # a1 - mem ptr > + # a2 - value > + > + addiu sp, sp, -8 # Reserve space > + sw a0, (sp) # Save arg0 > + > + addiu a0, a1, 4 # addr+size > + ori v0, a1, 4 # addr | size > + lw v1, THREAD_CURDS(gp) # current->thread.current_ds > + or v0, v0, a0 # addr | size | (addr+size) > + and v1, v1, v0 # (mask)&(addr | size | (addr+size) > + bltz v1, 5f > + nop > + > +2: > + ll v0, (a1) > + move t0, a2 > + sc t0, (a1) > + beqz t0, 2b > + nop > + > + sw v0, PT_R2+8(sp) # Result value > + sw zero, PT_R7+8(sp) # Success indicator > + > + lw t0, TASK_PTRACE(gp) # syscall tracing enabled? > + andi t0, PT_TRACESYS > + bnez t0, 3f > + nop > + > +4: > + lw a0, (sp) # Restore arg0 > + addiu sp, sp, 8 # Restore sp > + > + j o32_ret_from_sys_call > + nop > + > +3: > + sw ra, 4(sp) > + jal syscall_trace > + nop > + lw ra, 4(sp) > + j 4b > + nop > + > +5: > + lw a0, (sp) # Restore arg0 > + addiu sp, sp, 8 # Restore sp > + j ra > + li v0, -EFAULT > + > diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h > --- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 > +++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 > @@ -69,7 +69,7 @@ > SYS(irix_getgid, 0) /* 1047 getgid() V*/ > SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ > SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ > -SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ > +SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ > SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ > SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ > SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ > diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h > --- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 > +++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 > @@ -163,7 +163,7 @@ > SYS(sys_writev, 3) > SYS(sys_cacheflush, 3) > SYS(sys_cachectl, 3) > -SYS(sys_sysmips, 4) > +SYS(fast_sysmips, 4) > SYS(sys_ni_syscall, 0) /* 4150 */ > SYS(sys_getsid, 1) > SYS(sys_fdatasync, 0) -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Tue Jul 10 09:05:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AG5Tq29451 for linux-mips-outgoing; Tue, 10 Jul 2001 09:05:29 -0700 Received: from dea.waldorf-gmbh.de (u-58-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.58]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AG5RV29448 for ; Tue, 10 Jul 2001 09:05:27 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6AFvWD31134; Tue, 10 Jul 2001 17:57:32 +0200 Date: Tue, 10 Jul 2001 17:57:32 +0200 From: Ralf Baechle To: Barry Wu Cc: linux-mips@oss.sgi.com Subject: Re: Can mipsel linux support module? Message-ID: <20010710175732.B29473@bacchus.dhis.org> References: <20010707234715.80453.qmail@web13903.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010707234715.80453.qmail@web13903.mail.yahoo.com>; from wqb123@yahoo.com on Sat, Jul 07, 2001 at 04:47:15PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 499 Lines: 14 On Sat, Jul 07, 2001 at 04:47:15PM -0700, Barry Wu wrote: > I just port mipsel linux 2.2.12 to our hardware > evaluation board. I want to modify a module > to a character device driver. But I do not know > how to do and which files to update. > Can mipsel linux support module? If so, which rpm > do I have to download and where can I find them? > If not, how can I change a module to a character > device driver? Latest modutils package from ftp.kernel.org should work out of the box. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 10 09:28:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AGSFc30471 for linux-mips-outgoing; Tue, 10 Jul 2001 09:28:15 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AGSBV30467 for ; Tue, 10 Jul 2001 09:28:12 -0700 Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id <3GNKV5MK>; Tue, 10 Jul 2001 12:27:52 -0400 Message-ID: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> From: Marc Karasek To: "'linux-mips@oss.sgi.com'" Subject: MIPS Cross Compiler Tools Date: Tue, 10 Jul 2001 12:27:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 384 Lines: 11 I had a question about the cross compiler tools for MIPS, specifically glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and the compiler (C, C++). Are most people building glibc against these or are you building the tools completely from scratch? As glibc is needed to compile anything else other than the kernel. Marc Karasek Sr. Firmware Eng iVivity Inc From owner-linux-mips@oss.sgi.com Tue Jul 10 09:35:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AGZMr30671 for linux-mips-outgoing; Tue, 10 Jul 2001 09:35:22 -0700 Received: from tennyson.netexpress.net (IDENT:root@tennyson.netexpress.net [64.22.192.12]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AGZLV30667 for ; Tue, 10 Jul 2001 09:35:21 -0700 Received: from localhost (vorlon@localhost) by tennyson.netexpress.net (8.9.3/8.9.3) with ESMTP id LAA25591 for ; Tue, 10 Jul 2001 11:35:20 -0500 X-Authentication-Warning: tennyson.netexpress.net: vorlon owned process doing -bs Date: Tue, 10 Jul 2001 11:35:20 -0500 (CDT) From: Steve Langasek To: "'linux-mips@oss.sgi.com'" Subject: Re: MIPS Cross Compiler Tools In-Reply-To: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 806 Lines: 23 Hi Marc, On Tue, 10 Jul 2001, Marc Karasek wrote: > I had a question about the cross compiler tools for MIPS, specifically > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > the compiler (C, C++). > Are most people building glibc against these or are you building the tools > completely from scratch? As glibc is needed to compile anything else other > than the kernel. You don't need a special 'cross-compiler' glibc in order to set up a cross-build environment for MIPS; simply grab a glibc package that's precompiled for MIPS and install it into your cross-build root directory. I don't know who (if anyone) would have rpms for a recent mips glibc; I use Debian, where I have the packages available as part of the distro. Regards, Steve Langasek postmodern programmer From owner-linux-mips@oss.sgi.com Tue Jul 10 09:40:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AGegk30794 for linux-mips-outgoing; Tue, 10 Jul 2001 09:40:42 -0700 Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AGeeV30790 for ; Tue, 10 Jul 2001 09:40:41 -0700 Received: from pacbell.net ([63.194.214.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GG9002D6NNLJM@mta7.pltn13.pbi.net> for linux-mips@oss.sgi.com; Tue, 10 Jul 2001 09:40:34 -0700 (PDT) Date: Tue, 10 Jul 2001 09:39:02 -0700 From: Pete Popov Subject: Re: MIPS Cross Compiler Tools To: Marc Karasek Cc: "'linux-mips@oss.sgi.com'" Reply-to: ppopov@pacbell.net Message-id: <3B4B2FA6.4080508@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 680 Lines: 18 Marc Karasek wrote: > I had a question about the cross compiler tools for MIPS, specifically > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > the compiler (C, C++). > > Are most people building glibc against these or are you building the tools > completely from scratch? As glibc is needed to compile anything else other > than the kernel. Friday or Monday MontaVista should have the HHL2.0 Journeyman mips release on the ftp site which will include the userland apps, cross AND native tools, etc. The tools and glibc are very up to date. I would suggest checking Monday for the release and using that instead of building your own. Pete From owner-linux-mips@oss.sgi.com Tue Jul 10 09:46:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AGkUZ30952 for linux-mips-outgoing; Tue, 10 Jul 2001 09:46:30 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AGkTV30949 for ; Tue, 10 Jul 2001 09:46:29 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B2644125BA; Tue, 10 Jul 2001 09:46:27 -0700 (PDT) Date: Tue, 10 Jul 2001 09:46:27 -0700 From: "H . J . Lu" To: Marc Karasek Cc: "'linux-mips@oss.sgi.com'" Subject: Re: MIPS Cross Compiler Tools Message-ID: <20010710094627.D19026@lucon.org> References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25369470B6F0D41194820002B328BDD27D22@ATLOPS>; from marc_karasek@ivivity.com on Tue, Jul 10, 2001 at 12:27:43PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 988 Lines: 29 On Tue, Jul 10, 2001 at 12:27:43PM -0400, Marc Karasek wrote: > I had a question about the cross compiler tools for MIPS, specifically > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > the compiler (C, C++). > > Are most people building glibc against these or are you building the tools > completely from scratch? As glibc is needed to compile anything else other > than the kernel. My RedHat 7.1 release on oss.sgi.com has the complete cross toolchain: H.J. ----- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. From owner-linux-mips@oss.sgi.com Tue Jul 10 10:05:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AH5KA31554 for linux-mips-outgoing; Tue, 10 Jul 2001 10:05:20 -0700 Received: from localhost.localdomain (client124091.atl.mediaone.net [24.31.124.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AH5IV31551 for ; Tue, 10 Jul 2001 10:05:18 -0700 Received: (from marck@localhost) by localhost.localdomain (8.11.2/8.11.2) id f6AH52X09215; Tue, 10 Jul 2001 13:05:02 -0400 X-Authentication-Warning: localhost.localdomain: marck set sender to marc_karasek@ivivity.com using -f Subject: Re: MIPS Cross Compiler Tools From: Marc Karasek To: H "." J "." Lu Cc: "'linux-mips@oss.sgi.com'" In-Reply-To: <20010710094627.D19026@lucon.org> References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> <20010710094627.D19026@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 10 Jul 2001 13:05:01 -0400 Message-Id: <994784701.9191.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1792 Lines: 49 This is for an embedded platform, with no harddrive. So I will need to use things like busybox, etc. I just need the headers & libs. So far I have only been able to find glibc-2.2.2 from deb in an rpm format. Could not get this to install in /usr/local/mips-linux/... properly. I guess what I am really looking for is a tgz file of the libs/headers. SO I can put it where I want it. Any packaged dist (RH, deb) would not be usefull in this scenario. At least that is my experience todate.... Thanks for the quick response.. On 10 Jul 2001 09:46:27 -0700, H . J . Lu wrote: > On Tue, Jul 10, 2001 at 12:27:43PM -0400, Marc Karasek wrote: > > I had a question about the cross compiler tools for MIPS, specifically > > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > > the compiler (C, C++). > > > > Are most people building glibc against these or are you building the tools > > completely from scratch? As glibc is needed to compile anything else other > > than the kernel. > > My RedHat 7.1 release on oss.sgi.com has the complete cross toolchain: > > > > H.J. > ----- > My mini-port of RedHat 7.1 is at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > you should be able to put a small RedHat 7.1 on the mips/mipsel box and > compile the rest of RedHat 7.1 yourselves. > > Here are something you should know: > > 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a > toolchain rpm. The binary rpms for the mips and mipsel cross compilers > are included. > 2. You have to find a way to put those rpms on your machine. I use > network boot and NFS root to do it. -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Tue Jul 10 10:07:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AH7gC31650 for linux-mips-outgoing; Tue, 10 Jul 2001 10:07:42 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AH7fV31647 for ; Tue, 10 Jul 2001 10:07:41 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D9076125BA; Tue, 10 Jul 2001 10:07:40 -0700 (PDT) Date: Tue, 10 Jul 2001 10:07:40 -0700 From: "H . J . Lu" To: Marc Karasek Cc: "'linux-mips@oss.sgi.com'" Subject: Re: MIPS Cross Compiler Tools Message-ID: <20010710100740.G19026@lucon.org> References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> <20010710094627.D19026@lucon.org> <994784701.9191.0.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <994784701.9191.0.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Tue, Jul 10, 2001 at 01:05:01PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 699 Lines: 14 On Tue, Jul 10, 2001 at 01:05:01PM -0400, Marc Karasek wrote: > This is for an embedded platform, with no harddrive. So I will need to > use things like busybox, etc. I just need the headers & libs. So far I > have only been able to find glibc-2.2.2 from deb in an rpm format. > Could not get this to install in /usr/local/mips-linux/... properly. I > guess what I am really looking for is a tgz file of the libs/headers. > SO I can put it where I want it. Any packaged dist (RH, deb) would not > be usefull in this scenario. At least that is my experience todate.... What are you talking about? Did you ask for the cross toolchain? What does it have anything to do with your target? H.J. From owner-linux-mips@oss.sgi.com Tue Jul 10 10:09:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AH9wm31748 for linux-mips-outgoing; Tue, 10 Jul 2001 10:09:58 -0700 Received: from localhost.localdomain (client124091.atl.mediaone.net [24.31.124.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AH9uV31744 for ; Tue, 10 Jul 2001 10:09:57 -0700 Received: (from marck@localhost) by localhost.localdomain (8.11.2/8.11.2) id f6AH9gb09226; Tue, 10 Jul 2001 13:09:42 -0400 X-Authentication-Warning: localhost.localdomain: marck set sender to marc_karasek@ivivity.com using -f Subject: Re: MIPS Cross Compiler Tools From: Marc Karasek To: ppopov@pacbell.net Cc: "'linux-mips@oss.sgi.com'" In-Reply-To: <3B4B2FA6.4080508@pacbell.net> References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> <3B4B2FA6.4080508@pacbell.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 10 Jul 2001 13:09:42 -0400 Message-Id: <994784982.9191.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1444 Lines: 37 Will these be in the form of rpms or tgz files?? In the case of rpm do you know if they would be package similar to the ones on oss.sgi.com? ie Setup for a crossdev enviroment. I just really need the cross tools as the dev is on an embedded system, with no harddrive. The userland stuff is pretty worthless to me. I will be using busybox, tinylogin, etc. for the standard bin utilities. Having a few megabytes to store everything in makes you very sensitive to size.... :-) Thanks for the quick response... On 10 Jul 2001 09:39:02 -0700, Pete Popov wrote: > Marc Karasek wrote: > > > I had a question about the cross compiler tools for MIPS, specifically > > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > > the compiler (C, C++). > > > > Are most people building glibc against these or are you building the tools > > completely from scratch? As glibc is needed to compile anything else other > > than the kernel. > > Friday or Monday MontaVista should have the HHL2.0 Journeyman mips > release on the ftp site which will include the userland apps, cross AND > native tools, etc. The tools and glibc are very up to date. I would > suggest checking Monday for the release and using that instead of > building your own. > > Pete -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Tue Jul 10 10:12:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AHCNp31874 for linux-mips-outgoing; Tue, 10 Jul 2001 10:12:23 -0700 Received: from localhost.localdomain (client124091.atl.mediaone.net [24.31.124.91]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AHCLV31869 for ; Tue, 10 Jul 2001 10:12:22 -0700 Received: (from marck@localhost) by localhost.localdomain (8.11.2/8.11.2) id f6AHBrZ09236; Tue, 10 Jul 2001 13:11:53 -0400 X-Authentication-Warning: localhost.localdomain: marck set sender to marc_karasek@ivivity.com using -f Subject: Re: MIPS Cross Compiler Tools From: Marc Karasek To: Steve Langasek Cc: "'linux-mips@oss.sgi.com'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 10 Jul 2001 13:11:53 -0400 Message-Id: <994785113.9191.2.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1383 Lines: 39 I really need the libs to cross-compile some other apps. The target is an embedded system, so I need to crosscompile things like busybox, tinylogin, etc. (It will NOT have a harddrive) I have done this before with ARM and it is pretty easy once you get the tools in place. Sometimes that is the hardest part... On 10 Jul 2001 11:35:20 -0500, Steve Langasek wrote: > Hi Marc, > > On Tue, 10 Jul 2001, Marc Karasek wrote: > > > I had a question about the cross compiler tools for MIPS, specifically > > glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and > > the compiler (C, C++). > > > Are most people building glibc against these or are you building the tools > > completely from scratch? As glibc is needed to compile anything else other > > than the kernel. > > You don't need a special 'cross-compiler' glibc in order to set up a > cross-build environment for MIPS; simply grab a glibc package that's > precompiled for MIPS and install it into your cross-build root directory. > > I don't know who (if anyone) would have rpms or a recent mips glibc; I use > Debian, where I have the packages available as part of the distro. > > Regards, > Steve Langasek > postmodern programmer -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Tue Jul 10 10:31:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AHVPZ32265 for linux-mips-outgoing; Tue, 10 Jul 2001 10:31:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AHVMV32261; Tue, 10 Jul 2001 10:31:22 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id CD903125BA; Tue, 10 Jul 2001 10:31:21 -0700 (PDT) Date: Tue, 10 Jul 2001 10:31:21 -0700 From: "H . J . Lu" To: Carsten Langgaard Cc: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Illegal instruction Message-ID: <20010710103121.L19026@lucon.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B4AE384.52049D47@mips.com>; from carstenl@mips.com on Tue, Jul 10, 2001 at 01:14:12PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 342 Lines: 11 On Tue, Jul 10, 2001 at 01:14:12PM +0200, Carsten Langgaard wrote: > Thanks, that did the trick. > Now I would like to try to install H.J. Lu's RedHat7.1 RPM packages. > If I just do a: > rpm -Uvh --root /mnt/harddisk *.rpm Those rpms have to be installed in the right order. I have a set up to do that. I will see what I can do. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 10 10:57:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AHvLN00376 for linux-mips-outgoing; Tue, 10 Jul 2001 10:57:21 -0700 Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AHvKV00373 for ; Tue, 10 Jul 2001 10:57:20 -0700 Received: from pacbell.net ([63.194.214.47]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GG900ICMR7JN1@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Tue, 10 Jul 2001 10:57:19 -0700 (PDT) Date: Tue, 10 Jul 2001 10:55:53 -0700 From: Pete Popov Subject: Re: MIPS Cross Compiler Tools To: Marc Karasek Cc: "'linux-mips@oss.sgi.com'" Reply-to: ppopov@pacbell.net Message-id: <3B4B41A9.3010304@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> <3B4B2FA6.4080508@pacbell.net> <994784982.9191.1.camel@localhost.localdomain> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2070 Lines: 75 Marc Karasek wrote: > Will these be in the form of rpms or tgz files?? rpm In the case of rpm do > you know if they would be package similar to the ones on oss.sgi.com? I'm not sure how the oss.sgi.com tools are packaged. The MontaVista release gets installed in /opt/hardhat/<....>. The /opt/hardhat/devkit/mips/fp/target is the root fs that gets mounted over nfs. The target root fs has all the userland apps and native tools. The /opt/hardhat/devkit/mips/fp_/bin has the cross tools. > ie Setup for a crossdev enviroment. I just really need the cross tools > as the dev is on an embedded system, with no harddrive. That's what we work with mostly as well. > The userland > stuff is pretty worthless to me. I will be using busybox, tinylogin, > etc. for the standard bin utilities. OK, but we have all of those packaged in rpm as well, and it's very easy to rebuild the rpms from the source rpms, if you need to rebuild them. Pete > Having a few megabytes to store > everything in makes you very sensitive to size.... :-) > > Thanks for the quick response... > > On 10 Jul 2001 09:39:02 -0700, Pete Popov wrote: > >>Marc Karasek wrote: >> >> >>>I had a question about the cross compiler tools for MIPS, specifically >>>glibc. I d/l the rpms from oss.sgi.com, but they are only binutils, and >>>the compiler (C, C++). >>> >>>Are most people building glibc against these or are you building the tools >>>completely from scratch? As glibc is needed to compile anything else other >>>than the kernel. >>> >>Friday or Monday MontaVista should have the HHL2.0 Journeyman mips >>release on the ftp site which will include the userland apps, cross AND >>native tools, etc. The tools and glibc are very up to date. I would >>suggest checking Monday for the release and using that instead of >>building your own. >> >>Pete >> > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > (770) 986-8925 > (770) 986-8926 Fax > *************************/ > > From owner-linux-mips@oss.sgi.com Tue Jul 10 12:45:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AJjRO04788 for linux-mips-outgoing; Tue, 10 Jul 2001 12:45:27 -0700 Received: from web11906.mail.yahoo.com (web11906.mail.yahoo.com [216.136.172.190]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AJjQV04775 for ; Tue, 10 Jul 2001 12:45:26 -0700 Message-ID: <20010710194526.44019.qmail@web11906.mail.yahoo.com> Received: from [209.243.184.191] by web11906.mail.yahoo.com via HTTP; Tue, 10 Jul 2001 12:45:26 PDT Date: Tue, 10 Jul 2001 12:45:26 -0700 (PDT) From: Wayne Gowcher Subject: USB OHCI on 2.4.2 kernel using r4k processor To: linux-mips@oss.sgi.com In-Reply-To: <20010604235443.A27996@bacchus.dhis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 988 Lines: 36 Dear All, Has anyone got USB OHCI running on a 2.4.2 kernel with a mips r4k processor ? I have successfully used the above with a r3k mips processor but now after porting the same base code to a r4k processor the kernel throws an OOPS. I believe the problem may lay with the writeback cache because when I disable the d cache on the r4k 2.4.2 kernel USB works fine ! I did some digging around and noted that the working aic7xxx driver I have on the 2.4.2 r4k makes use of pci_map_single to handle cache flushing ( ??? please correct me if I am wrong ) and that this type of code doesn't make it into the usb code until 2.4.4 of the sgi linux kernel. Does anyone have a "back patch" to apply to the 2.4.2 usb code ? If not I am thinking of attempting this myself and would welcome any comments / advice about doing this TIA Wayne __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Tue Jul 10 13:14:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6AKEB509419 for linux-mips-outgoing; Tue, 10 Jul 2001 13:14:11 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6AKDxV09395 for ; Tue, 10 Jul 2001 13:14:00 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 34CC3125BA; Tue, 10 Jul 2001 13:13:54 -0700 (PDT) Date: Tue, 10 Jul 2001 13:13:53 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.11.90.0.23 is released. Message-ID: <20010710131353.A23616@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 12545 Lines: 452 This is the beta release of binutils 2.11.90.0.23 for Linux, which is based on binutils 2001 0706 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.23 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.23.tar.gz. Source code. 2. binutils-2.11.90.0.19-2.11.90.0.23.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.23-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.23.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 07/10/2001 From owner-linux-mips@oss.sgi.com Tue Jul 10 17:51:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B0pg715933 for linux-mips-outgoing; Tue, 10 Jul 2001 17:51:42 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B0peV15927 for ; Tue, 10 Jul 2001 17:51:40 -0700 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 f6B0pY000862; Tue, 10 Jul 2001 17:51:34 -0700 Message-ID: <3B4BA24E.1FB614B0@mvista.com> Date: Tue, 10 Jul 2001 17:48:14 -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: linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com Subject: memory alloc failuer : __alloc_pages: 1-order allocation failed. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4769 Lines: 93 I am running 2.4.2 on a linux/mips box, with 32MB system RAM (no swap). When I run a stress test, I will hit memory allocation failure: __alloc_pages: 1-order allocation failed. IP: queue_glue: no memory for gluing queue 8108cce0 However, I traced the system and found several questions. First, free reports enough free memory and LOTS of cache memory. See below. Should'nt Linux free cache memory to satisfy this request? total used free shared buffers cached Mem: 30052 29296 756 0 0 16928 -/+ buffers/cache: 12368 17684 Swap: 0 0 0 I used kgdb and dig into rmqueue() in mm/page_alloc.c file. There are two zones in this system. They do have many free pages but none of free blocks seem to be big enough for the 2-page request. Does this make sense? Why does kernel end up with so many fragmented 1-page free areas? See the kgdb output below. (gdb) p order $14 = 1 (gdb) p *zone $15 = {lock = {gcc_is_buggy = 0}, offset = 4096, free_pages = 65, inactive_clean_pages = 262, inactive_dirty_pages = 10, pages_min = 32, pages_low = 64, pages_high = 96, inactive_clean_list = {next = 0x8107cdf0, prev = 0x81053c40}, free_area = {{free_list = {next = 0x8105f548, prev = 0x810562a8}, map = 0x810884e0}, {free_list = { next = 0x801fe5f0, prev = 0x801fe5f0}, map = 0x810886e0}, { free_list = {next = 0x801fe5fc, prev = 0x801fe5fc}, map = 0x810887e0}, { free_list = {next = 0x801fe608, prev = 0x801fe608}, map = 0x81088860}, { free_list = {next = 0x801fe614, prev = 0x801fe614}, map = 0x810888a0}, { free_list = {next = 0x801fe620, prev = 0x801fe620}, map = 0x810888c0}, { free_list = {next = 0x801fe62c, prev = 0x801fe62c}, map = 0x810888e0}, { free_list = {next = 0x801fe638, prev = 0x801fe638}, map = 0x81088900}, { free_list = {next = 0x801fe644, prev = 0x801fe644}, map = 0x81088920}, { free_list = {next = 0x801fe650, prev = 0x801fe650}, map = 0x81088940}}, name = 0x801af0e4 "Normal", size = 4096, zone_pgdat = 0x801fe504, zone_start_paddr = 16777216, zone_start_mapnr = 4096, zone_mem_map = 0x81044010} (gdb) p z $23 = (zone_t *) 0x801fe504 (gdb) p *z $24 = {lock = {gcc_is_buggy = 0}, offset = 0, free_pages = 329, inactive_clean_pages = 861, inactive_dirty_pages = 16, pages_min = 128, pages_low = 256, pages_high = 384, inactive_clean_list = {next = 0x81020888, prev = 0x81036508}, free_area = {{free_list = {next = 0x8102d1c4, prev = 0x81035430}, map = 0x81088060}, {free_list = { next = 0x801fe538, prev = 0x801fe538}, map = 0x81088260}, { free_list = {next = 0x801fe544, prev = 0x801fe544}, map = 0x81088360}, { free_list = {next = 0x801fe550, prev = 0x801fe550}, map = 0x810883e0}, { free_list = {next = 0x801fe55c, prev = 0x801fe55c}, map = 0x81088420}, { free_list = {next = 0x801fe568, prev = 0x801fe568}, map = 0x81088440}, { free_list = {next = 0x801fe574, prev = 0x801fe574}, map = 0x81088460}, { free_list = {next = 0x801fe580, prev = 0x801fe580}, map = 0x81088480}, { free_list = {next = 0x801fe58c, prev = 0x801fe58c}, map = 0x810884a0}, { free_list = {next = 0x801fe598, prev = 0x801fe598}, map = 0x810884c0}}, name = 0x801af0ec "DMA", size = 4096, zone_pgdat = 0x801fe504, zone_start_paddr = 0, zone_start_mapnr = 0, zone_mem_map = 0x81000010} The current process does not have PF_MEMALLOC flag set. The callstack trace is as follows: (kgdb is lying - the gfp_mask should be 2 at frame #1. The size in kmalloc is probably a lie from kgdb too.) #0 __alloc_pages (zonelist=0x801fe754, order=1) at page_alloc.c:498 #1 0x800b3c08 in __get_free_pages (gfp_mask=0, order=1) at /local/jsun/2ND-DISK/work/ddb5477/build/hhl-2.4.2-010709/hhl-2.4.2/linux/ include/linux/mm.h:355 #2 0x800aedbc in kmem_cache_grow (cachep=0x8108b700, flags=2) at slab.c:485 #3 0x800af258 in kmalloc (size=2149573892, flags=2) at slab.c:1331 #4 0x801585bc in alloc_skb (size=4160, gfp_mask=2) at skbuff.c:189 #5 0x80166cbc in ip_frag_reasm (qp=0x8108cce0, dev=0x810a1800) at /local/jsun/2ND-DISK/work/ddb5477/build/hhl-2.4.2-010709/hhl-2.4.2/linux/ include/linux/skbuff.h:919 #6 0x80167040 in ip_defrag (skb=0x0) at ip_fragment.c:626 #7 0x80165c28 in ip_local_deliver (skb=0x810dcd20) at ip_input.c:291 #8 0x80166184 in ip_rcv (skb=0x810dcd20, dev=0x1, pt=0x0) at ip_input.c:363 #9 0x8015b5ec in net_rx_action (h=0x801fe504) at dev.c:1403 #10 0x800993d8 in do_softirq () at softirq.c:78 #11 0x801a2eb4 in do_IRQ (irq=16, regs=0x81c79d18) at irq.c:644 #12 0x801a50ec in vrc5477_irq_dispatch (regs=0x81c79d18) at irq.c:175 Would appreciate any pointers. Jun From owner-linux-mips@oss.sgi.com Tue Jul 10 18:34:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B1YD622061 for linux-mips-outgoing; Tue, 10 Jul 2001 18:34:13 -0700 Received: from humbolt.nl.linux.org (IDENT:root@humbolt.nl.linux.org [131.211.28.48]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B1YAV22058 for ; Tue, 10 Jul 2001 18:34:11 -0700 Received: from humbolt.nl.linux.org ([131.211.28.48]:39951 "HELO starship") by humbolt.nl.linux.org with SMTP id ; Wed, 11 Jul 2001 03:34:07 +0200 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Jun Sun , linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com Subject: Re: memory alloc failuer : __alloc_pages: 1-order allocation failed. Date: Wed, 11 Jul 2001 03:37:59 +0200 X-Mailer: KMail [version 1.2] References: <3B4BA24E.1FB614B0@mvista.com> In-Reply-To: <3B4BA24E.1FB614B0@mvista.com> MIME-Version: 1.0 Message-Id: <0107110337590G.22952@starship> Content-Transfer-Encoding: 7BIT Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 494 Lines: 16 On Wednesday 11 July 2001 02:48, Jun Sun wrote: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I am running 2.4.2 on a linux/mips box, with 32MB system RAM (no > swap). When I run a stress test, I will hit memory allocation > failure: > > __alloc_pages: 1-order allocation failed. > IP: queue_glue: no memory for gluing queue 8108cce0 Next step: install the latest stable kernel and see if the problem persists. (In this case I doubt it will) -- Daniel From owner-linux-mips@oss.sgi.com Tue Jul 10 18:40:31 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B1eVC22926 for linux-mips-outgoing; Tue, 10 Jul 2001 18:40:31 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B1eTV22920 for ; Tue, 10 Jul 2001 18:40:30 -0700 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 f6B1eN003522; Tue, 10 Jul 2001 18:40:23 -0700 Message-ID: <3B4BADBF.D3E27F42@mvista.com> Date: Tue, 10 Jul 2001 18:37:03 -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: linux-kernel@vger.kernel.org, linux-mips@oss.sgi.com Subject: Re: memory alloc failuer : __alloc_pages: 1-order allocation failed. References: <3B4BA24E.1FB614B0@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1687 Lines: 43 Just found more about this problem.... Jun Sun wrote: > > I am running 2.4.2 on a linux/mips box, with 32MB system RAM (no swap). When > I run a stress test, I will hit memory allocation failure: > > __alloc_pages: 1-order allocation failed. > IP: queue_glue: no memory for gluing queue 8108cce0 > > However, I traced the system and found several questions. > > First, free reports enough free memory and LOTS of cache memory. See below. > Should'nt Linux free cache memory to satisfy this request? > > total used free shared buffers cached > Mem: 30052 29296 756 0 0 16928 > -/+ buffers/cache: 12368 17684 > Swap: 0 0 0 > The memory allocation is invoked with GFP_ATOMIC, and thus does not free up the cached pages. (Why? because it is invoked from interrupt context?) > I used kgdb and dig into rmqueue() in mm/page_alloc.c file. There are two > zones in this system. They do have many free pages but none of free blocks > seem to be big enough for the 2-page request. Does this make sense? Why does > kernel end up with so many fragmented 1-page free areas? See the kgdb output > below. > Shouldn't some kernel daemon try to maintain a "reasonable" free_area, including a 2-page block? It seems like in my case the daemon failed to do the job. (Which daemon is it? kflushd?) What is the condition to kick start this daemon? I suppose in my case the total free page count is still high, which may fail to start the daemon. In the end, allocating memory from interrupt context for re-assembling IP packet does not sound pretty either ... Jun From owner-linux-mips@oss.sgi.com Tue Jul 10 21:38:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B4c5m07868 for linux-mips-outgoing; Tue, 10 Jul 2001 21:38:05 -0700 Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B4c3V07865 for ; Tue, 10 Jul 2001 21:38:03 -0700 Received: from pacbell.net ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGA006FOKVAHB@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Tue, 10 Jul 2001 21:38:02 -0700 (PDT) Date: Tue, 10 Jul 2001 21:36:36 -0700 From: Pete Popov Subject: Re: USB OHCI on 2.4.2 kernel using r4k processor To: Wayne Gowcher Cc: linux-mips@oss.sgi.com Reply-to: ppopov@pacbell.net Message-id: <3B4BD7D4.1060003@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <20010710194526.44019.qmail@web11906.mail.yahoo.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1559 Lines: 47 Wayne Gowcher wrote: > Dear All, > > Has anyone got USB OHCI running on a 2.4.2 kernel with > a mips r4k processor ? Yes, on a couple of different boards. > I have successfully used the above with a r3k mips > processor but now after porting the same base code to > a r4k processor the kernel throws an OOPS. > > I believe the problem may lay with the writeback cache > because when I disable the d cache on the r4k 2.4.2 > kernel USB works fine ! > I did some digging around and noted that the working > aic7xxx driver I have on the 2.4.2 r4k makes use of > pci_map_single to handle cache flushing ( ??? please > correct me if I am wrong ) and that this type of code > doesn't make it into the usb code until 2.4.4 of the > sgi linux kernel. > Does anyone have a "back patch" to apply to the 2.4.2 > usb code ? > If not I am thinking of attempting this myself and > would welcome any comments / advice about doing this Steve at MontaVista did the usb work for mips about six months ago on an ITE 8172 board. Since then we've also ported it to the Alchemy Au1000 board, both running on 2.4.2. He forwarded all patches to the usb maintainer but it looks like it took a bit of time for all the patches to be applied. I don't know if we still have patches against the 2.4.2 tree. One thing you can do is next Monday check our ftp site (HHL2.0 for mips should be released by early next week), grab the generic HHL2.0 mips kernel, and diff all the usb code against the stock 2.4.2. I don't think it would be too bad of a job. Pete From owner-linux-mips@oss.sgi.com Tue Jul 10 23:54:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B6sdm18507 for linux-mips-outgoing; Tue, 10 Jul 2001 23:54:39 -0700 Received: from cool.coventive.com (cool.coventive.com [211.79.9.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B6sbV18495 for ; Tue, 10 Jul 2001 23:54:38 -0700 Received: from jefflee (jungle.coventive.com [211.79.9.189]) by cool.coventive.com (8.10.2/8.10.2) with SMTP id f6B6nPW04069; Wed, 11 Jul 2001 14:49:25 +0800 Message-ID: <00ef01c109d6$c7b39150$9400a8c0@jefflee> From: "jeff_lee" To: Cc: "CIH" , =?big5?B?SmFsZW4gt6iqRqan?= Subject: DHCP problem Date: Wed, 11 Jul 2001 14:57:41 +0800 Organization: hardware MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EC_01C10A19.D5AD9E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2068 Lines: 54 This is a multi-part message in MIME format. ------=_NextPart_000_00EC_01C10A19.D5AD9E70 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I got some question about the DHCP. We have a mipsel machine and = running HomeRF wireless module on it. The CPU is Vr4121, HomeRF bus is = ISA-like bus. Now the module can work fine with fixed-ip. We want to get = the IP when system boot-up. We had tried two way: cross compiler the = pump and dhclient applications, but when we execute the pump, it show = the "operation failed". When we execute dhclient, it show "segment = fault" ....... I don't know what's going on .Can someone tell me what's = going on ?? Or where can I get the binary code for pump and dhclient ?? Thanks and best regs, Jeff ------=_NextPart_000_00EC_01C10A19.D5AD9E70 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all, I got some question about the = DHCP. We=20 have a mipsel machine and running HomeRF wireless module on it. The CPU = is=20 Vr4121, HomeRF bus is ISA-like bus. Now the module can work fine with = fixed-ip.=20 We want to get the IP when system boot-up. We had tried two way: cross = compiler=20 the pump and dhclient applications, but when we execute the pump, it = show the=20 "operation failed". When we execute dhclient, it show "segment fault" = ....... I=20 don't know what's going on .Can someone tell me what's going on ?? Or = where can=20 I get the binary code for pump and dhclient ??
Thanks and best regs,
 
Jeff
------=_NextPart_000_00EC_01C10A19.D5AD9E70-- From owner-linux-mips@oss.sgi.com Wed Jul 11 00:11:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B7BhE21203 for linux-mips-outgoing; Wed, 11 Jul 2001 00:11:43 -0700 Received: from chakotay.allgaeu.org (chakotay.allgaeu.org [213.182.8.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B7BfV21187 for ; Wed, 11 Jul 2001 00:11:41 -0700 Received: from tuvok.allgaeu.org (tuvok.allgaeu.org [213.182.8.4]) by chakotay.allgaeu.org (8.9.3/8.9.3) with ESMTP id JAA26039 for ; Wed, 11 Jul 2001 09:11:39 +0200 Received: by tuvok.allgaeu.org (Postfix, from userid 1000) id B3CB8304; Wed, 11 Jul 2001 09:11:39 +0200 (CEST) Date: Wed, 11 Jul 2001 09:11:39 +0200 From: Robert Einsle To: linux-mips@oss.sgi.com Subject: Boot-Problem on an indy Message-ID: <20010711091139.A24847@tuvok.allgaeu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 639 Lines: 26 Hy * I had installd debian-linux on an indy r4400, 160 mhz from an howto. but when running dvhtool it gives me an error back. Now i don't knew if i make a correct partition-table with right items or any other thing is wrong. I called dvhtool: dvhtool -d /dev/sda vmlinux-2.4.3.ecoff linux Today i don't remember the korrect Errormessage, but can you tell me where i can take a closer look about informations why this isnt running. Tnx for your help -- MFG Robert Einsle >>Warum muss ich bei "Verwaltung von Problemloesungen fuer eine EDV-Abteilung" an einen Waffenschrank denken?<< (Robin S. Socha in de.comp.os.unix.linux.misc) From owner-linux-mips@oss.sgi.com Wed Jul 11 01:26:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B8QX428334 for linux-mips-outgoing; Wed, 11 Jul 2001 01:26:33 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B8QUV28329 for ; Wed, 11 Jul 2001 01:26:30 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id MAA09915; Wed, 11 Jul 2001 12:26:53 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA00516; Wed, 11 Jul 2001 12:25:26 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA03741; Wed, 11 Jul 2001 12:23:27 +0400 (MSD) Message-ID: <3B4C114D.8ECC3997@niisi.msk.ru> Date: Wed, 11 Jul 2001 12:41:49 +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: Marc Karasek CC: "H . J . Lu" , "'linux-mips@oss.sgi.com'" Subject: Re: MIPS Cross Compiler Tools References: <25369470B6F0D41194820002B328BDD27D22@ATLOPS> <20010710094627.D19026@lucon.org> <994784701.9191.0.camel@localhost.localdomain> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 738 Lines: 16 Marc Karasek wrote: > > This is for an embedded platform, with no harddrive. So I will need to > use things like busybox, etc. I just need the headers & libs. So far I > have only been able to find glibc-2.2.2 from deb in an rpm format. > Could not get this to install in /usr/local/mips-linux/... properly. I > guess what I am really looking for is a tgz file of the libs/headers. I've got cross mipseb libc as rpm for a long time. Sure, it's installed in /usr/mips-linux and has noarch format. The SPEC file just picks up mips.rpm and builds noarch with /usr/mips-linux as root. Unfortunately, I haven't a place where I may upload rpm for public access. If it's what you need I may send the spec file by request. Regards, Gleb. From owner-linux-mips@oss.sgi.com Wed Jul 11 01:51:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6B8pSI30588 for linux-mips-outgoing; Wed, 11 Jul 2001 01:51:28 -0700 Received: from godevin.myreseau.loc (IDENT:105@r30m101.cybercable.tm.fr [195.132.30.101]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6B8pQV30584 for ; Wed, 11 Jul 2001 01:51:26 -0700 Received: from noos.fr (godevin.myreseau.loc [192.168.0.1]) by godevin.myreseau.loc (Postfix) with ESMTP id 9BC0A47801 for ; Wed, 11 Jul 2001 10:51:42 +0200 (CEST) Message-ID: <3B4C139E.BBE2A641@noos.fr> Date: Wed, 11 Jul 2001 10:51:42 +0200 From: =?iso-8859-1?Q?J=E9r=F4me?= Schell X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: fr, en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Re: Boot-Problem on an indy References: <20010711091139.A24847@tuvok.allgaeu.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 414 Lines: 17 Robert Einsle wrote: > > Hy * > > I had installd debian-linux on an indy r4400, 160 mhz > from an howto. but when running dvhtool it gives me an > error back. Now i don't knew if i make a correct > partition-table with right items or any other thing is > wrong. > I called dvhtool: > > dvhtool -d /dev/sda vmlinux-2.4.3.ecoff linux Is it not: dvhtool -d /dev/sda --unix-to-vh vmlinux-2.4.3.ecoff linux Jérôme From owner-linux-mips@oss.sgi.com Wed Jul 11 05:17:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BCHks18538 for linux-mips-outgoing; Wed, 11 Jul 2001 05:17:46 -0700 Received: from animal.pace.co.uk (gateway.pace.co.uk [195.44.197.250]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BCHiV18529 for ; Wed, 11 Jul 2001 05:17:44 -0700 Received: from exchange1.cam.pace.co.uk (exchange1.cam.pace.co.uk [136.170.131.80]) by animal.pace.co.uk (8.10.2/8.10.2) with ESMTP id f6BCHb414231 for ; Wed, 11 Jul 2001 13:17:37 +0100 Received: by exchange1.cam.pace.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 13:16:57 +0100 Message-ID: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.co.uk> From: Phil Thompson To: "'linux-mips@oss.sgi.com'" Subject: Moving from old-irq.c Date: Wed, 11 Jul 2001 13:16:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 166 Lines: 5 Is there any documentation around that describes how to move from interrupt code based on old-irq.c to the new code? Or any other hints or suggestions. Thanks, Phil From owner-linux-mips@oss.sgi.com Wed Jul 11 10:56:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BHubP15668 for linux-mips-outgoing; Wed, 11 Jul 2001 10:56:37 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BHuaV15663 for ; Wed, 11 Jul 2001 10:56:36 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f6BHuQZ03814; Wed, 11 Jul 2001 10:56:26 -0700 (PDT) Date: Wed, 11 Jul 2001 10:56:26 -0700 (PDT) From: "John D. Davis" To: , Subject: Illegal Instruction with 2.4.2 and 2.4.3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 16 I have been able to natively build kernels 2.4.0,2,3,4,5 on an Indy with without the CD-ROM support. I have only been able to boot 2.4.2 and 2.4.3. Previously, I was running 2.4.0-test9. 2.4.4 and 5 have ext2_fs inode problems. 2.4.0 hangs at cleaning the /tmp directory. Extracting tar files causes an illegal instruction on 2.4.2 and 3. Is there a patch for this. Furthermore, are there patches available for all the various kernel versions and how do I get them for each version of the kernel. Finally, I have read some email on stress tests. Are those publicly available? thank you for your time, john From owner-linux-mips@oss.sgi.com Wed Jul 11 11:30:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BIUQY16888 for linux-mips-outgoing; Wed, 11 Jul 2001 11:30:26 -0700 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BIUPV16883 for ; Wed, 11 Jul 2001 11:30:25 -0700 Received: from real.realitydiluted.com ([208.242.241.164] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15KOkV-0007Qb-00; Wed, 11 Jul 2001 13:30:11 -0500 Message-ID: <3B4C99CA.A2C9A9E8@cotw.com> Date: Wed, 11 Jul 2001 13:24:10 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: linux-mips@oss.sgi.com Subject: weird mmap bug from 2.4.3 -> 2.4.5... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1233 Lines: 31 Greetings. I have a framebuffer that is running under 2.4.3 on a MIPS platform. I also wrote a small little demo program that simply mmap's in the framebuffer in user space after which it simply moves the tux logo across the screen. The framebuffer is also used as the console and that also works great. After upgrading to 2.4.5, mmap no longer works. However, the console code works just fine i.e. the framebuffer console properly updates and displays things just fine on the screen. I can also do 'cat /bin/ls > /dev/fb0' and see garbage appear on the screen. Also, the virtual address returned by the mmap call for my demo program in user space is identical on 2.4.3 and 2.4.5, however no tux moves across the screen like it should for the 2.4.5 kernel meaning that the mmap call didn't actually get the framebuffer memory (that's my assumption). I have traced through 'do_mmap_pgoff' and that code appears to be nearly identical in 2.4.3 and 2.4.5. My architecture specific MM code has not changed either, so the cache flushing assembly code is identical. I'm working my way through the 'kmem_cache_XX' calls right now to find differences. Anyone have some ideas? Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Wed Jul 11 12:17:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BJHJt18106 for linux-mips-outgoing; Wed, 11 Jul 2001 12:17:19 -0700 Received: from aux153.plano.net (aux-209-217-36-11.oklahoma.net [209.217.36.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BJHHV18102 for ; Wed, 11 Jul 2001 12:17:17 -0700 Received: (qmail 23238 invoked from network); 11 Jul 2001 19:17:15 -0000 Received: from c572019-b.plano1.tx.home.com (HELO asrael) (24.17.166.65) by aux153.plano.net with SMTP; 11 Jul 2001 19:17:15 -0000 Reply-To: From: "Peter Milleson" To: Subject: boots then kernel panic Date: Wed, 11 Jul 2001 14:17:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 942 Lines: 36 Hi all! Finally have my bootp and tftp server working in order for my used Indy 175 to boot off the network. The system finally downloaded the kernel image (the kernel from hardhat-sgi-5.1) and the system kernel panics with the following error: SCSI bus is being reset for host 0 channel 0. scsi0: reset. page fault from irq handler: 0000 $0 : {lots of numbers} $4 : " " $8 : " " $12: " " $16: " " $29: " " $24: " " $28: " " epc : 880fa97c Status: 1004fc82 Cause : 000000008 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! In swapper task - not syncing Could there be a problem with the onboard SCSI controller? I don't know of any way to test the SCSI subsystem without a bootable SGI cdrom. I am going to try and download a different (newer?) kernel and try again and see what happens. Any help or pointers in the right direction would greatly be appreciated. Thanks, Peter mailto:pitr256@milleson.com From owner-linux-mips@oss.sgi.com Wed Jul 11 13:14:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BKETh19728 for linux-mips-outgoing; Wed, 11 Jul 2001 13:14:29 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BKERV19725 for ; Wed, 11 Jul 2001 13:14:28 -0700 Received: from scotty.mgnet.de (pD9024645.dip.t-dialin.net [217.2.70.69]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA18962 for ; Wed, 11 Jul 2001 22:14:25 +0200 (MET DST) Received: (qmail 32640 invoked from network); 11 Jul 2001 20:14:24 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 11 Jul 2001 20:14:24 -0000 Date: Wed, 11 Jul 2001 22:14:18 +0200 (CEST) From: Klaus Naumann To: Peter Milleson cc: linux-mips@oss.sgi.com Subject: Re: boots then kernel panic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1372 Lines: 44 On Wed, 11 Jul 2001, Peter Milleson wrote: > Hi all! > > Finally have my bootp and tftp server working in order for my used Indy 175 > to boot off the network. The system finally downloaded the kernel image (the > kernel from hardhat-sgi-5.1) and the system kernel panics with the following > error: > > SCSI bus is being reset for host 0 channel 0. > scsi0: reset. page fault from irq handler: 0000 > $0 : {lots of numbers} > $4 : " " > $8 : " " > $12: " " > $16: " " > $29: " " > $24: " " > $28: " " > epc : 880fa97c > Status: 1004fc82 > Cause : 000000008 > Aiee, killing interrupt handler > Kernel panic: Attempted to kill the idle task! > In swapper task - not syncing > > Could there be a problem with the onboard SCSI controller? I don't know of > any way to test the SCSI subsystem without a bootable SGI cdrom. I am going > to try and download a different (newer?) kernel and try again and see what > happens. This is very likely a problem with the SCSI Code or your hardware. But I would assume that the kernel is just plain too old. Please try a newer kernel (you can find one on ftp://source.rfc822.org/). HTH, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Wed Jul 11 13:20:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BKK8R19943 for linux-mips-outgoing; Wed, 11 Jul 2001 13:20:08 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BKK3V19925 for ; Wed, 11 Jul 2001 13:20:03 -0700 Received: from scotty.mgnet.de (pD9024645.dip.t-dialin.net [217.2.70.69]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA25920 for ; Wed, 11 Jul 2001 22:20:01 +0200 (MET DST) Received: (qmail 32679 invoked from network); 11 Jul 2001 20:19:59 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 11 Jul 2001 20:20:00 -0000 Date: Wed, 11 Jul 2001 22:19:54 +0200 (CEST) From: Klaus Naumann To: "John D. Davis" cc: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Re: Illegal Instruction with 2.4.2 and 2.4.3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811071-77193963-994882794=:11181" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6879 Lines: 128 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811071-77193963-994882794=:11181 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 11 Jul 2001, John D. Davis wrote: > I have been able to natively build kernels 2.4.0,2,3,4,5 on an Indy with > without the CD-ROM support. I have only been able to boot 2.4.2 and 2.4.3. > Previously, I was running 2.4.0-test9. 2.4.4 and 5 have ext2_fs inode > problems. 2.4.0 hangs at cleaning the /tmp directory. > > Extracting tar files causes an illegal instruction on 2.4.2 and 3. Is > there a patch for this. Furthermore, are there patches available for all > the various kernel versions and how do I get them for each version of the > kernel. Finally, I have read some email on stress tests. Are those > publicly available? Hi, the illigal instruction problem is known and a workaround has been implemented by several ppl. Personally I'm using the patch which lolo made (I have attached it to this mail). It should apply cleanly against any 2.4.x kernel. About the stress tests I don't know ... CU, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt ---1463811071-77193963-994882794=:11181 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sysmips-lolo.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sysmips-lolo.patch" ZGlmZiAtTnVyIGxpbnV4Lm9yaWcvYXJjaC9taXBzL2tlcm5lbC9NYWtlZmls ZSBsaW51eC9hcmNoL21pcHMva2VybmVsL01ha2VmaWxlDQotLS0gbGludXgu b3JpZy9hcmNoL21pcHMva2VybmVsL01ha2VmaWxlCU1vbiBBcHIgIDkgMDA6 MjM6MDggMjAwMQ0KKysrIGxpbnV4L2FyY2gvbWlwcy9rZXJuZWwvTWFrZWZp bGUJTW9uIEFwciAgOSAwMDoyMzozNCAyMDAxDQpAQCAtMjAsNyArMjAsNyBA QA0KIG9iai15CQkJCSs9IGJyYW5jaC5vIHByb2Nlc3MubyBzaWduYWwubyBl bnRyeS5vIFwNCiAJCQkJICAgdHJhcHMubyBwdHJhY2UubyB2bTg2Lm8gaW9w b3J0Lm8gcmVzZXQubyBcDQogCQkJCSAgIHNlbWFwaG9yZS5vIHNldHVwLm8g c3lzY2FsbC5vIHN5c21pcHMubyBcDQotCQkJCSAgIGlwYy5vIHNjYWxsX28z Mi5vIHVuYWxpZ25lZC5vDQorCQkJCSAgIGlwYy5vIHNjYWxsX28zMi5vIHVu YWxpZ25lZC5vIGZhc3Qtc3lzbWlwcy5vDQogb2JqLSQoQ09ORklHX01PRFVM RVMpCQkrPSBtaXBzX2tzeW1zLm8NCiANCiBpZmRlZiBDT05GSUdfQ1BVX1Iz MDAwDQpAQCAtNjksNSArNjksNiBAQA0KIA0KIGVudHJ5Lm86IGVudHJ5LlMN CiBoZWFkLm86IGhlYWQuUw0KK2Zhc3Qtc3lzbWlwcy5vOiBmYXN0LXN5c21p cHMuUw0KIA0KIGluY2x1ZGUgJChUT1BESVIpL1J1bGVzLm1ha2UNCmRpZmYg LU51ciBsaW51eC5vcmlnL2FyY2gvbWlwcy9rZXJuZWwvZmFzdC1zeXNtaXBz LlMgbGludXgvYXJjaC9taXBzL2tlcm5lbC9mYXN0LXN5c21pcHMuUw0KLS0t IGxpbnV4Lm9yaWcvYXJjaC9taXBzL2tlcm5lbC9mYXN0LXN5c21pcHMuUwlU aHUgSmFuICAxIDAxOjAwOjAwIDE5NzANCisrKyBsaW51eC9hcmNoL21pcHMv a2VybmVsL2Zhc3Qtc3lzbWlwcy5TCU1vbiBBcHIgIDkgMDA6Mjg6MjAgMjAw MQ0KQEAgLTAsMCArMSw4NSBAQA0KKy8qDQorICogTUlQU19BVE9NSUNfU0VU IGFzbSBpbXBsZW1lbnRhdGlvbiBmb3IgbGwvc2MgY2FwYWJsZSBjcHVzDQor ICoNCisgKiBUaGlzIGZpbGUgaXMgc3ViamVjdCB0byB0aGUgdGVybXMgYW5k IGNvbmRpdGlvbnMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYw0KKyAqIExp Y2Vuc2UuICBTZWUgdGhlIGZpbGUgIkNPUFlJTkciIGluIHRoZSBtYWluIGRp cmVjdG9yeSBvZiB0aGlzIGFyY2hpdmUNCisgKiBmb3IgbW9yZSBkZXRhaWxz Lg0KKyAqDQorICogQ29weXJpZ2h0IChDKSAyMDAxIEZsb3JpYW4gTG9ob2Zm IDxmbG9AcmZjODIyLm9yZz4NCisgKg0KKyAqLw0KKyNpbmNsdWRlIDxhc20v YXNtLmg+DQorI2luY2x1ZGUgPGFzbS9taXBzcmVncy5oPg0KKyNpbmNsdWRl IDxhc20vcmVnZGVmLmg+DQorI2luY2x1ZGUgPGFzbS9zdGFja2ZyYW1lLmg+ DQorI2luY2x1ZGUgPGFzbS9pc2FkZXAuaD4NCisjaW5jbHVkZSA8YXNtL3Vu aXN0ZC5oPg0KKyNpbmNsdWRlIDxhc20vc3lzbWlwcy5oPg0KKyNpbmNsdWRl IDxhc20vb2Zmc2V0Lmg+DQorI2luY2x1ZGUgPGFzbS9lcnJuby5oPg0KKw0K KyNkZWZpbmUgUFRfVFJBQ0VTWVMgICAgIDB4MDAwMDAwMDINCisNCisJRVhQ T1JUKGZhc3Rfc3lzbWlwcykNCisNCisJLnNldAlub3Jlb3JkZXINCisNCisJ bGkJdDAsIE1JUFNfQVRPTUlDX1NFVA0KKwliZXEJYTAsIHQwLCAxZg0KKwkg bm9wDQorCWoJc3lzX3N5c21pcHMNCisJIG5vcA0KKw0KKzE6DQorDQorCSMg YTAgLSBNSVBTX0FUT01JQ19TRVQNCisJIyBhMSAtIG1lbSBwdHINCisJIyBh MiAtIHZhbHVlDQorDQorCWFkZGl1CXNwLCBzcCwgLTgJCQkjIFJlc2VydmUg c3BhY2UNCisJc3cJYTAsIChzcCkJCQkjIFNhdmUgYXJnMA0KKw0KKwlhZGRp dQlhMCwgYTEsIDQJCQkjIGFkZHIrc2l6ZQ0KKwlvcmkJdjAsIGExLCA0CQkJ IyBhZGRyIHwgc2l6ZQ0KKwlsdwl2MSwgVEhSRUFEX0NVUkRTKGdwKQkJIyBj dXJyZW50LT50aHJlYWQuY3VycmVudF9kcw0KKwlvcgl2MCwgdjAsIGEwCQkJ IyBhZGRyIHwgc2l6ZSB8IChhZGRyK3NpemUpDQorCWFuZAl2MSwgdjEsIHYw CQkJIyAobWFzaykmKGFkZHIgfCBzaXplIHwgKGFkZHIrc2l6ZSkNCisJYmx0 egl2MSwgNWYNCisJIG5vcA0KKw0KKzI6DQorCWxsCXYwLCAoYTEpDQorCW1v dmUJdDAsIGEyDQorCXNjCXQwLCAoYTEpDQorCWJlcXoJdDAsIDJiDQorCSBu b3ANCisNCisJc3cJdjAsIFBUX1IyKzgoc3ApCQkJIyBSZXN1bHQgdmFsdWUN CisJc3cJemVybywgUFRfUjcrOChzcCkJCSMgU3VjY2VzcyBpbmRpY2F0b3IN CisNCisgICAgICAgIGx3ICAgICAgdDAsIFRBU0tfUFRSQUNFKGdwKQkJIyBz eXNjYWxsIHRyYWNpbmcgZW5hYmxlZD8NCisJYW5kaSAgICB0MCwgUFRfVFJB Q0VTWVMNCisJYm5leiAgICB0MCwgM2YNCisJIG5vcA0KKw0KKzQ6DQorCWx3 CWEwLCAoc3ApCQkJIyBSZXN0b3JlIGFyZzANCisJYWRkaXUJc3AsIHNwLCA4 CQkJIyBSZXN0b3JlIHNwDQorDQorCWoJbzMyX3JldF9mcm9tX3N5c19jYWxs DQorCSBub3ANCisNCiszOg0KKwlzdwlyYSwgNChzcCkNCisJamFsCXN5c2Nh bGxfdHJhY2UNCisJIG5vcA0KKwlsdwlyYSwgNChzcCkNCisJagk0Yg0KKwkg bm9wDQorDQorNToNCisJbHcJYTAsIChzcCkJCQkjIFJlc3RvcmUgYXJnMA0K KwlhZGRpdQlzcCwgc3AsIDgJCQkjIFJlc3RvcmUgc3ANCisJaglyYQ0KKwkg bGkJdjAsIC1FRkFVTFQNCisNCmRpZmYgLU51ciBsaW51eC5vcmlnL2FyY2gv bWlwcy9rZXJuZWwvaXJpeDVzeXMuaCBsaW51eC9hcmNoL21pcHMva2VybmVs L2lyaXg1c3lzLmgNCi0tLSBsaW51eC5vcmlnL2FyY2gvbWlwcy9rZXJuZWwv aXJpeDVzeXMuaAlNb24gQXByICA5IDAwOjE2OjI5IDIwMDENCisrKyBsaW51 eC9hcmNoL21pcHMva2VybmVsL2lyaXg1c3lzLmgJU3VuIEFwciAgOCAyMToy MToxNiAyMDAxDQpAQCAtNjksNyArNjksNyBAQA0KIFNZUyhpcml4X2dldGdp ZCwgMCkJCQkvKiAxMDQ3ICBnZXRnaWQoKQkgICAgICAgViovDQogU1lTKGly aXhfdW5pbXAsIDApCQkJLyogMTA0OCAgKFhYWCBJUklYIDQgc3NpZykgICAg IFYqLw0KIFNZUyhpcml4X21zZ3N5cywgNikJCQkvKiAxMDQ5ICBzeXNfbXNn c3lzCSAgICAgICBWKi8NCi1TWVMoc3lzX3N5c21pcHMsIDQpCQkJLyogMTA1 MCAgc3lzbWlwcygpCSAgICAgIEhWKi8NCitTWVMoZmFzdF9zeXNtaXBzLCA0 KQkJCS8qIDEwNTAgIHN5c21pcHMoKQkgICAgICBIViovDQogU1lTKGlyaXhf dW5pbXAsIDApCQkJLyogMTA1MQkgWFhYIHN5c2FjY3QoKQkgICAgICBJViov DQogU1lTKGlyaXhfc2htc3lzLCA1KQkJCS8qIDEwNTIgIHN5c19zaG1zeXMJ ICAgICAgIFYqLw0KIFNZUyhpcml4X3NlbXN5cywgMCkJCQkvKiAxMDUzICBz eXNfc2Vtc3lzCSAgICAgICBWKi8NCmRpZmYgLU51ciBsaW51eC5vcmlnL2Fy Y2gvbWlwcy9rZXJuZWwvc3lzY2FsbHMuaCBsaW51eC9hcmNoL21pcHMva2Vy bmVsL3N5c2NhbGxzLmgNCi0tLSBsaW51eC5vcmlnL2FyY2gvbWlwcy9rZXJu ZWwvc3lzY2FsbHMuaAlNb24gQXByICA5IDAwOjE2OjMwIDIwMDENCisrKyBs aW51eC9hcmNoL21pcHMva2VybmVsL3N5c2NhbGxzLmgJU3VuIEFwciAgOCAy MToyMTo0MyAyMDAxDQpAQCAtMTYzLDcgKzE2Myw3IEBADQogU1lTKHN5c193 cml0ZXYsIDMpDQogU1lTKHN5c19jYWNoZWZsdXNoLCAzKQ0KIFNZUyhzeXNf Y2FjaGVjdGwsIDMpDQotU1lTKHN5c19zeXNtaXBzLCA0KQ0KK1NZUyhmYXN0 X3N5c21pcHMsIDQpDQogU1lTKHN5c19uaV9zeXNjYWxsLCAwKQkJCQkvKiA0 MTUwICovDQogU1lTKHN5c19nZXRzaWQsIDEpDQogU1lTKHN5c19mZGF0YXN5 bmMsIDApDQoNCg0K ---1463811071-77193963-994882794=:11181-- From owner-linux-mips@oss.sgi.com Wed Jul 11 14:06:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6BL64G23019 for linux-mips-outgoing; Wed, 11 Jul 2001 14:06:04 -0700 Received: from cassidy.nuernberg.linuxtag.net (cassidy.nuernberg.linuxtag.net [212.204.83.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6BL60V23015 for ; Wed, 11 Jul 2001 14:06:02 -0700 Received: from hydra.linuxtag.uni-kl.de (hydra.hq.linuxtag.net [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id 460FBEC2AF; Wed, 11 Jul 2001 23:05:57 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id 99E6E50E5; Wed, 11 Jul 2001 23:05:50 +0200 (CEST) Date: Wed, 11 Jul 2001 23:05:50 +0200 From: Karsten Merker To: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: gpm-support for serial DECstation mouse (VSXXX-AA) Message-ID: <20010711230550.A26702@linuxtag.org> Mail-Followup-To: Karsten Merker , linux-mips@oss.sgi.com, debian-mips@lists.debian.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i X-No-Archive: yes Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 631 Lines: 19 Hallo everyone, I have added support for the DEC VSXXX-AA mouse (serial mouse used on the DECstation 5000/xxx systems) to the Debian gpm package. An experimental package containing the modification (both binary and source) can be found at: ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/packages/experimental/ If you have a DECstation 5000/xxx, please test the package and tell me if it works ok for you. Greetings, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Wed Jul 11 19:13:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6C2DGL00924 for linux-mips-outgoing; Wed, 11 Jul 2001 19:13:16 -0700 Received: from cool.coventive.com (cool.coventive.com [211.79.9.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6C2DEV00921 for ; Wed, 11 Jul 2001 19:13:14 -0700 Received: from jefflee (jungle.coventive.com [211.79.9.189]) by cool.coventive.com (8.10.2/8.10.2) with SMTP id f6C283W30271 for ; Thu, 12 Jul 2001 10:08:03 +0800 Message-ID: <00c401c10a78$a029ece0$9400a8c0@jefflee> From: "jeff_lee" To: References: <20010711230550.A26702@linuxtag.org> Subject: mipsel rpm Date: Thu, 12 Jul 2001 10:16:13 +0800 Organization: hardware MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 275 Lines: 10 Hi, Can mipsel rpm install in x86 platform ?? I got some rpm from pc1.peanuts.gr.jp/~kei/Hard-Float/Based-Kondara-1.1/RPMS/ mipsel/ , but can not install in x86 platform. How to use these prm ?? Or I need a mips platform to install theis rpm ?? Thanks and best regs, Jeff From owner-linux-mips@oss.sgi.com Thu Jul 12 05:03:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CC3vR16804 for linux-mips-outgoing; Thu, 12 Jul 2001 05:03:57 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CC3mV16797 for ; Thu, 12 Jul 2001 05:03:49 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA12453; Thu, 12 Jul 2001 14:05:07 +0200 (MET DST) Date: Thu, 12 Jul 2001 14:05:07 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Karsten Merker cc: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: Re: gpm-support for serial DECstation mouse (VSXXX-AA) In-Reply-To: <20010711230550.A26702@linuxtag.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4626 Lines: 105 On Wed, 11 Jul 2001, Karsten Merker wrote: > I have added support for the DEC VSXXX-AA mouse (serial mouse used on > the DECstation 5000/xxx systems) to the Debian gpm package. An I can't test the patch as I don't have a suitable console device. However, I can already see a problem with the protocol identification masks. Also it's worth mentioning the VSXXX-GA mouse as well (it might not be obvious to everyone the mice are compatible) and the mice are not just DECstation-specific. I think it's the right place to fully specify the protocol used -- specs are not widely available and chances are they might get lost if not cast in stone somewhere. Following is a patch against your version -- please consider the changes I propose. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + gpm-1.19.3-vsxxxaa.patch diff -up --recursive --new-file gpm-1.19.3.macro/mice.c gpm-1.19.3/mice.c --- gpm-1.19.3.macro/mice.c Wed Jul 11 18:12:59 2001 +++ gpm-1.19.3/mice.c Thu Jul 12 00:33:12 2001 @@ -1281,8 +1281,10 @@ static int M_wp(Gpm_Event *state, unsig } -/* DECstation 5000/xxx serial mouse (DEC VSXXX-AA) support */ -/* written 2001/07/11 by Karsten Merker (merker@linuxtag.org) */ +/* Support for DEC VSXXX-AA and VSXXX-GA serial mice used on */ +/* DECstation 5000/xxx, DEC 3000 AXP and VAXstation 4000 */ +/* workstations, written 2001/07/11 by Karsten Merker */ +/* (merker@linuxtag.org) */ static int M_vsxxx_aa(Gpm_Event *state, unsigned char *data) { state->buttons = data[0]&0x07; @@ -1292,8 +1294,8 @@ static int M_vsxxx_aa(Gpm_Event *state, /* Mouse protocol is as follows: - * 3 data bytes per packet, * 4800 bits per second, 8 data bits, 1 stop bit, odd parity + * 3 data bytes per data packet: * 7 6 5 4 3 2 1 0 * First Byte: 1 0 0 SignX SignY LMB MMB RMB * Second Byte 0 DX DX DX DX DX DX DX @@ -1304,8 +1306,29 @@ static int M_vsxxx_aa(Gpm_Event *state, * DX and DY: 7-bit-absolute values for delta-X and delta-Y, sign extensions * are in SignX resp. SignY. * - * Initialization is done by sending an "R" to the mouse; before receiving - * this character, the mouse does not produce a bytestream + * There are a few commands the mouse accepts: + * "D" selects the prompt mode, + * "P" requests the mouse's position (also selects the prompt mode), + * "R" selects the incremental stream mode, + * "T" performs a self test and identification (power-up-like), + * "Z" performs undocumented test functions (a byte follows). + * Parity as well as bit #7 of commands are ignored by the mouse. + * + * 4 data bytes per self test packet (useful for hot-plug): + * 7 6 5 4 3 2 1 0 + * First Byte: 1 0 1 0 R3 R2 R1 R0 + * Second Byte 0 M2 M1 M0 0 0 1 0 + * Third Byte 0 E6 E5 E4 E3 E2 E1 E0 + * Fourth Byte 0 0 0 0 0 LMB MMB RMB + * + * R3-R0: revision, + * M2-M0: manufacturer location code, + * E6-E0: error code: + * 0x00-0x1f: no error (fourth byte is button state), + * 0x3d: button error (fourth byte specifies which), + * else: other error. + * + * The mouse powers up in the prompt mode but we use the stream mode. */ } @@ -1455,7 +1478,7 @@ I_serial(int fd, unsigned short flags, if (type->fun==M_vsxxx_aa) { - setspeed (fd, 4800, 4800, 1, flags); + setspeed (fd, 4800, 4800, 0, flags); /* no write */ write(fd, "R", 1); /* initialize mouse, without getting an "R" the */ /* mouse does not send a bytestream */ } @@ -2057,9 +2080,9 @@ Gpm_Type mice[]={ {"brw", "Fellowes Browser - 4 buttons (and a wheel) (dual protocol?)", "", M_brw, I_pnp, CS7 | STD_FLG, {0xc0, 0x40, 0xc0, 0x00}, 4, 1, 0, 0, 0}, - {"vsxxxaa", "For the DEC VSXXX-AA serial mouse on DECstation 5000/xxx.", + {"vsxxxaa", "The DEC VSXXX-AA/GA serial mouse on DEC workstations.", "", M_vsxxx_aa, I_serial, CS8 | PARENB | PARODD | STD_FLG, - {0x80, 0x80, 0x00, 0x00}, 3, 1, 0, 0, 0}, + {0xe0, 0x80, 0x80, 0x00}, 3, 1, 0, 0, 0}, #ifdef HAVE_LINUX_JOYSTICK_H {"js", "Joystick mouse emulation", From owner-linux-mips@oss.sgi.com Thu Jul 12 11:37:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CIbUU27906 for linux-mips-outgoing; Thu, 12 Jul 2001 11:37:30 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CIbTV27902 for ; Thu, 12 Jul 2001 11:37:29 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E469DC4FE; Thu, 12 Jul 2001 20:37:27 +0200 (CEST) Date: Thu, 12 Jul 2001 20:37:27 +0200 From: Jan-Benedict Glaw To: SGI MIPS list Subject: ll/sc emulation patch Message-ID: <20010712203727.A18294@lug-owl.de> Mail-Followup-To: SGI MIPS list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 273 Lines: 9 Hi! 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? MfG, JBG From owner-linux-mips@oss.sgi.com Thu Jul 12 13:43:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CKh3u03858 for linux-mips-outgoing; Thu, 12 Jul 2001 13:43:03 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CKh2V03851 for ; Thu, 12 Jul 2001 13:43:02 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 0CDF2C4FE; Thu, 12 Jul 2001 22:43:00 +0200 (CEST) Date: Thu, 12 Jul 2001 22:43:00 +0200 From: Jan-Benedict Glaw To: SGI MIPS list , Debian MIPS list Subject: smbfs on DECstations R3k Message-ID: <20010712224300.C18294@lug-owl.de> Mail-Followup-To: SGI MIPS list , Debian MIPS list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 345 Lines: 12 Hi! I tried to compile smbfs support for DECstations R3k. The compiler (that one shipping with the make-cross script) fails in proc.c:smb_proc_setattr_trans2 with normal CFLAGS. Setting -O0 (instead of -O2) lets me compile the source. Is anybody interested in fixing the compiler? I do definitely not have the knowhow to do that... MfG, JBG From owner-linux-mips@oss.sgi.com Thu Jul 12 13:45:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CKjgU04186 for linux-mips-outgoing; Thu, 12 Jul 2001 13:45:42 -0700 Received: from dea.waldorf-gmbh.de (u-43-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CKjcV04183 for ; Thu, 12 Jul 2001 13:45:39 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Thu Jul 12 14:04:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CL4Av06240 for linux-mips-outgoing; Thu, 12 Jul 2001 14:04:10 -0700 Received: from bug.ucw.cz (root@[194.213.32.142]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CL46V06231 for ; Thu, 12 Jul 2001 14:04:07 -0700 Received: (from root@localhost) by bug.ucw.cz (8.9.3/8.8.5) id KAA00181; Thu, 12 Jul 2001 10:23:11 +0200 Date: Mon, 9 Jul 2001 12:02:44 +0000 From: Pavel Machek To: James Simmons Cc: Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com Subject: Re: [ANNOUNCE] Secondary mips tree. Message-ID: <20010709120243.A39@toy.ucw.cz> References: <20010630145732.E255@toy.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jsimmons@transvirtual.com on Sun, Jul 08, 2001 at 11:32:31AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1427 Lines: 34 Hi! > > > We have started a secondary tree for linux mips. This tree will > > > be to SGI mips tree as Alan Cox's tree is to linus branch. We will test > > > and play with "experimental patches" and then in time hand them off to the > > > main branch Ralf Baechle maintains. Also one of the main reasons for this > > > branch was to unite several of the mips trees into one place. Anyones > > > patches (if good) are welcomed. The site is > > > > Do you want to "eat" linux-vr tree? linux-vr list is dead and there's no > > (or not much) development in its CVS (at 240t7 :-() > > Yes. We are reworking the VR code and placing it into our tree. Good. I should definitely take a look. [Do you care about vr4130 or about tx3912, too?] > > > We also have a mailing list which instructions are on the SF page on how > > > to join. Thank you. > > > > Is it ok to be used as linux-vr list? > > I have no problem with it. VR is apart of the mips developement we are > doing. Also we do alot of IT 8172 and au1000 devleopement as well. Plus > some early work for the cobalt cube is being done. I will finish the cube > now that we have a pretty generic pci code layer that is shared amoung > many boards. Seems like there's one more mailinglist for me to read. Ook. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. From owner-linux-mips@oss.sgi.com Thu Jul 12 14:16:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CLGmY07414 for linux-mips-outgoing; Thu, 12 Jul 2001 14:16:48 -0700 Received: from dea.waldorf-gmbh.de (u-43-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CLGiV07408 for ; Thu, 12 Jul 2001 14:16:44 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6CLGKs24248; Thu, 12 Jul 2001 23:16:20 +0200 Date: Thu, 12 Jul 2001 23:16:20 +0200 From: Ralf Baechle To: Peter Milleson Cc: linux-mips@oss.sgi.com Subject: Re: boots then kernel panic Message-ID: <20010712231620.A24243@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 peter@milleson.com on Wed, Jul 11, 2001 at 02:17:14PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 355 Lines: 9 On Wed, Jul 11, 2001 at 02:17:14PM -0500, Peter Milleson wrote: > Finally have my bootp and tftp server working in order for my used Indy 175 > to boot off the network. The system finally downloaded the kernel image (the > kernel from hardhat-sgi-5.1) and the system kernel panics with the following That kernel is almost unusable old by today. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 12 16:15:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CNFee21645 for linux-mips-outgoing; Thu, 12 Jul 2001 16:15:40 -0700 Received: from mail.foobazco.org (snowman.foobazco.org [198.144.194.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CNFdV21634 for ; Thu, 12 Jul 2001 16:15:39 -0700 Received: by mail.foobazco.org (Postfix, from userid 1014) id 522823E90; Thu, 12 Jul 2001 16:07:54 -0700 (PDT) Date: Thu, 12 Jul 2001 16:07:54 -0700 From: Keith M Wesolowski To: Jan-Benedict Glaw Cc: SGI MIPS list , Debian MIPS list Subject: Re: smbfs on DECstations R3k Message-ID: <20010712160754.A8917@foobazco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010712224300.C18294@lug-owl.de> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 706 Lines: 17 On Thu, Jul 12, 2001 at 10:43:00PM +0200, Jan-Benedict Glaw wrote: > I tried to compile smbfs support for DECstations R3k. The compiler > (that one shipping with the make-cross script) fails in > proc.c:smb_proc_setattr_trans2 with normal CFLAGS. Setting -O0 > (instead of -O2) lets me compile the source. > > Is anybody interested in fixing the compiler? I do definitely not > have the knowhow to do that... Can you reproduce this bug with gcc 3.0? -- Keith M Wesolowski http://foobazco.org/~wesolows ------(( Project Foobazco Coordinator and Network Administrator ))------ "There is no such song as 'Acid Acid Acid' by 'The Acid Heads' but there might as well be." --jwz From owner-linux-mips@oss.sgi.com Thu Jul 12 16:31:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CNVUX24514 for linux-mips-outgoing; Thu, 12 Jul 2001 16:31:30 -0700 Received: from dea.waldorf-gmbh.de (u-43-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CNVNV24494 for ; Thu, 12 Jul 2001 16:31:23 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6CNUsA24937; Fri, 13 Jul 2001 01:30:54 +0200 Date: Fri, 13 Jul 2001 01:30:54 +0200 From: Ralf Baechle To: Phil Thompson Cc: "'linux-mips@oss.sgi.com'" Subject: Re: Moving from old-irq.c Message-ID: <20010713013054.A24695@bacchus.dhis.org> References: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.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: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.co.uk>; from Phil.Thompson@pace.co.uk on Wed, Jul 11, 2001 at 01:16:56PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2454 Lines: 88 On Wed, Jul 11, 2001 at 01:16:56PM +0100, Phil Thompson wrote: > Is there any documentation around that describes how to move from interrupt > code based on old-irq.c to the new code? Or any other hints or suggestions. First disable CONFIG_ROTTEN_IRQ if you were using that and enable CONFIG_NEW_IRQ. You'll probably have to hack arch/mips/config.in to do that. Next you have to rewrite your systems irq code. You'll have to provide an init_IRQ() function to initialize the interrupt system. As the absolute minimum it'll have to do something like: set_except_vector(0, myasmirqhandler); init_generic_irq(); and initialize the entries for all interrupts used by your system in the irq_desc array like: for (i = 0; i < NUM_MY_INTS; i++) { irq_desc[i].status = IRQ_DISABLED; irq_desc[i].action = 0; irq_desc[i].depth = 1; irq_desc[i].handler = handler; } where handler is a pointer to struct like this one: static struct hw_interrupt_type ip22_my_irq_type = { "My interrupt controller", startup_my_irq, shutdown_my_irq, enable_my_irq, disable_my_irq, mask_and_ack_my_irq, end_my_irq, NULL }; All that's left now is to write the function references in above struct initialization: static void enable_my_irq(unsigned int irq) { /* enable the interrupt in the controller */ } static unsigned int startup_my_irq(unsigned int irq) { enable_my_irq(irq); return 0; /* Never anything pending */ } static void disable_my_irq(unsigned int irq) { /* Disable function in the interrupt controller */ } static void shutdown_my_irq(unsigned int irq) { /* * Disable interrupt in the interrupt controller. Often this function * is identical to disable_my_irq. */ } static void mask_and_ack_my_irq(unsigned int irq) { /* * Mask and acknowledge interrupt. Often this function is identical * to disable_my_irq. Exception is for example the i8259 PICs. */ } static void end_my_irq (unsigned int irq) { if (!(irq_desc[irq].status & (IRQ_DISABLED|IRQ_INPROGRESS))) enable_my_irq(irq); } Take a look at arch/mips/sgi/indy_int.c but there are more examples. The plan is to nuke old-irq.c early in 2.5; at the same time also something like arch/{i386,mips}/kernel/irq.c will become kernel/irq.c. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 12 16:59:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6CNx5h29277 for linux-mips-outgoing; Thu, 12 Jul 2001 16:59:05 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6CNx0V29259; Thu, 12 Jul 2001 16:59:00 -0700 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 f6CMwrW24220; Thu, 12 Jul 2001 15:58:53 -0700 Message-ID: <3B4E38EF.3D3FF73E@mvista.com> Date: Thu, 12 Jul 2001 16:55:27 -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: Ralf Baechle CC: Phil Thompson , "'linux-mips@oss.sgi.com'" Subject: Re: Moving from old-irq.c References: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.co.uk> <20010713013054.A24695@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 787 Lines: 23 Ralf Baechle wrote: > > On Wed, Jul 11, 2001 at 01:16:56PM +0100, Phil Thompson wrote: > > > Is there any documentation around that describes how to move from interrupt > > code based on old-irq.c to the new code? Or any other hints or suggestions. > > Take a look at arch/mips/sgi/indy_int.c but there are more examples. > Under ddb5xxx/ directory there is an example of doing cascading portable IRQ controllers. The irq_cpu.c file really should be shared by all common r4k style CPUs. > You'll have to provide > an init_IRQ() Ralf, I think we should have a common init_IRQ() in arch/mips/kernel, which will then call (*setup_irq)(). This way it is easier to build a kernel for multiple boards. It is also more compatible with the current arrangment. What do you think? Jun From owner-linux-mips@oss.sgi.com Thu Jul 12 17:41:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6D0fXr02176 for linux-mips-outgoing; Thu, 12 Jul 2001 17:41:33 -0700 Received: from dea.waldorf-gmbh.de (u-43-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.43]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6D0fSV02165 for ; Thu, 12 Jul 2001 17:41:28 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6D0f8h26640; Fri, 13 Jul 2001 02:41:08 +0200 Date: Fri, 13 Jul 2001 02:41:08 +0200 From: Ralf Baechle To: Jun Sun Cc: Phil Thompson , "'linux-mips@oss.sgi.com'" Subject: Re: Moving from old-irq.c Message-ID: <20010713024108.A26493@bacchus.dhis.org> References: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.co.uk> <20010713013054.A24695@bacchus.dhis.org> <3B4E38EF.3D3FF73E@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: <3B4E38EF.3D3FF73E@mvista.com>; from jsun@mvista.com on Thu, Jul 12, 2001 at 04:55:27PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 596 Lines: 13 On Thu, Jul 12, 2001 at 04:55:27PM -0700, Jun Sun wrote: > Ralf, I think we should have a common init_IRQ() in arch/mips/kernel, which > will then call (*setup_irq)(). This way it is easier to build a kernel for > multiple boards. It is also more compatible with the current arrangment. > What do you think? Well, do you actually build kernels for multiple boards that need this? In practice pretty much nobody seems to be interested; technical problems also makes this much harder than on other architectures, for example of all my MIPS systems none could actually share a kernel. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 12 17:54:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6D0s8g03398 for linux-mips-outgoing; Thu, 12 Jul 2001 17:54:08 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6D0s6V03393 for ; Thu, 12 Jul 2001 17:54:06 -0700 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 f6CNs0W27406; Thu, 12 Jul 2001 16:54:00 -0700 Message-ID: <3B4E45D9.8DBE84E7@mvista.com> Date: Thu, 12 Jul 2001 17:50:33 -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: linux-mips@oss.sgi.com Subject: RFC: run-time defining serial ports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1053 Lines: 32 As more and more boards are added to Linux-mips tree, many places are getting crowdier and uglier, including serial.h. The same thing is true for PPC and other architectures. It turns out an easy solution is to let every board sets the serial port definitions at run-time through calling early_serial_setup() routine. An easy fix for now is to give a default table size when no serial definition is given, which at least reserves some slots in the rs_table array. See the patch below. A better solution is probably to provide a config option to define the serial table size. A by-product of this arrangement is that you can configure a kernel for multiple machines. What do you think? Jun diff -Nru include/asm-mips/serial.h.orig include/asm-mips/serial.h --- include/asm-mips/serial.h.orig Wed May 16 15:58:29 2001 +++ include/asm-mips/serial.h Thu Jul 12 17:06:05 2001 @@ -271,3 +271,6 @@ AU1000_SERIAL_PORT_DEFNS \ DDB5477_SERIAL_PORT_DEFNS +#ifnef SERIAL_PORT_DFNS +#define RS_TABLE_SIZE 4 +#endif From owner-linux-mips@oss.sgi.com Thu Jul 12 18:07:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6D17uu04627 for linux-mips-outgoing; Thu, 12 Jul 2001 18:07:56 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6D17oV04609; Thu, 12 Jul 2001 18:07:50 -0700 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 f6D07iW28283; Thu, 12 Jul 2001 17:07:44 -0700 Message-ID: <3B4E4911.25616E3@mvista.com> Date: Thu, 12 Jul 2001 18:04:17 -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: Ralf Baechle CC: Phil Thompson , "'linux-mips@oss.sgi.com'" Subject: Re: Moving from old-irq.c References: <54045BFDAD47D5118A850002A5095CC30AC548@exchange1.cam.pace.co.uk> <20010713013054.A24695@bacchus.dhis.org> <3B4E38EF.3D3FF73E@mvista.com> <20010713024108.A26493@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1030 Lines: 26 Ralf Baechle wrote: > > On Thu, Jul 12, 2001 at 04:55:27PM -0700, Jun Sun wrote: > > > Ralf, I think we should have a common init_IRQ() in arch/mips/kernel, which > > will then call (*setup_irq)(). This way it is easier to build a kernel for > > multiple boards. It is also more compatible with the current arrangment. > > What do you think? > > Well, do you actually build kernels for multiple boards that need this? The answer is actually yes. What is happening in embedded world is people often derive their boards from another board (probably reference board). Sometimes the difference between those two boards are very small (but still have difference such as in interrupt routing). It will then become interesting to share most of the code and leave some other code hookable. Another scenario is sometimes vendors builds a base board which can plug in multiple different daughter boards. In many cases it is desirable to build one kernel for the same "base board". That is the need I have seen so far. Jun From owner-linux-mips@oss.sgi.com Thu Jul 12 18:24:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6D1OAH05990 for linux-mips-outgoing; Thu, 12 Jul 2001 18:24:10 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6D1O3V05980 for ; Thu, 12 Jul 2001 18:24:03 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id F1E74125BA; Thu, 12 Jul 2001 18:24:02 -0700 (PDT) Date: Thu, 12 Jul 2001 18:24:02 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Cc: GNU C Library Subject: Clean up the mips dynamic linker Message-ID: <20010712182402.A10768@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 14741 Lines: 440 Here is a patch to cleanup the mips dynamic linker. It fixes 2 things: 1. We have been handling MAP_BASE_ADDR right for a long time. In the MIPS SVR4 ABI, DT_MIPS_MAP_BASE_ADDR holds the virtual address of the segment. According to the ABI, it is only used for The dynamic linker relocates the global offset table by first adding the difference between the base where the shared object is loaded and the value of dyamic tag DT_MIPS_MAP_BASE_ADDR to all local global offset table entries. In glibc, this difference is stored in the l_addr field in link_map. We have adjusted it in elf_machine_got_rel (): /* Relocate GOT. */ static inline void elf_machine_got_rel (struct link_map *map, int lazy) { ElfW(Addr) *got; ElfW(Sym) *sym; int i, n, symidx; got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]); n = map->l_info[DT_MIPS (LOCAL_GOTNO)]->d_un.d_val; /* The dynamic linker's local got entries have already been relocated. */ if (map != &_dl_rtld_map) { /* got[0] is reserved. got[1] is also reserved for the dynamic object generated by gnu ld. Skip these reserved entries from relocation. */ i = (got[1] & ELF_MIPS_GNU_GOT1_MASK)? 2 : 1; /* Add the run-time displacement to all local got entries if needed. */ if (__builtin_expect (map->l_addr != 0, 0)) { while (i < n) got[i++] += map->l_addr; } } In fact, DT_MIPS_MAP_BASE_ADDR is the same as the p_addr field of the first loadable segment in the program header. I think it is included in the MIPS ABI to give the dynamic linker easy access to it. I have tested DSOs with none-zero DT_MIPS_MAP_BASE_ADDR. It works fine. I think it is safe to remove MAP_BASE_ADDR and old binaries will work with the new glibc. If someone thinks I am wrong, please send me a testcase to show it. 2. The existing mips dynamic linker resolves GOT at the wrong time. It does it in elf_machine_got_rel called from elf_machine_runtime_setup. It doesn't work with Jakub's prelinking work. I think it should be done in elf_dynamic_do_rel. I introduced a new macro, ELF_MACHINE_RESOLVE_GOT, to do it. I also clean up a little bit to follow lazy binding. Any comments? Thanks. H.J. ----- 2001-07-12 H.J. Lu * elf/do-rel.h (ELF_MACHINE_RESOLVE_GOT): New. (elf_dynamic_do_rel): Call ELF_MACHINE_RESOLVE_GOT. * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Removed. (ELF_MACHINE_RESOLVE_GOT): Defined as elf_machine_resolve_got. (elf_machine_resolve_got): New fucntion to resolve GOT. (elf_machine_got_rel): Only do GOT relocation. * sysdeps/mips/rtld-ldscript.in: Removed. * sysdeps/mips/rtld-parms: Likewise. * sysdeps/mips/mips64/rtld-parms: Likewise. * sysdeps/mips/mipsel/rtld-parms: Likewise. --- libc/elf/do-rel.h.mips Sat Jul 7 16:44:45 2001 +++ libc/elf/do-rel.h Thu Jul 12 17:07:47 2001 @@ -30,6 +30,12 @@ # define VERSYMIDX(sym) (DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGIDX (sym)) #endif +/* Some machine, like mips, needs to resolve GOT. */ + +#ifndef ELF_MACHINE_RESOLVE_GOT +#define ELF_MACHINE_RESOLVE_GOT(map,lazy) +#endif + /* Perform the relocations in MAP on the running program image as specified by RELTAG, SZTAG. If LAZY is nonzero, this is the first pass on PLT relocations; they should be set up to call _dl_runtime_resolve, rather @@ -42,6 +48,8 @@ elf_dynamic_do_rel (struct link_map *map { const ElfW(Rel) *r = (const void *) reladdr; const ElfW(Rel) *end = (const void *) (reladdr + relsize); + + ELF_MACHINE_RESOLVE_GOT (map, lazy); if (lazy) { --- libc/sysdeps/mips/dl-machine.h.mips Sat Jul 7 16:46:05 2001 +++ libc/sysdeps/mips/dl-machine.h Thu Jul 12 17:36:11 2001 @@ -61,23 +61,6 @@ in l_info array. */ #define DT_MIPS(x) (DT_MIPS_##x - DT_LOPROC + DT_NUM) -/* - * MIPS libraries are usually linked to a non-zero base address. We - * subtract the base address from the address where we map the object - * to. This results in more efficient address space usage. - * - * FIXME: By the time when MAP_BASE_ADDR is called we don't have the - * DYNAMIC section read. Until this is fixed make the assumption that - * libraries have their base address at 0x5ffe0000. This needs to be - * fixed before we can safely get rid of this MIPSism. - */ -#if 0 -#define MAP_BASE_ADDR(l) ((l)->l_info[DT_MIPS(BASE_ADDRESS)] ? \ - (l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0) -#else -#define MAP_BASE_ADDR(l) 0x5ffe0000 -#endif - /* If there is a DT_MIPS_RLD_MAP entry in the dynamic section, fill it in with the run-time address of the r_debug structure */ #define ELF_MACHINE_DEBUG_SETUP(l,r) \ @@ -557,76 +540,31 @@ elf_machine_lazy_rel (struct link_map *m /* Do nothing. */ } -/* Relocate GOT. */ +#ifndef RTLD_BOOTSTRAP +#define ELF_MACHINE_RESOLVE_GOT(map,lazy) \ + elf_machine_resolve_got ((map), (lazy)) + +/* Resolve GOT. */ static inline void -elf_machine_got_rel (struct link_map *map, int lazy) +elf_machine_resolve_got (struct link_map *map, int lazy) { ElfW(Addr) *got; ElfW(Sym) *sym; - int i, n, symidx; - /* This function is loaded in dl-reloc as a nested function and can - therefore access the variables scope and strtab from - _dl_relocate_object. */ -#ifdef RTLD_BOOTSTRAP -# define RESOLVE_GOTSYM(sym,sym_index) 0 -#else -# define RESOLVE_GOTSYM(sym,sym_index) \ - ({ \ - const ElfW(Sym) *ref = sym; \ - ElfW(Addr) value; \ - \ - switch (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) \ - { \ - default: \ - { \ - const ElfW(Half) *vernum = \ - (const void *) D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); \ - ElfW(Half) ndx = vernum[sym_index]; \ - const struct r_found_version *version = &l->l_versions[ndx]; \ - \ - if (version->hash != 0) \ - { \ - value = _dl_lookup_versioned_symbol(strtab + sym->st_name,\ - map, \ - &ref, scope, version, \ - R_MIPS_REL32, 0); \ - break; \ - } \ - /* Fall through. */ \ - } \ - case 0: \ - value = _dl_lookup_symbol (strtab + sym->st_name, map, &ref, \ - scope, R_MIPS_REL32, 0); \ - } \ - \ - (ref)? value + ref->st_value: 0; \ - }) -#endif /* RTLD_BOOTSTRAP */ + int i, n; + const ElfW(Half) *const version; - got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]); - - n = map->l_info[DT_MIPS (LOCAL_GOTNO)]->d_un.d_val; - /* The dynamic linker's local got entries have already been relocated. */ - if (map != &_dl_rtld_map) - { - /* got[0] is reserved. got[1] is also reserved for the dynamic object - generated by gnu ld. Skip these reserved entries from relocation. */ - i = (got[1] & ELF_MIPS_GNU_GOT1_MASK)? 2 : 1; + if (map->l_info[VERSYMIDX (DT_VERSYM)]) + version = (const void *) D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); + else + version = NULL; - /* Add the run-time displacement to all local got entries if - needed. */ - if (__builtin_expect (map->l_addr != 0, 0)) - { - while (i < n) - got[i++] += map->l_addr; - } - } + got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]); /* Handle global got entries. */ - got += n; + got += map->l_info[DT_MIPS (LOCAL_GOTNO)]->d_un.d_val; /* Keep track of the symbol index. */ - symidx = map->l_info[DT_MIPS (GOTSYM)]->d_un.d_val; - sym = (ElfW(Sym) *) D_PTR (map, l_info[DT_SYMTAB]) + symidx; + sym = (ElfW(Sym) *) D_PTR (map, l_info[DT_SYMTAB]) + + map->l_info[DT_MIPS (GOTSYM)]->d_un.d_val; i = (map->l_info[DT_MIPS (SYMTABNO)]->d_un.d_val - map->l_info[DT_MIPS (GOTSYM)]->d_un.d_val); @@ -635,17 +573,25 @@ elf_machine_got_rel (struct link_map *ma { if (sym->st_shndx == SHN_UNDEF) { - if (ELFW(ST_TYPE) (sym->st_info) == STT_FUNC - && sym->st_value && lazy) - *got = sym->st_value + map->l_addr; + if (ELFW(ST_TYPE) (sym->st_info) == STT_FUNC) + { + if (sym->st_value == 0) + { + if (!lazy) + *got = RESOLVE (&sym, version, R_MIPS_REL32); + } + else if (*got == sym->st_value) + *got += map->l_addr; + else + *got = sym->st_value + map->l_addr; + } else - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE (&sym, version, R_MIPS_REL32); } else if (sym->st_shndx == SHN_COMMON) - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE (&sym, version, R_MIPS_REL32); else if (ELFW(ST_TYPE) (sym->st_info) == STT_FUNC - && *got != sym->st_value - && lazy) + && *got != sym->st_value) *got += map->l_addr; else if (ELFW(ST_TYPE) (sym->st_info) == STT_SECTION) { @@ -653,17 +599,40 @@ elf_machine_got_rel (struct link_map *ma *got += map->l_addr; } else - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE (&sym, version, R_MIPS_REL32); ++got; ++sym; - ++symidx; } +} -#undef RESOLVE_GOTSYM +/* Relocate GOT. */ +static inline void +elf_machine_got_rel (struct link_map *map, int lazy) +{ + ElfW(Addr) *got; + int i, n; + + got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]); + + n = map->l_info[DT_MIPS (LOCAL_GOTNO)]->d_un.d_val; + /* The dynamic linker's local got entries have already been relocated. */ + if (map != &_dl_rtld_map) + { + /* got[0] is reserved. got[1] is also reserved for the dynamic object + generated by gnu ld. Skip these reserved entries from relocation. */ + i = (got[1] & ELF_MIPS_GNU_GOT1_MASK)? 2 : 1; - return; + /* Add the run-time displacement to all local got entries if + needed. */ + if (__builtin_expect (map->l_addr != 0, 0)) + { + while (i < n) + got[i++] += map->l_addr; + } + } } +#endif /* Set up the loaded object described by L so its stub function will jump to the on-demand fixup code __dl_runtime_resolve. */ --- libc/sysdeps/mips/mips64/rtld-parms.mips Sat Jul 12 16:26:11 1997 +++ libc/sysdeps/mips/mips64/rtld-parms Thu Jul 12 17:49:55 2001 @@ -1,3 +0,0 @@ -ifndef rtld-wordsize -rtld-wordsize = 64 -endif --- libc/sysdeps/mips/mipsel/rtld-parms.mips Sat Jul 12 16:26:15 1997 +++ libc/sysdeps/mips/mipsel/rtld-parms Thu Jul 12 17:49:55 2001 @@ -1,3 +0,0 @@ -ifndef rtld-oformat -rtld-oformat = elf32-littlemips -endif --- libc/sysdeps/mips/rtld-ldscript.in.mips Sun May 13 20:39:31 2001 +++ libc/sysdeps/mips/rtld-ldscript.in Thu Jul 12 17:49:55 2001 @@ -1,105 +0,0 @@ -OUTPUT_ARCH(@@rtld-arch@@) -ENTRY(@@rtld-entry@@) -SECTIONS -{ - /* Read-only sections, merged into text segment: */ - . = @@rtld-base@@; - .reginfo : { *(.reginfo) } - .dynamic : { *(.dynamic) } - .dynstr : { *(.dynstr) } - .dynsym : { *(.dynsym) } - .hash : { *(.hash) } - .rel.text : { *(.rel.text) } - .rela.text : { *(.rela.text) } - .rel.data : { *(.rel.data) } - .rela.data : { *(.rela.data) } - .rel.rodata : { *(.rel.rodata) } - .rela.rodata : { *(.rela.rodata) } - .rel.got : { *(.rel.got) } - .rela.got : { *(.rela.got) } - .rel.ctors : { *(.rel.ctors) } - .rela.ctors : { *(.rela.ctors) } - .rel.dtors : { *(.rel.dtors) } - .rela.dtors : { *(.rela.dtors) } - .rel.init : { *(.rel.init) } - .rela.init : { *(.rela.init) } - .rel.fini : { *(.rel.fini) } - .rela.fini : { *(.rela.fini) } - .rel.bss : { *(.rel.bss) } - .rela.bss : { *(.rela.bss) } - .rel.plt : { *(.rel.plt) } - .rela.plt : { *(.rela.plt) } - .rodata : { *(.rodata) } - .rodata1 : { *(.rodata1) } - .init : { *(.init) } =0 - .text : - { - *(.text) - *(.stub) - /* .gnu.warning sections are handled specially by elf32.em. */ - *(.gnu.warning) - } =0 - .fini : { *(.fini) } =0 - /* Adjust the address for the data segment. We want to adjust up to - the same address within the page on the next page up. It would - be more correct to do this: - . = 0x10000000; - The current expression does not correctly handle the case of a - text segment ending precisely at the end of a page; it causes the - data segment to skip a page. The above expression does not have - this problem, but it will currently (2/95) cause BFD to allocate - a single segment, combining both text and data, for this case. - This will prevent the text segment from being shared among - multiple executions of the program; I think that is more - important than losing a page of the virtual address space (note - that no actual memory is lost; the page which is skipped can not - be referenced). */ - . += 0x10000; - .data : - { - *(.data) - CONSTRUCTORS - } - .data1 : { *(.data1) } - .ctors : { *(.ctors) } - .dtors : { *(.dtors) } - _gp = ALIGN(16) + 0x7ff0; - .got : - { - *(.got.plt) *(.got) - } - /* We want the small data sections together, so single-instruction offsets - can access them all, and initialized data all before uninitialized, so - we can shorten the on-disk segment size. */ - .sdata : { *(.sdata) } - .lit8 : { *(.lit8) } - .lit4 : { *(.lit4) } - .sbss : { *(.sbss) *(.scommon) } - .bss : - { - *(.dynbss) - *(.bss) - *(COMMON) - } - /* The normal linker scripts created by the binutils doesn't have the - symbols end and _end which breaks ld.so's dl-minimal.c. */ - _end = . ; - PROVIDE (end = .); - /* These are needed for ELF backends which have not yet been - converted to the new style linker. */ - .stab 0 : { *(.stab) } - .stabstr 0 : { *(.stabstr) } - /* DWARF debug sections. - Symbols in the .debug DWARF section are relative to the beginning of the - section so we begin .debug at 0. It's not clear yet what needs to happen - for the others. */ - .debug 0 : { *(.debug) } - .debug_srcinfo 0 : { *(.debug_srcinfo) } - .debug_aranges 0 : { *(.debug_aranges) } - .debug_pubnames 0 : { *(.debug_pubnames) } - .debug_sfnames 0 : { *(.debug_sfnames) } - .line 0 : { *(.line) } - /* These must appear regardless of . */ - .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } - .gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) } -} --- libc/sysdeps/mips/rtld-parms.mips Mon Jul 21 17:04:07 1997 +++ libc/sysdeps/mips/rtld-parms Thu Jul 12 17:49:55 2001 @@ -1,15 +0,0 @@ -ifndef rtld-wordsize -rtld-wordsize = 32 -endif -ifndef rtld-oformat -rtld-oformat = elf$(rtld-wordsize)-bigmips -endif -ifndef rtld-arch -rtld-arch = mips -endif -ifndef rtld-entry -rtld-entry = __start -endif -ifndef rtld-base -rtld-base = 0x0fb60000 + SIZEOF_HEADERS -endif From owner-linux-mips@oss.sgi.com Fri Jul 13 03:51:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DApTd08360 for linux-mips-outgoing; Fri, 13 Jul 2001 03:51:29 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DApKV08350; Fri, 13 Jul 2001 03:51:21 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 617 Lines: 15 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 owner-linux-mips@oss.sgi.com Fri Jul 13 06:01:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DD13W12428 for linux-mips-outgoing; Fri, 13 Jul 2001 06:01:03 -0700 Received: from dea.waldorf-gmbh.de (u-18-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DD10V12424 for ; Fri, 13 Jul 2001 06:01:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6DBZIO01441; Fri, 13 Jul 2001 13:35:18 +0200 Date: Fri, 13 Jul 2001 13:35:18 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: sti() does not work. Message-ID: <20010713133517.C1378@bacchus.dhis.org> References: <20010704152619.E3829@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 Thu, Jul 05, 2001 at 01:35:11PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 838 Lines: 22 On Thu, Jul 05, 2001 at 01:35:11PM +0200, Maciej W. Rozycki wrote: > > > (why is noreorder used here?). > > > > Without the .set noreorder the assembler would be free to do arbitrary > > reordering of the object code generated. Gas doesn't do that but there > > are other assemblers that do flow analysis and may generate object code > > that doesn't look very much like the source they were fed with. > > Hmm, I would consider that a bug in such an assembler. The mtc0 and > possibly the mfc0 opcode should be treated as reordering barriers as they > may involve side effects an assembler might not be aware of. Assembler is the art of using sideeffects so things are fairly explicit. Optimizations are controlled using .set noreorder / reorder .set volatile / novolatile .set nomove / nomove .set nobopt / bopt Ralf From owner-linux-mips@oss.sgi.com Fri Jul 13 06:01:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DD1Ee12488 for linux-mips-outgoing; Fri, 13 Jul 2001 06:01:14 -0700 Received: from dea.waldorf-gmbh.de (u-18-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DD1BV12484 for ; Fri, 13 Jul 2001 06:01:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6DBLPg01390; Fri, 13 Jul 2001 13:21:25 +0200 Date: Fri, 13 Jul 2001 13:21:25 +0200 From: Ralf Baechle To: Phil Thompson Cc: "'linux-mips@oss.sgi.com'" Subject: Re: OSS CVS Tree and 2.5.x Message-ID: <20010713132124.A1378@bacchus.dhis.org> References: <54045BFDAD47D5118A850002A5095CC30AC542@exchange1.cam.pace.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: <54045BFDAD47D5118A850002A5095CC30AC542@exchange1.cam.pace.co.uk>; from Phil.Thompson@pace.co.uk on Thu, Jul 05, 2001 at 10:09:43AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 261 Lines: 10 On Thu, Jul 05, 2001 at 10:09:43AM +0100, Phil Thompson wrote: > I wasn't around the last time this would have happened... > > What happens to the OSS tree when 2.5.x gets started? Will 2.4.x and 2.5.x > both be maintained on separate branches? Yes. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 13 06:00:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DD0Q612364 for linux-mips-outgoing; Fri, 13 Jul 2001 06:00:26 -0700 Received: from dea.waldorf-gmbh.de (u-18-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DCxdV12315 for ; Fri, 13 Jul 2001 05:59:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6DBhPw01469; Fri, 13 Jul 2001 13:43:25 +0200 Date: Fri, 13 Jul 2001 13:43:25 +0200 From: Ralf Baechle To: Jun Sun Cc: linux-mips@oss.sgi.com Subject: Re: RFC: run-time defining serial ports Message-ID: <20010713134324.D1378@bacchus.dhis.org> References: <3B4E45D9.8DBE84E7@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: <3B4E45D9.8DBE84E7@mvista.com>; from jsun@mvista.com on Thu, Jul 12, 2001 at 05:50:33PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 910 Lines: 25 On Thu, Jul 12, 2001 at 05:50:33PM -0700, Jun Sun wrote: > As more and more boards are added to Linux-mips tree, many places are getting > crowdier and uglier, including serial.h. The same thing is true for PPC and > other architectures. > > It turns out an easy solution is to let every board sets the serial port > definitions at run-time through calling early_serial_setup() routine. > > An easy fix for now is to give a default table size when no serial definition > is given, which at least reserves some slots in the rs_table array. See the > patch below. > > A better solution is probably to provide a config option to define the serial > table size. It's needed; I have machines here with upto 11 serial interfaces on a lowly R4700 box; Origins may have _many_ more. > A by-product of this arrangement is that you can configure a kernel for > multiple machines. > > What do you think? Ralf From owner-linux-mips@oss.sgi.com Fri Jul 13 06:01:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DD1Qj12544 for linux-mips-outgoing; Fri, 13 Jul 2001 06:01:26 -0700 Received: from dea.waldorf-gmbh.de (u-18-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DD1NV12541; Fri, 13 Jul 2001 06:01:23 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6DBNP901401; Fri, 13 Jul 2001 13:23:25 +0200 Date: Fri, 13 Jul 2001 13:23:25 +0200 From: Ralf Baechle To: Paul Mundt Cc: Shaolin Zhang <1&2@oss.sgi.com>, linux-mips@oss.sgi.com, Victor Yodaiken , Cort Dougan Subject: Re: RTLinux for Mips Message-ID: <20010713132325.B1378@bacchus.dhis.org> References: <004301c10500$be67d820$cd22690a@huawei.com> <20010706114845.C29684@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: <20010706114845.C29684@mvista.com>; from pmundt@mvista.com on Fri, Jul 06, 2001 at 11:48:45AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 458 Lines: 13 On Fri, Jul 06, 2001 at 11:48:45AM -0700, Paul Mundt wrote: > On Thu, Jul 05, 2001 at 11:15:29AM +0800, Shaolin Zhang wrote: > > anyone have experience of rtlinux from fsmlabs ? > > > RTL hasn't been ported to MIPS. It only runs on x86/PPC/Alpha and only > supports SMP on x86 and PPC. Strange that there companies shipping RTlinux/MIPS products then. It's just that the MIPS work hasn't really been integrated into the official RTlinux sources. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 13 06:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DD1kx12601 for linux-mips-outgoing; Fri, 13 Jul 2001 06:01:46 -0700 Received: from dea.waldorf-gmbh.de (u-18-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DD1hV12598 for ; Fri, 13 Jul 2001 06:01:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6D9QaB32326; Fri, 13 Jul 2001 11:26:36 +0200 Date: Fri, 13 Jul 2001 11:26:36 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010713112635.A32010@bacchus.dhis.org> References: <20010712182402.A10768@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010712182402.A10768@lucon.org>; from hjl@lucon.org on Thu, Jul 12, 2001 at 06:24:02PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 955 Lines: 21 On Thu, Jul 12, 2001 at 06:24:02PM -0700, H . J . Lu wrote: > In fact, DT_MIPS_MAP_BASE_ADDR is the same as the p_addr field of the > first loadable segment in the program header. I think it is included > in the MIPS ABI to give the dynamic linker easy access to it. Afair there is no requirement for loadable segments to be sorted so you'd have to go through all the program header table to find the one with the lowest address which isn't necessarily the first segment. As the ABI doesn't give any guarantee that the lowest address in the segment table is the value of DT_MIPS_BASE_ADDR I just tried to find a binary on my IRIX boxen that violates this rule but I didn't find any. So please, go ahead. > I have tested DSOs with none-zero DT_MIPS_MAP_BASE_ADDR. It works > fine. I think it is safe to remove MAP_BASE_ADDR and old binaries > will work with the new glibc. If someone thinks I am wrong, please > send me a testcase to show it. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 13 07:08:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DE8Am14650 for linux-mips-outgoing; Fri, 13 Jul 2001 07:08:10 -0700 Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DE82V14646; Fri, 13 Jul 2001 07:08:04 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08084; Fri, 13 Jul 2001 16:01:31 +0200 (MET DST) Date: Fri, 13 Jul 2001 16:01:29 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: sti() does not work. In-Reply-To: <20010713133517.C1378@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1591 Lines: 39 On Fri, 13 Jul 2001, Ralf Baechle wrote: > > Hmm, I would consider that a bug in such an assembler. The mtc0 and > > possibly the mfc0 opcode should be treated as reordering barriers as they > > may involve side effects an assembler might not be aware of. > > Assembler is the art of using sideeffects so things are fairly explicit. > Optimizations are controlled using > > .set noreorder / reorder > .set volatile / novolatile > .set nomove / nomove > .set nobopt / bopt Sure, but sometimes ".set reorder" allows you to achieve better optimization across various ISAs without a need to resort to the preprocessor. Consider the following code: lw $1,($2) addu $3,$1 You need an instruction between the two for a MIPS I CPU but MIPS II+ CPUs interlock here if no instruction is placed. Assuming no real instruction can be reordered here, a nop must be inserted if the code gets compiled for a MIPS I CPU but no instruction is preferred otherwise. The assembler does it automatically if the ".set reorder" directive is active, but you need to decide yourself if it is not. Actually with mfc0 there is no problem -- you need a nop in the case like the above one as coprocessor transfers never interlock; at least docs state so. But who believes docs without a grain of salt, so please correct me if I am wrong (I don't have appropriate hardware to perform a test). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Fri Jul 13 07:21:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DELDM15014 for linux-mips-outgoing; Fri, 13 Jul 2001 07:21:13 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DEL6V15009 for ; Fri, 13 Jul 2001 07:21:07 -0700 Received: from [192.168.1.169] (192.168.1.169 [192.168.1.169]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3GNKV62P; Fri, 13 Jul 2001 10:20:52 -0400 Subject: Re: RFC: run-time defining serial ports From: Marc Karasek To: Jun Sun Cc: linux-mips@oss.sgi.com In-Reply-To: <3B4E45D9.8DBE84E7@mvista.com> References: <3B4E45D9.8DBE84E7@mvista.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 13 Jul 2001 10:20:05 -0400 Message-Id: <995034043.1803.0.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2144 Lines: 58 Good idea, I would take it a step further coming at it from a purely embedded standpoint. If a option to the kernel could be defined so that the init code that brings the system up could setup things like the serial port, etc. and then notify the kernel that the serial port has been setup with parameters xyz. All boot monitors (YAMON, PMON, REDBOOT) initialize the serial port as part of there bootup for use as a debug monitor, etc. Why should we have to redo something that is already taken care of. Unless there is some case where you want to reset it, maybe the baud rate is too slow or something. I think as linux moves more into the embedded space we will need to deal with more issues like this. Where the embedded requirements do not match with those coming from the desktop/workstation world. On 12 Jul 2001 17:50:33 -0700, Jun Sun wrote: > > As more and more boards are added to Linux-mips tree, many places are getting > crowdier and uglier, including serial.h. The same thing is true for PPC and > other architectures. > > It turns out an easy solution is to let every board sets the serial port > definitions at run-time through calling early_serial_setup() routine. > > An easy fix for now is to give a default table size when no serial definition > is given, which at least reserves some slots in the rs_table array. See the > patch below. > > A better solution is probably to provide a config option to define the serial > table size. > > A by-product of this arrangement is that you can configure a kernel for > multiple machines. > > What do you think? > > Jun > > diff -Nru include/asm-mips/serial.h.orig include/asm-mips/serial.h > --- include/asm-mips/serial.h.orig Wed May 16 15:58:29 2001 > +++ include/asm-mips/serial.h Thu Jul 12 17:06:05 2001 > @@ -271,3 +271,6 @@ > AU1000_SERIAL_PORT_DEFNS \ > DDB5477_SERIAL_PORT_DEFNS > > +#ifnef SERIAL_PORT_DFNS > +#define RS_TABLE_SIZE 4 > +#endif -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Fri Jul 13 07:55:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DEtZ116193 for linux-mips-outgoing; Fri, 13 Jul 2001 07:55:35 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DEtYV16184 for ; Fri, 13 Jul 2001 07:55:34 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id SAA02910; Fri, 13 Jul 2001 18:56:06 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id SAA11711; Fri, 13 Jul 2001 18:53:16 +0400 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id SAA24868; Fri, 13 Jul 2001 18:49:11 +0400 (MSD) Message-ID: <3B4F0A5B.C1C0287D@niisi.msk.ru> Date: Fri, 13 Jul 2001 18:48:59 +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: Marc Karasek CC: Jun Sun , linux-mips@oss.sgi.com Subject: Re: RFC: run-time defining serial ports References: <3B4E45D9.8DBE84E7@mvista.com> <995034043.1803.0.camel@localhost.localdomain> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 526 Lines: 15 Marc Karasek wrote: > > All boot monitors (YAMON, PMON, > REDBOOT) initialize the serial port as part of there bootup for use as a > debug monitor, etc. Why should we have to redo something that is > already taken care of. Because we've got completely another policy of handling a device. For example, a boot monitor (good one) must implement polling technique only, Linux uses interrupt-driven technique (well, mostly). In general case, Linux has to reinitialize a device after a boot monitor. It's clear. Regards, Gleb. From owner-linux-mips@oss.sgi.com Fri Jul 13 08:01:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DF1pZ16576 for linux-mips-outgoing; Fri, 13 Jul 2001 08:01:51 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DF1kV16570 for ; Fri, 13 Jul 2001 08:01:46 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6DF1avf030607; Fri, 13 Jul 2001 08:01:37 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6DF1ZK7030603; Fri, 13 Jul 2001 08:01:36 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 13 Jul 2001 08:01:35 -0700 (PDT) From: James Simmons To: Pavel Machek cc: Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [ANNOUNCE] Secondary mips tree. In-Reply-To: <20010709120243.A39@toy.ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 140 Lines: 7 > Good. I should definitely take a look. [Do you care about vr4130 or about > tx3912, too?] Yes. If you want to work on it no problem. From owner-linux-mips@oss.sgi.com Fri Jul 13 08:13:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DFDH317144 for linux-mips-outgoing; Fri, 13 Jul 2001 08:13:17 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DFDFV17140 for ; Fri, 13 Jul 2001 08:13:15 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id AC106C4FE; Fri, 13 Jul 2001 17:13:13 +0200 (CEST) Date: Fri, 13 Jul 2001 17:13:13 +0200 From: Jan-Benedict Glaw To: SGI MIPS list , Debian MIPS list Subject: Patch to ptrace.c Message-ID: <20010713171313.E22543@lug-owl.de> Mail-Followup-To: SGI MIPS list , Debian MIPS list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 843 Lines: 35 Hi! Fixing a little typo preventing proper compiling... Ralf? Would you please apply it? Index: ptrace.c =================================================================== RCS file: /cvs/linux/arch/mips/kernel/ptrace.c,v retrieving revision 1.28 diff -u -r1.28 ptrace.c --- ptrace.c 2001/07/12 00:16:53 1.28 +++ ptrace.c 2001/07/13 12:10:36 @@ -155,7 +155,7 @@ * registers - unless we're using r2k_switch.S. */ #ifdef CONFIG_CPU_R3000 - if (mips_cpu_options & MIPS_CPU_FPU) + if (mips_cpu.options & MIPS_CPU_FPU) tmp = *(unsigned long *)(fregs + addr); else #endif @@ -252,7 +252,7 @@ * we're using r2k_switch.S. */ #ifdef CONFIG_CPU_R3000 - if (mips_cpu_options & MIPS_CPU_FPU) + if (mips_cpu.options & MIPS_CPU_FPU) *(unsigned long *)(fregs + addr) = data; else #endif MfG, JBG From owner-linux-mips@oss.sgi.com Fri Jul 13 09:11:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DGB3920598 for linux-mips-outgoing; Fri, 13 Jul 2001 09:11:03 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DGAsV20594; Fri, 13 Jul 2001 09:10:55 -0700 Received: from otr.mynet (fiendish.cygnus.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA11549; Fri, 13 Jul 2001 09:10:47 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.11.2/8.11.2) id f6DG6nq12196; Fri, 13 Jul 2001 09:06:49 -0700 X-Authentication-Warning: otr.mynet: drepper set sender to drepper@redhat.com using -f To: Ralf Baechle Cc: "H . J . Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@bacchus.dhis.org> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 13 Jul 2001 09:06:49 -0700 In-Reply-To: Ralf Baechle's message of "Fri, 13 Jul 2001 11:26:36 +0200" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 328 Lines: 10 Ralf Baechle writes: > So please, go ahead. So you say the patch is OK from your POV? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Fri Jul 13 11:10:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DIARo23506 for linux-mips-outgoing; Fri, 13 Jul 2001 11:10:27 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DIAGV23495; Fri, 13 Jul 2001 11:10:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id CE2C5125BA; Fri, 13 Jul 2001 11:10:10 -0700 (PDT) Date: Fri, 13 Jul 2001 11:10:10 -0700 From: "H . J . Lu" To: Ulrich Drepper Cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010713111010.A25902@lucon.org> References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@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 drepper@redhat.com on Fri, Jul 13, 2001 at 09:06:49AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9592 Lines: 287 On Fri, Jul 13, 2001 at 09:06:49AM -0700, Ulrich Drepper wrote: > Ralf Baechle writes: > > > So please, go ahead. > > So you say the patch is OK from your POV? > My last patch was not ok :-(. Somehow, make didn't rebuild. In this patch, I rewrote RESOLVE_GOTSYM with RESOLVE to help prelink. H.J. ----- 2001-07-13 H.J. Lu * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Removed. (elf_machine_got_rel): Defined only if RTLD_BOOTSTRAP is not defined. (RESOLVE_GOTSYM): Rewrite to use RESOLVE. * sysdeps/mips/rtld-ldscript.in: Removed. * sysdeps/mips/rtld-parms: Likewise. * sysdeps/mips/mips64/rtld-parms: Likewise. * sysdeps/mips/mipsel/rtld-parms: Likewise. --- libc/sysdeps/mips/dl-machine.h.mips Sat Jul 7 16:46:05 2001 +++ libc/sysdeps/mips/dl-machine.h Fri Jul 13 10:53:42 2001 @@ -61,23 +61,6 @@ in l_info array. */ #define DT_MIPS(x) (DT_MIPS_##x - DT_LOPROC + DT_NUM) -/* - * MIPS libraries are usually linked to a non-zero base address. We - * subtract the base address from the address where we map the object - * to. This results in more efficient address space usage. - * - * FIXME: By the time when MAP_BASE_ADDR is called we don't have the - * DYNAMIC section read. Until this is fixed make the assumption that - * libraries have their base address at 0x5ffe0000. This needs to be - * fixed before we can safely get rid of this MIPSism. - */ -#if 0 -#define MAP_BASE_ADDR(l) ((l)->l_info[DT_MIPS(BASE_ADDRESS)] ? \ - (l)->l_info[DT_MIPS(BASE_ADDRESS)]->d_un.d_ptr : 0) -#else -#define MAP_BASE_ADDR(l) 0x5ffe0000 -#endif - /* If there is a DT_MIPS_RLD_MAP entry in the dynamic section, fill it in with the run-time address of the r_debug structure */ #define ELF_MACHINE_DEBUG_SETUP(l,r) \ @@ -557,51 +540,30 @@ elf_machine_lazy_rel (struct link_map *m /* Do nothing. */ } +#ifndef RTLD_BOOTSTRAP /* Relocate GOT. */ static inline void elf_machine_got_rel (struct link_map *map, int lazy) { ElfW(Addr) *got; ElfW(Sym) *sym; + const ElfW(Half) *vernum; int i, n, symidx; - /* This function is loaded in dl-reloc as a nested function and can - therefore access the variables scope and strtab from - _dl_relocate_object. */ -#ifdef RTLD_BOOTSTRAP -# define RESOLVE_GOTSYM(sym,sym_index) 0 -#else -# define RESOLVE_GOTSYM(sym,sym_index) \ + +#define RESOLVE_GOTSYM(sym,vernum,sym_index) \ ({ \ const ElfW(Sym) *ref = sym; \ + const struct r_found_version *version \ + = vernum ? &map->l_versions [vernum [sym_index]] : NULL; \ ElfW(Addr) value; \ - \ - switch (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) \ - { \ - default: \ - { \ - const ElfW(Half) *vernum = \ - (const void *) D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); \ - ElfW(Half) ndx = vernum[sym_index]; \ - const struct r_found_version *version = &l->l_versions[ndx]; \ - \ - if (version->hash != 0) \ - { \ - value = _dl_lookup_versioned_symbol(strtab + sym->st_name,\ - map, \ - &ref, scope, version, \ - R_MIPS_REL32, 0); \ - break; \ - } \ - /* Fall through. */ \ - } \ - case 0: \ - value = _dl_lookup_symbol (strtab + sym->st_name, map, &ref, \ - scope, R_MIPS_REL32, 0); \ - } \ - \ + value = RESOLVE (&ref, version, R_MIPS_REL32); \ (ref)? value + ref->st_value: 0; \ }) -#endif /* RTLD_BOOTSTRAP */ + + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) + vernum = (const void *) D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); + else + vernum = NULL; got = (ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]); @@ -639,10 +601,10 @@ elf_machine_got_rel (struct link_map *ma && sym->st_value && lazy) *got = sym->st_value + map->l_addr; else - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE_GOTSYM (sym, vernum, symidx); } else if (sym->st_shndx == SHN_COMMON) - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE_GOTSYM (sym, vernum, symidx); else if (ELFW(ST_TYPE) (sym->st_info) == STT_FUNC && *got != sym->st_value && lazy) @@ -653,7 +615,7 @@ elf_machine_got_rel (struct link_map *ma *got += map->l_addr; } else - *got = RESOLVE_GOTSYM (sym, symidx); + *got = RESOLVE_GOTSYM (sym, vernum, symidx); ++got; ++sym; @@ -661,9 +623,8 @@ elf_machine_got_rel (struct link_map *ma } #undef RESOLVE_GOTSYM - - return; } +#endif /* Set up the loaded object described by L so its stub function will jump to the on-demand fixup code __dl_runtime_resolve. */ --- libc/sysdeps/mips/mips64/rtld-parms.mips Sat Jul 12 16:26:11 1997 +++ libc/sysdeps/mips/mips64/rtld-parms Fri Jul 13 10:54:55 2001 @@ -1,3 +0,0 @@ -ifndef rtld-wordsize -rtld-wordsize = 64 -endif --- libc/sysdeps/mips/mipsel/rtld-parms.mips Sat Jul 12 16:26:15 1997 +++ libc/sysdeps/mips/mipsel/rtld-parms Fri Jul 13 10:54:55 2001 @@ -1,3 +0,0 @@ -ifndef rtld-oformat -rtld-oformat = elf32-littlemips -endif --- libc/sysdeps/mips/rtld-ldscript.in.mips Sun May 13 20:39:31 2001 +++ libc/sysdeps/mips/rtld-ldscript.in Fri Jul 13 10:54:55 2001 @@ -1,105 +0,0 @@ -OUTPUT_ARCH(@@rtld-arch@@) -ENTRY(@@rtld-entry@@) -SECTIONS -{ - /* Read-only sections, merged into text segment: */ - . = @@rtld-base@@; - .reginfo : { *(.reginfo) } - .dynamic : { *(.dynamic) } - .dynstr : { *(.dynstr) } - .dynsym : { *(.dynsym) } - .hash : { *(.hash) } - .rel.text : { *(.rel.text) } - .rela.text : { *(.rela.text) } - .rel.data : { *(.rel.data) } - .rela.data : { *(.rela.data) } - .rel.rodata : { *(.rel.rodata) } - .rela.rodata : { *(.rela.rodata) } - .rel.got : { *(.rel.got) } - .rela.got : { *(.rela.got) } - .rel.ctors : { *(.rel.ctors) } - .rela.ctors : { *(.rela.ctors) } - .rel.dtors : { *(.rel.dtors) } - .rela.dtors : { *(.rela.dtors) } - .rel.init : { *(.rel.init) } - .rela.init : { *(.rela.init) } - .rel.fini : { *(.rel.fini) } - .rela.fini : { *(.rela.fini) } - .rel.bss : { *(.rel.bss) } - .rela.bss : { *(.rela.bss) } - .rel.plt : { *(.rel.plt) } - .rela.plt : { *(.rela.plt) } - .rodata : { *(.rodata) } - .rodata1 : { *(.rodata1) } - .init : { *(.init) } =0 - .text : - { - *(.text) - *(.stub) - /* .gnu.warning sections are handled specially by elf32.em. */ - *(.gnu.warning) - } =0 - .fini : { *(.fini) } =0 - /* Adjust the address for the data segment. We want to adjust up to - the same address within the page on the next page up. It would - be more correct to do this: - . = 0x10000000; - The current expression does not correctly handle the case of a - text segment ending precisely at the end of a page; it causes the - data segment to skip a page. The above expression does not have - this problem, but it will currently (2/95) cause BFD to allocate - a single segment, combining both text and data, for this case. - This will prevent the text segment from being shared among - multiple executions of the program; I think that is more - important than losing a page of the virtual address space (note - that no actual memory is lost; the page which is skipped can not - be referenced). */ - . += 0x10000; - .data : - { - *(.data) - CONSTRUCTORS - } - .data1 : { *(.data1) } - .ctors : { *(.ctors) } - .dtors : { *(.dtors) } - _gp = ALIGN(16) + 0x7ff0; - .got : - { - *(.got.plt) *(.got) - } - /* We want the small data sections together, so single-instruction offsets - can access them all, and initialized data all before uninitialized, so - we can shorten the on-disk segment size. */ - .sdata : { *(.sdata) } - .lit8 : { *(.lit8) } - .lit4 : { *(.lit4) } - .sbss : { *(.sbss) *(.scommon) } - .bss : - { - *(.dynbss) - *(.bss) - *(COMMON) - } - /* The normal linker scripts created by the binutils doesn't have the - symbols end and _end which breaks ld.so's dl-minimal.c. */ - _end = . ; - PROVIDE (end = .); - /* These are needed for ELF backends which have not yet been - converted to the new style linker. */ - .stab 0 : { *(.stab) } - .stabstr 0 : { *(.stabstr) } - /* DWARF debug sections. - Symbols in the .debug DWARF section are relative to the beginning of the - section so we begin .debug at 0. It's not clear yet what needs to happen - for the others. */ - .debug 0 : { *(.debug) } - .debug_srcinfo 0 : { *(.debug_srcinfo) } - .debug_aranges 0 : { *(.debug_aranges) } - .debug_pubnames 0 : { *(.debug_pubnames) } - .debug_sfnames 0 : { *(.debug_sfnames) } - .line 0 : { *(.line) } - /* These must appear regardless of . */ - .gptab.sdata : { *(.gptab.data) *(.gptab.sdata) } - .gptab.sbss : { *(.gptab.bss) *(.gptab.sbss) } -} --- libc/sysdeps/mips/rtld-parms.mips Mon Jul 21 17:04:07 1997 +++ libc/sysdeps/mips/rtld-parms Fri Jul 13 10:54:55 2001 @@ -1,15 +0,0 @@ -ifndef rtld-wordsize -rtld-wordsize = 32 -endif -ifndef rtld-oformat -rtld-oformat = elf$(rtld-wordsize)-bigmips -endif -ifndef rtld-arch -rtld-arch = mips -endif -ifndef rtld-entry -rtld-entry = __start -endif -ifndef rtld-base -rtld-base = 0x0fb60000 + SIZEOF_HEADERS -endif From owner-linux-mips@oss.sgi.com Fri Jul 13 11:14:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DIERP23625 for linux-mips-outgoing; Fri, 13 Jul 2001 11:14:27 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DIEPV23622; Fri, 13 Jul 2001 11:14:25 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 20B73125BA; Fri, 13 Jul 2001 11:14:25 -0700 (PDT) Date: Fri, 13 Jul 2001 11:14:25 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010713111424.B25902@lucon.org> References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@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: <20010713112635.A32010@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, Jul 13, 2001 at 11:26:36AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 996 Lines: 22 On Fri, Jul 13, 2001 at 11:26:36AM +0200, Ralf Baechle wrote: > On Thu, Jul 12, 2001 at 06:24:02PM -0700, H . J . Lu wrote: > > > In fact, DT_MIPS_MAP_BASE_ADDR is the same as the p_addr field of the > > first loadable segment in the program header. I think it is included > > in the MIPS ABI to give the dynamic linker easy access to it. > > Afair there is no requirement for loadable segments to be sorted so you'd > have to go through all the program header table to find the one with the > lowest address which isn't necessarily the first segment. > > As the ABI doesn't give any guarantee that the lowest address in the segment > table is the value of DT_MIPS_BASE_ADDR I just tried to find a binary on > my IRIX boxen that violates this rule but I didn't find any. So please, > go ahead. It doesn't matter. DT_MIPS_BASE_ADDR is the "Base Address" in the gABI. glibc has to get the "Base Address" right. Otherwise, it won't work correctly for all cases. It is not mips specific. H.J. From owner-linux-mips@oss.sgi.com Fri Jul 13 11:16:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DIGb523714 for linux-mips-outgoing; Fri, 13 Jul 2001 11:16:37 -0700 Received: from mail.kdt.de (mail.kdt.de [195.8.224.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DIGXV23711; Fri, 13 Jul 2001 11:16:33 -0700 Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5]) by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f6DIGHT05463; Fri, 13 Jul 2001 20:16:17 +0200 Received: from gromit.moeb ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.30 #1) id 15L7Lp-0006r1-00; Fri, 13 Jul 2001 20:07:41 +0200 Received: by gromit.moeb (Postfix, from userid 207) id 1D2FF1EA2A; Fri, 13 Jul 2001 20:07:40 +0200 (CEST) Mail-Copies-To: never To: drepper@cygnus.com (Ulrich Drepper) Cc: Ralf Baechle , "H . J . Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@bacchus.dhis.org> From: Andreas Jaeger Date: Fri, 13 Jul 2001 20:07:40 +0200 In-Reply-To: (Ulrich Drepper's message of "13 Jul 2001 09:06:49 -0700") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 382 Lines: 17 Ulrich Drepper writes: > Ralf Baechle writes: > >> So please, go ahead. > > So you say the patch is OK from your POV? Just for the record, I also think it's ok - but will not apply it since it depends on patches for generic code. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Jul 13 11:17:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DIHpU23790 for linux-mips-outgoing; Fri, 13 Jul 2001 11:17:51 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DIHnV23787; Fri, 13 Jul 2001 11:17:49 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id AF72F125BA; Fri, 13 Jul 2001 11:17:43 -0700 (PDT) Date: Fri, 13 Jul 2001 11:17:43 -0700 From: "H . J . Lu" To: Andreas Jaeger Cc: Ulrich Drepper , Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010713111743.C25902@lucon.org> References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@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 aj@suse.de on Fri, Jul 13, 2001 at 08:07:40PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 467 Lines: 17 On Fri, Jul 13, 2001 at 08:07:40PM +0200, Andreas Jaeger wrote: > Ulrich Drepper writes: > > > Ralf Baechle writes: > > > >> So please, go ahead. > > > > So you say the patch is OK from your POV? > > Just for the record, I also think it's ok - but will not apply it > since it depends on patches for generic code. Please ignore my first patch, which is wrong. The second one is ok which doesn't touch generic code. H.J. From owner-linux-mips@oss.sgi.com Fri Jul 13 12:27:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DJRq825396 for linux-mips-outgoing; Fri, 13 Jul 2001 12:27:52 -0700 Received: from hefeweizen.linnaean.org (hefeweizen.cv.linnaean.org [209.58.179.123]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DJRmV25391; Fri, 13 Jul 2001 12:27:48 -0700 Received: from perdition.linnaean.org (hagx.ne.mediaone.net [24.147.20.16]) by hefeweizen.linnaean.org (8.9.3/8.9.3/AI2.13/linnaean.master:2.6) with ESMTP id PAA19543; Fri, 13 Jul 2001 15:25:36 -0400 (EDT) Received: by perdition.linnaean.org (Postfix, from userid 5281) id 36A9199766; Fri, 13 Jul 2001 15:25:00 -0400 (EDT) From: Roland McGrath MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ralf Baechle Cc: "H . J . Lu" , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker In-Reply-To: Ralf Baechle's message of Fri, 13 July 2001 11:26:36 +0200 <20010713112635.A32010@bacchus.dhis.org> Emacs: ed :: 20-megaton hydrogen bomb : firecracker Message-Id: <20010713192500.36A9199766@perdition.linnaean.org> Date: Fri, 13 Jul 2001 15:25:00 -0400 (EDT) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 141 Lines: 3 > Afair there is no requirement for loadable segments to be sorted PT_LOAD entries appear in ascending order, sorted on the p_vaddr member. From owner-linux-mips@oss.sgi.com Fri Jul 13 12:31:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DJV4F25556 for linux-mips-outgoing; Fri, 13 Jul 2001 12:31:04 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DJV1V25553; Fri, 13 Jul 2001 12:31:01 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 1FFE7125BA; Fri, 13 Jul 2001 12:31:00 -0700 (PDT) Date: Fri, 13 Jul 2001 12:31:00 -0700 From: "H . J . Lu" To: Roland McGrath Cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010713123100.A27305@lucon.org> References: <20010713112635.A32010@bacchus.dhis.org> <20010713192500.36A9199766@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010713192500.36A9199766@perdition.linnaean.org>; from roland@frob.com on Fri, Jul 13, 2001 at 03:25:00PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 375 Lines: 11 On Fri, Jul 13, 2001 at 03:25:00PM -0400, Roland McGrath wrote: > > Afair there is no requirement for loadable segments to be sorted > > PT_LOAD entries appear in ascending order, sorted on the p_vaddr member. Thanks. I missed that one. In any case, glibc has been right on mips for a long time. We just don't need that specical treatmeant for DT_MIPS_BASE_ADDRESS. H.J. From owner-linux-mips@oss.sgi.com Fri Jul 13 16:44:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6DNiI904221 for linux-mips-outgoing; Fri, 13 Jul 2001 16:44:18 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6DNiGV04215 for ; Fri, 13 Jul 2001 16:44:17 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id BE694125BA; Fri, 13 Jul 2001 16:44:15 -0700 (PDT) Date: Fri, 13 Jul 2001 16:44:15 -0700 From: "H . J . Lu" To: GDB Cc: linux-mips@oss.sgi.com Subject: Gdb quit problem on Linux/mips Message-ID: <20010713164415.A31747@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 478 Lines: 25 Did anyone see the quit problem on Linux/mips with gdb 2001-07-13-cvs? I got (gdb) b main Breakpoint 1 at 0x400744: file x.c, line 3. (gdb) r Starting program: /tmp/./a.out Breakpoint 1, main () at x.c:3 3 printf ("Hello\n"); (gdb) q The program is running. Exit anyway? (y or n) y It stops here. I get 1540 pts/0 S 0:04 ./gdb ./a.out 1550 pts/0 T 0:00 /tmp/./a.out # strace -p 1540 wait4(-1, It may be a kernel bug. I am running 2.4.3. H.J. From owner-linux-mips@oss.sgi.com Fri Jul 13 17:05:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6E05L205620 for linux-mips-outgoing; Fri, 13 Jul 2001 17:05:21 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6E05GV05616 for ; Fri, 13 Jul 2001 17:05:16 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA09108 for ; Fri, 13 Jul 2001 17:05:06 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15LClu-00059C-00; Fri, 13 Jul 2001 16:54:58 -0700 Date: Fri, 13 Jul 2001 16:54:58 -0700 From: Daniel Jacobowitz To: "H . J . Lu" Cc: GDB , linux-mips@oss.sgi.com Subject: Re: Gdb quit problem on Linux/mips Message-ID: <20010713165458.A19776@nevyn.them.org> Mail-Followup-To: "H . J . Lu" , GDB , linux-mips@oss.sgi.com References: <20010713164415.A31747@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010713164415.A31747@lucon.org>; from hjl@lucon.org on Fri, Jul 13, 2001 at 04:44:15PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 866 Lines: 31 On Fri, Jul 13, 2001 at 04:44:15PM -0700, H . J . Lu wrote: > Did anyone see the quit problem on Linux/mips with gdb 2001-07-13-cvs? > I got > > (gdb) b main > Breakpoint 1 at 0x400744: file x.c, line 3. > (gdb) r > Starting program: /tmp/./a.out > > Breakpoint 1, main () at x.c:3 > 3 printf ("Hello\n"); > (gdb) q > The program is running. Exit anyway? (y or n) y > > It stops here. I get > > 1540 pts/0 S 0:04 ./gdb ./a.out > 1550 pts/0 T 0:00 /tmp/./a.out > > # strace -p 1540 > wait4(-1, > > It may be a kernel bug. I am running 2.4.3. Yes, it's a kernel bug. I believe this is fixed in the SGI tree; I know it's fixed in ours (which will be available Monday or later tonight). -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Sat Jul 14 03:53:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EArev09440 for linux-mips-outgoing; Sat, 14 Jul 2001 03:53:40 -0700 Received: from dea.waldorf-gmbh.de (u-121-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EArcV09434 for ; Sat, 14 Jul 2001 03:53:38 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Sat Jul 14 03:54:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EAsv509561 for linux-mips-outgoing; Sat, 14 Jul 2001 03:54:57 -0700 Received: from dea.waldorf-gmbh.de (u-121-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EAstV09555 for ; Sat, 14 Jul 2001 03:54:55 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6EAsLw06081; Sat, 14 Jul 2001 12:54:21 +0200 Date: Sat, 14 Jul 2001 12:54:21 +0200 From: Ralf Baechle To: Jan-Benedict Glaw Cc: SGI MIPS list , Debian MIPS list Subject: Re: Patch to ptrace.c Message-ID: <20010714125421.B6713@bacchus.dhis.org> References: <20010713171313.E22543@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: <20010713171313.E22543@lug-owl.de>; from jbglaw@lug-owl.de on Fri, Jul 13, 2001 at 05:13:13PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 213 Lines: 8 On Fri, Jul 13, 2001 at 05:13:13PM +0200, Jan-Benedict Glaw wrote: > Fixing a little typo preventing proper compiling... Ralf? Would you please > apply it? Already fixed before your patch reached me ... Ralf From owner-linux-mips@oss.sgi.com Sat Jul 14 04:05:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EB5Df10558 for linux-mips-outgoing; Sat, 14 Jul 2001 04:05:13 -0700 Received: from dea.waldorf-gmbh.de (u-121-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EB59V10555 for ; Sat, 14 Jul 2001 04:05:10 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6EB4mr06127; Sat, 14 Jul 2001 13:04:48 +0200 Date: Sat, 14 Jul 2001 13:04:48 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: sti() does not work. Message-ID: <20010714130448.C6713@bacchus.dhis.org> References: <20010713133517.C1378@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 04:01:29PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1517 Lines: 42 On Fri, Jul 13, 2001 at 04:01:29PM +0200, Maciej W. Rozycki wrote: > Sure, but sometimes ".set reorder" allows you to achieve better > optimization across various ISAs without a need to resort to the > preprocessor. Consider the following code: > > lw $1,($2) > addu $3,$1 > > You need an instruction between the two for a MIPS I CPU but MIPS II+ CPUs > interlock here if no instruction is placed. Assuming no real instruction > can be reordered here, a nop must be inserted if the code gets compiled > for a MIPS I CPU but no instruction is preferred otherwise. The assembler > does it automatically if the ".set reorder" directive is active, but you > need to decide yourself if it is not. > > Actually with mfc0 there is no problem -- you need a nop in the case like > the above one as coprocessor transfers never interlock; at least docs > state so. But who believes docs without a grain of salt, so please > correct me if I am wrong (I don't have appropriate hardware to perform a > test). Real wild pig hackers on R3000 were writing code which knows that in the load delay slot they still have the old register value available. So you can implement var1++; var2++ as: .set noreorder lw $reg, var1($gp) nop addiu $reg, $reg, 1 lw $reg, var2($gp) sw $reg, var1($gp) addiu $reg, $reg, 1 sw $reg, var2($gp) .common var1, 4, 4 .common var2, 4, 4 Of course only safe with interrupts disabled. So in a sense introducing the load interlock broke semantics of MIPS machine code ;-) Ralf From owner-linux-mips@oss.sgi.com Sat Jul 14 04:35:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EBZk912790 for linux-mips-outgoing; Sat, 14 Jul 2001 04:35:46 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EBZgV12779; Sat, 14 Jul 2001 04:35:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA14426; Sat, 14 Jul 2001 04:35:34 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA13232; Sat, 14 Jul 2001 04:35:31 -0700 (PDT) Message-ID: <007f01c10c59$bbe8bfa0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Maciej W. Rozycki" Cc: "Thiemo Seufer" , References: <20010713133517.C1378@bacchus.dhis.org> <20010714130448.C6713@bacchus.dhis.org> Subject: Re: sti() does not work. Date: Sat, 14 Jul 2001 13:39:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1940 Lines: 54 > Real wild pig hackers on R3000 were writing code which knows that in the > load delay slot they still have the old register value available. So you > can implement var1++; var2++ as: > > .set noreorder > lw $reg, var1($gp) > nop > addiu $reg, $reg, 1 > lw $reg, var2($gp) > sw $reg, var1($gp) > addiu $reg, $reg, 1 > sw $reg, var2($gp) > > .common var1, 4, 4 > .common var2, 4, 4 > > Of course only safe with interrupts disabled. So in a sense introducing > the load interlock broke semantics of MIPS machine code ;-) Architecturally, the target register value is UNDEFINED during the load delay slot on a MIPS I CPU. Anyone who coded to any particular assumption regarding its value was coding to a specific CPU implementation. Introducing the load interlock in later versions of the ISA and later implementations did not reach backward in time and break the old hardware. The implementation-specific code still works for its specific implementation. Refining the spec did not break the code for later implementations - it was *always* broken for later implementations! ;-) In a less pedantic tone, there actually is an architecturally legal case where an assembly coder can justify the use of noreorder for something other than CP0 pipeline hazards. If what I want to do is to test a value, branch on the result, and modify that value regardless of whether the branch is taken, I can code something like: .set noreorder bltz t0,foo sra t0,t0,2 .set reorder foo: Whereas otherwise I need to either consume another register or replicate the shift both after the branch and after foo. If I'm very very lucky, the assembler will "hoist" such a replicated instruction into the delay slot - a good compiler back-end optimiser certainly would. But I'm not aware of any MIPS assembler that would perform that optimisation - certainly the GNU assembler does not. Kevin K. From owner-linux-mips@oss.sgi.com Sat Jul 14 10:16:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EHGeP27870 for linux-mips-outgoing; Sat, 14 Jul 2001 10:16:40 -0700 Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [212.227.116.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EHGaV27867; Sat, 14 Jul 2001 10:16:37 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Sat Jul 14 10:36:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6EHamh28369 for linux-mips-outgoing; Sat, 14 Jul 2001 10:36:48 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6EHakV28366 for ; Sat, 14 Jul 2001 10:36:46 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id TAA337434; Sat, 14 Jul 2001 19:36:44 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15LTLG-0007MD-00; Sat, 14 Jul 2001 19:36:34 +0200 Date: Sat, 14 Jul 2001 19:36:34 +0200 To: linux-mips@oss.sgi.com Subject: SUCCESS: Booting a real 64bit Kernel on Indigo2 R10000 (IP28) Message-ID: <20010714193634.B24615@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4195 Lines: 108 Hi All, as exclaimed in the Subject, I have now a 64bit Kernel booting into /bin/sash on my IP28. Unfortunately, it crashes immediately at the first keystroke. In Detail, I used the following software: - Current binutils CVS with my patch to partially support mips64-linux (It's barely enough to build a Kernel). - An GCC CVS snapshot of 2001-05-01 (later ones do not work) with a patch from Ralf to support R10000 and an patch to make it bootstrap for mips64-linux. - Current linux oss CVS with a large patch for mips64 support. I got with this: - A real 64bit Kernel image without linker crashes etc. No objcopy tricks, the Kernel is loaded at 0xa800000000000000. - The Kernel uses new-style interrupts (the old ones were confusing and crashed on my first attempts to use the serial console). - The sgiseeq ethernet works, it gets the bootp parameters and allows nfs-mounting the rootfs. - The serial console seems to work also, as good as it can be predicted with an immediatly crashing init-shell. Thiemo Setting $netaddr to 10.0.0.5 (from server rembrandt) Obtaining from server rembrandt 1750448+278528+259632 entry: 0xa8000000201b4000 ARCH: SGI-IP28 PROMLIB: ARC firmware Version 64 Revision 0 Linux version 2.4.5-1 (ths@rembrandt) (gcc version 3.1 20010501 (experimental)) #52 Sat Jul 14 15:46:49 CEST 2001 Loading R10000 MMU routines. CPU implementation 9, CPU revision 37 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 MC: SGI memory controller Revision 5 On node 0 totalpages: 262144 zone(0): 262144 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: rw init=/bin/sash Entering 64-bit mode. calculating r4koff... 000d5ba8(875432) Console: colour dummy device 80x25 zs0: console I/O Console: ttyS0 (Zilog8530), 9600 baud Calibrating delay loop... 174.89 BogoMIPS Memory: 488192k/917500k available (1709k kernel code, 429308k reserved, 132k data, 88k init) Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 initialize_kbd: Keyboard failed self test pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: queued sectors max/low 321560kB/190488kB, 960 slots per queue sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:0b:35:da SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Jul 14 2001 at 15:41:11 wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Jul 14 2001 at 15:41:11 scsi0 : SGI WD93 scsi1 : SGI WD93 SGI Zilog8530 serial driver version 1.01 ttyS0 at 0xbfbd9830 (irq = 21) is a Zilog8530 ttyS1 at 0xbfbd9838 (irq = 21) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.5 IP-Config: Complete: device=eth0, addr=10.0.0.5, mask=255.0.0.0, gw=10.0.0.1, host=10.0.0.5, domain=, nis-domain=(none), bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=/home/linux-mips NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 10.0.0.1 Looking up port of RPC 100005/2 on 10.0.0.1 VFS: Mounted root (nfs filesystem). Freeing prom memory: 1024kb freed Freeing unused kernel memory: 88k freed Stand-alone shell (version 3.4) > From owner-linux-mips@oss.sgi.com Sun Jul 15 21:36:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6G4aHq24039 for linux-mips-outgoing; Sun, 15 Jul 2001 21:36:17 -0700 Received: from orion.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6G4aDV24029; Sun, 15 Jul 2001 21:36:13 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Sun Jul 15 21:53:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6G4r6k25892 for linux-mips-outgoing; Sun, 15 Jul 2001 21:53:06 -0700 Received: from dea.waldorf-gmbh.de (pD956F5FD.dip.t-dialin.net [217.86.245.253]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6G4r3V25889 for ; Sun, 15 Jul 2001 21:53:03 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Sun Jul 15 23:39:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6G6dRv03855 for linux-mips-outgoing; Sun, 15 Jul 2001 23:39:27 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6G6dGV03828; Sun, 15 Jul 2001 23:39:16 -0700 Received: from otr.mynet (fiendish.cygnus.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA06808; Sun, 15 Jul 2001 23:39:12 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.11.2/8.11.2) id f6G6Z5k20997; Sun, 15 Jul 2001 23:35:05 -0700 X-Authentication-Warning: otr.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@bacchus.dhis.org> <20010713111010.A25902@lucon.org> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 15 Jul 2001 23:35:04 -0700 In-Reply-To: "H . J . Lu"'s message of "Fri, 13 Jul 2001 11:10:10 -0700" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 727 Lines: 20 "H . J . Lu" writes: > 2001-07-13 H.J. Lu > > * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Removed. > (elf_machine_got_rel): Defined only if RTLD_BOOTSTRAP is not > defined. > (RESOLVE_GOTSYM): Rewrite to use RESOLVE. > > * sysdeps/mips/rtld-ldscript.in: Removed. > * sysdeps/mips/rtld-parms: Likewise. > * sysdeps/mips/mips64/rtld-parms: Likewise. > * sysdeps/mips/mipsel/rtld-parms: Likewise. Is this the complete patch? Nothing needed from the other patches? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jul 16 03:22:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GAMD218552 for linux-mips-outgoing; Mon, 16 Jul 2001 03:22:13 -0700 Received: from laxmls03.socal.rr.com (laxmls03.socal.rr.com [24.30.163.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GAM7V18546 for ; Mon, 16 Jul 2001 03:22:08 -0700 Received: from compiler (sc-66-74-235-241.socal.rr.com [66.74.235.241]) by laxmls03.socal.rr.com (8.11.2/8.11.1) with SMTP id f6GALZV14520; Mon, 16 Jul 2001 03:21:37 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" From: Shane Nay To: James Simmons , Pavel Machek Subject: Re: [ANNOUNCE] Secondary mips tree. Date: Mon, 16 Jul 2001 03:22:40 -0700 X-Mailer: KMail [version 1.2] Cc: Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net References: In-Reply-To: MIME-Version: 1.0 Message-Id: <0107160322400A.02677@compiler> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 864 Lines: 20 On Friday 13 July 2001 08:01, James Simmons wrote: > > Good. I should definitely take a look. [Do you care about vr4130 or about > > tx3912, too?] > > Yes. If you want to work on it no problem. Huh, Very Cool. I was getting ready to queue up a huge IRDA forward port in linux-vr to the 2.4.6 version. (Still el-crashola on me right now) The one in the present repository likes to overwrite userspace applications pretty much at randomn. Maybe after things simmer down I'll port the Agenda hardware platform over to your repository, and Agenda can switch to using that. linux-vr has been really really stale since we froze at our present version for toolchain reasons. Those toolchain problems were fixed ages ago, but Mike & Brad who had been responsible for forward porting the kernel stopped doing that work for the most part. Thanks, Shane Nay. From owner-linux-mips@oss.sgi.com Mon Jul 16 04:00:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GB0FS21111 for linux-mips-outgoing; Mon, 16 Jul 2001 04:00:15 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GB0BV21100; Mon, 16 Jul 2001 04:00:12 -0700 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: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 503 Lines: 13 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 owner-linux-mips@oss.sgi.com Mon Jul 16 04:28:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GBS4k23979 for linux-mips-outgoing; Mon, 16 Jul 2001 04:28:04 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GBRsV23964; Mon, 16 Jul 2001 04:27:54 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA24153; Mon, 16 Jul 2001 04:27:45 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA00561; Mon, 16 Jul 2001 04:27:42 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6GBQWa03636; Mon, 16 Jul 2001 13:26:32 +0200 (MEST) Message-ID: <3B52CF68.4687EBCB@mips.com> Date: Mon, 16 Jul 2001 13:26:32 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Illegal instruction References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 983 Lines: 31 "H . J . Lu" wrote: > On Tue, Jul 10, 2001 at 01:14:12PM +0200, Carsten Langgaard wrote: > > Thanks, that did the trick. > > Now I would like to try to install H.J. Lu's RedHat7.1 RPM packages. > > If I just do a: > > rpm -Uvh --root /mnt/harddisk *.rpm > > Those rpms have to be installed in the right order. I have a set up > to do that. I will see what I can do. Thanks, please do. Another thing, I can see your distribution is lacking kernel header files, I guess they are needed to do a native compile of the source RPMs. Are you only cross compiling the RPMs. It would be great, if you could put together a RPM containing the kernel header files. > > H.J. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Mon Jul 16 06:57:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GDvJR03913 for linux-mips-outgoing; Mon, 16 Jul 2001 06:57:19 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GDvAV03900; Mon, 16 Jul 2001 06:57:10 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id A2188125BC; Mon, 16 Jul 2001 06:57:09 -0700 (PDT) Date: Mon, 16 Jul 2001 06:57:09 -0700 From: "H . J . Lu" To: Ulrich Drepper Cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker Message-ID: <20010716065709.A27252@lucon.org> References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@bacchus.dhis.org> <20010713111010.A25902@lucon.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 drepper@redhat.com on Sun, Jul 15, 2001 at 11:35:04PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 656 Lines: 22 On Sun, Jul 15, 2001 at 11:35:04PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > 2001-07-13 H.J. Lu > > > > * sysdeps/mips/dl-machine.h (MAP_BASE_ADDR): Removed. > > (elf_machine_got_rel): Defined only if RTLD_BOOTSTRAP is not > > defined. > > (RESOLVE_GOTSYM): Rewrite to use RESOLVE. > > > > * sysdeps/mips/rtld-ldscript.in: Removed. > > * sysdeps/mips/rtld-parms: Likewise. > > * sysdeps/mips/mips64/rtld-parms: Likewise. > > * sysdeps/mips/mipsel/rtld-parms: Likewise. > > Is this the complete patch? Nothing needed from the other patches? > Yes, it is complete. Tested on Linux/mipsel. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 16 09:02:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GG2BF14183 for linux-mips-outgoing; Mon, 16 Jul 2001 09:02:11 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GG1tV14160; Mon, 16 Jul 2001 09:01:55 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08202; Mon, 16 Jul 2001 09:01:36 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA14187; Mon, 16 Jul 2001 14:46:50 +0200 (MET DST) Date: Mon, 16 Jul 2001 14:46:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: sti() does not work. In-Reply-To: <20010714130448.C6713@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 822 Lines: 21 On Sat, 14 Jul 2001, Ralf Baechle wrote: > Real wild pig hackers on R3000 were writing code which knows that in the > load delay slot they still have the old register value available. So you > can implement var1++; var2++ as: That's crazy... > Of course only safe with interrupts disabled. So in a sense introducing > the load interlock broke semantics of MIPS machine code ;-) That broke the MIPS' virtue as well, as MIPS stands for "Microprocessor without Interlocked Pipeline Stages" (actually mfhi/mflo broke that in the first place, but it was less significant due to the multiplier being a separate unit). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 16 09:06:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GG6xB14426 for linux-mips-outgoing; Mon, 16 Jul 2001 09:06:59 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GG6uV14423; Mon, 16 Jul 2001 09:06:56 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA08534; Mon, 16 Jul 2001 09:06:54 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 588 Lines: 14 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 owner-linux-mips@oss.sgi.com Mon Jul 16 09:46:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GGk0x15287 for linux-mips-outgoing; Mon, 16 Jul 2001 09:46:00 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GGjqV15278; Mon, 16 Jul 2001 09:45:52 -0700 Received: from delta.ds2.pg.gda.pl (delta.ds2.pg.gda.pl [213.192.72.1]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA00533; Mon, 16 Jul 2001 09:05:34 -0700 (PDT) mail_from (macro@ds2.pg.gda.pl) 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1232 Lines: 26 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 owner-linux-mips@oss.sgi.com Mon Jul 16 11:41:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GIf6I17664 for linux-mips-outgoing; Mon, 16 Jul 2001 11:41:06 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GIewV17661 for ; Mon, 16 Jul 2001 11:40:58 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 72AEA125BC; Mon, 16 Jul 2001 11:40:55 -0700 (PDT) Date: Mon, 16 Jul 2001 11:40:55 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, GNU C Library , gcc@gcc.gnu.org, Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.11.90.0.24 iss released. Message-ID: <20010716114055.A32248@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 12682 Lines: 458 This is the beta release of binutils 2.11.90.0.24 for Linux, which is based on binutils 2001 0714 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.24 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.24.tar.gz. Source code. 2. binutils-2.11.90.0.23-2.11.90.0.24.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.24-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.24.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 07/16/2001 From owner-linux-mips@oss.sgi.com Mon Jul 16 11:41:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GIfuX17719 for linux-mips-outgoing; Mon, 16 Jul 2001 11:41:56 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GIfpV17716 for ; Mon, 16 Jul 2001 11:41:52 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 7196 Lines: 262 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 owner-linux-mips@oss.sgi.com Mon Jul 16 11:47:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GIlHR17943 for linux-mips-outgoing; Mon, 16 Jul 2001 11:47:17 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GIlGV17937 for ; Mon, 16 Jul 2001 11:47:16 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id LAA09164; Mon, 16 Jul 2001 11:47:04 -0700 Message-Id: <200107161847.LAA09164@saturn.mikemac.com> To: "Maciej W. Rozycki" cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: Your message of "Mon, 16 Jul 2001 14:03:30 +0200." Date: Mon, 16 Jul 2001 11:47:04 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1165 Lines: 27 >Date: Mon, 16 Jul 2001 14:03:30 +0200 (MET DST) >From: "Maciej W. Rozycki" >To: Ralf Baechle >Subject: Re: ll/sc emulation patch > >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. Not knowing anything about the glibc architecture, I have a dumb question: why is 'ls' doing anything at all with pthreads? Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Mon Jul 16 11:50:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GIoEX18097 for linux-mips-outgoing; Mon, 16 Jul 2001 11:50:14 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GIoDV18094 for ; Mon, 16 Jul 2001 11:50:13 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id D924B125BC; Mon, 16 Jul 2001 11:50:12 -0700 (PDT) Date: Mon, 16 Jul 2001 11:50:12 -0700 From: "H . J . Lu" To: Mike McDonald Cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010716115012.A32434@lucon.org> References: <200107161847.LAA09164@saturn.mikemac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107161847.LAA09164@saturn.mikemac.com>; from mikemac@mikemac.com on Mon, Jul 16, 2001 at 11:47:04AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 290 Lines: 10 On Mon, Jul 16, 2001 at 11:47:04AM -0700, Mike McDonald wrote: > > Not knowing anything about the glibc architecture, I have a dumb > question: why is 'ls' doing anything at all with pthreads? You must be using a broken Linux. /bin/ls in my RedHat 7.1/mips doesn't use pthreads. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 16 12:12:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJCD519666 for linux-mips-outgoing; Mon, 16 Jul 2001 12:12:13 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJCCV19663 for ; Mon, 16 Jul 2001 12:12:12 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id MAA09606; Mon, 16 Jul 2001 12:12:08 -0700 Message-Id: <200107161912.MAA09606@saturn.mikemac.com> cc: "Maciej W. Rozycki" , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch In-Reply-To: Your message of "Mon, 16 Jul 2001 11:47:04 PDT." <200107161847.LAA09164@saturn.mikemac.com> Date: Mon, 16 Jul 2001 12:12:08 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1136 Lines: 28 >To: "Maciej W. Rozycki" >Subject: Re: ll/sc emulation patch >Date: Mon, 16 Jul 2001 11:47:04 -0700 >From: Mike McDonald > > >>Date: Mon, 16 Jul 2001 14:03:30 +0200 (MET DST) >>From: "Maciej W. Rozycki" >>To: Ralf Baechle >>Subject: Re: ll/sc emulation patch >> 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. > > Not knowing anything about the glibc architecture, I have a dumb >question: why is 'ls' doing anything at all with pthreads? OK, let me rephrase this: why are ~90% of ls's syscalls calls to _test_and_set() when 'ls' is(??) a single threaded program? Does glibc always assume it's running in a multithreaded environment? Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Mon Jul 16 12:28:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJSoS20889 for linux-mips-outgoing; Mon, 16 Jul 2001 12:28:50 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJRmV20809 for ; Mon, 16 Jul 2001 12:27:48 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6GJRadi022414; Mon, 16 Jul 2001 12:27:36 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6GJRZJQ022410; Mon, 16 Jul 2001 12:27:36 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 16 Jul 2001 12:27:35 -0700 (PDT) From: James Simmons To: Shane Nay cc: Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel] Re: [ANNOUNCE] Secondary mips tree. In-Reply-To: <0107160322400A.02677@compiler> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 644 Lines: 18 > Maybe after things simmer down I'll port the Agenda hardware platform over to > your repository, and Agenda can switch to using that. That would be good. I look forward to the patches. > linux-vr has been > really really stale since we froze at our present version for toolchain > reasons. Those toolchain problems were fixed ages ago, but Mike & Brad who > had been responsible for forward porting the kernel stopped doing that work > for the most part. So we have noticed. Things are starting to get updated now. P.S We have been having problems with toolchains as well. We plan to have a new toolchain ready by Wednesday. From owner-linux-mips@oss.sgi.com Mon Jul 16 12:36:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJaqA21465 for linux-mips-outgoing; Mon, 16 Jul 2001 12:36:52 -0700 Received: from delta.ds2.pg.gda.pl (root@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJamV21461 for ; Mon, 16 Jul 2001 12:36:49 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4271 Lines: 125 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 owner-linux-mips@oss.sgi.com Mon Jul 16 12:37:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJbuS21650 for linux-mips-outgoing; Mon, 16 Jul 2001 12:37:56 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJbrV21641 for ; Mon, 16 Jul 2001 12:37:53 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 504 Lines: 15 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 owner-linux-mips@oss.sgi.com Mon Jul 16 12:49:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GJnHR22786 for linux-mips-outgoing; Mon, 16 Jul 2001 12:49:17 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GJnEV22777 for ; Mon, 16 Jul 2001 12:49:15 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 914 Lines: 27 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 owner-linux-mips@oss.sgi.com Mon Jul 16 13:09:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GK9FR24724 for linux-mips-outgoing; Mon, 16 Jul 2001 13:09:15 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GK9EV24721 for ; Mon, 16 Jul 2001 13:09:14 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id CE826125BC; Mon, 16 Jul 2001 13:09:13 -0700 (PDT) Date: Mon, 16 Jul 2001 13:09:13 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Mike McDonald , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010716130913.A1412@lucon.org> References: <20010716115012.A32434@lucon.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 09:51:12PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 478 Lines: 14 On Mon, Jul 16, 2001 at 09:51:12PM +0200, Maciej W. Rozycki wrote: > > 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(). > 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. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 16 13:25:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKPND26027 for linux-mips-outgoing; Mon, 16 Jul 2001 13:25:23 -0700 Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [212.227.116.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKPMV26009 for ; Mon, 16 Jul 2001 13:25:22 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 16 13:28:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKSes26440 for linux-mips-outgoing; Mon, 16 Jul 2001 13:28:40 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKSdV26436 for ; Mon, 16 Jul 2001 13:28:39 -0700 Received: from excalibur.cologne.de (p3E9BE94E.dip.t-dialin.net [62.155.233.78]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id WAA06580; Mon, 16 Jul 2001 22:28:33 +0200 (MET DST) Received: from karsten by excalibur.cologne.de with local (Exim 3.12 #1 (Debian)) id 15MEns-00007y-00; Mon, 16 Jul 2001 22:17:16 +0200 Date: Mon, 16 Jul 2001 22:17:16 +0200 To: "Maciej W. Rozycki" Cc: linux-mips@oss.sgi.com, debian-mips@lists.debian.org Subject: Re: gpm-support for serial DECstation mouse (VSXXX-AA) Message-ID: <20010716221716.A442@excalibur.cologne.de> References: <20010711230550.A26702@linuxtag.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 Thu, Jul 12, 2001 at 02:05:07PM +0200 From: Karsten Merker Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 569 Lines: 16 On Thu, Jul 12, 2001 at 02:05:07PM +0200, Maciej W. Rozycki wrote: [gpm-patch for DEC VS-XXX-AA-support] > Following is a patch against your version -- please consider the changes > I propose. I have uploaded a new version (gpm_1.19.3-6merker2) containing your patch to ftp://bolugftp.uni-bonn.de/pub/mipsel-linux/packages/experimental/. Greetings, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From owner-linux-mips@oss.sgi.com Mon Jul 16 13:31:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKVTF26808 for linux-mips-outgoing; Mon, 16 Jul 2001 13:31:29 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKVRV26803 for ; Mon, 16 Jul 2001 13:31:27 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 854 Lines: 19 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 owner-linux-mips@oss.sgi.com Mon Jul 16 13:37:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKbYw27537 for linux-mips-outgoing; Mon, 16 Jul 2001 13:37:34 -0700 Received: from mimi.clarku.edu (mimi.clarku.edu [140.232.1.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKbXV27534 for ; Mon, 16 Jul 2001 13:37:33 -0700 Received: from localhost ([140.232.202.11]) by CLARKU.EDU (PMDF V5.2-27 #30607) with ESMTP id <01K607H86ZGY935IZ1@CLARKU.EDU> for linux-mips@oss.sgi.com; Mon, 16 Jul 2001 16:36:58 EST Received: from gjohnson by localhost with local (Exim 3.22 #1 (Debian)) id 15MF7A-0003DH-00 for ; Mon, 16 Jul 2001 16:37:12 -0400 Date: Mon, 16 Jul 2001 16:37:12 -0400 From: Greg Johnson Subject: Linux on a 100MHz r4000 indy? To: linux-mips@oss.sgi.com Message-id: <20010716163712.B12104@superweasel.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 739 Lines: 18 I have tried recently to get Debian installed on a 100MHz r4000 indy. I got it to install and boot the base system, but when I upgrade to the more recent libc6, I get Bus Errors when I run things like "ls". I understand that this is related to the MIPS_ATOMIC/ll/sc stuff that has been discussed here lately. So, I tried the fast-sysmips patch. This changed the Bus Errors to Segfaults. I also have another indy with a 175MHz r4400. This machine seems to work fine even without the fast-sysmips patch. So what's the deal? Are the r4000 and r4400 that different? It's my understanding that both the r4000 and the r4400 support the ll/sc instructions. Should I expect bad/broken hardware on the r4000 machine? Thanks, Greg From owner-linux-mips@oss.sgi.com Mon Jul 16 13:43:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKh4S28017 for linux-mips-outgoing; Mon, 16 Jul 2001 13:43:04 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKh3V28012 for ; Mon, 16 Jul 2001 13:43:03 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 566 Lines: 16 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 owner-linux-mips@oss.sgi.com Mon Jul 16 13:43:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GKhZx28121 for linux-mips-outgoing; Mon, 16 Jul 2001 13:43:35 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GKhYV28118 for ; Mon, 16 Jul 2001 13:43:34 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 73543125BC; Mon, 16 Jul 2001 13:43:33 -0700 (PDT) Date: Mon, 16 Jul 2001 13:43:33 -0700 From: "H . J . Lu" To: "Maciej W. Rozycki" Cc: Mike McDonald , linux-mips@oss.sgi.com, linux-mips@fnet.fr Subject: Re: ll/sc emulation patch Message-ID: <20010716134333.A2045@lucon.org> References: <20010716130913.A1412@lucon.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 10:33:42PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 833 Lines: 20 On Mon, Jul 16, 2001 at 10:33:42PM +0200, Maciej W. Rozycki wrote: > 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. I am happy to let Red Hat deal with it. FWIW, RedHat 7.1 has fileutils 4.0.36. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 16 14:28:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GLSBk32215 for linux-mips-outgoing; Mon, 16 Jul 2001 14:28:11 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GLS3V32209; Mon, 16 Jul 2001 14:28:03 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 229C6125BC; Mon, 16 Jul 2001 14:28:02 -0700 (PDT) Date: Mon, 16 Jul 2001 14:28:02 -0700 From: "H . J . Lu" To: Carsten Langgaard Cc: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Updates on RedHat 7.1/mips Message-ID: <20010716142802.A2757@lucon.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B52CF68.4687EBCB@mips.com>; from carstenl@mips.com on Mon, Jul 16, 2001 at 01:26:32PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1385 Lines: 44 On Mon, Jul 16, 2001 at 01:26:32PM +0200, Carsten Langgaard wrote: > "H . J . Lu" wrote: > > > Now I would like to try to install H.J. Lu's RedHat7.1 RPM packages. > > > If I just do a: > > > rpm -Uvh --root /mnt/harddisk *.rpm > > > > Those rpms have to be installed in the right order. I have a set up > > to do that. I will see what I can do. > > Thanks, please do. They are in install.tar.bz2 now. > Another thing, I can see your distribution is lacking kernel header > files, I guess they are needed to do a native compile of the source RPMs. I added gdb and kernel-headers. I also updated gcc, glibc and binutils. The toolchain rpms are updated. H.J. ------ My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You will need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. Thanks. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 16 15:31:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6GMVpN01960 for linux-mips-outgoing; Mon, 16 Jul 2001 15:31:51 -0700 Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6GMVmV01957; Mon, 16 Jul 2001 15:31:48 -0700 Received: from otr.mynet (fiendish.cygnus.com [205.180.231.146]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA01949; Mon, 16 Jul 2001 15:31:35 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.11.2/8.11.2) id f6GMRBW23098; Mon, 16 Jul 2001 15:27:11 -0700 X-Authentication-Warning: otr.mynet: drepper set sender to drepper@redhat.com using -f To: "H . J . Lu" Cc: Ralf Baechle , linux-mips@oss.sgi.com, GNU C Library Subject: Re: Clean up the mips dynamic linker References: <20010712182402.A10768@lucon.org> <20010713112635.A32010@bacchus.dhis.org> <20010713111010.A25902@lucon.org> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A X-fingerprint: e6:49:07:36:9a:0d:b7:ba:b5:e9:06:f3:e7:e7:08:4a From: Ulrich Drepper Date: 16 Jul 2001 15:27:11 -0700 In-Reply-To: "H . J . Lu"'s message of "Fri, 13 Jul 2001 11:10:10 -0700" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.2 (Thelxepeia) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 416 Lines: 11 "H . J . Lu" writes: > My last patch was not ok :-(. Somehow, make didn't rebuild. In this > patch, I rewrote RESOLVE_GOTSYM with RESOLVE to help prelink. Applied now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From owner-linux-mips@oss.sgi.com Mon Jul 16 18:42:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H1gqX05294 for linux-mips-outgoing; Mon, 16 Jul 2001 18:42:52 -0700 Received: from dea.waldorf-gmbh.de (u-16-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.16]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H1gmV05291 for ; Mon, 16 Jul 2001 18:42:49 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6H1Kt901266; Tue, 17 Jul 2001 03:20:55 +0200 Date: Tue, 17 Jul 2001 03:20:55 +0200 From: Ralf Baechle To: Greg Johnson Cc: linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? Message-ID: <20010717032055.A1236@bacchus.dhis.org> References: <20010716163712.B12104@superweasel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010716163712.B12104@superweasel.com>; from gjohnson@superweasel.com on Mon, Jul 16, 2001 at 04:37:12PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 996 Lines: 27 On Mon, Jul 16, 2001 at 04:37:12PM -0400, Greg Johnson wrote: > I also have another indy with a 175MHz r4400. This machine seems to > work fine even without the fast-sysmips patch. This could be explained if you have different libraries, the one compiled for MIPS II, the other one only for MIPS I on these two systems. Sure you're running the very same binaries? > So what's the deal? Are the r4000 and r4400 that different? They're very similar, almost the same silicon. > It's my understanding that both the r4000 and the r4400 support the ll/sc > instructions. > Should I expect bad/broken hardware on the r4000 machine? Depends. The older R4000s were really buggy silicon and we don't have all the workarounds needed to keep them happy. So in theory if circumstances are just right that can explain why you have so much fun with the R4000 machine. When the kernel is booting it prints a a line "CPU revision is: xxx" where xxx is a 8 digit hex number. What number? Ralf From owner-linux-mips@oss.sgi.com Mon Jul 16 19:41:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H2fcD06671 for linux-mips-outgoing; Mon, 16 Jul 2001 19:41:38 -0700 Received: from fullass (matt.superweasel.com [216.36.92.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H2fRV06666; Mon, 16 Jul 2001 19:41:27 -0700 Received: from foo.inside ([10.0.1.1] helo=localhost) by fullass with esmtp (Exim 3.22 #1 (Debian)) id 15MKlb-0007nL-00; Mon, 16 Jul 2001 22:39:19 -0400 Received: from gjohnson by localhost with local (Exim 3.22 #1 (Debian)) id 15MKlK-0004G4-00; Mon, 16 Jul 2001 22:39:02 -0400 Date: Mon, 16 Jul 2001 22:39:02 -0400 From: Greg Johnson To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? Message-ID: <20010716223902.A16351@superweasel.com> References: <20010716163712.B12104@superweasel.com> <20010717032055.A1236@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010717032055.A1236@bacchus.dhis.org> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1533 Lines: 48 On Tue, Jul 17, 2001 at 03:20:55AM +0200, Ralf Baechle wrote: > On Mon, Jul 16, 2001 at 04:37:12PM -0400, Greg Johnson wrote: > > > I also have another indy with a 175MHz r4400. This machine seems to > > work fine even without the fast-sysmips patch. > > This could be explained if you have different libraries, the one compiled for > MIPS II, the other one only for MIPS I on these two systems. Sure you're > running the very same binaries? They're the same. > Depends. The older R4000s were really buggy silicon and we don't > have all the workarounds needed to keep them happy. So in theory if > circumstances are just right that can explain why you have so much > fun with the R4000 machine. Interesting. > When the kernel is booting it prints a a line "CPU revision is: xxx" > where xxx is a 8 digit hex number. What number? For the r4000 indy: ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4000 FPU ICACHE DCACHE SCACHE Loading R4000 MMU routines. CPU revision is: 00000422 Primary instruction cache 8kb, linesize 16 bytes. Primary data cache 8kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 128 bytes. For the r4400 indy: ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4400 FPU ICACHE DCACHE SCACHE Loading R4000 MMU routines. CPU revision is: 00000460 Primary instruction cache 16kb, linesize 16 bytes. Primary data cache 16kb, linesize 16 bytes. Secondary cache sized at 1024K linesize 128 bytes. Thanks, Greg From owner-linux-mips@oss.sgi.com Mon Jul 16 20:02:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H32so07017 for linux-mips-outgoing; Mon, 16 Jul 2001 20:02:54 -0700 Received: from dea.waldorf-gmbh.de (u-198-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.198]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H32oV07014 for ; Mon, 16 Jul 2001 20:02:51 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6H30ot01797; Tue, 17 Jul 2001 05:00:50 +0200 Date: Tue, 17 Jul 2001 05:00:50 +0200 From: Ralf Baechle To: Greg Johnson Cc: linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? Message-ID: <20010717050050.A1737@bacchus.dhis.org> References: <20010716163712.B12104@superweasel.com> <20010717032055.A1236@bacchus.dhis.org> <20010716223902.A16351@superweasel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010716223902.A16351@superweasel.com>; from gjohnson@superweasel.com on Mon, Jul 16, 2001 at 10:39:02PM -0400 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1923 Lines: 49 On Mon, Jul 16, 2001 at 10:39:02PM -0400, Greg Johnson wrote: > CPU revision is: 00000422 That's a really old and buggy CPU. Kevin Kissel may correct me but I think it's the first series shipped to customers. Among the fun bugs: ----------------------------------------------------------------------------- 4. R4000PC, R4000SC: An instruction sequence which contains a load which causes a data cache miss and a jump, where the jump instruction is that last instruction in the page and the delay slot of the jump is not currently mapped, causes the exception vector to be overwritten by the jump address. The R4000 will use the jump address as the exception vector. Example: lw <---- data cache miss noop <---- one or two Noops jr <---- last instruction in the page (jump or branch in- struction) --------------<---- page boundary noop Workaround: Jump and branch instructions should never be in the last loca- tion of a page. 11. R4000PC, R4000SC: In the case: lw rA, (rn) noop (or any non-conflicting instruction) lw rn, (rA) (where the address in rA causes a TLB refill) --------------------> end of page page not mapped where rn and RA are general purpose registers r0 through r31 This code sequence causes the second load instruction to slip due to a load use interlock. When the R4000 crosses the page boundary after the lw, it vectors to 0x8000 0000 and later causes an instruction cache miss. After the instruction cache miss is complete the LW causes another TLB refill. This should vector to 0x8000 0000 but instead goes to 0x8000 0180. 14 (Just an update of erratum 4) ----------------------------------------------------------------------------- There's more but I don't want to paste the whole errata document in here and above bugs alone without the respective workarounds in kernel and tools are grave bugs. Ralf From owner-linux-mips@oss.sgi.com Mon Jul 16 20:09:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H391n07171 for linux-mips-outgoing; Mon, 16 Jul 2001 20:09:01 -0700 Received: from fullass (mail@superweasel.com [216.36.92.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H38rV07168; Mon, 16 Jul 2001 20:08:53 -0700 Received: from foo.inside ([10.0.1.1] helo=localhost) by fullass with esmtp (Exim 3.22 #1 (Debian)) id 15MLE7-0007oj-00; Mon, 16 Jul 2001 23:08:47 -0400 Received: from gjohnson by localhost with local (Exim 3.22 #1 (Debian)) id 15MLDq-0004Jm-00; Mon, 16 Jul 2001 23:08:30 -0400 Date: Mon, 16 Jul 2001 23:08:30 -0400 From: Greg Johnson To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? Message-ID: <20010716230830.A16564@superweasel.com> References: <20010716163712.B12104@superweasel.com> <20010717032055.A1236@bacchus.dhis.org> <20010716223902.A16351@superweasel.com> <20010717050050.A1737@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010717050050.A1737@bacchus.dhis.org> User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 436 Lines: 18 On Tue, Jul 17, 2001 at 05:00:50AM +0200, Ralf Baechle wrote: > There's more but I don't want to paste the whole errata document in here > and above bugs alone without the respective workarounds in kernel and tools > are grave bugs. > > Ralf Ok. Fixing any of that is beyond me. I guess it makes a nice monitor stand for now. :-) It's nice to know that there is a reason it doesn't work. Thanks again, Greg From owner-linux-mips@oss.sgi.com Mon Jul 16 22:45:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H5jlp09251 for linux-mips-outgoing; Mon, 16 Jul 2001 22:45:47 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H5jfV09248; Mon, 16 Jul 2001 22:45:42 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id WAA05814; Mon, 16 Jul 2001 22:45:33 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id WAA22530; Mon, 16 Jul 2001 22:45:32 -0700 (PDT) Message-ID: <001301c10e84$570805a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Greg Johnson" Cc: References: <20010716163712.B12104@superweasel.com> <20010717032055.A1236@bacchus.dhis.org> <20010716223902.A16351@superweasel.com> <20010717050050.A1737@bacchus.dhis.org> Subject: Re: Linux on a 100MHz r4000 indy? Date: Tue, 17 Jul 2001 07:50:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2596 Lines: 77 I don't have access to old R4000 revision data, and I'll take your word for the errata applicable to rev 0422. A am a *little* surprised that such early parts found their way into Indys, since the Indy was not the first R4000 platform (I believe that honor belongs to the "Crimson" graphics workstations), but it's certainly possible. Regards, Kevin K. ----- Original Message ----- From: "Ralf Baechle" To: "Greg Johnson" Cc: Sent: Tuesday, July 17, 2001 5:00 AM Subject: Re: Linux on a 100MHz r4000 indy? > On Mon, Jul 16, 2001 at 10:39:02PM -0400, Greg Johnson wrote: > > > CPU revision is: 00000422 > > That's a really old and buggy CPU. Kevin Kissel may correct me but I think > it's the first series shipped to customers. Among the fun bugs: > > -------------------------------------------------------------------------- --- > > 4. R4000PC, R4000SC: An instruction sequence which contains a load which causes > a data cache miss and a jump, where the jump instruction is that last > instruction in the page and the delay slot of the jump is not currently > mapped, causes the exception vector to be overwritten by the jump address. > The R4000 will use the jump address as the exception vector. > > Example: lw <---- data cache miss > noop <---- one or two Noops > jr <---- last instruction in the page (jump or branch in- > struction) > --------------<---- page boundary > noop > > Workaround: Jump and branch instructions should never be in the last loca- > tion of a page. > 11. R4000PC, R4000SC: In the case: > > lw rA, (rn) > noop (or any non-conflicting instruction) > lw rn, (rA) (where the address in rA causes a TLB refill) > --------------------> end of page > page not mapped > > where rn and RA are general purpose registers r0 through r31 > > This code sequence causes the second load instruction to slip due to a > load use interlock. When the R4000 crosses the page boundary after the > lw, it vectors to 0x8000 0000 and later causes an instruction cache miss. > After the instruction cache miss is complete the LW causes another TLB > refill. This should vector to 0x8000 0000 but instead goes to 0x8000 0180. > > 14 (Just an update of erratum 4) > > -------------------------------------------------------------------------- --- > > There's more but I don't want to paste the whole errata document in here > and above bugs alone without the respective workarounds in kernel and tools > are grave bugs. > > Ralf From owner-linux-mips@oss.sgi.com Tue Jul 17 00:03:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H73G210676 for linux-mips-outgoing; Tue, 17 Jul 2001 00:03:16 -0700 Received: from dea.waldorf-gmbh.de (u-83-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H73CV10670 for ; Tue, 17 Jul 2001 00:03:13 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6H3S9e01328; Tue, 17 Jul 2001 05:28:09 +0200 Date: Tue, 17 Jul 2001 05:28:09 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: SUCCESS: Booting a real 64bit Kernel on Indigo2 R10000 (IP28) Message-ID: <20010717052809.A1319@bacchus.dhis.org> References: <20010714193634.B24615@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010714193634.B24615@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Sat, Jul 14, 2001 at 07:36:34PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 395 Lines: 10 On Sat, Jul 14, 2001 at 07:36:34PM +0200, Thiemo Seufer wrote: > - A real 64bit Kernel image without linker crashes etc. > No objcopy tricks, the Kernel is loaded at 0xa800000000000000. Using the assembler in 32-bit mode results in better code also. So while I came up with the objcopy trick as a way to kludge around the kernel bugs it has become the way of choice for the Origin. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 17 00:06:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H76nN10780 for linux-mips-outgoing; Tue, 17 Jul 2001 00:06:49 -0700 Received: from dea.waldorf-gmbh.de (u-83-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.83]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H76kV10775 for ; Tue, 17 Jul 2001 00:06:46 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6H76OL02575; Tue, 17 Jul 2001 09:06:24 +0200 Date: Tue, 17 Jul 2001 09:06:24 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: Greg Johnson , linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? Message-ID: <20010717090624.A2471@bacchus.dhis.org> References: <20010716163712.B12104@superweasel.com> <20010717032055.A1236@bacchus.dhis.org> <20010716223902.A16351@superweasel.com> <20010717050050.A1737@bacchus.dhis.org> <001301c10e84$570805a0$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001301c10e84$570805a0$0deca8c0@Ulysses>; from kevink@mips.com on Tue, Jul 17, 2001 at 07:50:00AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 757 Lines: 20 On Tue, Jul 17, 2001 at 07:50:00AM +0200, Kevin D. Kissell wrote: > I don't have access to old R4000 revision data, and I'll take your > word for the errata applicable to rev 0422. There is a cool site on the internet to get such data. It's http://www.mips.com/Documentation/R4000_3.0_2.2_PC_SC_errata.pdf :-) > A am a *little* surprised that such early parts found their way into > Indys, since the Indy was not the first R4000 platform (I believe that > honor belongs to the "Crimson" graphics workstations), but it's certainly > possible. Agreed. So far I thought the oldest CPU module we have to worry about is v3.0. If somebody has an old 2.2 CPU module for an Indy lying around which he wants to send to me for debugging such stuff ... Ralf From owner-linux-mips@oss.sgi.com Tue Jul 17 00:15:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H7FXT10986 for linux-mips-outgoing; Tue, 17 Jul 2001 00:15:33 -0700 Received: from laxmls04.socal.rr.com (laxmls04.socal.rr.com [24.30.163.18]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H7FTV10983 for ; Tue, 17 Jul 2001 00:15:29 -0700 Received: from compiler (sc-66-74-235-241.socal.rr.com [66.74.235.241]) by laxmls04.socal.rr.com (8.11.2/8.11.1) with SMTP id f6H7F7g20833; Tue, 17 Jul 2001 00:15:08 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" From: Shane Nay To: James Simmons Subject: Re: [Linux-mips-kernel] Re: [ANNOUNCE] Secondary mips tree. Date: Tue, 17 Jul 2001 00:16:15 -0700 X-Mailer: KMail [version 1.2] Cc: Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net References: In-Reply-To: MIME-Version: 1.0 Message-Id: <0107170016150H.02677@compiler> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1277 Lines: 29 > That would be good. I look forward to the patches. Most my MIPs time is in fixing small problems at the moment, but initiating a forward port to an active repository is a Good Idea. Most of my time is being funneled into ARM bootloader work here lately though :(. > > linux-vr has been > > really really stale since we froze at our present version for toolchain > > reasons. Those toolchain problems were fixed ages ago, but Mike & Brad > > who had been responsible for forward porting the kernel stopped doing > > that work for the most part. > > So we have noticed. Things are starting to get updated now. > > P.S > We have been having problems with toolchains as well. We plan to have a > new toolchain ready by Wednesday. Yes, there have been a lot of toolchain issues with MIPs. The last time I went on a toolchain testing binge for MIPs was with GCC CVS in about April. I had really good results with that toolchain with both the kernel and userland. I did some micro tests with 3.0 and they appeared solid, but I had updated to the latest non-CVS version of bintools and it was chocking out lots of assembler warnings when rebuilding glibc. There are source and binary snaps of that toolchain on the agenda FTP site under snow. Thanks, Shane Nay. From owner-linux-mips@oss.sgi.com Tue Jul 17 00:28:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H7SZo11237 for linux-mips-outgoing; Tue, 17 Jul 2001 00:28:35 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H7SHV11233; Tue, 17 Jul 2001 00:28:17 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA04632; Tue, 17 Jul 2001 09:28:09 +0200 (MET DST) Date: Tue, 17 Jul 2001 09:28:08 +0200 (MEST) From: Geert Uytterhoeven To: Ralf Baechle cc: "Kevin D. Kissell" , Greg Johnson , linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? In-Reply-To: <20010717090624.A2471@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 728 Lines: 20 On Tue, 17 Jul 2001, Ralf Baechle wrote: > On Tue, Jul 17, 2001 at 07:50:00AM +0200, Kevin D. Kissell wrote: > > I don't have access to old R4000 revision data, and I'll take your > > word for the errata applicable to rev 0422. > > There is a cool site on the internet to get such data. It's > http://www.mips.com/Documentation/R4000_3.0_2.2_PC_SC_errata.pdf :-) You did make a copy on CDR? Interesting docs tend to disappear from the Internet... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jul 17 01:14:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6H8EDm12295 for linux-mips-outgoing; Tue, 17 Jul 2001 01:14:14 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6H8E7V12292; Tue, 17 Jul 2001 01:14:07 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA08332; Tue, 17 Jul 2001 10:16:19 +0200 (MET DST) Date: Tue, 17 Jul 2001 10:16:18 +0200 (MET DST) From: "Maciej W. Rozycki" To: Geert Uytterhoeven cc: Ralf Baechle , "Kevin D. Kissell" , Greg Johnson , linux-mips@oss.sgi.com Subject: Re: Linux on a 100MHz r4000 indy? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 477 Lines: 13 On Tue, 17 Jul 2001, Geert Uytterhoeven wrote: > You did make a copy on CDR? Interesting docs tend to disappear from the > Internet... I'm mirroring whatever I can -- feel free to ask if you are looking for a particular document or for any documents on a particular item. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Tue Jul 17 06:07:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HD7hY18701 for linux-mips-outgoing; Tue, 17 Jul 2001 06:07:43 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HD7fV18697 for ; Tue, 17 Jul 2001 06:07:41 -0700 Message-Id: <200107171307.f6HD7fV18697@oss.sgi.com> Received: (qmail 32133 invoked from network); 17 Jul 2001 13:02:13 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 17 Jul 2001 13:02:13 -0000 Date: Thu, 19 Jul 2001 21:41:5 +0800 From: Fuxin Zhang To: "linux-mips@oss.sgi.com" Subject: help on linux-mipsel frame buffer X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1843 Lines: 45 hello,linux-mips gurus Recently I am trying to make frame buffer work on my P6032 board (from Algorithmics).I have a cirrus logic 5430,a RIVA TNT2 and a Trident 3dImage9750 on hand.The linux kernel I am using is 2.2.14 ( mipsel 1.05? modified by Algorithmics. BTW,could someone tell me how to access the mips tree and what the version scheme for mipsel? I read the mips-howto. but although i can login to the cvs server of oss.sgi.com i could not find out where is the kernel. "cvs get linux" responded with "cannot find module 'linux'" I am new to mips world. ) and the distribution is Hardhat downloaded from oss.sgi.com First I try the vga16 frame buffer driver,but i can only get some black/white strips on the screen.(after made some changes to the source,most important one is use pci to find and set the vbase address). I can use tty driver,because I can switch consoles using alt-f? on the keyboard attached to the board and even login and reboot the machine: just no readable display. Then I try to use vesa driver. This one use some vgabios code I commented out the x86 relevant codes and made it compiled,(again use pci_find_device to find video memory address,and tweak the make file to force vgacon use vesa driver). But the result is a blank screen.The fb driver is certainly on: I can copy to/from /dev/fb0. but with no visual effect. Finally I back port the Riva TNT frame buffer code to 2.2,the result is the same as the vesa driver. I suspect that the pci memory map is somewhat broken,but I checked the source code and the bonito(P6032 north bridge) manual and found no obvious flaw. Where could i be wrong?Is there anybody has some experience with frame buffer for mips? Any help will be great appreciated. Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Jul 17 08:35:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HFZJ321601 for linux-mips-outgoing; Tue, 17 Jul 2001 08:35:19 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HFZFV21598 for ; Tue, 17 Jul 2001 08:35:15 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 9752A125BC; Tue, 17 Jul 2001 08:35:14 -0700 (PDT) Date: Tue, 17 Jul 2001 08:35:14 -0700 From: "H . J . Lu" To: Shane Nay Cc: James Simmons , Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: [Linux-mips-kernel] Re: [ANNOUNCE] Secondary mips tree. Message-ID: <20010717083514.A19836@lucon.org> References: <0107170016150H.02677@compiler> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0107170016150H.02677@compiler>; from shane@minirl.com on Tue, Jul 17, 2001 at 12:16:15AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 922 Lines: 19 On Tue, Jul 17, 2001 at 12:16:15AM -0700, Shane Nay wrote: > > We have been having problems with toolchains as well. We plan to have a > > new toolchain ready by Wednesday. > > Yes, there have been a lot of toolchain issues with MIPs. The last time I > went on a toolchain testing binge for MIPs was with GCC CVS in about April. > I had really good results with that toolchain with both the kernel and > userland. I did some micro tests with 3.0 and they appeared solid, but I had > updated to the latest non-CVS version of bintools and it was chocking out > lots of assembler warnings when rebuilding glibc. There are source and > binary snaps of that toolchain on the agenda FTP site under snow. > The toolchain in my RedHat 7.1 mips port is as good as the x86 version for RedHat 7.1. Since there is no mips maintainer for gcc, many mips patches aren't reviewed. But they are in my mips toolchain. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 09:12:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HGC2u22899 for linux-mips-outgoing; Tue, 17 Jul 2001 09:12:02 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HGBwV22896 for ; Tue, 17 Jul 2001 09:11:59 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 67506C4FE; Tue, 17 Jul 2001 18:11:56 +0200 (CEST) Date: Tue, 17 Jul 2001 18:11:56 +0200 From: Jan-Benedict Glaw To: SGI MIPS list , Debian MIPS list Subject: Oops in serial driver Message-ID: <20010717181156.A32024@lug-owl.de> Mail-Followup-To: SGI MIPS list , Debian MIPS list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 456 Lines: 13 Hi! I'm currently testing with current CVS kernels and facing some bad Oopses in DECstation's serial driver:-( Top fafourites are Hi! I'm currently testing with current CVS kernels and facing some bad Oopses in DECstation's serial driver:-( Top fafourites are rs_interrupt and zs_channels. Does anybody already have a fix for this? I fear noting down all the Oops from framebuffer, as it is for obvious reason not written to serial console... MfG, JBG From owner-linux-mips@oss.sgi.com Tue Jul 17 09:17:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HGH7V23028 for linux-mips-outgoing; Tue, 17 Jul 2001 09:17:07 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HGH5V23025 for ; Tue, 17 Jul 2001 09:17:05 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id SAA387329 for ; Tue, 17 Jul 2001 18:17:03 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15MXWp-0001uu-00 for ; Tue, 17 Jul 2001 18:16:55 +0200 Date: Tue, 17 Jul 2001 18:16:55 +0200 To: linux-mips@oss.sgi.com Subject: Re: SUCCESS: Booting a real 64bit Kernel on Indigo2 R10000 (IP28) Message-ID: <20010717181655.B3241@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010717052809.A1319@bacchus.dhis.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1219 Lines: 36 Ralf Baechle wrote: > On Sat, Jul 14, 2001 at 07:36:34PM +0200, Thiemo Seufer wrote: > > > - A real 64bit Kernel image without linker crashes etc. > > No objcopy tricks, the Kernel is loaded at 0xa800000000000000. > > Using the assembler in 32-bit mode results in better code also. ITYM more compact and possibly faster. The 'faster' part depends on what is done in the Kernel, since there are 64bit syscalls it can't be true for everything. To the 'more compact' part: text + data of my kernel is about 2.0 MB, including the standard drivers for an I2 (except newport). an roughly comparable kernel (2.4.3 from ftp.rfc822.org) which supports newport but keeps some other things in modules needs about 1.6 MB. IMHO that's not too much difference, I2's aren't that low on memory. Anyway, the Firmware of newer I2 does not load 32bit kernels, so a 64bit Kernel is needed there. > So > while I came up with the objcopy trick as a way to kludge around the > kernel bugs it has become the way of choice for the Origin. How much is the performance difference there? Do you have some estimates? Supporting both sorts of kernels would require really ugly ifdef'ing for most of the low-level assembly code. Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 17 09:42:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HGgMs23542 for linux-mips-outgoing; Tue, 17 Jul 2001 09:42:22 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HGgIV23539 for ; Tue, 17 Jul 2001 09:42:18 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6HGffdi017606; Tue, 17 Jul 2001 09:41:41 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6HGfEMW017579; Tue, 17 Jul 2001 09:41:39 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 17 Jul 2001 09:41:14 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: Shane Nay , Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Toolchains In-Reply-To: <20010717083514.A19836@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 250 Lines: 7 > The toolchain in my RedHat 7.1 mips port is as good as the x86 version > for RedHat 7.1. Since there is no mips maintainer for gcc, many > mips patches aren't reviewed. But they are in my mips toolchain. Where are they? On the oss.sgi.com site. From owner-linux-mips@oss.sgi.com Tue Jul 17 10:20:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HHKrL24697 for linux-mips-outgoing; Tue, 17 Jul 2001 10:20:53 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HHKpV24694 for ; Tue, 17 Jul 2001 10:20:51 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id DCCC9125BD; Tue, 17 Jul 2001 10:20:50 -0700 (PDT) Date: Tue, 17 Jul 2001 10:20:50 -0700 From: "H . J . Lu" To: James Simmons Cc: Shane Nay , Pavel Machek , Linux Kernel Mailing List , linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: Toolchains Message-ID: <20010717102050.A21784@lucon.org> References: <20010717083514.A19836@lucon.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 jsimmons@transvirtual.com on Tue, Jul 17, 2001 at 09:41:14AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1036 Lines: 30 On Tue, Jul 17, 2001 at 09:41:14AM -0700, James Simmons wrote: > > > The toolchain in my RedHat 7.1 mips port is as good as the x86 version > > for RedHat 7.1. Since there is no mips maintainer for gcc, many > > mips patches aren't reviewed. But they are in my mips toolchain. > > Where are they? On the oss.sgi.com site. My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You will need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. Thanks. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 11:10:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HIAxj25818 for linux-mips-outgoing; Tue, 17 Jul 2001 11:10:59 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HIAwV25815 for ; Tue, 17 Jul 2001 11:10:58 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id D212D801; Tue, 17 Jul 2001 20:10:56 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 65CD14626; Tue, 17 Jul 2001 20:11:14 +0200 (CEST) Date: Tue, 17 Jul 2001 20:11:14 +0200 From: Florian Lohoff To: SGI MIPS list , Debian MIPS list Subject: Re: Oops in serial driver Message-ID: <20010717201114.C5552@paradigm.rfc822.org> References: <20010717181156.A32024@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010717181156.A32024@lug-owl.de>; from jbglaw@lug-owl.de on Tue, Jul 17, 2001 at 06:11:56PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 795 Lines: 19 On Tue, Jul 17, 2001 at 06:11:56PM +0200, Jan-Benedict Glaw wrote: > Hi! > I'm currently testing with current CVS kernels and facing some bad > Oopses in DECstation's serial driver:-( Top fafourites are rs_interrupt > and zs_channels. Does anybody already have a fix for this? I fear > noting down all the Oops from framebuffer, as it is for obvious reason > not written to serial console... Loop up the assembly code in the functions and check which register they attempt to use. You wont need to write down all registers. It would be interesting under which occurencies the oops happens - When running on fb why do you use the serials ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue Jul 17 11:15:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HIFFT26293 for linux-mips-outgoing; Tue, 17 Jul 2001 11:15:15 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HIFEV26290 for ; Tue, 17 Jul 2001 11:15:14 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 0BC347FE; Tue, 17 Jul 2001 20:15:13 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id DD0434626; Tue, 17 Jul 2001 20:13:21 +0200 (CEST) Date: Tue, 17 Jul 2001 20:13:21 +0200 From: Florian Lohoff To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: SUCCESS: Booting a real 64bit Kernel on Indigo2 R10000 (IP28) Message-ID: <20010717201321.D5552@paradigm.rfc822.org> References: <20010717052809.A1319@bacchus.dhis.org> <20010717181655.B3241@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010717181655.B3241@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jul 17, 2001 at 06:16:55PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 372 Lines: 13 On Tue, Jul 17, 2001 at 06:16:55PM +0200, Thiemo Seufer wrote: > > Anyway, the Firmware of newer I2 does not load 32bit kernels, so > a 64bit Kernel is needed there. > You mean R10k or R8k I2s not newer ones right ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Tue Jul 17 11:38:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HIcdb27119 for linux-mips-outgoing; Tue, 17 Jul 2001 11:38:39 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HIcaV27116 for ; Tue, 17 Jul 2001 11:38:36 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id UAA390339 for ; Tue, 17 Jul 2001 20:38:35 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15MZjr-0000lb-00 for ; Tue, 17 Jul 2001 20:38:31 +0200 Date: Tue, 17 Jul 2001 20:38:31 +0200 To: linux-mips@oss.sgi.com Subject: Re: SUCCESS: Booting a real 64bit Kernel on Indigo2 R10000 (IP28) Message-ID: <20010717203831.D3241@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010717201321.D5552@paradigm.rfc822.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 365 Lines: 16 Florian Lohoff wrote: > On Tue, Jul 17, 2001 at 06:16:55PM +0200, Thiemo Seufer wrote: > > > > Anyway, the Firmware of newer I2 does not load 32bit kernels, so > > a 64bit Kernel is needed there. > > > > You mean R10k or R8k I2s not newer ones right ? I meant my Indigo2 R10000 Impact Ready: ARCH: SGI-IP28 PROMLIB: ARC firmware Version 64 Revision 0 Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 17 11:56:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HIue927780 for linux-mips-outgoing; Tue, 17 Jul 2001 11:56:40 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HIucV27776 for ; Tue, 17 Jul 2001 11:56:38 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id 8EACFC4FE; Tue, 17 Jul 2001 20:56:36 +0200 (CEST) Date: Tue, 17 Jul 2001 20:56:36 +0200 From: Jan-Benedict Glaw To: SGI MIPS list , Debian MIPS list Subject: Re: Oops in serial driver Message-ID: <20010717205636.A467@lug-owl.de> Mail-Followup-To: SGI MIPS list , Debian MIPS list References: <20010717181156.A32024@lug-owl.de> <20010717201114.C5552@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010717201114.C5552@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Jul 17, 2001 at 08:11:14PM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1329 Lines: 31 On Tue, Jul 17, 2001 at 08:11:14PM +0200, Florian Lohoff wrote: > On Tue, Jul 17, 2001 at 06:11:56PM +0200, Jan-Benedict Glaw wrote: > > Hi! > > I'm currently testing with current CVS kernels and facing some bad > > Oopses in DECstation's serial driver:-( Top fafourites are rs_interrupt > > and zs_channels. Does anybody already have a fix for this? I fear > > noting down all the Oops from framebuffer, as it is for obvious reason > > not written to serial console... > > Loop up the assembly code in the functions and check which register > they attempt to use. You wont need to write down all registers. Ok. Will do that tomorrow (Don't have access to that box right now) > It would be interesting under which occurencies the oops happens - When > running on fb why do you use the serials ? Well... Serial console seems to be *very* handy at all. I'm not yet that far to use DECstation's own keyboard (which is btw a serial device-:-) How's that done? "console=tty0 console=ttyS0"? Another thing is stability. I'm currently using Karsten's glibc2.2 based debian base filesystem which is not that much fun on a R3k (-> ll/sc and sysmips - any solution at horizon?). Binaries tend to SIGBUS, Illegal Insn, ... But everything will be good at some point:-) Some hints on serial keyboard would be nice! Karsten? MfG, JBG From owner-linux-mips@oss.sgi.com Tue Jul 17 12:15:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HJFI928506 for linux-mips-outgoing; Tue, 17 Jul 2001 12:15:18 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HJFDV28502; Tue, 17 Jul 2001 12:15:14 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id MAA12245; Tue, 17 Jul 2001 12:15:01 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA03708; Tue, 17 Jul 2001 12:14:59 -0700 (PDT) Received: from mips.com (coppccl [172.17.27.2]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6HJDpa16789; Tue, 17 Jul 2001 21:13:52 +0200 (MEST) Message-ID: <3B548EF5.993C271E@mips.com> Date: Tue, 17 Jul 2001 21:16:05 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2017 Lines: 59 "H . J . Lu" wrote: > On Mon, Jul 16, 2001 at 01:26:32PM +0200, Carsten Langgaard wrote: > > "H . J . Lu" wrote: > > > > Now I would like to try to install H.J. Lu's RedHat7.1 RPM packages. > > > > If I just do a: > > > > rpm -Uvh --root /mnt/harddisk *.rpm > > > > > > Those rpms have to be installed in the right order. I have a set up > > > to do that. I will see what I can do. > > > > Thanks, please do. > > They are in install.tar.bz2 now. Thanks a lot, that look like something we have been needing for a long time > > Another thing, I can see your distribution is lacking kernel header > > files, I guess they are needed to do a native compile of the source RPMs. > > I added gdb and kernel-headers. I also updated gcc, glibc and binutils. > The toolchain rpms are updated. Now that I'm at it :-) Could you add a Perl rpm to you distribution, this also seems to be needed to build the RPMs natively. I also would like to do a cross build, but how do I do that ? Do I have to change all the spec files, to set the target arch to MIPS, or is there a easier and better way to do that ? I guess if I just install the SRPMs and the cross toolchain, and try to build out of that I will simply build for the build platform, which is i386. > > > H.J. > ------ > My mini-port of RedHat 7.1 is at > > ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ > > you should be able to put a small RedHat 7.1 on the mips/mipsel box and > compile the rest of RedHat 7.1 yourselves. > > Here are something you should know: > > 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a > toolchain rpm. The binary rpms for the mips and mipsel cross compilers > are included. You will need glibc 2.2.3-11 or above to use those > rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. > 2. You have to find a way to put those rpms on your machine. I use > network boot and NFS root to do it. > 3. install.tar.bz2 has some scripts to prepare NFS root and install > RedHat 7.1 on a hard drive. > > Thanks. > > H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 12:29:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HJTEj28807 for linux-mips-outgoing; Tue, 17 Jul 2001 12:29:14 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HJT9V28803; Tue, 17 Jul 2001 12:29:10 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id B6EB9125BE; Tue, 17 Jul 2001 12:29:02 -0700 (PDT) Date: Tue, 17 Jul 2001 12:29:02 -0700 From: "H . J . Lu" To: Carsten Langgaard Cc: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010717122902.B24048@lucon.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B548EF5.993C271E@mips.com>; from carstenl@mips.com on Tue, Jul 17, 2001 at 09:16:05PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2578 Lines: 67 On Tue, Jul 17, 2001 at 09:16:05PM +0200, Carsten Langgaard wrote: > Could you add a Perl rpm to you distribution, this also seems to be needed to > build the RPMs natively. Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build perl yourself. You may need to build/install the tcsh rpm first. > > I also would like to do a cross build, but how do I do that ? > Do I have to change all the spec files, to set the target arch to MIPS, or is > there a easier and better way to do that ? > I guess if I just install the SRPMs and the cross toolchain, and try to build > out of that I will simply build for the build platform, which is i386. You need my patched `rpm' to do cross build. You also need some specicial set up. I am enclosng a message of mine. I will see if I can cleanup my cross build environment and upload it. H.J. ----- > they work great! Thanks for all your hard work. Now, I would like > to be able to build some RPMs as well. I have never cross-built > RPMs before. I took the SRPMS for make and tried: > > rpm -ba make.spec --target=mipsel > > This did not do anything and built nothing. Is there a FAQ that > I can read on cross building RPMS in addition to the documentation > on http://www.rpm.org/ ? Do you have any quick pointers? Thanks > again. Although my source rpms do support cross compile, FYI, all my mips/mipsel rpms are cross compiled from ia32 machines, the unpatched rpm, that is /bin/rpm, doesn't support cross compile. In my RedHat 7.1, there are i386 rpm binaries which support cross compile. I have a setup to cross build rpms to mips/mipsel. Make sure your rpm sees %__ar %{_target_prefix}-linux-ar %__as %{_target_prefix}-linux-as %__cc %{_target_prefix}-linux-gcc %__cxx %{_target_prefix}-linux-c++ %__ld %{_target_prefix}-linux-ld %__nm %{_target_prefix}-linux-nm %__objcopy %{_target_prefix}-linux-objcopy %__objdump %{_target_prefix}-linux-objdump %__ranlib %{_target_prefix}-linux-ranlib %__strip %{_target_prefix}-linux-strip and do # rpm --target=mips --define '_target_prefix mips' or # rpm --target=mipsel --define '_target_prefix mipsel' BTW, you alao need to rebuild binutils with # rpm --define 'ENABLE_ALL_TARGETS 1' -ta binutils-2.11.90.0.23.tar.gz H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 12:57:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HJvLp29551 for linux-mips-outgoing; Tue, 17 Jul 2001 12:57:21 -0700 Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [212.227.116.80]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HJvKV29548 for ; Tue, 17 Jul 2001 12:57:20 -0700 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 f6HJvFg19509; Tue, 17 Jul 2001 21:57:15 +0200 Received: from intel by smtp.web.de with smtp (freemail 4.2.2.2 #11) id m15May1-007oN0C; Tue, 17 Jul 2001 21:57 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Harald Koerfgen Organization: none to speak of To: Jan-Benedict Glaw , SGI MIPS list , Debian MIPS list Subject: Re: Oops in serial driver Date: Tue, 17 Jul 2001 22:00:20 +0200 X-Mailer: KMail [version 1.2] References: <20010717181156.A32024@lug-owl.de> <20010717201114.C5552@paradigm.rfc822.org> <20010717205636.A467@lug-owl.de> In-Reply-To: <20010717205636.A467@lug-owl.de> MIME-Version: 1.0 Message-Id: <01071722002001.05690@intel> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 160 Lines: 7 On Tuesday 17 July 2001 20:56, Jan-Benedict Glaw wrote: > Some hints on serial keyboard would be nice! Karsten? Just commited Maciej's fix. Greetings, Harald From owner-linux-mips@oss.sgi.com Tue Jul 17 12:57:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HJvPm29577 for linux-mips-outgoing; Tue, 17 Jul 2001 12:57:25 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HJvOV29574 for ; Tue, 17 Jul 2001 12:57:24 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id DEA60125BC; Tue, 17 Jul 2001 12:57:18 -0700 (PDT) Date: Tue, 17 Jul 2001 12:57:18 -0700 From: "H . J . Lu" To: Daniel Jacobowitz Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010717125718.A24725@lucon.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> <20010717122902.B24048@lucon.org> <20010717125027.A22672@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010717125027.A22672@nevyn.them.org>; from drow@mvista.com on Tue, Jul 17, 2001 at 12:50:27PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 693 Lines: 17 On Tue, Jul 17, 2001 at 12:50:27PM -0700, Daniel Jacobowitz wrote: > > > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > > perl yourself. You may need to build/install the tcsh rpm first. > > It's not yet available for MIPS (later this week), but MontaVista Journeyman > contains the patches to cross-compile Perl. It's not pretty, though. > That is a reason why I didn't bother with cross-compile Perl :-). The next thing on my todo list is to cross compile XFree86 :-(. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 13:01:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HK1IE29912 for linux-mips-outgoing; Tue, 17 Jul 2001 13:01:18 -0700 Received: from xstreamlogic.com (mail.xstreamlogic.com [65.105.228.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HK1GV29904 for ; Tue, 17 Jul 2001 13:01:17 -0700 Received: from [192.168.1.117] ([192.168.1.117] verified) by xstreamlogic.com (CommuniGate Pro SMTP 3.3.1) with ESMTP id 1039451 for linux-mips@oss.sgi.com; Tue, 17 Jul 2001 13:01:11 -0700 Date: Tue, 17 Jul 2001 12:59:23 -0700 From: Narendra Sankar Reply-To: Narendra Sankar To: linux-mips@oss.sgi.com Subject: MIPS processor identification register Message-ID: <1114092660.995374763@[192.168.1.117]> X-Mailer: Mulberry/2.1.0b2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 287 Lines: 10 hi everyone I could not find an answer to this question in the archives and hence am trying here - Is there a complete list somewhere of the different PRID (CP0 register 15) values across the entire MIPS family - including all the different vendors? Thanks Naren Clearwater Networks From owner-linux-mips@oss.sgi.com Tue Jul 17 13:01:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HK1Lx29935 for linux-mips-outgoing; Tue, 17 Jul 2001 13:01:21 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HK1FV29903 for ; Tue, 17 Jul 2001 13:01:15 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA03452 for ; Tue, 17 Jul 2001 13:01:00 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15MarT-0005vj-00; Tue, 17 Jul 2001 12:50:27 -0700 Date: Tue, 17 Jul 2001 12:50:27 -0700 From: Daniel Jacobowitz To: "H . J . Lu" Cc: Jun Sun , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010717125027.A22672@nevyn.them.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> <20010717122902.B24048@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010717122902.B24048@lucon.org>; from hjl@lucon.org on Tue, Jul 17, 2001 at 12:29:02PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 854 Lines: 17 On Tue, Jul 17, 2001 at 12:29:02PM -0700, H . J . Lu wrote: > On Tue, Jul 17, 2001 at 09:16:05PM +0200, Carsten Langgaard wrote: > > Could you add a Perl rpm to you distribution, this also seems to be needed to > > build the RPMs natively. > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > perl yourself. You may need to build/install the tcsh rpm first. It's not yet available for MIPS (later this week), but MontaVista Journeyman contains the patches to cross-compile Perl. It's not pretty, though. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Tue Jul 17 13:05:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HK5hk30240 for linux-mips-outgoing; Tue, 17 Jul 2001 13:05:43 -0700 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HK5fV30237 for ; Tue, 17 Jul 2001 13:05:41 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1975 Lines: 51 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 owner-linux-mips@oss.sgi.com Tue Jul 17 13:09:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HK96o30363 for linux-mips-outgoing; Tue, 17 Jul 2001 13:09:06 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HK94V30360 for ; Tue, 17 Jul 2001 13:09:04 -0700 Received: (qmail 29906 invoked by uid 502); 17 Jul 2001 20:09:03 -0000 Content-Type: text/plain; charset="koi8-r" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: "H . J . Lu" Subject: Re: Updates on RedHat 7.1/mips Date: Tue, 17 Jul 2001 13:09:00 -0700 X-Mailer: KMail [version 1.2] Cc: linux-mips@oss.sgi.com References: <3B4573B8.9F89022B@mips.com> <20010717125027.A22672@nevyn.them.org> <20010717125718.A24725@lucon.org> In-Reply-To: <20010717125718.A24725@lucon.org> MIME-Version: 1.0 Message-Id: <01071713090011.04620@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1869 Lines: 44 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 July 2001 12:57, H . J . Lu wrote: > On Tue, Jul 17, 2001 at 12:50:27PM -0700, Daniel Jacobowitz wrote: > > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > > > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > > > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > > > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > > > perl yourself. You may need to build/install the tcsh rpm first. > > > > It's not yet available for MIPS (later this week), but MontaVista > > Journeyman contains the patches to cross-compile Perl. It's not pretty, > > though. > > That is a reason why I didn't bother with cross-compile Perl :-). The > next thing on my todo list is to cross compile XFree86 :-(. If you can get cross-compiling full XFree86, you'll be a hero of all times. It shouldn't be hard to get it with KDriveArchitecture & TinyX enabled. I was working on it a while ago, and here are few pointers: Some tools have to be run natively (i.e. xkbcomp), but also need to be installed on target. I din't find a rule that does both. I think new rule is needed. gcc-3.0 crashes when compiling some parts of Xserver and Xlib, with very obscure bug. Minimal test case I came up with is ~45(!) lines long. Keith filed report to gcc team on my behalf, but there seems to be no responce. I do not know if your gcc has same problem, but someone mentioned similar problem with 2.9x.y series on this list not so long ago. Hmm... I can't remember any other interesting things at this moment, but if I will, I'll follow up... Ilya. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtUm18ACgkQtKh84cA8u2ll+QCfSjexRpQ2H7Qa16JYrun/vvVd vCQAoIKb1BRxJ/508SWu9uHEP0okhH00 =kWTa -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Tue Jul 17 13:11:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HKBqj30493 for linux-mips-outgoing; Tue, 17 Jul 2001 13:11:52 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HKBpV30490 for ; Tue, 17 Jul 2001 13:11:51 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 555D1125BC; Tue, 17 Jul 2001 13:11:46 -0700 (PDT) Date: Tue, 17 Jul 2001 13:11:46 -0700 From: "H . J . Lu" To: Ilya Volynets Cc: linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010717131146.A24907@lucon.org> References: <3B4573B8.9F89022B@mips.com> <20010717125027.A22672@nevyn.them.org> <20010717125718.A24725@lucon.org> <01071713090011.04620@gateway> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01071713090011.04620@gateway>; from ilya@theIlya.com on Tue, Jul 17, 2001 at 01:09:00PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 793 Lines: 22 On Tue, Jul 17, 2001 at 01:09:00PM -0700, Ilya Volynets wrote: > > I was working on it a while ago, and here are few pointers: > Some tools have to be run natively (i.e. xkbcomp), but also need to > be installed on target. I din't find a rule that does both. I think new > rule is needed. I am aware of those. I want to delay it as much as I can. > > gcc-3.0 crashes when compiling some parts of Xserver and Xlib, > with very obscure bug. Minimal test case I came up with is > ~45(!) lines long. Keith filed report to gcc team on my behalf, > but there seems to be no responce. I do not know if your > gcc has same problem, but someone mentioned similar problem > with 2.9x.y series on this list not so long ago. > Don't bother with gcc-3.0. I won't use it myself for building X. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 17 13:44:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HKi5j31617 for linux-mips-outgoing; Tue, 17 Jul 2001 13:44:05 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HKi2V31608 for ; Tue, 17 Jul 2001 13:44:03 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA13379; Tue, 17 Jul 2001 13:43:53 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA05411; Tue, 17 Jul 2001 13:43:52 -0700 (PDT) Message-ID: <012501c10f01$d5fd0f40$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Narendra Sankar" , References: <1114092660.995374763@[192.168.1.117]> Subject: Re: MIPS processor identification register Date: Tue, 17 Jul 2001 22:48:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 772 Lines: 26 There is no list that is both public and complete. MIPS issues PRID values to MIPS licensees, but has no control over how, when and whether the associated processors are commercialized, and does not publish the full list of registered values. Kevin K. ----- Original Message ----- From: "Narendra Sankar" To: Sent: Tuesday, July 17, 2001 9:59 PM Subject: MIPS processor identification register > hi everyone > I could not find an answer to this question in the archives and hence am > trying here - > > Is there a complete list somewhere of the different PRID (CP0 register 15) > values across the entire MIPS family - including all the different vendors? > > Thanks > Naren > Clearwater Networks From owner-linux-mips@oss.sgi.com Tue Jul 17 13:46:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6HKkWb31777 for linux-mips-outgoing; Tue, 17 Jul 2001 13:46:32 -0700 Received: from mailhub.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6HKkVV31774 for ; Tue, 17 Jul 2001 13:46:31 -0700 Received: (qmail 6374 invoked from network); 17 Jul 2001 20:46:25 -0000 Received: from r049112.stusta.swh.mhn.de (HELO magi) (10.150.49.112) by mailhub.stusta.mhn.de with SMTP; 17 Jul 2001 20:46:25 -0000 Received: from oliver by magi with local (Exim 3.22 #1 (Debian)) id 15MbjY-00015t-00 for ; Tue, 17 Jul 2001 22:46:20 +0200 Date: Tue, 17 Jul 2001 22:46:17 +0200 From: "Oliver M . Bolzer" To: linux-mips@oss.sgi.com Subject: Re: MIPS processor identification register Message-ID: <20010717224617.A4132@magi.sukisuki.org> References: <1114092660.995374763@[192.168.1.117]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Mutt/1.2.4i-jp0 In-Reply-To: <1114092660.995374763@[192.168.1.117]>; from naren@clearwaternetworks.com on Tue, Jul 17, 2001 at 12:59:23PM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1302 Lines: 36 Hi! On Tue, Jul 17, 2001 at 12:59:23PM -0700, Narendra Sankar wrote... > Is there a complete list somewhere of the different PRID (CP0 register 15) > values across the entire MIPS family - including all the different vendors? Not that I know of any, but for reference, the PlayStation2's EmotionEngine Processor (R5900) has a fixed Impl value of 0x2E. [oliver@asuka tmp]$ cat /proc/cpuinfo cpu : MIPS cpu model : R5900 V1.4 system type : EE PS2 BogoMIPS : 392.40 byteorder : little endian unaligned accesses : 0 wait instruction : no microsecond timers : no extra interrupt vector : yes hardware watchpoint : no VCED exceptions : not available VCEI exceptions : not available # If anybody is interested in poking around a PlayStation2 running Linux # by SSH. send me a mail. I got a non-NDA fully GPL/LGPL compliant unit. # It's running an 2.2.1 kernel that looks more like a 2.2.1{8,9} when # looked under the hood. It was delivered that way by SCEI and somebody # despeartely needs to update it. Unfortunatly I'm a userspace guy. -- Oliver M. Bolzer oliver@gol.com GPG (PGP) Fingerprint = 621B 52F6 2AC1 36DB 8761 018F 8786 87AD EF50 D1FF From owner-linux-mips@oss.sgi.com Tue Jul 17 17:01:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I01Ou16536 for linux-mips-outgoing; Tue, 17 Jul 2001 17:01:24 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I01NV16531 for ; Tue, 17 Jul 2001 17:01:23 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6I017di029867; Tue, 17 Jul 2001 17:01:07 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6I015vS029863; Tue, 17 Jul 2001 17:01:06 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 17 Jul 2001 17:01:05 -0700 (PDT) From: James Simmons To: Fuxin Zhang cc: "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer In-Reply-To: <200107171307.f6HD7fV18697@oss.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1073 Lines: 25 > First I try the vga16 frame buffer driver,but i can only get > some black/white strips on the screen.(after made some changes > to the source,most important one is use pci to find and set the > vbase address). It is hardwired into the vga16fb driver the memory region (0xA000). This is very wrong on non intel platforms. So that drivers pretty much doesn't work on anything else. > Then I try to use vesa driver. This one use some vgabios code > I commented out the x86 relevant codes and made it compiled, The VESA framebuffer is also intel specific. It uses the BIOS to setup the video mode. This is done long before the cpu is placed into protect mode. > Finally I back port the Riva TNT frame buffer code to 2.2,the result > is the same as the vesa driver. Hum. Try a cat /dev/urandom > /dev/fb0. If you don't see anything then the virtual memory address of the framebuffer is wrong. It could be that the physical address is wrong (smem_start). Go to the fbdev website (http://www.linux-fbdev.org) and download a tool called fbtest and give it a try. From owner-linux-mips@oss.sgi.com Tue Jul 17 20:42:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I3gs825876 for linux-mips-outgoing; Tue, 17 Jul 2001 20:42:54 -0700 Received: from cool.coventive.com (cool.coventive.com [211.79.9.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I3gqV25873 for ; Tue, 17 Jul 2001 20:42:53 -0700 Received: from jefflee (miao.coventive.com [202.145.111.189]) by cool.coventive.com (8.10.2/8.10.2) with SMTP id f6I3ghR05282 for ; Wed, 18 Jul 2001 11:42:44 +0800 Message-ID: <024501c10f3c$27d290d0$b310a8c0@jefflee> From: "jeff_lee" To: Subject: mipsel machine Date: Wed, 18 Jul 2001 11:45:52 +0800 Organization: hardware MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 343 Lines: 11 Dear All I am Jeff. I need to find out a mips machine (with HDD and bigger RAM) that can run the mipsel. Do you have any suggestion about the machine ? Where can I find the machine. We need the machine to do the native compiler. Thanks and best regs, Jeff at Coventive company ========================================================== From owner-linux-mips@oss.sgi.com Tue Jul 17 20:53:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I3r2e26447 for linux-mips-outgoing; Tue, 17 Jul 2001 20:53:02 -0700 Received: from netbank.com.br (IDENT:postfix@garrincha.netbank.com.br [200.203.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I3r0V26441 for ; Tue, 17 Jul 2001 20:53:01 -0700 Received: from brinquedo.distro.conectiva (1-102.ctame701-2.telepar.net.br [200.181.138.102]) by netbank.com.br (Postfix) with ESMTP id D64124680A; Wed, 18 Jul 2001 00:52:08 -0300 (BRST) Received: by brinquedo.distro.conectiva (Postfix, from userid 501) id AB02DCC25; Wed, 18 Jul 2001 00:52:55 -0300 (BRT) Date: Wed, 18 Jul 2001 00:52:55 -0300 From: Arnaldo Carvalho de Melo To: "H . J . Lu" Cc: Ilya Volynets , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010718005255.R10373@conectiva.com.br> References: <3B4573B8.9F89022B@mips.com> <20010717125027.A22672@nevyn.them.org> <20010717125718.A24725@lucon.org> <01071713090011.04620@gateway> <20010717131146.A24907@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010717131146.A24907@lucon.org>; from hjl@lucon.org on Tue, Jul 17, 2001 at 01:11:46PM -0700 X-Url: http://advogato.org/person/acme Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1055 Lines: 31 Em Tue, Jul 17, 2001 at 01:11:46PM -0700, H . J . Lu escreveu: > On Tue, Jul 17, 2001 at 01:09:00PM -0700, Ilya Volynets wrote: > > > > I was working on it a while ago, and here are few pointers: > > Some tools have to be run natively (i.e. xkbcomp), but also need to > > be installed on target. I din't find a rule that does both. I think new > > rule is needed. > > I am aware of those. I want to delay it as much as I can. recent messages to the XFree86 mailing lists has the recipe to x-compile XFree86, IIRC Keith Packard did the work > > > > gcc-3.0 crashes when compiling some parts of Xserver and Xlib, > > with very obscure bug. Minimal test case I came up with is > > ~45(!) lines long. Keith filed report to gcc team on my behalf, > > but there seems to be no responce. I do not know if your > > gcc has same problem, but someone mentioned similar problem > > with 2.9x.y series on this list not so long ago. > > > > Don't bother with gcc-3.0. I won't use it myself for building X. > > > H.J. -- - Arnaldo From owner-linux-mips@oss.sgi.com Tue Jul 17 21:01:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I41PU27195 for linux-mips-outgoing; Tue, 17 Jul 2001 21:01:25 -0700 Received: from gateway.total-knowledge.com (c1213523-b.smateo1.sfba.home.com [24.1.66.97]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I41OV27190 for ; Tue, 17 Jul 2001 21:01:24 -0700 Received: (qmail 1561 invoked by uid 502); 18 Jul 2001 04:01:23 -0000 Content-Type: text/plain; charset="koi8-r" From: Ilya Volynets Reply-To: ilya@theIlya.com Organization: Total knowledge To: Arnaldo Carvalho de Melo , "H . J . Lu" Subject: Re: Updates on RedHat 7.1/mips Date: Tue, 17 Jul 2001 21:01:20 -0700 X-Mailer: KMail [version 1.2] Cc: linux-mips@oss.sgi.com References: <3B4573B8.9F89022B@mips.com> <20010717131146.A24907@lucon.org> <20010718005255.R10373@conectiva.com.br> In-Reply-To: <20010718005255.R10373@conectiva.com.br> MIME-Version: 1.0 Message-Id: <01071721012019.04620@gateway> Content-Transfer-Encoding: 8bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1534 Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Those messages are about compiling using TinyX and KDrive, which works with only minor modifications. Thing is, it is not what is really needed. On Tuesday 17 July 2001 20:52, Arnaldo Carvalho de Melo wrote: > Em Tue, Jul 17, 2001 at 01:11:46PM -0700, H . J . Lu escreveu: > > On Tue, Jul 17, 2001 at 01:09:00PM -0700, Ilya Volynets wrote: > > > I was working on it a while ago, and here are few pointers: > > > Some tools have to be run natively (i.e. xkbcomp), but also need to > > > be installed on target. I din't find a rule that does both. I think new > > > rule is needed. > > > > I am aware of those. I want to delay it as much as I can. > > recent messages to the XFree86 mailing lists has the recipe to x-compile > XFree86, IIRC Keith Packard did the work > > > > gcc-3.0 crashes when compiling some parts of Xserver and Xlib, > > > with very obscure bug. Minimal test case I came up with is > > > ~45(!) lines long. Keith filed report to gcc team on my behalf, > > > but there seems to be no responce. I do not know if your > > > gcc has same problem, but someone mentioned similar problem > > > with 2.9x.y series on this list not so long ago. > > > > Don't bother with gcc-3.0. I won't use it myself for building X. > > > > > > H.J. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtVChMACgkQtKh84cA8u2nRTACgvPDSNX0E62POj2W+QkntYE9l pzIAnAjjprS4qWgUfELszqT94T+XGV0C =tJST -----END PGP SIGNATURE----- From owner-linux-mips@oss.sgi.com Tue Jul 17 21:15:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I4F2a28018 for linux-mips-outgoing; Tue, 17 Jul 2001 21:15:02 -0700 Received: from scsoftware.sc-software.com (mipsdev@[206.40.202.193]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I4F0V28004 for ; Tue, 17 Jul 2001 21:15:01 -0700 Received: from localhost (mipsdev@localhost) by scsoftware.sc-software.com (8.8.3/8.8.3) with SMTP id VAA15136; Tue, 17 Jul 2001 21:12:15 GMT Date: Tue, 17 Jul 2001 21:12:15 +0000 ( ) From: John Heil To: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com cc: mipsdev@scsoftware.sc-software.com Subject: Any old Cobalt Qube2 kernel src around? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 238 Lines: 13 Where can I find the Cobalt Qube2 buildable mips kernel source to match the Qube2's kerel-2.0.34C53_SK, if its still available? I went through the ftp.cobalt.com and found only precompiled kernel and headers. Thanks much John H. From owner-linux-mips@oss.sgi.com Wed Jul 18 00:14:48 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I7Emj07860 for linux-mips-outgoing; Wed, 18 Jul 2001 00:14:48 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I7EhV07856; Wed, 18 Jul 2001 00:14:43 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA19070; Wed, 18 Jul 2001 00:14:29 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA15496; Wed, 18 Jul 2001 00:14:30 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6I7DKa06857; Wed, 18 Jul 2001 09:13:21 +0200 (MEST) Message-ID: <3B553710.8B7A4CDE@mips.com> Date: Wed, 18 Jul 2001 09:13:20 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> <20010717122902.B24048@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3338 Lines: 90 "H . J . Lu" wrote: > On Tue, Jul 17, 2001 at 09:16:05PM +0200, Carsten Langgaard wrote: > > Could you add a Perl rpm to you distribution, this also seems to be needed to > > build the RPMs natively. > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > perl yourself. You may need to build/install the tcsh rpm first. It look like there is a cross dependence, the build of tcsh failed with the following message: /var/tmp/rpm-tmp.7250: /usr/bin/perl: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.7250 (%build) So tcsh is needed to build perl and perl is needed to build tcsh :-( > > > > > I also would like to do a cross build, but how do I do that ? > > Do I have to change all the spec files, to set the target arch to MIPS, or is > > there a easier and better way to do that ? > > I guess if I just install the SRPMs and the cross toolchain, and try to build > > out of that I will simply build for the build platform, which is i386. > > You need my patched `rpm' to do cross build. You also need some > specicial set up. I am enclosng a message of mine. I will see if > I can cleanup my cross build environment and upload it. > > H.J. > ----- > > they work great! Thanks for all your hard work. Now, I would like > > to be able to build some RPMs as well. I have never cross-built > > RPMs before. I took the SRPMS for make and tried: > > > > rpm -ba make.spec --target=mipsel > > > > This did not do anything and built nothing. Is there a FAQ that > > I can read on cross building RPMS in addition to the documentation > > on http://www.rpm.org/ ? Do you have any quick pointers? Thanks > > again. > > Although my source rpms do support cross compile, FYI, all my > mips/mipsel rpms are cross compiled from ia32 machines, the > unpatched rpm, that is /bin/rpm, doesn't support cross compile. > In my RedHat 7.1, there are i386 rpm binaries which support > cross compile. I have a setup to cross build rpms to mips/mipsel. > Make sure your rpm sees > > %__ar %{_target_prefix}-linux-ar > %__as %{_target_prefix}-linux-as > %__cc %{_target_prefix}-linux-gcc > %__cxx %{_target_prefix}-linux-c++ > %__ld %{_target_prefix}-linux-ld > %__nm %{_target_prefix}-linux-nm > %__objcopy %{_target_prefix}-linux-objcopy > %__objdump %{_target_prefix}-linux-objdump > %__ranlib %{_target_prefix}-linux-ranlib > %__strip %{_target_prefix}-linux-strip > How do I do that ? > > and do > > # rpm --target=mips --define '_target_prefix mips' > > or > > # rpm --target=mipsel --define '_target_prefix mipsel' > > BTW, you alao need to rebuild binutils with > > # rpm --define 'ENABLE_ALL_TARGETS 1' -ta binutils-2.11.90.0.23.tar.gz > > H.J. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 18 00:18:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I7Ip008074 for linux-mips-outgoing; Wed, 18 Jul 2001 00:18:51 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I7InV08068 for ; Wed, 18 Jul 2001 00:18:49 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA03094; Wed, 18 Jul 2001 09:18:10 +0200 (MET DST) Date: Wed, 18 Jul 2001 09:18:10 +0200 (MEST) From: Geert Uytterhoeven To: James Simmons cc: Fuxin Zhang , "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1216 Lines: 31 On Tue, 17 Jul 2001, James Simmons wrote: > > First I try the vga16 frame buffer driver,but i can only get > > some black/white strips on the screen.(after made some changes > > to the source,most important one is use pci to find and set the > > vbase address). > > It is hardwired into the vga16fb driver the memory region (0xA000). This > is very wrong on non intel platforms. So that drivers pretty much doesn't > work on anything else. Does your firmware initialize the VGA card to VGA text mode? Vga16fb requires this initialization, which is normally done by the VGA BIOS. An x86 BIOS-emulator may be your friend. > > Then I try to use vesa driver. This one use some vgabios code > > I commented out the x86 relevant codes and made it compiled, > > The VESA framebuffer is also intel specific. It uses the BIOS to setup the > video mode. This is done long before the cpu is placed into protect mode. Similar issue here. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Wed Jul 18 00:35:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I7Z3v09140 for linux-mips-outgoing; Wed, 18 Jul 2001 00:35:03 -0700 Received: from chakotay.allgaeu.org (chakotay.allgaeu.org [213.182.8.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I7Z1V09134 for ; Wed, 18 Jul 2001 00:35:01 -0700 Received: from tuvok.allgaeu.org (tuvok.allgaeu.org [213.182.8.4]) by chakotay.allgaeu.org (8.9.3/8.9.3) with ESMTP id JAA20313 for ; Wed, 18 Jul 2001 09:34:59 +0200 Received: by tuvok.allgaeu.org (Postfix, from userid 1000) id CC54E31C; Wed, 18 Jul 2001 09:34:58 +0200 (CEST) Date: Wed, 18 Jul 2001 09:34:58 +0200 From: Robert Einsle To: linux-mips@oss.sgi.com Subject: Booting an SGI Indy from Harddisk Message-ID: <20010718093458.A27749@tuvok.allgaeu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 654 Lines: 22 Hy all I've a little Problem booting an SGI Indy from Harddisk. There is Linux Debian installen, and i made with dvhtool an korrekt Startfile. While starting, the indy loads the Kernel, and boots. But then, it mounts my root-Partition from the remote Server where i had the install-Partition. How can I tell the Indy to boot from /dev/sda1 I think i must set an StartOS ... but i dont knew what, and i don't knew where to search. TNX for help. -- MFG Robert Einsle BNA Technik, Postmaster >>Warum muss ich bei "Verwaltung von Problemloesungen fuer eine EDV-Abteilung" an einen Waffenschrank denken?<< (Robin S. Socha in de.comp.os.unix.linux.misc) From owner-linux-mips@oss.sgi.com Wed Jul 18 02:05:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I95bq15318 for linux-mips-outgoing; Wed, 18 Jul 2001 02:05:37 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I95ZV15313 for ; Wed, 18 Jul 2001 02:05:35 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15MnGp-0003ZD-00; Wed, 18 Jul 2001 11:05:27 +0200 Date: Wed, 18 Jul 2001 11:05:27 +0200 From: Guido Guenther To: Robert Einsle Cc: linux-mips@oss.sgi.com Subject: Re: Booting an SGI Indy from Harddisk Message-ID: <20010718110527.B13569@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Robert Einsle , linux-mips@oss.sgi.com References: <20010718093458.A27749@tuvok.allgaeu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718093458.A27749@tuvok.allgaeu.org>; from robert@einsle.de on Wed, Jul 18, 2001 at 09:34:58AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 629 Lines: 15 On Wed, Jul 18, 2001 at 09:34:58AM +0200, Robert Einsle wrote: > Hy all > > I've a little Problem booting an SGI Indy from Harddisk. > There is Linux Debian installen, and i made with dvhtool > an korrekt Startfile. > While starting, the indy loads the Kernel, and boots. > But then, it mounts my root-Partition from the remote > Server where i had the install-Partition. > How can I tell the Indy to boot from /dev/sda1 > I think i must set an StartOS ... but i dont knew > what, and i don't knew where to search. > TNX for help. http://honk.physik.uni-konstanz.de/linux-mips/indy-boot/indy-hd-boot-micro-howto.html -- Guido From owner-linux-mips@oss.sgi.com Wed Jul 18 02:19:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6I9JLR16289 for linux-mips-outgoing; Wed, 18 Jul 2001 02:19:21 -0700 Received: from storm.physik.tu-cottbus.de (storm.physik.TU-Cottbus.De [141.43.75.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6I9JCV16279 for ; Wed, 18 Jul 2001 02:19:12 -0700 Received: by storm.physik.tu-cottbus.de (Postfix, from userid 7215) id D46F36004D; Wed, 18 Jul 2001 11:19:07 +0200 (CEST) Date: Wed, 18 Jul 2001 11:19:07 +0200 To: linux-mips@oss.sgi.com Subject: kernel did not compile Message-ID: <20010718111907.A29667@physik.tu-cottbus.de> Mail-Followup-To: heinold@physik.tu-cottbus.de, linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline User-Agent: Mutt/1.3.18i From: heinold@physik.tu-cottbus.de (H.Heinold) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13346 Lines: 606 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I tried to compile a kernel from the yesterday cvs for an indy, with msdosfilesystem support. I got the following errors. make[3]: Leaving directory `/usr/src/linux/arch/mips/lib' make[2]: Leaving directory `/usr/src/linux/arch/mips/lib' sed -e 's/@@LOADADDR@@/0x88002000/' arch/mips/ld.script ld -G 0 -static -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o arch/mips/sgi/kernel/ip22-kern.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sgi/sgi.a drivers/video/video.o \ net/network.o \ arch/mips/lib/lib.a /usr/src/linux/lib/lib.a arch/mips/arc/arclib.a \ --end-group \ -o vmlinux fs/fs.o: In function `fat_read_super': inode.c(.text+0x3a980): undefined reference to `generic_ffs' inode.c(.text+0x3ac0c): undefined reference to `generic_ffs' inode.c(.text+0x3adcc): undefined reference to `generic_ffs' make[1]: *** [vmlinux] Error 1 Attached is the config-file. -- Henning Heinold --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=config-indy # # Automatically generated make config: don't edit # CONFIG_MIPS=y # CONFIG_SMP is not set # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Machine selection # # CONFIG_ACER_PICA_61 is not set # CONFIG_ALGOR_P4032 is not set # CONFIG_BAGET_MIPS is not set # CONFIG_DECSTATION is not set # CONFIG_DDB5074 is not set # CONFIG_MIPS_EV96100 is not set # CONFIG_MIPS_EV64120 is not set # CONFIG_MIPS_ATLAS is not set # CONFIG_MIPS_MALTA is not set # CONFIG_NINO is not set # CONFIG_MIPS_MAGNUM_4000 is not set # CONFIG_MOMENCO_OCELOT is not set # CONFIG_DDB5476 is not set # CONFIG_DDB5477 is not set # CONFIG_OLIVETTI_M700 is not set CONFIG_SGI_IP22=y # CONFIG_SNI_RM200_PCI is not set # CONFIG_MIPS_ITE8172 is not set # CONFIG_MIPS_IVR is not set # CONFIG_MIPS_PB1000 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_MCA is not set # CONFIG_SBUS is not set CONFIG_ARC32=y CONFIG_BOARD_SCACHE=y CONFIG_PC_KEYB=y CONFIG_SGI=y CONFIG_NEW_IRQ=y CONFIG_OLD_TIME_C=y # CONFIG_ISA is not set # CONFIG_EISA is not set # CONFIG_PCI is not set # CONFIG_I8259 is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # CPU selection # # CONFIG_CPU_R3000 is not set # CONFIG_CPU_R6000 is not set # CONFIG_CPU_R4300 is not set CONFIG_CPU_R4X00=y # CONFIG_CPU_R5000 is not set # CONFIG_CPU_R5432 is not set # CONFIG_CPU_RM7000 is not set # CONFIG_CPU_NEVADA is not set # CONFIG_CPU_R10000 is not set # CONFIG_CPU_SB1 is not set # CONFIG_CPU_MIPS32 is not set # CONFIG_CPU_ADVANCED is not set CONFIG_CPU_HAS_LLSC=y CONFIG_CPU_HAS_LLDSCD=y # CONFIG_CPU_HAS_WB is not set # # General setup # # CONFIG_CPU_LITTLE_ENDIAN is not set CONFIG_KCORE_ELF=y CONFIG_ELF_KERNEL=y CONFIG_BINFMT_IRIX=y CONFIG_FORWARD_KEYBOARD=y CONFIG_ARC_CONSOLE=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_NET=y # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 # CONFIG_CHR_DEV_SG is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_DEBUG_QUEUES is not set # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # CONFIG_SGIWD93_SCSI=y # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_DEBUG is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set CONFIG_SGISEEQ=y # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_SERIAL is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_MOUSE is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # SGI Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_SGI_NEWPORT_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_PSMOUSE is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # File systems # # CONFIG_QUOTA is not set CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_UMSDOS_FS=y # CONFIG_VFAT_FS is not set CONFIG_EFS_FS=y # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_TMPFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_MINIX_FS=y # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_ROOT_NFS=y # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # # CONFIG_VGA_CONSOLE is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # # CONFIG_SOUND is not set # # SGI devices # CONFIG_SGI_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_SGI_DS1286=y # CONFIG_SGI_NEWPORT_GFX is not set # # USB support # # CONFIG_USB is not set # # Input core support # # CONFIG_INPUT is not set # # Kernel hacking # # CONFIG_CROSSCOMPILE is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_MIPS_UNCACHED is not set --dDRMvlgZJXvWKvBx-- From owner-linux-mips@oss.sgi.com Wed Jul 18 04:54:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IBsQ129658 for linux-mips-outgoing; Wed, 18 Jul 2001 04:54:26 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IBsOV29655 for ; Wed, 18 Jul 2001 04:54:24 -0700 Message-Id: <200107181154.f6IBsOV29655@oss.sgi.com> Received: (qmail 9952 invoked from network); 18 Jul 2001 11:48:38 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 18 Jul 2001 11:48:38 -0000 Date: Wed, 18 Jul 2001 19:53:48 +0800 From: Fuxin Zhang To: Geert Uytterhoeven CC: "linux-mips@oss.sgi.com" Subject: Re: Re: help on linux-mipsel frame buffer X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6IBsPV29656 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1482 Lines: 39 hello,Geert Uytterhoeven£¡ 2001-07-18 09:18:00£º >On Tue, 17 Jul 2001, James Simmons wrote: >> > First I try the vga16 frame buffer driver,but i can only get >> > some black/white strips on the screen.(after made some changes >> > to the source,most important one is use pci to find and set the >> > vbase address). >> >> It is hardwired into the vga16fb driver the memory region (0xA000). This >> is very wrong on non intel platforms. So that drivers pretty much doesn't >> work on anything else. > >Does your firmware initialize the VGA card to VGA text mode? Vga16fb requires >this initialization, which is normally done by the VGA BIOS. An x86 >BIOS-emulator may be your friend. Cound you give me a link to such a emulator?My firmware doesn't initialize VGA card.That seems the real problem. Thank you. > >> > Then I try to use vesa driver. This one use some vgabios code >> > I commented out the x86 relevant codes and made it compiled, >> >> The VESA framebuffer is also intel specific. It uses the BIOS to setup the >> video mode. This is done long before the cpu is placed into protect mode. > >Similar issue here. > >Gr{oetje,eeting}s, > > Geert > >-- >Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) >Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 >Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Wed Jul 18 05:18:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ICIwI32053 for linux-mips-outgoing; Wed, 18 Jul 2001 05:18:58 -0700 Received: from t111.niisi.ras.ru (IDENT:root@t111.niisi.ras.ru [193.232.173.111]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ICIsV32048 for ; Wed, 18 Jul 2001 05:18:55 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id QAA22696 for ; Wed, 18 Jul 2001 16:19:24 +0400 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id QAA01257 for linux-mips@oss.sgi.com; Wed, 18 Jul 2001 16:16: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 QAA29667 for ; Wed, 18 Jul 2001 16:06:39 +0400 (MSD) Message-ID: <3B557BF3.22C43175@niisi.msk.ru> Date: Wed, 18 Jul 2001 16:07:15 +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: linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Content-Type: multipart/mixed; boundary="------------7241F4AE3BBCA1C849A25667" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4056 Lines: 115 This is a multi-part message in MIME format. --------------7241F4AE3BBCA1C849A25667 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hello, "H . J . Lu" wrote: > The next thing on my todo list is to cross compile XFree86 :-(. > It has been done already for Xserver only. I use to cross-compile FBDev XServer for a long time. My host.def is attached here for reference. In order to cross-compile entire XFree86 cleanly you need to patch config/util/Imakefile first, it's primary source of problems during cross-compilation. It may be just workarounded though, if you don't pretend to be perfectionist. Regards, Gleb. --------------7241F4AE3BBCA1C849A25667 Content-Type: image/x-xbitmap; name="host.def" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="host.def" #define BuildServersOnly YES /* #define DoLoadableServer NO */ /* Servers never be needed */ #define XprtServer NO #define XVirtualFramebufferServer NO #define XnestServer NO #define BuildFontServer NO #define BuildFonts NO #define SharedLibFont NO #define NormalLibFont YES /* HW stuff */ #define XF86CardDrivers fbdev #define XInputDrivers mouse void #define XF86FBDevHw YES #define XF24_32Bpp YES /* May be needed */ #define BuildXIE NO #define XF86XAA NO /* #define BuildXF86MiscExt YES */ /* Never be needed */ #define BuildScreenSaverExt NO #define BuildPexExt NO #define BuildGLXLibrary NO #define BuildGlxExt NO #define XF86Ramdac NO #define XF86Int10 NO #define XF86INT10_BUILD X86INT10_STUB #define UseX86Emu NO /* Definitions for cross compilation */ #define MipsArchitecture #define __mips #undef i386Architecture #undef SparcArchitecture #define OSName Linux 2.2.1 mips [ELF] #define OSMajorVersion 2 #define OSMinorVersion 2 #define OSTeenyVersion 1 #define LinuxCLibMajorVersion 6 #define LinuxCLibMinorVersion 0 #define LinuxCLibTeenyVersion 6 #define LinuxBinUtilsMajorVersion 28 #define CcCmd mips-linux-gcc -g #define AsCmd mips-linux-gcc -c -x assembler-with-cpp -g #define LdCmd mips-linux-ld -g #define ArCmdBase mips-linux-ar #define RanlibCmd mips-linux-ranlib #define CrossCompiling YES #define ComplexHostProgramTarget(program) @@\ CC=cc @@\ STD_INCLUDES= @@\ CFLAGS=$(TOP_INCLUDES) $(INCLUDES) $(BOOTSTRAPCFLAGS) @@\ EXTRA_LOAD_FLAGS= @@\ PROGRAM = program @@\ @@\ AllTarget(program) @@\ @@\ program: $(OBJS) $(DEPLIBS) @@\ RemoveTargetProgram($@) @@\ HostLinkRule($@,$(_NOOP_),$(OBJS),$(DEPLIBS) $(LOCAL_LIBRARIES)) @@\ @@\ DependTarget() @@\ @@\ LintTarget() @@\ @@\ clean:: @@\ RemoveFile(ProgramTargetName(program)) #define SimpleHostProgramTarget(program) @@\ OBJS = program.o @@\ SRCS = program.c @@\ @@\ ComplexHostProgramTarget(program) #define HostLinkRule(target, flags, src, libs) gcc -o target flags src libs $(EXTRA_LOAD_FLAGS) --------------7241F4AE3BBCA1C849A25667-- From owner-linux-mips@oss.sgi.com Wed Jul 18 05:37:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ICbpT01365 for linux-mips-outgoing; Wed, 18 Jul 2001 05:37:51 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ICbnV01361 for ; Wed, 18 Jul 2001 05:37:50 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA18560; Wed, 18 Jul 2001 14:37:43 +0200 (MET DST) Date: Wed, 18 Jul 2001 14:37:43 +0200 (MEST) From: Geert Uytterhoeven To: Fuxin Zhang cc: "linux-mips@oss.sgi.com" Subject: Re: Re: help on linux-mipsel frame buffer In-Reply-To: <200107181154.NAA16473@mail.sonytel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.sonytel.be id OAA18560 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6ICbpV01363 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1171 Lines: 28 On Wed, 18 Jul 2001, Fuxin Zhang wrote: > 2001-07-18 09:18:00£º > >On Tue, 17 Jul 2001, James Simmons wrote: > >> > First I try the vga16 frame buffer driver,but i can only get > >> > some black/white strips on the screen.(after made some changes > >> > to the source,most important one is use pci to find and set the > >> > vbase address). > >> > >> It is hardwired into the vga16fb driver the memory region (0xA000). This > >> is very wrong on non intel platforms. So that drivers pretty much doesn't > >> work on anything else. > > > >Does your firmware initialize the VGA card to VGA text mode? Vga16fb requires > >this initialization, which is normally done by the VGA BIOS. An x86 > >BIOS-emulator may be your friend. > Cound you give me a link to such a emulator?My firmware doesn't initialize VGA card.That seems the real problem. I don't know whether it exists for Linux/MIPS yet. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Wed Jul 18 06:29:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IDT1i06301 for linux-mips-outgoing; Wed, 18 Jul 2001 06:29:01 -0700 Received: from dea.waldorf-gmbh.de (u-132-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.132]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IDSuV06283 for ; Wed, 18 Jul 2001 06:28:56 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6IDQVS01847; Wed, 18 Jul 2001 15:26:31 +0200 Date: Wed, 18 Jul 2001 15:26:31 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "H . J . Lu" , Jun Sun , vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010718152631.A1809@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 913 Lines: 21 On Wed, Jul 18, 2001 at 09:13:20AM +0200, Carsten Langgaard wrote: > It look like there is a cross dependence, the build of tcsh failed with the > following message: > > /var/tmp/rpm-tmp.7250: /usr/bin/perl: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.7250 (pbuild) > > So tcsh is needed to build perl and perl is needed to build tcsh :-( One of the reasons why I believe that the major Linux distributions are fundamentally flawed - their build process doesn't account for such dependencies. Point for BSD. The escape from this circular dependency is to build those packages manually which may require cheating in the configure and build process a bit. Or install them from a binary package (which may require --nodeps and --force to install). General rule therefore should be to only do such distribution package builds on systems which have a maximum installation. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 18 06:31:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IDVSR06547 for linux-mips-outgoing; Wed, 18 Jul 2001 06:31:28 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IDVOV06540 for ; Wed, 18 Jul 2001 06:31:26 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1045 Lines: 22 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 owner-linux-mips@oss.sgi.com Wed Jul 18 08:11:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IFBWd14953 for linux-mips-outgoing; Wed, 18 Jul 2001 08:11:32 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IFBOV14934; Wed, 18 Jul 2001 08:11:24 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 20933125BC; Wed, 18 Jul 2001 08:11:22 -0700 (PDT) Date: Wed, 18 Jul 2001 08:11:22 -0700 From: "H . J . Lu" To: Carsten Langgaard Cc: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010718081122.A10848@lucon.org> References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> <20010717122902.B24048@lucon.org> <3B553710.8B7A4CDE@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B553710.8B7A4CDE@mips.com>; from carstenl@mips.com on Wed, Jul 18, 2001 at 09:13:20AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1136 Lines: 32 On Wed, Jul 18, 2001 at 09:13:20AM +0200, Carsten Langgaard wrote: > "H . J . Lu" wrote: > > > On Tue, Jul 17, 2001 at 09:16:05PM +0200, Carsten Langgaard wrote: > > > Could you add a Perl rpm to you distribution, this also seems to be needed to > > > build the RPMs natively. > > > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > > perl yourself. You may need to build/install the tcsh rpm first. > > It look like there is a cross dependence, the build of tcsh failed with the > following message: > > /var/tmp/rpm-tmp.7250: /usr/bin/perl: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.7250 (%build) > > So tcsh is needed to build perl and perl is needed to build tcsh :-( > It is ok since the tcsh binary has been built. Just install it to /bin/tcsh and build the perl rpm. You may have to # rpm --nodeps --force --rebuild perl-xxx.src.rpm You only have to do those the first time. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 18 08:25:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IFPOG16241 for linux-mips-outgoing; Wed, 18 Jul 2001 08:25:24 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IFPKV16237; Wed, 18 Jul 2001 08:25:20 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA22108; Wed, 18 Jul 2001 08:25:05 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id IAA19776; Wed, 18 Jul 2001 08:25:05 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6IFNua03029; Wed, 18 Jul 2001 17:23:56 +0200 (MEST) Message-ID: <3B55AA0B.42D212E@mips.com> Date: Wed, 18 Jul 2001 17:23:55 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "H . J . Lu" CC: Jun Sun , ralf@oss.sgi.com, vhouten@kpn.com, linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips References: <3B4573B8.9F89022B@mips.com> <3B4635FB.1ED5D222@mvista.com> <3B4AE384.52049D47@mips.com> <20010710103121.L19026@lucon.org> <3B52CF68.4687EBCB@mips.com> <20010716142802.A2757@lucon.org> <3B548EF5.993C271E@mips.com> <20010717122902.B24048@lucon.org> <3B553710.8B7A4CDE@mips.com> <20010718081122.A10848@lucon.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4949 Lines: 109 "H . J . Lu" wrote: > On Wed, Jul 18, 2001 at 09:13:20AM +0200, Carsten Langgaard wrote: > > "H . J . Lu" wrote: > > > > > On Tue, Jul 17, 2001 at 09:16:05PM +0200, Carsten Langgaard wrote: > > > > Could you add a Perl rpm to you distribution, this also seems to be needed to > > > > build the RPMs natively. > > > > > > Perl has to be built natively. I uploaded mysql-3.23.36-1.1.src.rpm, > > > perl-5.6.0-12.1.src.rpm, apache-1.3.19-5.src.rpm, > > > mod_perl-1.24_01-2.src.rpm, tcsh-6.10-5.src.rpm and > > > zsh-3.0.8-8.src.rpm. Just installed my RedHat 7.1. Then you can build > > > perl yourself. You may need to build/install the tcsh rpm first. > > > > It look like there is a cross dependence, the build of tcsh failed with the > > following message: > > > > /var/tmp/rpm-tmp.7250: /usr/bin/perl: No such file or directory > > error: Bad exit status from /var/tmp/rpm-tmp.7250 (%build) > > > > So tcsh is needed to build perl and perl is needed to build tcsh :-( > > > > It is ok since the tcsh binary has been built. Just install it to > /bin/tcsh and build the perl rpm. You may have to > > # rpm --nodeps --force --rebuild perl-xxx.src.rpm > > You only have to do those the first time. I got through the tcsh and perl build, but now it fails on glibc. make -s -j2 -C iconvdata others make[2]: Entering directory `/usr/src/redhat/BUILD/glibc-2.2.3/iconvdata' make[2]: warning: -jN forced in submake: disabling jobserver mode. In file included from 8bit-gap.c:33, from iso8859-15.c:28: /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: numeric constant with no digits /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: parse error before `nan' /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: numeric constant with no digits /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: parse error before `nan' /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:260: (near initialization for `from_idx[1].idx') /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:261: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:261: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:261: (near initialization for `from_idx[2].idx') /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:262: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:262: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:262: (near initialization for `from_idx[3].idx') /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:263: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:263: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:263: (near initialization for `from_idx[4].idx') /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:264: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:264: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:264: (near initialization for `from_idx[5].idx') /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:265: `nan' undeclared here (not in a function) /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:265: initializer element is not constant /usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.h:265: (near initialization for `from_idx[6].idx') make[2]: *** [/usr/src/redhat/BUILD/glibc-2.2.3/build-mipsel-linux/iconvdata/iso8859-15.os] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.2.3/iconvdata' make[1]: *** [iconvdata/others] Error 2 make[1]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.2.3' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.98017 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.98017 (%build) > > H.J. -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 18 09:36:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IGaal19813 for linux-mips-outgoing; Wed, 18 Jul 2001 09:36:36 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IGaZV19810 for ; Wed, 18 Jul 2001 09:36:35 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6IGaCdi015337; Wed, 18 Jul 2001 09:36:12 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6IGaBDO015333; Wed, 18 Jul 2001 09:36:12 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 18 Jul 2001 09:36:11 -0700 (PDT) From: James Simmons To: John Heil cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 317 Lines: 9 > Where can I find the Cobalt Qube2 buildable > mips kernel source to match the Qube2's kerel-2.0.34C53_SK, > if its still available? Hum. So you want the cobalt 2.0.34 source code? Okay I cross posted to the cobalt list since someone there will have the code. The cobalt tree has been updated to the 2.4.X BTW. From owner-linux-mips@oss.sgi.com Wed Jul 18 09:48:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IGmAG20175 for linux-mips-outgoing; Wed, 18 Jul 2001 09:48:10 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IGm9V20172 for ; Wed, 18 Jul 2001 09:48:09 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6IGm6473867 for ; Wed, 18 Jul 2001 17:48:06 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id RAA04208 for ; Wed, 18 Jul 2001 17:48:05 +0100 (BST) Message-ID: <011a01c10fa9$6abbd970$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "Linux-MIPS" Subject: ATI Victoria on Malta Date: Wed, 18 Jul 2001 17:48:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 387 Lines: 14 Has anyone managed to get the ATI Victoria graphics card working on the MIPS Malta development board with Linux? This is the card that MIPS specify for use with the Malta board with another OS (which I shall refrain from naming). There does seem to be some code for the ATI Rage XL hardware (as used on the card) in v2.4.6 of the kernel. Regards, Andrew Thornton Insignia Solutions From owner-linux-mips@oss.sgi.com Wed Jul 18 09:50:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IGotv20261 for linux-mips-outgoing; Wed, 18 Jul 2001 09:50:55 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IGosV20258 for ; Wed, 18 Jul 2001 09:50:54 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 5FD35125BC; Wed, 18 Jul 2001 09:50:53 -0700 (PDT) Date: Wed, 18 Jul 2001 09:50:53 -0700 From: "H . J . Lu" To: James Simmons Cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? Message-ID: <20010718095053.A12345@lucon.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 jsimmons@transvirtual.com on Wed, Jul 18, 2001 at 09:36:11AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 443 Lines: 14 On Wed, Jul 18, 2001 at 09:36:11AM -0700, James Simmons wrote: > > > Where can I find the Cobalt Qube2 buildable > > mips kernel source to match the Qube2's kerel-2.0.34C53_SK, > > if its still available? > > Hum. So you want the cobalt 2.0.34 source code? Okay I cross posted to the > cobalt list since someone there will have the code. The cobalt tree has > been updated to the 2.4.X BTW. Where can I get the cobalt kernel tree? H.J. From owner-linux-mips@oss.sgi.com Wed Jul 18 09:59:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IGx2k20546 for linux-mips-outgoing; Wed, 18 Jul 2001 09:59:02 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IGwwV20543; Wed, 18 Jul 2001 09:58:58 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id JAA03059; Wed, 18 Jul 2001 09:58:42 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15MuV8-0006SM-00; Wed, 18 Jul 2001 09:48:42 -0700 Date: Wed, 18 Jul 2001 09:48:42 -0700 From: Daniel Jacobowitz To: Ralf Baechle Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010718094841.A24612@nevyn.them.org> References: <20010718152631.A1809@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010718152631.A1809@bacchus.dhis.org>; from ralf@oss.sgi.com on Wed, Jul 18, 2001 at 03:26:31PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1707 Lines: 35 On Wed, Jul 18, 2001 at 03:26:31PM +0200, Ralf Baechle wrote: > On Wed, Jul 18, 2001 at 09:13:20AM +0200, Carsten Langgaard wrote: > > > It look like there is a cross dependence, the build of tcsh failed with the > > following message: > > > > /var/tmp/rpm-tmp.7250: /usr/bin/perl: No such file or directory > > error: Bad exit status from /var/tmp/rpm-tmp.7250 (pbuild) > > > > So tcsh is needed to build perl and perl is needed to build tcsh :-( > > One of the reasons why I believe that the major Linux distributions are > fundamentally flawed - their build process doesn't account for such > dependencies. Point for BSD. Debian has been going to great lengths to fix this. We're a great deal of the way along, too - to the point where bringing up our complete hppa and ia64 distributions (with the exception of a few platform-specific tool bugs and some gcc-3.0 incompatibilities) was really relatively painless for the vast majority of packages. Only a tiny subset of packages are assumed installed at build time if they aren't explicitly listed. > The escape from this circular dependency is to build those packages manually > which may require cheating in the configure and build process a bit. Or > install them from a binary package (which may require --nodeps and --force > to install). General rule therefore should be to only do such distribution > package builds on systems which have a maximum installation. Although I'm pretty sure that Debian's Perl package builds without the use of tcsh... I've no idea where this is coming from. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Wed Jul 18 10:06:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IH67B20721 for linux-mips-outgoing; Wed, 18 Jul 2001 10:06:07 -0700 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IH64V20718 for ; Wed, 18 Jul 2001 10:06:04 -0700 X-Envelope-Sender-Is: thomas.langer@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f6IH62211307 for ; Wed, 18 Jul 2001 19:06:02 +0200 (MET DST) Received: by mchb0b1w.muc.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 19:05:40 +0200 Message-ID: <57427888BDF5D4118BA40008C7286B3E097B7A@MCHB0FXA> From: thomas.langer@infineon.com To: linux-mips@oss.sgi.com Subject: Malta Board and PC Keyboard Date: Wed, 18 Jul 2001 19:05:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 421 Lines: 12 Has somebody already used a PC Keyboard with the Malta development Board? I have enabled the driver for the keyboard, but I get the bootmessage: initialize_kbd: Keyboard failed self test keyboard: Timeout - AT keyboard not present? Maybe a problem with the mapping from Intel-IO to mmio? I'm just starting development on MIPS and don't know where to search. (My Kernel is 2.4.3-MIPS-01.00 from ftp.mips.com) Thomas From owner-linux-mips@oss.sgi.com Wed Jul 18 11:58:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IIwxw23523 for linux-mips-outgoing; Wed, 18 Jul 2001 11:58:59 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IIwuV23519 for ; Wed, 18 Jul 2001 11:58:57 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6IIwhdi019849; Wed, 18 Jul 2001 11:58:43 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6IIwgx9019845; Wed, 18 Jul 2001 11:58:42 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 18 Jul 2001 11:58:42 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? In-Reply-To: <20010718095053.A12345@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 276 Lines: 9 > > Hum. So you want the cobalt 2.0.34 source code? Okay I cross posted to the > > cobalt list since someone there will have the code. The cobalt tree has > > been updated to the 2.4.X BTW. > > Where can I get the cobalt kernel tree? http://www.sf.net/projects/linux-mips From owner-linux-mips@oss.sgi.com Wed Jul 18 13:53:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IKrSX31703 for linux-mips-outgoing; Wed, 18 Jul 2001 13:53:28 -0700 Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IKrQV31699 for ; Wed, 18 Jul 2001 13:53:26 -0700 Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45]) by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA27139; Wed, 18 Jul 2001 22:53:22 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA07635; Wed, 18 Jul 2001 22:53:22 +0200 (CEST) Date: Wed, 18 Jul 2001 22:53:22 +0200 (CEST) From: Seth Mos To: linux-mips@oss.sgi.com cc: "H . J . Lu" Subject: Re: Updates on RedHat 7.1/mips In-Reply-To: <3B55AA0B.42D212E@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2127 Lines: 56 I am having trouble getting the mipsel packages installed using the installer provided for 7.1. I have hooked up a second disk to my i386 workstatition that will house the filesystem for my mipsel box. Once everything is installed I will put this disk back in my Qube2 for testing. In the worst case scenario I will need to boot with the 2.0 kernel that came with the cube. I have the original disk for the Qube2 so it isn't a big problem if it takes 50 attempts. I have a lot of patience ;-) Am I correct to assume that I need to use the install.i386.hd on my workstation to install the mipsel packages on the second harddrive (hdd in my case) I have tried this approach using both the Makefile approach and by running the install.i386.hd script. Traceback (innermost, last): File "./findrpm", line 5, in ? import rpm ImportError: No module named rpm Does this ring any bells? The mipsel packages are located in the RPMS directory which is in the same directory as the installer and I edited the Makefile and changed ROOT and REDHAT-ROOT I wonder if anyone can provide a basic root tarbal which I can use to set up the basics after which i can start adding stuff. If I get it into a decent state I will probably make a dump of the fs so other people with a Qube (1 or 2) can easily clone it. I was working to use a 2.4 kernel on a standard Qube but that was a big problem since 2.4 does not compile with the compiler that came with it and the glibc did not have large file support. A fs that I would like to put on the Qube is XFS which I already use on my own i386 home machines and production machines at work. Since XFS is also tested on mip64 Irix (IIRC) ai64 PPC ai32 and alpha under linux I expect that it will probably more work but it is more resilient and faster recovering after crashes. So if anyone can give advice on installing using the toolkit or provide a bootable dump image or root tarbal I would be most grateful. The qube2 comes with a boot loader that understands ext2 and loads the linux kernel it finds on the system it will probably make it easier to boot afterwards. Cheers Seth From owner-linux-mips@oss.sgi.com Wed Jul 18 15:11:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IMB3V06429 for linux-mips-outgoing; Wed, 18 Jul 2001 15:11:03 -0700 Received: from dea.waldorf-gmbh.de (u-79-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.79]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IMB0V06424 for ; Wed, 18 Jul 2001 15:11:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6IDZF801904; Wed, 18 Jul 2001 15:35:15 +0200 Date: Wed, 18 Jul 2001 15:35:15 +0200 From: Ralf Baechle To: John Heil Cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: Any old Cobalt Qube2 kernel src around? Message-ID: <20010718153515.B1533@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 mipsdev@scsoftware.sc-software.com on Tue, Jul 17, 2001 at 09:12:15PM +0000 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 392 Lines: 13 On Tue, Jul 17, 2001 at 09:12:15PM +0000, John Heil wrote: > Where can I find the Cobalt Qube2 buildable > mips kernel source to match the Qube2's kerel-2.0.34C53_SK, > if its still available? > > I went through the ftp.cobalt.com and found only > precompiled kernel and headers. As per GPL you have the right to get the sources from whoever gave you the binaries on your Qube. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 18 15:23:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IMNYN07506 for linux-mips-outgoing; Wed, 18 Jul 2001 15:23:34 -0700 Received: from dea.waldorf-gmbh.de (u-79-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.79]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IMNWV07499 for ; Wed, 18 Jul 2001 15:23:33 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6IMNNC01748; Thu, 19 Jul 2001 00:23:23 +0200 Date: Thu, 19 Jul 2001 00:23:22 +0200 From: Ralf Baechle To: Daniel Jacobowitz Cc: Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010719002322.C1669@bacchus.dhis.org> References: <20010718152631.A1809@bacchus.dhis.org> <20010718094841.A24612@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718094841.A24612@nevyn.them.org>; from drow@mvista.com on Wed, Jul 18, 2001 at 09:48:42AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 326 Lines: 9 On Wed, Jul 18, 2001 at 09:48:42AM -0700, Daniel Jacobowitz wrote: > Although I'm pretty sure that Debian's Perl package builds without the > use of tcsh... I've no idea where this is coming from. Anyway, Perl is calling csh internally for something but I forgot what it was; too long that I researched the details. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 18 15:34:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IMYfu08403 for linux-mips-outgoing; Wed, 18 Jul 2001 15:34:41 -0700 Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IMYcV08398 for ; Wed, 18 Jul 2001 15:34:38 -0700 Received: from agile.tv (IDENT:ldavies@tugun.oz.agile.tv [192.168.16.20]) by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f6IMYHa12783; Thu, 19 Jul 2001 08:34:17 +1000 Message-ID: <3B560EEA.499BBB70@agile.tv> Date: Thu, 19 Jul 2001 08:34:18 +1000 From: Liam Davies Reply-To: ldavies@oz.agile.tv Organization: AgileTV Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Heil CC: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 467 Lines: 22 It is available at ftp://ftp.cobaltnet.com/pub/experimental/SRPMS/kernel-2.0.34C53_SK-3.src.rpm or off the Cobalt-22 developers website as a tarball at ftp://devel.alal.com/pub/cobalt Cheers Liam John Heil wrote: > Where can I find the Cobalt Qube2 buildable > mips kernel source to match the Qube2's kerel-2.0.34C53_SK, > if its still available? > > I went through the ftp.cobalt.com and found only > precompiled kernel and headers. > > Thanks much > > John H. From owner-linux-mips@oss.sgi.com Wed Jul 18 16:07:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6IN7xR11672 for linux-mips-outgoing; Wed, 18 Jul 2001 16:07:59 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6IN7xV11669 for ; Wed, 18 Jul 2001 16:07:59 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 0338E125BC; Wed, 18 Jul 2001 16:07:57 -0700 (PDT) Date: Wed, 18 Jul 2001 16:07:57 -0700 From: "H . J . Lu" To: James Simmons Cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? Message-ID: <20010718160757.A19581@lucon.org> References: <20010718095053.A12345@lucon.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 jsimmons@transvirtual.com on Wed, Jul 18, 2001 at 11:58:42AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 495 Lines: 15 On Wed, Jul 18, 2001 at 11:58:42AM -0700, James Simmons wrote: > > > > Hum. So you want the cobalt 2.0.34 source code? Okay I cross posted to the > > > cobalt list since someone there will have the code. The cobalt tree has > > > been updated to the 2.4.X BTW. > > > > Where can I get the cobalt kernel tree? > > http://www.sf.net/projects/linux-mips How can I get a working 2.4 kernel for raq2 with serial console and NFS root? I tried that kernel with Linux 2.4.5. It doesn't work. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 18 17:36:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J0aBN20783 for linux-mips-outgoing; Wed, 18 Jul 2001 17:36:11 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J0aAV20780 for ; Wed, 18 Jul 2001 17:36:10 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 15E7F125BD; Wed, 18 Jul 2001 17:36:09 -0700 (PDT) Date: Wed, 18 Jul 2001 17:36:09 -0700 From: "H . J . Lu" To: Seth Mos Cc: linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010718173609.A21139@lucon.org> References: <3B55AA0B.42D212E@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from knuffie@xs4all.nl on Wed, Jul 18, 2001 at 10:53:22PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1469 Lines: 48 On Wed, Jul 18, 2001 at 10:53:22PM +0200, Seth Mos wrote: > > I am having trouble getting the mipsel packages installed using the > installer provided for 7.1. > > > I have hooked up a second disk to my i386 workstatition that will house > the filesystem for my mipsel box. Once everything is installed I will put > this disk back in my Qube2 for testing. In the worst case scenario I will > need to boot with the 2.0 kernel that came with the cube. > > I have the original disk for the Qube2 so it isn't a big problem if it > takes 50 attempts. I have a lot of patience ;-) > > Am I correct to assume that I need to use the install.i386.hd on my > workstation to install the mipsel packages on the second harddrive (hdd in > my case) No. It should be install.mipsel.nfs. install.mipsel.hd is for the native mipsel machine install. > > Traceback (innermost, last): > File "./findrpm", line 5, in ? > import rpm > ImportError: No module named rpm > > Does this ring any bells? You need to install the rpm-python rpm. > The mipsel packages are located in the RPMS directory which is in the same > directory as the installer and I edited the Makefile and changed ROOT and > REDHAT-ROOT Sure. > > I wonder if anyone can provide a basic root tarbal which I can use to set > up the basics after which i can start adding stuff. > install.mipsel.nfs is used to create a NFS root tree for mipsel. If you tar it up, you get what you are asking for. H.J. From owner-linux-mips@oss.sgi.com Wed Jul 18 19:55:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J2tHq24856 for linux-mips-outgoing; Wed, 18 Jul 2001 19:55:17 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J2tGV24853 for ; Wed, 18 Jul 2001 19:55:16 -0700 Received: from mvista.com (IDENT:ahennessy@penelope.mvista.com [10.0.0.122]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f6J1suW19457; Wed, 18 Jul 2001 18:54:56 -0700 Message-ID: <3B564CE7.2CF85A65@mvista.com> Date: Wed, 18 Jul 2001 19:58:47 -0700 From: Alice Hennessy X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com CC: ahennessy@mvista.com Subject: R3000 and kgdb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 888 Lines: 32 Has anyone used kgdb with an R3000 cpu? There was an obvious problem in gdb-low.S (patch below) but I still cannot get kgdb to work. Alice --- arch/mips/kernel/gdb-low.S.orig Wed Jul 18 18:47:57 2001 +++ arch/mips/kernel/gdb-low.S Wed Jul 18 17:52:21 2001 @@ -302,11 +302,18 @@ lw v1,GDB_FR_REG3(sp) lw v0,GDB_FR_REG2(sp) lw $1,GDB_FR_REG1(sp) +#if defined(CONFIG_CPU_R3000) + lw k0, GDB_FR_EPC(sp) + lw sp,GDB_FR_REG29(sp) /* Deallocate stack */ + jr k0 + rfe +#else lw sp,GDB_FR_REG29(sp) /* Deallocate stack */ .set mips3 eret .set mips0 +#endif .set at .set reorder END(trap_low) From owner-linux-mips@oss.sgi.com Wed Jul 18 20:01:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J31dE25041 for linux-mips-outgoing; Wed, 18 Jul 2001 20:01:39 -0700 Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J31bV25033 for ; Wed, 18 Jul 2001 20:01:37 -0700 Message-ID: <20010719030136.63012.qmail@web13905.mail.yahoo.com> Received: from [61.133.136.72] by web13905.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 20:01:36 PDT Date: Wed, 18 Jul 2001 20:01:36 -0700 (PDT) From: Barry Wu Subject: about mipsel linux thread problem To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 685 Lines: 24 Hi, all, I just port mipsel linux 2.2.12 to our mips evaluation board, and I use glibc-2.0.6-5l and linuxthread 0.7. But when I run linuxthread application on it. The application reports "Bus error". I add some print information in linuxthreads source code, and find that when call linuxthreads/restart.h suspend() function, the application will Bus error. I do not know which glibc and linuxthreads version can support mips linux well. And I do not know what the problem I meet is. If someone knows, please help me! Thanks! Barry __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Wed Jul 18 21:09:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J49uf28203 for linux-mips-outgoing; Wed, 18 Jul 2001 21:09:56 -0700 Received: from b0rked.dhs.org (postfix@b0rked.dhs.org [216.99.196.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J49sV28199 for ; Wed, 18 Jul 2001 21:09:54 -0700 Received: by b0rked.dhs.org (Postfix, from userid 500) id 7B9EF21EE; Wed, 18 Jul 2001 21:09:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by b0rked.dhs.org (Postfix) with ESMTP id 7759621ED; Wed, 18 Jul 2001 21:09:42 -0700 (PDT) Date: Wed, 18 Jul 2001 21:09:42 -0700 (PDT) From: Chris Vandomelen To: , Subject: Patches to support 48M IBM Workpad z50? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 772 Lines: 24 Since I can't seem to find any information about this anywhere else, I figured this would be the appropriate place to ask. I'm using a moderately hacked 2.4.0-test9 kernel from the linux-vr repository (the only complete kernel, excluding NetBSD, that I've found which runs on CE devices at the moment), and it doesn't want to recognize all 48M of RAM in the device, only the 1st 16. The memory is mapped as such: 0M - 16M: On-board memory 16M - 32M: Unmapped region 32M - 64M: Memory expansion card When the first 16M is checked, the memory immediately after that is found to be non-existant. Does anyone have a patch (other than the hack I tossed together to turn the 32M-64M chunk into an MTD device) that would be useful to work past the memory hole? TIA Chris From owner-linux-mips@oss.sgi.com Thu Jul 19 02:26:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6J9QUh08810 for linux-mips-outgoing; Thu, 19 Jul 2001 02:26:30 -0700 Received: from dea.waldorf-gmbh.de (u-243-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.243]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6J9QRV08806 for ; Thu, 19 Jul 2001 02:26:27 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Thu Jul 19 03:25:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JAPvE11592 for linux-mips-outgoing; Thu, 19 Jul 2001 03:25:57 -0700 Received: from dea.waldorf-gmbh.de (u-233-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JAPrV11584 for ; Thu, 19 Jul 2001 03:25:54 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6JANPn04429; Thu, 19 Jul 2001 12:23:25 +0200 Date: Thu, 19 Jul 2001 12:23:24 +0200 From: Ralf Baechle To: Barry Wu Cc: linux-mips@oss.sgi.com Subject: Re: about mipsel linux thread problem Message-ID: <20010719122324.B2422@bacchus.dhis.org> References: <20010719030136.63012.qmail@web13905.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010719030136.63012.qmail@web13905.mail.yahoo.com>; from wqb123@yahoo.com on Wed, Jul 18, 2001 at 08:01:36PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 733 Lines: 19 On Wed, Jul 18, 2001 at 08:01:36PM -0700, Barry Wu wrote: > I just port mipsel linux 2.2.12 to our mips evaluation > board, and I use glibc-2.0.6-5l and linuxthread 0.7. > But when I run linuxthread application on it. > The application reports "Bus error". > I add some print information in linuxthreads source > code, and find that when call > linuxthreads/restart.h suspend() function, the > application will Bus error. > I do not know which glibc and linuxthreads version > can support mips linux well. And I do not know what > the problem I meet is. Please upgrade to glibc 2.2.x which will work much better. Linuxthreads is known to be broken with glibc 2.0 and nobody here intends to fix it as glibc 2.0 is so old. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 19 03:26:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JAQCU11662 for linux-mips-outgoing; Thu, 19 Jul 2001 03:26:12 -0700 Received: from dea.waldorf-gmbh.de (u-233-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JAQ9V11650 for ; Thu, 19 Jul 2001 03:26:09 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6JALEM04420; Thu, 19 Jul 2001 12:21:14 +0200 Date: Thu, 19 Jul 2001 12:21:14 +0200 From: Ralf Baechle To: Chris Vandomelen Cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: Patches to support 48M IBM Workpad z50? Message-ID: <20010719122113.A2422@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 chrisv@b0rked.dhs.org on Wed, Jul 18, 2001 at 09:09:42PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1320 Lines: 35 On Wed, Jul 18, 2001 at 09:09:42PM -0700, Chris Vandomelen wrote: > Since I can't seem to find any information about this anywhere else, I > figured this would be the appropriate place to ask. > > I'm using a moderately hacked 2.4.0-test9 kernel from the linux-vr > repository (the only complete kernel, excluding NetBSD, that I've found > which runs on CE devices at the moment), and it doesn't want to recognize > all 48M of RAM in the device, only the 1st 16. The memory is mapped as > such: > > 0M - 16M: On-board memory > 16M - 32M: Unmapped region > 32M - 64M: Memory expansion card > > When the first 16M is checked, the memory immediately after that is found > to be non-existant. > > Does anyone have a patch (other than the hack I tossed together to turn > the 32M-64M chunk into an MTD device) Now that hack took longer to implement than a proper solution ... > that would be useful to work past the memory hole? Put something like the following into your systems prom_meminit: add_memory_region(0UL , 16UL << 20, BOOT_MEM_RAM); add_memory_region(16UL , 16UL << 20, BOOT_MEM_RESERVED); add_memory_region(32UL << 20, 32UL << 20, BOOT_MEM_RAM); You may want to account for additional memory areas and do a proper detection etc., exclude area which are used by the firmware etc. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 19 03:30:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JAUDL11942 for linux-mips-outgoing; Thu, 19 Jul 2001 03:30:13 -0700 Received: from b0rked.dhs.org (postfix@b0rked.dhs.org [216.99.196.11]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JAUAV11939; Thu, 19 Jul 2001 03:30:10 -0700 Received: by b0rked.dhs.org (Postfix, from userid 500) id 95E7C1DC5; Thu, 19 Jul 2001 03:30:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by b0rked.dhs.org (Postfix) with ESMTP id 91A9E1DC0; Thu, 19 Jul 2001 03:30:08 -0700 (PDT) Date: Thu, 19 Jul 2001 03:30:08 -0700 (PDT) From: Chris Vandomelen To: Ralf Baechle Cc: , Subject: Re: Patches to support 48M IBM Workpad z50? In-Reply-To: <20010719122113.A2422@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 963 Lines: 26 > Now that hack took longer to implement than a proper solution ... Yeah, that hack did take longer to implement than a proper solution. But it was what I could come up with at the time, as I haven't gone digging that far down into the kernel sources yet (and unfortunately, the prom.c source wasn't very helpful either. > > that would be useful to work past the memory hole? > > Put something like the following into your systems prom_meminit: > > add_memory_region(0UL , 16UL << 20, BOOT_MEM_RAM); > add_memory_region(16UL , 16UL << 20, BOOT_MEM_RESERVED); > add_memory_region(32UL << 20, 32UL << 20, BOOT_MEM_RAM); > > You may want to account for additional memory areas and do a proper detection > etc., exclude area which are used by the firmware etc. I'm pretty sure that 16M region in the 16-32M area is unused: it's possible to solder another 2 8M dram chips on the board and increase the memory to 64M.. Thanks for the help. :) Chris From owner-linux-mips@oss.sgi.com Thu Jul 19 03:35:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JAZDt12268 for linux-mips-outgoing; Thu, 19 Jul 2001 03:35:13 -0700 Received: from dea.waldorf-gmbh.de (u-233-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.233]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JAZAV12263 for ; Thu, 19 Jul 2001 03:35:11 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6JAZ2g04529; Thu, 19 Jul 2001 12:35:02 +0200 Date: Thu, 19 Jul 2001 12:35:02 +0200 From: Ralf Baechle To: Alice Hennessy Cc: linux-mips@oss.sgi.com Subject: Re: R3000 and kgdb Message-ID: <20010719123502.A4434@bacchus.dhis.org> References: <3B564CE7.2CF85A65@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: <3B564CE7.2CF85A65@mvista.com>; from ahennessy@mvista.com on Wed, Jul 18, 2001 at 07:58:47PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 480 Lines: 14 Alice, On Wed, Jul 18, 2001 at 07:58:47PM -0700, Alice Hennessy wrote: > Has anyone used kgdb with an R3000 cpu? There was an obvious problem > in gdb-low.S (patch below) but I still cannot get kgdb to work. Your patch looks good, so I've applied it. In the future please do not send patches using Netscape; it garbles patches such that they can only applied manually which would force me to refuse any larger patch. Some MUA like Mutt or Pine won't trash patches. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 19 04:35:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JBZdp15678 for linux-mips-outgoing; Thu, 19 Jul 2001 04:35:39 -0700 Received: from dea.waldorf-gmbh.de (u-46-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JBZYV15616 for ; Thu, 19 Jul 2001 04:35:34 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6JBWkt15812; Thu, 19 Jul 2001 13:32:46 +0200 Date: Thu, 19 Jul 2001 13:32:46 +0200 From: Ralf Baechle To: thomas.langer@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: Malta Board and PC Keyboard Message-ID: <20010719133246.B4434@bacchus.dhis.org> References: <57427888BDF5D4118BA40008C7286B3E097B7A@MCHB0FXA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <57427888BDF5D4118BA40008C7286B3E097B7A@MCHB0FXA>; from thomas.langer@infineon.com on Wed, Jul 18, 2001 at 07:05:54PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1617 Lines: 51 On Wed, Jul 18, 2001 at 07:05:54PM +0200, thomas.langer@infineon.com wrote: > Has somebody already used a PC Keyboard with the Malta development Board? > I have enabled the driver for the keyboard, but I get the bootmessage: > initialize_kbd: Keyboard failed self test > keyboard: Timeout - AT keyboard not present? > > Maybe a problem with the mapping from Intel-IO to mmio? > I'm just starting development on MIPS and don't know where to search. > > (My Kernel is 2.4.3-MIPS-01.00 from ftp.mips.com) Malta kernels don't have a complete keyboard driver. The small bits that are necessary to access the keyboard's I/O register are missing. Please try the (untested) patch below and tell me if it fixes kbd and PS/2 mouse for you. Ralf Index: arch/mips/mips-boards/malta/malta_setup.c =================================================================== RCS file: /home/pub/cvs/linux/arch/mips/mips-boards/malta/malta_setup.c,v retrieving revision 1.6 diff -u -r1.6 malta_setup.c --- arch/mips/mips-boards/malta/malta_setup.c 2001/07/11 23:55:41 1.6 +++ arch/mips/mips-boards/malta/malta_setup.c 2001/07/19 11:28:22 @@ -49,13 +49,10 @@ static int remote_debug = 0; #endif -#ifdef CONFIG_BLK_DEV_IDE extern struct ide_ops std_ide_ops; -#endif -#ifdef CONFIG_BLK_DEV_FD extern struct fd_ops std_fd_ops; -#endif extern struct rtc_ops malta_rtc_ops; +extern struct kbd_ops std_kbd_ops; extern void mips_reboot_setup(void); @@ -130,6 +127,9 @@ #endif #ifdef CONFIG_BLK_DEV_FD fd_ops = &std_fd_ops; +#endif +#ifdef CONFIG_PC_KEYB + kbd_ops = &std_kbd_ops; #endif mips_reboot_setup(); } From owner-linux-mips@oss.sgi.com Thu Jul 19 05:54:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JCs1007158 for linux-mips-outgoing; Thu, 19 Jul 2001 05:54:01 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JCroV07108; Thu, 19 Jul 2001 05:53:53 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1052 Lines: 22 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 owner-linux-mips@oss.sgi.com Thu Jul 19 07:14:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JEEwp25367 for linux-mips-outgoing; Thu, 19 Jul 2001 07:14:58 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JEEgV25359; Thu, 19 Jul 2001 07:14:42 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 9B8AB7F3; Thu, 19 Jul 2001 16:14:40 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 594594626; Thu, 19 Jul 2001 15:29:50 +0200 (CEST) Date: Thu, 19 Jul 2001 15:29:50 +0200 From: Florian Lohoff To: Ralf Baechle Cc: Daniel Jacobowitz , Carsten Langgaard , linux-mips@oss.sgi.com Subject: Re: Updates on RedHat 7.1/mips Message-ID: <20010719152950.C2543@paradigm.rfc822.org> References: <20010718152631.A1809@bacchus.dhis.org> <20010718094841.A24612@nevyn.them.org> <20010719002322.C1669@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: <20010719002322.C1669@bacchus.dhis.org>; from ralf@oss.sgi.com on Thu, Jul 19, 2001 at 12:23:22AM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 589 Lines: 16 On Thu, Jul 19, 2001 at 12:23:22AM +0200, Ralf Baechle wrote: > On Wed, Jul 18, 2001 at 09:48:42AM -0700, Daniel Jacobowitz wrote: > > > Although I'm pretty sure that Debian's Perl package builds without the > > use of tcsh... I've no idea where this is coming from. > > Anyway, Perl is calling csh internally for something but I forgot what it > was; too long that I researched the details. For path globbing perl uses csh or tcsh Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Thu Jul 19 10:24:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JHOTx14528 for linux-mips-outgoing; Thu, 19 Jul 2001 10:24:29 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JHOSV14519 for ; Thu, 19 Jul 2001 10:24:28 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6JHNfc1023220; Thu, 19 Jul 2001 10:23:41 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6JHNEtc023164; Thu, 19 Jul 2001 10:23:39 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 19 Jul 2001 10:23:13 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? In-Reply-To: <20010718160757.A19581@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 187 Lines: 7 > How can I get a working 2.4 kernel for raq2 with serial console and > NFS root? I tried that kernel with Linux 2.4.5. It doesn't work. Can you tell me what happens so I can fix it. From owner-linux-mips@oss.sgi.com Thu Jul 19 10:26:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JHQJQ15044 for linux-mips-outgoing; Thu, 19 Jul 2001 10:26:19 -0700 Received: from chakotay.allgaeu.org (chakotay.allgaeu.org [213.182.8.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JHQHV15041 for ; Thu, 19 Jul 2001 10:26:18 -0700 Received: from tuvok.allgaeu.org (tuvok.allgaeu.org [213.182.8.4]) by chakotay.allgaeu.org (8.9.3/8.9.3) with ESMTP id TAA21632 for ; Thu, 19 Jul 2001 19:26:15 +0200 Received: by tuvok.allgaeu.org (Postfix, from userid 1000) id D312A327; Thu, 19 Jul 2001 19:26:14 +0200 (CEST) Date: Thu, 19 Jul 2001 19:26:14 +0200 From: Robert Einsle To: linux-mips@oss.sgi.com Subject: Probs running ntp on an indy Message-ID: <20010719192614.A22495@tuvok.allgaeu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 422 Lines: 22 Hy Is it possible to run ntp on an indy?? while running ntpdate i got the error ntpdate[621]: poll(): nfound = 0, error: Operation not permitted the same thing happens while running ntpd Thanks for your help -- MFG Robert Einsle BNA Technik, Postmaster >>Warum muss ich bei "Verwaltung von Problemloesungen fuer eine EDV-Abteilung" an einen Waffenschrank denken?<< (Robin S. Socha in de.comp.os.unix.linux.misc) From owner-linux-mips@oss.sgi.com Thu Jul 19 10:27:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JHRaV15438 for linux-mips-outgoing; Thu, 19 Jul 2001 10:27:36 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JHRZV15433 for ; Thu, 19 Jul 2001 10:27:35 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 419CB125BD; Thu, 19 Jul 2001 10:27:32 -0700 (PDT) Date: Thu, 19 Jul 2001 10:27:32 -0700 From: "H . J . Lu" To: James Simmons Cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? Message-ID: <20010719102732.D4795@lucon.org> References: <20010718160757.A19581@lucon.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 jsimmons@transvirtual.com on Thu, Jul 19, 2001 at 10:23:13AM -0700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 359 Lines: 13 On Thu, Jul 19, 2001 at 10:23:13AM -0700, James Simmons wrote: > > > How can I get a working 2.4 kernel for raq2 with serial console and > > NFS root? I tried that kernel with Linux 2.4.5. It doesn't work. > > Can you tell me what happens so I can fix it. > When I boot the new kernel. nothing prints out on serial console and the machine is dead. H.J. From owner-linux-mips@oss.sgi.com Thu Jul 19 12:03:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JJ3O513530 for linux-mips-outgoing; Thu, 19 Jul 2001 12:03:24 -0700 Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JJ3OV13527 for ; Thu, 19 Jul 2001 12:03:24 -0700 Received: from pacbell.net ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGQ00MEBI9N1Z@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Thu, 19 Jul 2001 12:03:23 -0700 (PDT) Date: Thu, 19 Jul 2001 12:03:24 -0700 From: Pete Popov Subject: hard hat linux 2.0 To: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Reply-to: ppopov@pacbell.net Message-id: <3B572EFC.9090903@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1098 Lines: 22 Looks like ftp.mvista.com was updated last night to include the mips journeyman edition. The images of interest would be ftp.mvista.com:/pub/Journeyman/cdimages/{je-d1-hhl2.0.cdimage, je-src-hhl2.0.cdimage}. They are rather large so it takes a while to download them. In addition to the userland packages, there is an up to date cross toolchain which can build the kernel as well as useland apps. There is also a native toolchain. The toolchain is 2.95.3 based; glibc is 2.2.3. Since there was some perl interest recently, perl is included. Rebuilding any of the userland packages, for those interested in doing that, is pretty trivial (cross based building!). This is an embedded linux distribution so it's not as large as a RedHat desktop system. For embedded work though, I think it's more than sufficient. One note, to anyone trying it. A number of binaries are linked with pthreads, so you'll need either the new sysmips fix that Ralf is working on, when he completes it, or the patch from Florian. Otherwise binaries like ls, tar, and many others will seg fault. Pete From owner-linux-mips@oss.sgi.com Thu Jul 19 13:04:44 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JK4im17649 for linux-mips-outgoing; Thu, 19 Jul 2001 13:04:44 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JK4iV17644 for ; Thu, 19 Jul 2001 13:04:44 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6JK4Tc1028538; Thu, 19 Jul 2001 13:04:29 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6JK4T7w028534; Thu, 19 Jul 2001 13:04:29 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 19 Jul 2001 13:04:29 -0700 (PDT) From: James Simmons To: "H . J . Lu" cc: John Heil , linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com, cobalt-22@devel.alal.com Subject: Re: Any old Cobalt Qube2 kernel src around? In-Reply-To: <20010718160757.A19581@lucon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 319 Lines: 10 > > http://www.sf.net/projects/linux-mips > > How can I get a working 2.4 kernel for raq2 with serial console and > NFS root? I tried that kernel with Linux 2.4.5. It doesn't work. Hold on. I'm grabbing a toolchain and setting up a cross build environment. Once I have it setup. I will give my cobalt cube a wirl. From owner-linux-mips@oss.sgi.com Thu Jul 19 13:24:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JKOUa18888 for linux-mips-outgoing; Thu, 19 Jul 2001 13:24:30 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JKOSV18882 for ; Thu, 19 Jul 2001 13:24:28 -0700 Received: from scotty.mgnet.de (pD90249E9.dip.t-dialin.net [217.2.73.233]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA19984 for ; Thu, 19 Jul 2001 22:24:21 +0200 (MET DST) Received: (qmail 2618 invoked from network); 19 Jul 2001 20:24:12 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 19 Jul 2001 20:24:12 -0000 Date: Thu, 19 Jul 2001 22:24:06 +0200 (CEST) From: Klaus Naumann To: Robert Einsle cc: linux-mips@oss.sgi.com Subject: Re: Probs running ntp on an indy In-Reply-To: <20010719192614.A22495@tuvok.allgaeu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 687 Lines: 25 On Thu, 19 Jul 2001, Robert Einsle wrote: > Hy > > Is it possible to run ntp on an indy?? > > while running ntpdate i got the error > > ntpdate[621]: poll(): nfound = 0, error: Operation not permitted > > the same thing happens while running ntpd I know the problem but no solution. I suspect that it's a problem of the poll function in Big Endian environments, because I can reproduce this on my Indigo2 and on an Ultra 1 as well. CU, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Thu Jul 19 13:51:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JKpR521187 for linux-mips-outgoing; Thu, 19 Jul 2001 13:51:27 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JKpPV21179 for ; Thu, 19 Jul 2001 13:51:25 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 7A6D47FA; Thu, 19 Jul 2001 22:51:24 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C768843E3; Thu, 19 Jul 2001 22:51:37 +0200 (CEST) Date: Thu, 19 Jul 2001 22:51:37 +0200 From: Florian Lohoff To: Klaus Naumann Cc: Robert Einsle , linux-mips@oss.sgi.com Subject: Re: Probs running ntp on an indy Message-ID: <20010719225137.B1599@paradigm.rfc822.org> References: <20010719192614.A22495@tuvok.allgaeu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: ; from spock@mgnet.de on Thu, Jul 19, 2001 at 10:24:06PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 523 Lines: 13 On Thu, Jul 19, 2001 at 10:24:06PM +0200, Klaus Naumann wrote: > I know the problem but no solution. I suspect that it's a > problem of the poll function in Big Endian environments, because > I can reproduce this on my Indigo2 and on an Ultra 1 as well. I remember seeing a patch concerning this problem - Something with rtsignals - But i cant seem to find it anymore. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Thu Jul 19 14:03:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JL3Uk22072 for linux-mips-outgoing; Thu, 19 Jul 2001 14:03:30 -0700 Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JL3SV22067 for ; Thu, 19 Jul 2001 14:03:28 -0700 Received: from auto-nb1.xs4all.nl (perle-wan1.coltex.nl [10.0.1.177]) by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f6JL3Me07114; Thu, 19 Jul 2001 23:03:23 +0200 Message-Id: <4.3.2.7.2.20010719225315.03c4a878@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 23:03:07 +0200 To: "H . J . Lu" From: Seth Mos Subject: Re: Updates on RedHat 7.1/mips Cc: linux-mips@oss.sgi.com In-Reply-To: <20010718173609.A21139@lucon.org> References: <3B55AA0B.42D212E@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2320 Lines: 69 At 17:36 18-7-2001 -0700, H . J . Lu wrote: >On Wed, Jul 18, 2001 at 10:53:22PM +0200, Seth Mos wrote: > > > > I am having trouble getting the mipsel packages installed using the > > installer provided for 7.1. > > > > > > I have hooked up a second disk to my i386 workstatition that will house > > the filesystem for my mipsel box. Once everything is installed I will put > > this disk back in my Qube2 for testing. In the worst case scenario I will > > need to boot with the 2.0 kernel that came with the cube. > > > > I have the original disk for the Qube2 so it isn't a big problem if it > > takes 50 attempts. I have a lot of patience ;-) > > > > Am I correct to assume that I need to use the install.i386.hd on my > > workstation to install the mipsel packages on the second harddrive (hdd in > > my case) > >No. It should be install.mipsel.nfs. install.mipsel.hd is for the >native mipsel machine install. Thank you, it worked :-) > > Traceback (innermost, last): > > File "./findrpm", line 5, in ? > > import rpm > > ImportError: No module named rpm > > > > Does this ring any bells? > >You need to install the rpm-python rpm. And again, thank you. >install.mipsel.nfs is used to create a NFS root tree for mipsel. If >you tar it up, you get what you are asking for. Will do once it works. Everythinhg seems to be installed like it should and I copied the 2.0.34 cobalt kernel to /boot on the Qube2. I have enabled the serial console of the Qube2 and see the firmware scroll along. BOOTLOADER ramcode: selected partition /dev/hda1 Decompressing done Executing bootloader kernel... Jump_to_Real_Kernel: disk error, trying BFD again. BOOTLOADER ramcode: selected partition /dev/hdc1 etc.. Qubes don't have the second IDE controller so this is nonsense ;-) Does anybody know what's missing? Do I need to format the ext2 root fs in a special way? Do I need to pass on other bootoptions and if so. How do I get to a command line prompt of the firmware? I see that the NetBSD people did that to make it boot another kernel. I thought that the firmware from the Qubes just boot the vmlinux.gz image that it finds in the /boot directory on hda1? Any help appreciated. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-mips@oss.sgi.com Thu Jul 19 15:03:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JM3Jr24723 for linux-mips-outgoing; Thu, 19 Jul 2001 15:03:19 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JM3BV24719 for ; Thu, 19 Jul 2001 15:03:11 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA05543 for ; Thu, 19 Jul 2001 15:02:51 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15NLDN-0006vL-00; Thu, 19 Jul 2001 14:20:09 -0700 Date: Thu, 19 Jul 2001 14:20:09 -0700 From: Daniel Jacobowitz To: Florian Lohoff Cc: libc-alpha@sources.redhat.com, Klaus Naumann , Robert Einsle , linux-mips@oss.sgi.com Subject: Re: Probs running ntp on an indy Message-ID: <20010719142009.A26517@nevyn.them.org> Mail-Followup-To: Florian Lohoff , libc-alpha@sources.redhat.com, Klaus Naumann , Robert Einsle , linux-mips@oss.sgi.com References: <20010719192614.A22495@tuvok.allgaeu.org> <20010719225137.B1599@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010719225137.B1599@paradigm.rfc822.org>; from flo@rfc822.org on Thu, Jul 19, 2001 at 10:51:37PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1202 Lines: 30 On Thu, Jul 19, 2001 at 10:51:37PM +0200, Florian Lohoff wrote: > On Thu, Jul 19, 2001 at 10:24:06PM +0200, Klaus Naumann wrote: > > I know the problem but no solution. I suspect that it's a > > problem of the poll function in Big Endian environments, because > > I can reproduce this on my Indigo2 and on an Ultra 1 as well. > > I remember seeing a patch concerning this problem - Something with > rtsignals - But i cant seem to find it anymore. That's probably this one. I knew I'd let a patch slip. Glibc folk, is this OK? The siginfo struct is different on MIPS. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer --- glibc-2.2.3/sysdeps/unix/sysv/linux/mips/bits/siginfo.h.orig Thu May 24 15:35:42 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/bits/siginfo.h Thu May 24 15:35:49 2001 @@ -45,9 +45,9 @@ typedef struct siginfo { int si_signo; /* Signal number. */ + int si_code; /* Signal code. */ int si_errno; /* If non-zero, an errno value associated with this signal, as defined in . */ - int si_code; /* Signal code. */ union { From owner-linux-mips@oss.sgi.com Thu Jul 19 16:57:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6JNvof29791 for linux-mips-outgoing; Thu, 19 Jul 2001 16:57:50 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6JNvnV29788 for ; Thu, 19 Jul 2001 16:57:49 -0700 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 f6JMvRW18525; Thu, 19 Jul 2001 15:57:27 -0700 Message-ID: <3B57730E.338B7B10@mvista.com> Date: Thu, 19 Jul 2001 16:53:50 -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: linux-mips@oss.sgi.com Subject: PATCH: wrong number of kbytes reported in freeing initrd Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 799 Lines: 23 ... a pretty much self-explanatory patch. Jun diff -Nru linux/arch/mips/mm/init.c.orig linux/arch/mips/mm/init.c --- linux/arch/mips/mm/init.c.orig Tue Mar 27 14:03:35 2001 +++ linux/arch/mips/mm/init.c Thu Jul 19 16:39:31 2001 @@ -332,13 +332,14 @@ #ifdef CONFIG_BLK_DEV_INITRD void free_initrd_mem(unsigned long start, unsigned long end) { + unsigned long start1 = start; for (; start < end; start += PAGE_SIZE) { ClearPageReserved(virt_to_page(start)); set_page_count(virt_to_page(start), 1); free_page(start); totalram_pages++; } - printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10); + printk ("Freeing initrd memory: %ldk freed\n", (end - start1) >> 10); } #endif From owner-linux-mips@oss.sgi.com Thu Jul 19 19:10:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6K2A4c06165 for linux-mips-outgoing; Thu, 19 Jul 2001 19:10:04 -0700 Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6K2A2V06159 for ; Thu, 19 Jul 2001 19:10:02 -0700 Received: from pacbell.net ([63.194.214.47]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGR00KD820OL1@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Thu, 19 Jul 2001 19:10:00 -0700 (PDT) Date: Thu, 19 Jul 2001 19:10:07 -0700 From: Pete Popov Subject: generic ramdisk support To: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Reply-to: ppopov@pacbell.net Message-id: <3B5792FF.1030808@pacbell.net> MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------050502010009030901000804 X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2581 Lines: 84 This is a multi-part message in MIME format. --------------050502010009030901000804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Any reason why we don't have a single directory for a ramdisk linker script and Makefile? I've attached that does that. You just put a ramdisk.gz image in arch/mips/ramdisk and turn on initrd support. At somepoint I'll upload some useful ramdisks to the sourceforge linux-mips anonymous ftp site. Pete --------------050502010009030901000804 Content-Type: text/plain; name="ramdisk.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ramdisk.patch" diff -Naur --exclude=CVS linux-mips-dev-orig/arch/mips/Makefile linux-mips-dev/arch/mips/Makefile --- linux-mips-dev-orig/arch/mips/Makefile Thu Jul 12 11:41:14 2001 +++ linux-mips-dev/arch/mips/Makefile Thu Jul 19 18:54:29 2001 @@ -90,6 +90,16 @@ CORE_FILES +=arch/mips/math-emu/fpu_emulator.o SUBDIRS +=arch/mips/math-emu +# +# ramdisk/initrd support +# You need a compressed ramdisk image, named ramdisk.gz in +# arch/mips/ramdisk +# +ifdef CONFIG_BLK_DEV_INITRD +CORE_FILES += arch/mips/ramdisk/ramdisk.o +SUBDIRS += arch/mips/ramdisk +endif + # # Board-dependent options and extra files # diff -Naur --exclude=CVS linux-mips-dev-orig/arch/mips/ramdisk/Makefile linux-mips-dev/arch/mips/ramdisk/Makefile --- linux-mips-dev-orig/arch/mips/ramdisk/Makefile Wed Dec 31 16:00:00 1969 +++ linux-mips-dev/arch/mips/ramdisk/Makefile Thu Jul 19 18:07:46 2001 @@ -0,0 +1,22 @@ +# +# Makefile for a ramdisk image +# +# Note! Dependencies are done automagically by 'make dep', which also +# removes any old dependencies. DON'T put your own dependencies here +# unless it's something special (ie not a .c file). +# + +ifdef CONFIG_CPU_LITTLE_ENDIAN +output-format = elf32-tradlittlemips +else +output-format = elf32-tradbigmips +endif + +ramdisk.o: ramdisk.gz ld.script + $(LD) -T ld.script -b binary -o $@ ramdisk.gz + +ld.script: $(TOPDIR)/arch/$(ARCH)/ramdisk/ld.script.in + sed 's/@@OUTPUT_FORMAT@@/$(output-format)/' <$< >$@ + +include $(TOPDIR)/Rules.make + diff -Naur --exclude=CVS linux-mips-dev-orig/arch/mips/ramdisk/ld.script.in linux-mips-dev/arch/mips/ramdisk/ld.script.in --- linux-mips-dev-orig/arch/mips/ramdisk/ld.script.in Wed Dec 31 16:00:00 1969 +++ linux-mips-dev/arch/mips/ramdisk/ld.script.in Thu Jul 19 17:36:10 2001 @@ -0,0 +1,10 @@ +OUTPUT_FORMAT("@@OUTPUT_FORMAT@@") +OUTPUT_ARCH(mips) +SECTIONS +{ + .initrd : + { + *(.data) + } +} + --------------050502010009030901000804-- From owner-linux-mips@oss.sgi.com Thu Jul 19 19:34:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6K2YYT07661 for linux-mips-outgoing; Thu, 19 Jul 2001 19:34:34 -0700 Received: from cool.coventive.com (cool.coventive.com [211.79.9.188]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6K2YWV07654 for ; Thu, 19 Jul 2001 19:34:32 -0700 Received: from jefflee (jungle.coventive.com [211.79.9.189]) by cool.coventive.com (8.10.2/8.10.2) with SMTP id f6K2XqR15865; Fri, 20 Jul 2001 10:33:56 +0800 Message-ID: <008101c110c4$de161c70$9400a8c0@jefflee> From: "jeff_lee" To: , , References: <3B572EFC.9090903@pacbell.net> Subject: Re: hard hat linux 2.0 Date: Fri, 20 Jul 2001 10:37:02 +0800 Organization: hardware MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1464 Lines: 35 Hi , How can I ftp the site ?? Do I need the user name or passward ?? Or how is the port number ?? Thanks !!! ----- Original Message ----- From: "Pete Popov" To: ; Sent: Friday, July 20, 2001 3:03 AM Subject: hard hat linux 2.0 > Looks like ftp.mvista.com was updated last night to include the mips > journeyman edition. The images of interest would be > ftp.mvista.com:/pub/Journeyman/cdimages/{je-d1-hhl2.0.cdimage, > je-src-hhl2.0.cdimage}. They are rather large so it takes a while to > download them. > > In addition to the userland packages, there is an up to date cross > toolchain which can build the kernel as well as useland apps. There is > also a native toolchain. The toolchain is 2.95.3 based; glibc is 2.2.3. > Since there was some perl interest recently, perl is included. > Rebuilding any of the userland packages, for those interested in doing > that, is pretty trivial (cross based building!). > > This is an embedded linux distribution so it's not as large as a RedHat > desktop system. For embedded work though, I think it's more than > sufficient. One note, to anyone trying it. A number of binaries are > linked with pthreads, so you'll need either the new sysmips fix that > Ralf is working on, when he completes it, or the patch from Florian. > Otherwise binaries like ls, tar, and many others will seg fault. > > Pete From owner-linux-mips@oss.sgi.com Thu Jul 19 19:37:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6K2bPD07902 for linux-mips-outgoing; Thu, 19 Jul 2001 19:37:25 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6K2bOV07899 for ; Thu, 19 Jul 2001 19:37:24 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6K2atc1009792; Thu, 19 Jul 2001 19:36:55 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6K2arSr009788; Thu, 19 Jul 2001 19:36:53 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Thu, 19 Jul 2001 19:36:53 -0700 (PDT) From: James Simmons To: jeff_lee cc: ppopov@pacbell.net, linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: hard hat linux 2.0 In-Reply-To: <008101c110c4$de161c70$9400a8c0@jefflee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 197 Lines: 8 > How can I ftp the site ?? ftp ftp.mvista.com No password. Its in pub/JourneyMan directory. Note it is a CD image and its big. It toke me a hour for each image and this is with a T1 line. From owner-linux-mips@oss.sgi.com Thu Jul 19 20:06:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6K36Jk10121 for linux-mips-outgoing; Thu, 19 Jul 2001 20:06:19 -0700 Received: from viditec-netmedia.com.tw (61-220-240-70.HINET-IP.hinet.net [61.220.240.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6K36GV10113 for ; Thu, 19 Jul 2001 20:06:16 -0700 Received: from kjlin ([61.220.240.66]) by viditec-netmedia.com.tw (8.10.0/8.10.0) with SMTP id f6K5BFv06730 for ; Fri, 20 Jul 2001 13:11:15 +0800 Message-ID: <016701c110c6$a371d580$056aaac0@kjlin> From: "kjlin" To: Subject: weird printf problem Date: Fri, 20 Jul 2001 10:49:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C11109.B05F54A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3564 Lines: 106 This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C11109.B05F54A0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi all, I ported linux to my embeded board and encountered a weird "printf" = problem. The library i used is uClibc. I made the kernel to run a testing program directly after boot up. In my case, less "printf" work well but more will fail. Here is my testing program: main() { int i=3D0; while(i<200) { printf("Hello World=3D%d\n",i); i++; } } =20 The output message will die at "Hello World=3D10" or "Hello World=3D168" = or "Hello World=3D76" ........ Every times the message dies at different place but it will never = successfully be outputed "200" times. However, if the condition is changed to "while(i<100)", then everything = is fine. It is so weird!! Why too much "printf" will cause the program to die? Is it the problem of uClibc or kernel? Does the compiler for my testing program concern this weird problem? Can anybody give me some hints? Thanks, KJ ------=_NextPart_000_0164_01C11109.B05F54A0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I ported linux to my embeded board and = encountered a=20 weird "printf" problem.
The library i used is uClibc.
I made the kernel to run a testing program directly = after boot=20 up.
In my case, less "printf" work well but more = will=20 fail.
Here is my testing program:
 
main()
{
    int i=3D0;
 
   =20 while(i<200)
    {
    &= nbsp;          =20 printf("Hello=20 World=3D%d\n",i);
        &nbs= p;      =20 i++;
    }
}
 
The output message will die at "Hello = World=3D10" or "Hello=20 World=3D168" or "Hello World=3D76" ........
Every times the message dies at different = place but it will never successfully be outputed "200"=20 times.
However, if the condition is changed to = "while(i<100)",=20 then everything is fine.
It is so weird!!
Why too much "printf" will cause the program to=20 die?
Is it the problem of uClibc or kernel?
Does the compiler for my testing program concern this weird = problem?
Can anybody give me some hints?
 
Thanks,
KJ
------=_NextPart_000_0164_01C11109.B05F54A0-- From owner-linux-mips@oss.sgi.com Thu Jul 19 23:05:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6K65LS19935 for linux-mips-outgoing; Thu, 19 Jul 2001 23:05:21 -0700 Received: from mail.kdt.de (mail.kdt.de [195.8.224.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6K65JV19932 for ; Thu, 19 Jul 2001 23:05:20 -0700 Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5]) by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f6K64tj29563; Fri, 20 Jul 2001 08:04:55 +0200 Received: from gromit.moeb ([192.168.27.3] ident=postfix) by arthur.inka.de with esmtp (Exim 3.30 #1) id 15NTP1-00012r-00; Fri, 20 Jul 2001 08:04:43 +0200 Received: by gromit.moeb (Postfix, from userid 207) id 258201EA2A; Fri, 20 Jul 2001 08:04:42 +0200 (CEST) Mail-Copies-To: never To: Daniel Jacobowitz Cc: Florian Lohoff , libc-alpha@sources.redhat.com, Klaus Naumann , Robert Einsle , linux-mips@oss.sgi.com Subject: Re: Probs running ntp on an indy References: <20010719192614.A22495@tuvok.allgaeu.org> <20010719225137.B1599@paradigm.rfc822.org> <20010719142009.A26517@nevyn.them.org> From: Andreas Jaeger Date: Fri, 20 Jul 2001 08:04:41 +0200 In-Reply-To: <20010719142009.A26517@nevyn.them.org> (Daniel Jacobowitz's message of "Thu, 19 Jul 2001 14:20:09 -0700") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 785 Lines: 23 Daniel Jacobowitz writes: > On Thu, Jul 19, 2001 at 10:51:37PM +0200, Florian Lohoff wrote: >> On Thu, Jul 19, 2001 at 10:24:06PM +0200, Klaus Naumann wrote: >> > I know the problem but no solution. I suspect that it's a >> > problem of the poll function in Big Endian environments, because >> > I can reproduce this on my Indigo2 and on an Ultra 1 as well. >> >> I remember seeing a patch concerning this problem - Something with >> rtsignals - But i cant seem to find it anymore. > > That's probably this one. I knew I'd let a patch slip. Glibc folk, is > this OK? The siginfo struct is different on MIPS. Yes, that's fine. Thanks, I've committed it, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-mips@oss.sgi.com Fri Jul 20 06:25:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KDPOW30423 for linux-mips-outgoing; Fri, 20 Jul 2001 06:25:24 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KDPMV30416 for ; Fri, 20 Jul 2001 06:25:22 -0700 Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Fri, 20 Jul 2001 09:25:14 -0400 Message-ID: <25369470B6F0D41194820002B328BDD27D2B@ATLOPS> From: Marc Karasek Reply-To: ppopov@pacbell.net To: "'Pete Popov '" , "'linux-mips-kernel@lists.sourceforge.net '" , "'linux-mips@oss.sgi.com '" Subject: RE: hard hat linux 2.0 Date: Fri, 20 Jul 2001 09:25:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1318 Lines: 30 Is there somewhere I can grab the patch from Florian? -----Original Message----- From: Pete Popov To: linux-mips-kernel@lists.sourceforge.net; linux-mips@oss.sgi.com Sent: 7/19/01 3:03 PM Subject: hard hat linux 2.0 Looks like ftp.mvista.com was updated last night to include the mips journeyman edition. The images of interest would be ftp.mvista.com:/pub/Journeyman/cdimages/{je-d1-hhl2.0.cdimage, je-src-hhl2.0.cdimage}. They are rather large so it takes a while to download them. In addition to the userland packages, there is an up to date cross toolchain which can build the kernel as well as useland apps. There is also a native toolchain. The toolchain is 2.95.3 based; glibc is 2.2.3. Since there was some perl interest recently, perl is included. Rebuilding any of the userland packages, for those interested in doing that, is pretty trivial (cross based building!). This is an embedded linux distribution so it's not as large as a RedHat desktop system. For embedded work though, I think it's more than sufficient. One note, to anyone trying it. A number of binaries are linked with pthreads, so you'll need either the new sysmips fix that Ralf is working on, when he completes it, or the patch from Florian. Otherwise binaries like ls, tar, and many others will seg fault. Pete From owner-linux-mips@oss.sgi.com Fri Jul 20 09:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KGC1J14072 for linux-mips-outgoing; Fri, 20 Jul 2001 09:12:01 -0700 Received: from web14005.mail.yahoo.com (web14005.mail.yahoo.com [216.136.175.121]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KGC1V14069 for ; Fri, 20 Jul 2001 09:12:01 -0700 Message-ID: <20010720161201.3455.qmail@web14005.mail.yahoo.com> Received: from [132.170.193.43] by web14005.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 09:12:01 PDT Date: Fri, 20 Jul 2001 09:12:01 -0700 (PDT) From: Eugenio Diaz Subject: test-discard To: MIPS Maillist MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 246 Lines: 12 test ===== ________________________ Eugenio Diaz, BSEE/BSCE Linux Engineer getnito@yahoo.com __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-linux-mips@oss.sgi.com Fri Jul 20 09:18:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KGIrM14395 for linux-mips-outgoing; Fri, 20 Jul 2001 09:18:53 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KGIrV14392 for ; Fri, 20 Jul 2001 09:18:53 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id CB584125BA; Fri, 20 Jul 2001 09:18:52 -0700 (PDT) Date: Fri, 20 Jul 2001 09:18:52 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: XFree86 4.1 rpms are available Message-ID: <20010720091852.A26953@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 150 Lines: 8 FYI, I have uploaded XFree86 4.1 mips/mipsel rpms to ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ It doesn't have any servers, just clients. H.J. From owner-linux-mips@oss.sgi.com Fri Jul 20 09:26:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KGQLP14617 for linux-mips-outgoing; Fri, 20 Jul 2001 09:26:21 -0700 Received: from snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KGQJV14614 for ; Fri, 20 Jul 2001 09:26:19 -0700 Received: from pacbell.net ([63.194.214.47]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GGS004DR5NKOZ@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com; Fri, 20 Jul 2001 09:26:09 -0700 (PDT) Date: Fri, 20 Jul 2001 09:26:14 -0700 From: Pete Popov Subject: Re: hard hat linux 2.0 Cc: "'linux-mips-kernel@lists.sourceforge.net '" , "'linux-mips@oss.sgi.com '" Reply-to: ppopov@pacbell.net Message-id: <3B585BA6.1080507@pacbell.net> MIME-version: 1.0 Content-type: multipart/mixed; boundary=------------060708080104040003040608 X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 References: <25369470B6F0D41194820002B328BDD27D2B@ATLOPS> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5587 Lines: 193 This is a multi-part message in MIME format. --------------060708080104040003040608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Marc Karasek wrote: > Is there somewhere I can grab the patch from Florian? Yes, somewhere in the mail archives. If you use the 2.4.2 based kernel in HHL2.0, that patch and others have been applied. I've attached Florian's patch. Pete > > -----Original Message----- > From: Pete Popov > To: linux-mips-kernel@lists.sourceforge.net; linux-mips@oss.sgi.com > Sent: 7/19/01 3:03 PM > Subject: hard hat linux 2.0 > > Looks like ftp.mvista.com was updated last night to include the mips > journeyman edition. The images of interest would be > ftp.mvista.com:/pub/Journeyman/cdimages/{je-d1-hhl2.0.cdimage, > je-src-hhl2.0.cdimage}. They are rather large so it takes a while to > download them. > > In addition to the userland packages, there is an up to date cross > toolchain which can build the kernel as well as useland apps. There is > also a native toolchain. The toolchain is 2.95.3 based; glibc is 2.2.3. > > Since there was some perl interest recently, perl is included. > Rebuilding any of the userland packages, for those interested in doing > that, is pretty trivial (cross based building!). > > This is an embedded linux distribution so it's not as large as a RedHat > desktop system. For embedded work though, I think it's more than > sufficient. One note, to anyone trying it. A number of binaries are > linked with pthreads, so you'll need either the new sysmips fix that > Ralf is working on, when he completes it, or the patch from Florian. > Otherwise binaries like ls, tar, and many others will seg fault. > > Pete > > --------------060708080104040003040608 Content-Type: text/plain; name="florian_sysmips.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="florian_sysmips.patch" diff -Nur linux.orig/arch/mips/kernel/Makefile linux/arch/mips/kernel/Makefile --- linux.orig/arch/mips/kernel/Makefile Mon Apr 9 00:23:08 2001 +++ linux/arch/mips/kernel/Makefile Mon Apr 9 00:23:34 2001 @@ -20,7 +20,7 @@ obj-y += branch.o process.o signal.o entry.o \ traps.o ptrace.o vm86.o ioport.o reset.o \ semaphore.o setup.o syscall.o sysmips.o \ - ipc.o scall_o32.o unaligned.o + ipc.o scall_o32.o unaligned.o fast-sysmips.o obj-$(CONFIG_MODULES) += mips_ksyms.o ifdef CONFIG_CPU_R3000 @@ -69,5 +69,6 @@ entry.o: entry.S head.o: head.S +fast-sysmips.o: fast-sysmips.S include $(TOPDIR)/Rules.make diff -Nur linux.orig/arch/mips/kernel/fast-sysmips.S linux/arch/mips/kernel/fast-sysmips.S --- linux.orig/arch/mips/kernel/fast-sysmips.S Thu Jan 1 01:00:00 1970 +++ linux/arch/mips/kernel/fast-sysmips.S Mon Apr 9 00:28:20 2001 @@ -0,0 +1,85 @@ +/* + * MIPS_ATOMIC_SET asm implementation for ll/sc capable cpus + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2001 Florian Lohoff + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PT_TRACESYS 0x00000002 + + EXPORT(fast_sysmips) + + .set noreorder + + li t0, MIPS_ATOMIC_SET + beq a0, t0, 1f + nop + j sys_sysmips + nop + +1: + + # a0 - MIPS_ATOMIC_SET + # a1 - mem ptr + # a2 - value + + addiu sp, sp, -8 # Reserve space + sw a0, (sp) # Save arg0 + + addiu a0, a1, 4 # addr+size + ori v0, a1, 4 # addr | size + lw v1, THREAD_CURDS(gp) # current->thread.current_ds + or v0, v0, a0 # addr | size | (addr+size) + and v1, v1, v0 # (mask)&(addr | size | (addr+size) + bltz v1, 5f + nop + +2: + ll v0, (a1) + move t0, a2 + sc t0, (a1) + beqz t0, 2b + nop + + sw v0, PT_R2+8(sp) # Result value + sw zero, PT_R7+8(sp) # Success indicator + + lw t0, TASK_PTRACE(gp) # syscall tracing enabled? + andi t0, PT_TRACESYS + bnez t0, 3f + nop + +4: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + + j o32_ret_from_sys_call + nop + +3: + sw ra, 4(sp) + jal syscall_trace + nop + lw ra, 4(sp) + j 4b + nop + +5: + lw a0, (sp) # Restore arg0 + addiu sp, sp, 8 # Restore sp + j ra + li v0, -EFAULT + diff -Nur linux.orig/arch/mips/kernel/irix5sys.h linux/arch/mips/kernel/irix5sys.h --- linux.orig/arch/mips/kernel/irix5sys.h Mon Apr 9 00:16:29 2001 +++ linux/arch/mips/kernel/irix5sys.h Sun Apr 8 21:21:16 2001 @@ -69,7 +69,7 @@ SYS(irix_getgid, 0) /* 1047 getgid() V*/ SYS(irix_unimp, 0) /* 1048 (XXX IRIX 4 ssig) V*/ SYS(irix_msgsys, 6) /* 1049 sys_msgsys V*/ -SYS(sys_sysmips, 4) /* 1050 sysmips() HV*/ +SYS(fast_sysmips, 4) /* 1050 sysmips() HV*/ SYS(irix_unimp, 0) /* 1051 XXX sysacct() IV*/ SYS(irix_shmsys, 5) /* 1052 sys_shmsys V*/ SYS(irix_semsys, 0) /* 1053 sys_semsys V*/ diff -Nur linux.orig/arch/mips/kernel/syscalls.h linux/arch/mips/kernel/syscalls.h --- linux.orig/arch/mips/kernel/syscalls.h Mon Apr 9 00:16:30 2001 +++ linux/arch/mips/kernel/syscalls.h Sun Apr 8 21:21:43 2001 @@ -163,7 +163,7 @@ SYS(sys_writev, 3) SYS(sys_cacheflush, 3) SYS(sys_cachectl, 3) -SYS(sys_sysmips, 4) +SYS(fast_sysmips, 4) SYS(sys_ni_syscall, 0) /* 4150 */ SYS(sys_getsid, 1) SYS(sys_fdatasync, 0) --------------060708080104040003040608-- From owner-linux-mips@oss.sgi.com Fri Jul 20 10:43:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KHhMi16485 for linux-mips-outgoing; Fri, 20 Jul 2001 10:43:22 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KHhMV16479 for ; Fri, 20 Jul 2001 10:43:22 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6KHhCc1028363; Fri, 20 Jul 2001 10:43:12 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6KHhB5N028358; Fri, 20 Jul 2001 10:43:12 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Fri, 20 Jul 2001 10:43:11 -0700 (PDT) From: James Simmons To: Andrew Thornton cc: Linux-MIPS Subject: Re: ATI Victoria on Malta In-Reply-To: <011a01c10fa9$6abbd970$d11110ac@snow.isltd.insignia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 178 Lines: 6 > There does seem to be some code for the ATI Rage XL hardware (as used on the > card) in v2.4.6 of the kernel. I don't have this board but give the atyfb framebuffer a try. From owner-linux-mips@oss.sgi.com Fri Jul 20 10:49:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KHnJ316707 for linux-mips-outgoing; Fri, 20 Jul 2001 10:49:19 -0700 Received: from saturn.mikemac.com (saturn.mikemac.com [216.99.199.88]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KHnJV16704 for ; Fri, 20 Jul 2001 10:49:19 -0700 Received: from Saturn (localhost [127.0.0.1]) by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id KAA05236 for ; Fri, 20 Jul 2001 10:49:16 -0700 Message-Id: <200107201749.KAA05236@saturn.mikemac.com> To: linux-mips@oss.sgi.com Subject: I2 R10K status? Date: Fri, 20 Jul 2001 10:49:16 -0700 From: Mike McDonald Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 196 Lines: 7 What's the status of linux for the I2 R10K? Any hope at all? I'm well aware of the problems SGI had getting Irix to work on it. (I was part of ISD then.) Mike McDonald mikemac@mikemac.com From owner-linux-mips@oss.sgi.com Fri Jul 20 11:16:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KIG8117273 for linux-mips-outgoing; Fri, 20 Jul 2001 11:16:08 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KIFdV17265 for ; Fri, 20 Jul 2001 11:15:39 -0700 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 f6KHF0W07704; Fri, 20 Jul 2001 10:15:03 -0700 Message-ID: <3B58744B.659668CF@mvista.com> Date: Fri, 20 Jul 2001 11:11:23 -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: ppopov@pacbell.net CC: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: generic ramdisk support References: <3B5792FF.1030808@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 535 Lines: 17 Pete Popov wrote: > > Any reason why we don't have a single directory for a ramdisk linker > script and Makefile? I've attached that does that. You just put a > ramdisk.gz image in arch/mips/ramdisk and turn on initrd support. At > somepoint I'll upload some useful ramdisks to the sourceforge linux-mips > anonymous ftp site. > This is a good idea. People don't have to maintain a separate script to generate the ram root fs. BTW, I created 1.4 MB busybox ram fs for mips-le. You can find it at http://65.5.25.179/linux. Jun From owner-linux-mips@oss.sgi.com Fri Jul 20 11:22:51 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KIMpk17458 for linux-mips-outgoing; Fri, 20 Jul 2001 11:22:51 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KIMmV17455 for ; Fri, 20 Jul 2001 11:22:48 -0700 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 f6KHLkW08175; Fri, 20 Jul 2001 10:21:46 -0700 Message-ID: <3B5875E1.C7D897BE@mvista.com> Date: Fri, 20 Jul 2001 11:18:09 -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: Geert Uytterhoeven CC: Fuxin Zhang , "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer References: Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by hermes.mvista.com id f6KHLkW08175 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6KIMmV17456 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1332 Lines: 34 Geert Uytterhoeven wrote: > > On Wed, 18 Jul 2001, Fuxin Zhang wrote: > > 2001-07-18 09:18:00£º > > >On Tue, 17 Jul 2001, James Simmons wrote: > > >> > First I try the vga16 frame buffer driver,but i can only get > > >> > some black/white strips on the screen.(after made some changes > > >> > to the source,most important one is use pci to find and set the > > >> > vbase address). > > >> > > >> It is hardwired into the vga16fb driver the memory region (0xA000). This > > >> is very wrong on non intel platforms. So that drivers pretty much doesn't > > >> work on anything else. > > > > > >Does your firmware initialize the VGA card to VGA text mode? Vga16fb requires > > >this initialization, which is normally done by the VGA BIOS. An x86 > > >BIOS-emulator may be your friend. > > Cound you give me a link to such a emulator?My firmware doesn't initialize VGA card.That seems the real problem. > > I don't know whether it exists for Linux/MIPS yet. > > Gr{oetje,eeting}s, > > Geert FYI, without the emulator, I have successfully run Matrox Millinium PCI card from SGI CVS tree. With some patches, I have got MQ200 and Voodoo3 2000/3000 working as well. I don't know if any other cards work on MIPS. For voodoo3 patch, look at http://www.medex.hu/~danthe/tdfx/. Jun From owner-linux-mips@oss.sgi.com Fri Jul 20 13:02:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KK25c24109 for linux-mips-outgoing; Fri, 20 Jul 2001 13:02:05 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KK23V24106 for ; Fri, 20 Jul 2001 13:02:03 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id WAA04271 for ; Fri, 20 Jul 2001 22:02:01 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15NgTD-0002uU-00 for ; Fri, 20 Jul 2001 22:01:55 +0200 Date: Fri, 20 Jul 2001 22:01:55 +0200 To: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? Message-ID: <20010720220155.D16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200107201749.KAA05236@saturn.mikemac.com> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4872 Lines: 138 Mike McDonald wrote: > > What's the status of linux for the I2 R10K? Any hope at all? I'm > well aware of the problems SGI had getting Irix to work on it. (I was > part of ISD then.) A few days ago I posted about some success booting my ip28 AKA Indigo2 R10000 Impact Ready. A updated version of the bootlog is appended. Used Tools: - CVS binutils, hacked to allow assembly and linking of 64bit non-pic executables. - GCC snapshot as of 2001-05-01 with some patch by Ralf to work better for R10000 and one more by myself. - CVS linux from oss, patched to recognize an ip28 and to work in a real 64bit address space. The Patches are available at http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/src The script I use to crosscompile is at http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/edit Current State: The Kernel boots via bootp/tftp/nfs into an initshell, execution of not too complex programs may or may not succeed, it's pretty at random. /sbin/init itself seems to run, too, but all(?) spawned processes crash due to unaligned access/illegal instruction in kernel space. The serial console drops characters on high throughput. If you want to try it out, the kernel is available at http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/mips64-linux-ip28-2001-07-20.tar.gz Thiemo ------------------------------------------------- >> bootp(): init=/bin/sash Setting $netaddr to 10.0.0.5 (from server rembrandt) Obtaining from server rembrandt 1750384+278528+259632 entry: 0xa8000000201b4000 ARCH: SGI-IP28 PROMLIB: ARC firmware Version 64 Revision 0 Linux version 2.4.5-1 (ths@rembrandt) (gcc version 3.1 20010501 (experimental)) #78 Mon Jul 16 17:06:48 CEST 2001 Loading R10000 MMU routines. CPU implementation 9, CPU revision 37 Primary instruction cache 32kb, linesize 64 bytes Primary data cache 32kb, linesize 32 bytes Secondary cache sized at 1024K, linesize 128 MC: SGI memory controller Revision 5 On node 0 totalpages: 262144 zone(0): 262144 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: init=/bin/sash Entering 64-bit mode. calculating r4koff... 000d5bea(875498) Console: colour dummy device 80x25 zs0: console I/O Console: ttyS0 (Zilog8530), 9600 baud Calibrating delay loop... 174.89 BogoMIPS Memory: 488192k/917500k available (1709k kernel code, 429308k reserved, 132k data, 88k init) Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 initialize_kbd: Keyboard failed self test pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? DS1286 Real Time Clock Driver v1.0 streamable misc devices registered (keyb:150, gfx:148) block: queued sectors max/low 321560kB/190488kB, 960 slots per queue sgiseeq.c: David S. Miller (dm@engr.sgi.com) eth0: SGI Seeq8003 08:00:69:0b:35:da SCSI subsystem driver Revision: 1.00 wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Jul 16 2001 at 02:37:07 wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 setup_args=,,,,,,,,, Version 1.25 - 09/Jul/1997, Compiled Jul 16 2001 at 02:37:07 scsi0 : SGI WD93 scsi1 : SGI WD93 SGI Zilog8530 serial driver version 1.01 ttyS0 at 0xbfbd9830 (irq = 21) is a Zilog8530 ttyS1 at 0xbfbd9838 (irq = 21) is a Zilog8530 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) Sending BOOTP requests . OK IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.5 IP-Config: Complete: device=eth0, addr=10.0.0.5, mask=255.0.0.0, gw=10.0.0.1, host=10.0.0.5, domain=, nis-domain=(none), bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=/home/linux-mips NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 10.0.0.1 Looking up port of RPC 100005/2 on 10.0.0.1 VFS: Mounted root (nfs filesystem) readonly. Freeing prom memory: 1024kb freed Freeing unused kernel memory: 88k freed Stand-alone shell (version 3.4) > -ls . .. bin boot data.tar.gz dev etc home lib lost+found mipsroot-rh7.tar.bz2 mnt opt proc root sbin tmp usr var > ls bin data.tar.gz etc lib mipsroot-rh7.tar.bz2 opt root tmp var boot dev home lost+found mnt proc sbin usr > ls pid 9: killed by signal 11 > From owner-linux-mips@oss.sgi.com Fri Jul 20 13:57:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KKvkr27272 for linux-mips-outgoing; Fri, 20 Jul 2001 13:57:46 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KKviV27268 for ; Fri, 20 Jul 2001 13:57:44 -0700 Received: from scotty.mgnet.de (pD902463B.dip.t-dialin.net [217.2.70.59]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA20911 for ; Fri, 20 Jul 2001 22:57:41 +0200 (MET DST) Received: (qmail 11311 invoked from network); 20 Jul 2001 20:57:40 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 20 Jul 2001 20:57:40 -0000 Date: Fri, 20 Jul 2001 22:57:33 +0200 (CEST) From: Klaus Naumann To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? In-Reply-To: <20010720220155.D16278@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 997 Lines: 31 On Fri, 20 Jul 2001, Thiemo Seufer wrote: > kernel space. The serial console drops characters on high > throughput. This is not a IP28 specific problem. Esp. on Backspace and such things the current serial console just f*cks up. Also a lot of data throughput will make things worse. [snip] > Console: ttyS0 (Zilog8530), 9600 baud Try using 38400, it helps a bit I think ... > Memory: 488192k/917500k available (1709k kernel code, 429308k reserved, 132k data, 88k init) > Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) > Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) > Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) > Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) [snap] CU, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Fri Jul 20 14:01:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KL1sG27453 for linux-mips-outgoing; Fri, 20 Jul 2001 14:01:54 -0700 Received: from ns.snowman.net (ns.snowman.net [63.80.4.34]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KL1pV27450 for ; Fri, 20 Jul 2001 14:01:51 -0700 Received: from localhost (nick@localhost) by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id RAA10168; Fri, 20 Jul 2001 17:01:13 -0400 Date: Fri, 20 Jul 2001 17:01:13 -0400 (EDT) From: X-Sender: nick@ns To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? In-Reply-To: <20010720220155.D16278@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5242 Lines: 146 What bootimage are you useing? Thanks Nick On Fri, 20 Jul 2001, Thiemo Seufer wrote: > Mike McDonald wrote: > > > > What's the status of linux for the I2 R10K? Any hope at all? I'm > > well aware of the problems SGI had getting Irix to work on it. (I was > > part of ISD then.) > > A few days ago I posted about some success booting my ip28 AKA > Indigo2 R10000 Impact Ready. A updated version of the bootlog is > appended. > > Used Tools: > - CVS binutils, hacked to allow assembly and linking of 64bit > non-pic executables. > - GCC snapshot as of 2001-05-01 with some patch by Ralf to work > better for R10000 and one more by myself. > - CVS linux from oss, patched to recognize an ip28 and to work > in a real 64bit address space. > > The Patches are available at > http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/src > The script I use to crosscompile is at > http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/edit > > Current State: > The Kernel boots via bootp/tftp/nfs into an initshell, execution > of not too complex programs may or may not succeed, it's pretty at > random. /sbin/init itself seems to run, too, but all(?) spawned > processes crash due to unaligned access/illegal instruction in > kernel space. The serial console drops characters on high > throughput. > > If you want to try it out, the kernel is available at > http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/mips64-linux-ip28-2001-07-20.tar.gz > > > Thiemo > > > ------------------------------------------------- > >> bootp(): init=/bin/sash > Setting $netaddr to 10.0.0.5 (from server rembrandt) > Obtaining from server rembrandt > 1750384+278528+259632 entry: 0xa8000000201b4000 > ARCH: SGI-IP28 > PROMLIB: ARC firmware Version 64 Revision 0 > Linux version 2.4.5-1 (ths@rembrandt) (gcc version 3.1 20010501 (experimental)) #78 Mon Jul 16 17:06:48 CEST 2001 > Loading R10000 MMU routines. > CPU implementation 9, CPU revision 37 > Primary instruction cache 32kb, linesize 64 bytes > Primary data cache 32kb, linesize 32 bytes > Secondary cache sized at 1024K, linesize 128 > MC: SGI memory controller Revision 5 > On node 0 totalpages: 262144 > zone(0): 262144 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: init=/bin/sash > Entering 64-bit mode. > calculating r4koff... 000d5bea(875498) > Console: colour dummy device 80x25 > zs0: console I/O > Console: ttyS0 (Zilog8530), 9600 baud > Calibrating delay loop... 174.89 BogoMIPS > Memory: 488192k/917500k available (1709k kernel code, 429308k reserved, 132k data, 88k init) > Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) > Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) > Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) > Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) > Checking for 'wait' instruction... unavailable. > POSIX conformance testing by UNIFIX > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd v1.8 > initialize_kbd: Keyboard failed self test > pty: 256 Unix98 ptys configured > keyboard: Timeout - AT keyboard not present? > keyboard: Timeout - AT keyboard not present? > DS1286 Real Time Clock Driver v1.0 > streamable misc devices registered (keyb:150, gfx:148) > block: queued sectors max/low 321560kB/190488kB, 960 slots per queue > sgiseeq.c: David S. Miller (dm@engr.sgi.com) > eth0: SGI Seeq8003 08:00:69:0b:35:da > SCSI subsystem driver Revision: 1.00 > wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 > setup_args=,,,,,,,,, > Version 1.25 - 09/Jul/1997, Compiled Jul 16 2001 at 02:37:07 > wd33c93-1: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00 > setup_args=,,,,,,,,, > Version 1.25 - 09/Jul/1997, Compiled Jul 16 2001 at 02:37:07 > scsi0 : SGI WD93 > scsi1 : SGI WD93 > SGI Zilog8530 serial driver version 1.01 > ttyS0 at 0xbfbd9830 (irq = 21) is a Zilog8530 > ttyS1 at 0xbfbd9838 (irq = 21) is a Zilog8530 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 8192 buckets, 64Kbytes > TCP: Hash tables configured (established 262144 bind 65536) > Sending BOOTP requests . OK > IP-Config: Got BOOTP answer from 10.0.0.1, my address is 10.0.0.5 > IP-Config: Complete: > device=eth0, addr=10.0.0.5, mask=255.0.0.0, gw=10.0.0.1, > host=10.0.0.5, domain=, nis-domain=(none), > bootserver=10.0.0.1, rootserver=10.0.0.1, rootpath=/home/linux-mips > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Looking up port of RPC 100003/2 on 10.0.0.1 > Looking up port of RPC 100005/2 on 10.0.0.1 > VFS: Mounted root (nfs filesystem) readonly. > Freeing prom memory: 1024kb freed > Freeing unused kernel memory: 88k freed > Stand-alone shell (version 3.4) > > -ls > . > .. > bin > boot > data.tar.gz > dev > etc > home > lib > lost+found > mipsroot-rh7.tar.bz2 > mnt > opt > proc > root > sbin > tmp > usr > var > > ls > bin data.tar.gz etc lib mipsroot-rh7.tar.bz2 opt root tmp var > boot dev home lost+found mnt proc sbin usr > > ls > pid 9: killed by signal 11 > > > From owner-linux-mips@oss.sgi.com Fri Jul 20 14:33:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KLXJU29439 for linux-mips-outgoing; Fri, 20 Jul 2001 14:33:19 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KLXIV29434 for ; Fri, 20 Jul 2001 14:33:18 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id XAA05569 for ; Fri, 20 Jul 2001 23:33:16 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Nhtc-0007lb-00 for ; Fri, 20 Jul 2001 23:33:16 +0200 Date: Fri, 20 Jul 2001 23:33:16 +0200 To: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? Message-ID: <20010720233316.E16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 639 Lines: 19 Klaus Naumann wrote: [snip] > > Console: ttyS0 (Zilog8530), 9600 baud > > Try using 38400, it helps a bit I think ... Thanks, I'll try it out. > > Memory: 488192k/917500k available (1709k kernel code, 429308k reserved, 132k data, 88k init) > > Dentry-cache hash table entries: 131072 (order: 9, 2097152 bytes) > > Inode-cache hash table entries: 65536 (order: 8, 1048576 bytes) > > Buffer-cache hash table entries: 65536 (order: 7, 524288 bytes) > > Page-cache hash table entries: 262144 (order: 9, 2097152 bytes) I forgot, there's something wrong here: My machine has 512MB RAM, I don't know how these numbers were computed. Thiemo From owner-linux-mips@oss.sgi.com Fri Jul 20 15:15:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6KMFBo00666 for linux-mips-outgoing; Fri, 20 Jul 2001 15:15:11 -0700 Received: from earth.ayrnetworks.com ([64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6KMFBV00663 for ; Fri, 20 Jul 2001 15:15:11 -0700 Received: from [10.21.56.226] (earth.ayrnetworks.com [10.1.1.24]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6KMDZr02116 for ; Fri, 20 Jul 2001 15:13:35 -0700 User-Agent: Microsoft-Entourage/9.0.2509 Date: Fri, 20 Jul 2001 16:15:28 -0600 Subject: SHN_MIPS_SCOMMON From: Greg Satz To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 427 Lines: 12 When making modules for the 2.4.2 kernel, gcc and friends will generate SHN_MIPS_SCOMMON ELF segments (0xff03). Unfortunately insmod (obj_reloc.c) doesn't know how to relocate these symbols and the module page faults at location 4 upon initialization. Is this a bug in obj_reloc.c not handling SHN_MIPS_SCOMMON like SHN_COMMON or should everyone who makes mips kernel modules be using the -fno-common gcc flag? Thanks, Greg From owner-linux-mips@oss.sgi.com Fri Jul 20 18:30:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6L1Ufj12747 for linux-mips-outgoing; Fri, 20 Jul 2001 18:30:41 -0700 Received: from dea.waldorf-gmbh.de (u-129-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6L1UZV12744 for ; Fri, 20 Jul 2001 18:30:38 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6L1UKB22838; Sat, 21 Jul 2001 03:30:20 +0200 Date: Sat, 21 Jul 2001 03:30:20 +0200 From: Ralf Baechle To: Greg Satz Cc: linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721033019.A22637@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 satz@ayrnetworks.com on Fri, Jul 20, 2001 at 04:15:28PM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 186 Lines: 7 On Fri, Jul 20, 2001 at 04:15:28PM -0600, Greg Satz wrote: > When making modules for the 2.4.2 kernel, gcc and friends will generate Rotten kernel error. Upgrade to >= 2.4.5. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 20 18:36:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6L1a5l12833 for linux-mips-outgoing; Fri, 20 Jul 2001 18:36:05 -0700 Received: from dea.waldorf-gmbh.de (u-129-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6L1a1V12830 for ; Fri, 20 Jul 2001 18:36:02 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6L1ZrO22860; Sat, 21 Jul 2001 03:35:53 +0200 Date: Sat, 21 Jul 2001 03:35:53 +0200 From: Ralf Baechle To: Eugenio Diaz Cc: MIPS Maillist Subject: Re: test-discard Message-ID: <20010721033553.B22637@bacchus.dhis.org> References: <20010720161201.3455.qmail@web14005.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010720161201.3455.qmail@web14005.mail.yahoo.com>; from getnito@yahoo.com on Fri, Jul 20, 2001 at 09:12:01AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 252 Lines: 13 On Fri, Jul 20, 2001 at 09:12:01AM -0700, Eugenio Diaz wrote: > test > > ===== > ________________________ > Eugenio Diaz, BSEE/BSCE > Linux Engineer > getnito@yahoo.com Thanks for proofing excellence in engineering in this demonstration. Ralf From owner-linux-mips@oss.sgi.com Fri Jul 20 18:42:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6L1g7u12941 for linux-mips-outgoing; Fri, 20 Jul 2001 18:42:07 -0700 Received: from dea.waldorf-gmbh.de (u-129-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.129]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6L1g4V12938 for ; Fri, 20 Jul 2001 18:42:05 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6L1fe022905; Sat, 21 Jul 2001 03:41:40 +0200 Date: Sat, 21 Jul 2001 03:41:40 +0200 From: Ralf Baechle To: kjlin Cc: linux-mips@oss.sgi.com Subject: Re: weird printf problem Message-ID: <20010721034140.C22637@bacchus.dhis.org> References: <016701c110c6$a371d580$056aaac0@kjlin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <016701c110c6$a371d580$056aaac0@kjlin>; from kj.lin@viditec-netmedia.com.tw on Fri, Jul 20, 2001 at 10:49:45AM +0800 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 476 Lines: 12 On Fri, Jul 20, 2001 at 10:49:45AM +0800, kjlin wrote: > Why too much "printf" will cause the program to die? > Is it the problem of uClibc or kernel? > Does the compiler for my testing program concern this weird problem? > Can anybody give me some hints? You gave no details such as sw version numbers and hardware details. However given such random behaviour my guess would be a kernel bug, possibly the TLB or cache managment code doesn't handle your CPU right. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 02:21:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6L9LAu16639 for linux-mips-outgoing; Sat, 21 Jul 2001 02:21:10 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6L9L1V16635; Sat, 21 Jul 2001 02:21:01 -0700 Received: from [10.21.56.226] (earth.ayrnetworks.com [10.1.1.24]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6L9KKr10694; Sat, 21 Jul 2001 02:20:20 -0700 User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 21 Jul 2001 03:22:17 -0600 Subject: Re: SHN_MIPS_SCOMMON From: Greg Satz To: Ralf Baechle CC: Message-ID: In-Reply-To: <20010721033019.A22637@bacchus.dhis.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1325 Lines: 35 Hi Ralf, maybe I am missing something but after downloading and some perusal I don't see where the newer (2.4.5) kernel addresses this problem. At the risk of being redundant, the issue, as I see it, is the use of SCOMMON symbols in ELF section SHN_MIPS_SCOMMON (0xff03). These symbols are overlooked when insmod relocates symbols in the SHN_COMMON ELF section. They end up in the kernel with a value of 4. Upon being referenced, the module gets a page fault opps. The file obj/obj_reloc.c in the modutils package is where the SHN_COMMON symbol relocation work is performed. Using the gcc flag -fno-common forces all commons info bss thus preventing the problem. We do this as a work-around now. The question is whether the gcc -fno-common flag is the real fix or is obj/obj_reloc.c deficient. I have a patch that appears to work for obj/obj_reloc.c We create the problem situation by declaring variables in one file as extern and defining them in another. The compiler puts these variables in the SCOMMON segment instead of the COMMON segment. Thanks, Greg on 7/20/01 7:30 PM, Ralf Baechle at ralf@oss.sgi.com wrote: > On Fri, Jul 20, 2001 at 04:15:28PM -0600, Greg Satz wrote: > >> When making modules for the 2.4.2 kernel, gcc and friends will generate > > Rotten kernel error. Upgrade to >= 2.4.5. > > Ralf > From owner-linux-mips@oss.sgi.com Sat Jul 21 02:27:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6L9RP116732 for linux-mips-outgoing; Sat, 21 Jul 2001 02:27:25 -0700 Received: from fe040.worldonline.dk (fe040.worldonline.dk [212.54.64.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6L9RMV16729 for ; Sat, 21 Jul 2001 02:27:22 -0700 Received: (qmail 11697 invoked by uid 0); 21 Jul 2001 09:27:16 -0000 Received: from 213.237.49.98.skovlyporten.dk (HELO tuxedo.skovlyporten.dk) (213.237.49.98) by fe040.worldonline.dk with SMTP; 21 Jul 2001 09:27:16 -0000 Received: by tuxedo.skovlyporten.dk (Postfix, from userid 501) id 54DEE2608A; Sat, 21 Jul 2001 11:27:15 +0200 (CEST) Date: Sat, 21 Jul 2001 11:27:15 +0200 From: Lars Munch Christensen To: linux-mips@oss.sgi.com Subject: mips64 linker bug? Message-ID: <20010721112715.C2335@tuxedo.skovlyporten.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1961 Lines: 89 Hi All I think I have found a linker bug! I use the following cross compilers from sgi's ftp: binutils-mips64-linux-2.9.5-3.i386.rpm egcs-mips64-linux-1.1.2-4.i386.rpm binutils-mips64el-linux-2.9.5-3.i386.rpm egcs-mips64el-linux-1.1.2-4.i386.rpm Anyway the bug is that static functions get linked wrongly. Test program: --------------------- /* This function has to be here to get the error */ int test1(void) { return 1; } static int test2(void) { /* <---- notice this static */ return 2; } int main() { test2(); return 1; } --------------------- Compile and link with: mips64-linux-gcc -mcpu=r4600 -mabi=64 -mips3 -g -c -O2 -o main.o main.c mips64-linux-ld -m elf64btsmip -nostdlib -e main main.o -o main.elf Now I see the bug where main calls test2: Doing a 'mips64-linux-objdump -S test.elf' gives me: main.elf: file format elf64-bigmips Disassembly of section .text: 00000000100000f0 : return 1; 100000f0: 03e00008 jr $ra 100000f4: 24020001 li $v0,1 00000000100000f8 : } static int test2(void) { return 2; 100000f8: 03e00008 jr $ra 100000fc: 24020002 li $v0,2 0000000010000100
: } int main() { 10000100: 67bdfff0 0x67bdfff0 10000104: ffbf0000 0xffbf0000 0000000010000108 <$LM6>: test2(); 10000108: 0c000044 jal 10000110 <$LM7> <-- 110 ???????????? 1000010c: 00000000 nop 0000000010000110 <$LM7>: return 1; 10000110: dfbf0000 0xdfbf0000 10000114: 24020001 li $v0,1 10000118: 03e00008 jr $ra 1000011c: 67bd0010 0x67bd0010 When removing the static I get the correct address 100000f8 ?!? Am I missing something. Please help me, I have spend 3 days chasing this bug, until I figures out it was related to static functions. btw why isn't everything disassembled? Thanks Lars Munch From owner-linux-mips@oss.sgi.com Sat Jul 21 03:55:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LAt5v17169 for linux-mips-outgoing; Sat, 21 Jul 2001 03:55:05 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LAt3V17166 for ; Sat, 21 Jul 2001 03:55:03 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA13848; Sat, 21 Jul 2001 12:54:17 +0200 (MET DST) Date: Sat, 21 Jul 2001 12:53:52 +0200 (MET DST) From: Geert Uytterhoeven To: Jun Sun cc: Fuxin Zhang , "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer In-Reply-To: <3B5875E1.C7D897BE@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.sonytel.be id MAA13848 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6LAt4V17167 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1526 Lines: 36 On Fri, 20 Jul 2001, Jun Sun wrote: > Geert Uytterhoeven wrote: > > On Wed, 18 Jul 2001, Fuxin Zhang wrote: > > > 2001-07-18 09:18:00£º > > > >On Tue, 17 Jul 2001, James Simmons wrote: > > > >> > First I try the vga16 frame buffer driver,but i can only get > > > >> > some black/white strips on the screen.(after made some changes > > > >> > to the source,most important one is use pci to find and set the > > > >> > vbase address). > > > >> > > > >> It is hardwired into the vga16fb driver the memory region (0xA000). This > > > >> is very wrong on non intel platforms. So that drivers pretty much doesn't > > > >> work on anything else. > > > > > > > >Does your firmware initialize the VGA card to VGA text mode? Vga16fb requires > > > >this initialization, which is normally done by the VGA BIOS. An x86 > > > >BIOS-emulator may be your friend. > > > Cound you give me a link to such a emulator?My firmware doesn't initialize VGA card.That seems the real problem. > > > > I don't know whether it exists for Linux/MIPS yet. > > FYI, without the emulator, I have successfully run Matrox Millinium PCI card > from SGI CVS tree. That's because matroxfb is one of the few frame buffer devices that know how to initialize uninitialized cards. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Sat Jul 21 05:12:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LCC0l18091 for linux-mips-outgoing; Sat, 21 Jul 2001 05:12:00 -0700 Received: from dea.waldorf-gmbh.de (u-103-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.103]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LCBqV18087 for ; Sat, 21 Jul 2001 05:11:53 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LCBKw25155; Sat, 21 Jul 2001 14:11:20 +0200 Date: Sat, 21 Jul 2001 14:11:20 +0200 From: Ralf Baechle To: Greg Satz Cc: linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721141119.A25053@bacchus.dhis.org> References: <20010721033019.A22637@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 satz@ayrnetworks.com on Sat, Jul 21, 2001 at 03:22:17AM -0600 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1698 Lines: 38 On Sat, Jul 21, 2001 at 03:22:17AM -0600, Greg Satz wrote: > Hi Ralf, maybe I am missing something but after downloading and some perusal > I don't see where the newer (2.4.5) kernel addresses this problem. At the > risk of being redundant, the issue, as I see it, is the use of SCOMMON > symbols in ELF section SHN_MIPS_SCOMMON (0xff03). These symbols are > overlooked when insmod relocates symbols in the SHN_COMMON ELF section. They > end up in the kernel with a value of 4. Upon being referenced, the module > gets a page fault opps. > > The file obj/obj_reloc.c in the modutils package is where the SHN_COMMON > symbol relocation work is performed. Using the gcc flag -fno-common forces > all commons info bss thus preventing the problem. We do this as a > work-around now. > > The question is whether the gcc -fno-common flag is the real fix or is > obj/obj_reloc.c deficient. I have a patch that appears to work for > obj/obj_reloc.c > > We create the problem situation by declaring variables in one file as extern > and defining them in another. You have common declarations that's declarations without static or extern keywords and initalization. Perfectly legal. > The compiler puts these variables in the SCOMMON segment instead of the > COMMON segment. Only if you don't compile / assemble / link with -G 0. .scommon shouldn't ever be in a kernel object. It seems that ld started to move .common objects to .scommon from a certain version on, so 2.4.5 now passes the right options. .scommon is used in global pointer optimizations which doesn't work under Linux anyway as we use $gp ($28) for a different purpose. So modutils should reject such a module right away. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 08:23:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LFNIp22578 for linux-mips-outgoing; Sat, 21 Jul 2001 08:23:18 -0700 Received: from dea.waldorf-gmbh.de (u-154-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LFNFV22575 for ; Sat, 21 Jul 2001 08:23:16 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LFN9L25832; Sat, 21 Jul 2001 17:23:09 +0200 Date: Sat, 21 Jul 2001 17:23:09 +0200 From: Ralf Baechle To: Lars Munch Christensen Cc: linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010721172309.A25467@bacchus.dhis.org> References: <20010721112715.C2335@tuxedo.skovlyporten.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010721112715.C2335@tuxedo.skovlyporten.dk>; from c948114@student.dtu.dk on Sat, Jul 21, 2001 at 11:27:15AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 773 Lines: 24 On Sat, Jul 21, 2001 at 11:27:15AM +0200, Lars Munch Christensen wrote: > 0000000010000110 <$LM7>: > return 1; > 10000110: dfbf0000 0xdfbf0000 > 10000114: 24020001 li $v0,1 > 10000118: 03e00008 jr $ra > 1000011c: 67bd0010 0x67bd0010 > > > When removing the static I get the correct address 100000f8 ?!? > > Am I missing something. Gas and ld of the published 64-bit binutils are entirely useless for 64-bit code. Various people are working on fixing that but that takes time, especially the non-pic case is a bit hairy. > btw why isn't everything disassembled? Executive summary: because binutils is a stupid. Technical answer, objdump only disassembles MIPS I instructions by default. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 08:25:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LFPhw22726 for linux-mips-outgoing; Sat, 21 Jul 2001 08:25:43 -0700 Received: from dea.waldorf-gmbh.de (u-154-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.154]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LFPfV22723 for ; Sat, 21 Jul 2001 08:25:41 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LFPIS25843; Sat, 21 Jul 2001 17:25:18 +0200 Date: Sat, 21 Jul 2001 17:25:18 +0200 From: Ralf Baechle To: Geert Uytterhoeven Cc: Jun Sun , Fuxin Zhang , "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer Message-ID: <20010721172518.B25467@bacchus.dhis.org> References: <3B5875E1.C7D897BE@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: ; from Geert.Uytterhoeven@sonycom.com on Sat, Jul 21, 2001 at 12:53:52PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 278 Lines: 9 On Sat, Jul 21, 2001 at 12:53:52PM +0200, Geert Uytterhoeven wrote: > That's because matroxfb is one of the few frame buffer devices that know how > to initialize uninitialized cards. Is that true for all of the Matrox PCI cards or which would be your recommendation? Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 09:17:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LGHg424215 for linux-mips-outgoing; Sat, 21 Jul 2001 09:17:42 -0700 Received: from fe040.worldonline.dk (fe040.worldonline.dk [212.54.64.205]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LGHeV24210 for ; Sat, 21 Jul 2001 09:17:41 -0700 Received: (qmail 5482 invoked by uid 0); 21 Jul 2001 16:17:34 -0000 Received: from 213.237.49.98.skovlyporten.dk (HELO tuxedo.skovlyporten.dk) (213.237.49.98) by fe040.worldonline.dk with SMTP; 21 Jul 2001 16:17:34 -0000 Received: by tuxedo.skovlyporten.dk (Postfix, from userid 501) id 063662608E; Sat, 21 Jul 2001 18:17:33 +0200 (CEST) Date: Sat, 21 Jul 2001 18:17:33 +0200 From: Lars Munch Christensen To: Ralf Baechle Cc: Lars Munch Christensen , linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010721181733.A3591@tuxedo.skovlyporten.dk> References: <20010721112715.C2335@tuxedo.skovlyporten.dk> <20010721172309.A25467@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: <20010721172309.A25467@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 21, 2001 at 05:23:09PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 866 Lines: 26 On Sat, Jul 21, 2001 at 05:23:09PM +0200, Ralf Baechle wrote: > On Sat, Jul 21, 2001 at 11:27:15AM +0200, Lars Munch Christensen wrote: > > > 0000000010000110 <$LM7>: > > return 1; > > 10000110: dfbf0000 0xdfbf0000 > > 10000114: 24020001 li $v0,1 > > 10000118: 03e00008 jr $ra > > 1000011c: 67bd0010 0x67bd0010 > > > > > > When removing the static I get the correct address 100000f8 ?!? > > > > Am I missing something. > > Gas and ld of the published 64-bit binutils are entirely useless for 64-bit > code. Various people are working on fixing that but that takes time, > especially the non-pic case is a bit hairy. > Thanks...What should I do now? Change my code to mips32 or are there some patches to binutils that I can use, to get it working? Thanks for your help Regards Lars Munch From owner-linux-mips@oss.sgi.com Sat Jul 21 09:46:13 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LGkDj24978 for linux-mips-outgoing; Sat, 21 Jul 2001 09:46:13 -0700 Received: from web13906.mail.yahoo.com (web13906.mail.yahoo.com [216.136.175.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LGkBV24975 for ; Sat, 21 Jul 2001 09:46:11 -0700 Message-ID: <20010721164611.96915.qmail@web13906.mail.yahoo.com> Received: from [61.133.134.171] by web13906.mail.yahoo.com via HTTP; Sat, 21 Jul 2001 09:46:11 PDT Date: Sat, 21 Jul 2001 09:46:11 -0700 (PDT) From: Barry Wu Subject: about alim15x3 ide driver To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 549 Lines: 17 Hi, all, I meet problem about Ali 1535D alim15x3 ide driver. Because our hardware bug in mips evaluation board, I can not use DMA mode in alim15x3.c, I have to use PIO mode. In 2.2.12, I just modify ali15x3_dmaproc function, and can support PIO directly. I do not know how to support only PIO mode for alim15x3 under 2.4.3 kernel. If someone knows, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Sat Jul 21 10:42:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LHg3V26460 for linux-mips-outgoing; Sat, 21 Jul 2001 10:42:03 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LHfkV26452; Sat, 21 Jul 2001 10:41:46 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6B50E125BA; Sat, 21 Jul 2001 10:41:44 -0700 (PDT) Date: Sat, 21 Jul 2001 10:41:44 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Greg Satz , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721104144.A17894@lucon.org> References: <20010721033019.A22637@bacchus.dhis.org> <20010721141119.A25053@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: <20010721141119.A25053@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 21, 2001 at 02:11:20PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 322 Lines: 10 On Sat, Jul 21, 2001 at 02:11:20PM +0200, Ralf Baechle wrote: > Only if you don't compile / assemble / link with -G 0. > > .scommon shouldn't ever be in a kernel object. It seems that ld started > to move .common objects to .scommon from a certain version on, so 2.4.5 Send me a testcase. I will fix the linker. H.J. From owner-linux-mips@oss.sgi.com Sat Jul 21 11:11:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LIBbu27321 for linux-mips-outgoing; Sat, 21 Jul 2001 11:11:37 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LIBXV27312; Sat, 21 Jul 2001 11:11:33 -0700 Received: from [10.21.56.226] (earth.ayrnetworks.com [10.1.1.24]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6LIAUr24590; Sat, 21 Jul 2001 11:10:30 -0700 User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 21 Jul 2001 12:12:29 -0600 Subject: Re: SHN_MIPS_SCOMMON From: Greg Satz To: "H . J . Lu" , Ralf Baechle CC: Message-ID: In-Reply-To: <20010721104144.A17894@lucon.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 602 Lines: 21 The problem I ran into was making NFS as a kernel module. The resulting sunrpc.o module crashed when insmod was run over it. Ralf's fix that all compiles and links use -G 0 worked for me. Thanks, Greg on 7/21/01 11:41 AM, H . J . Lu at hjl@lucon.org wrote: > On Sat, Jul 21, 2001 at 02:11:20PM +0200, Ralf Baechle wrote: >> Only if you don't compile / assemble / link with -G 0. >> >> .scommon shouldn't ever be in a kernel object. It seems that ld started >> to move .common objects to .scommon from a certain version on, so 2.4.5 > > Send me a testcase. I will fix the linker. > > > H.J. > From owner-linux-mips@oss.sgi.com Sat Jul 21 11:13:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LIDJX27439 for linux-mips-outgoing; Sat, 21 Jul 2001 11:13:19 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LIDHV27436; Sat, 21 Jul 2001 11:13:17 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id 788D2125BA; Sat, 21 Jul 2001 11:13:16 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 2E89AEC2D; Sat, 21 Jul 2001 11:13:16 -0700 (PDT) Date: Sat, 21 Jul 2001 11:13:16 -0700 From: "H . J . Lu" To: Greg Satz Cc: Ralf Baechle , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721111315.A9479@lucon.org> References: <20010721104144.A17894@lucon.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 satz@ayrnetworks.com on Sat, Jul 21, 2001 at 12:12:29PM -0600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 348 Lines: 10 On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote: > The problem I ran into was making NFS as a kernel module. The resulting > sunrpc.o module crashed when insmod was run over it. Ralf's fix that all > compiles and links use -G 0 worked for me. In that case, it is no linker bug. I believe -G 0 is required for mips kernel modules. H.J. From owner-linux-mips@oss.sgi.com Sat Jul 21 11:55:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LItX728577 for linux-mips-outgoing; Sat, 21 Jul 2001 11:55:33 -0700 Received: from dea.waldorf-gmbh.de (u-151-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LItUV28574 for ; Sat, 21 Jul 2001 11:55:30 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LIt2026575; Sat, 21 Jul 2001 20:55:02 +0200 Date: Sat, 21 Jul 2001 20:55:02 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Greg Satz , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721205502.A25928@bacchus.dhis.org> References: <20010721033019.A22637@bacchus.dhis.org> <20010721141119.A25053@bacchus.dhis.org> <20010721104144.A17894@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010721104144.A17894@lucon.org>; from hjl@lucon.org on Sat, Jul 21, 2001 at 10:41:44AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 339 Lines: 10 On Sat, Jul 21, 2001 at 10:41:44AM -0700, H . J . Lu wrote: > > .scommon shouldn't ever be in a kernel object. It seems that ld started > > to move .common objects to .scommon from a certain version on, so 2.4.5 > > Send me a testcase. I will fix the linker. There is no linker bug, this is just the GP optimization in action. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 11:59:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LIx5228766 for linux-mips-outgoing; Sat, 21 Jul 2001 11:59:05 -0700 Received: from dea.waldorf-gmbh.de (u-151-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LIvUV28705 for ; Sat, 21 Jul 2001 11:57:37 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LIuxG26582; Sat, 21 Jul 2001 20:56:59 +0200 Date: Sat, 21 Jul 2001 20:56:59 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Greg Satz , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721205659.B25928@bacchus.dhis.org> References: <20010721104144.A17894@lucon.org> <20010721111315.A9479@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010721111315.A9479@lucon.org>; from hjl@lucon.org on Sat, Jul 21, 2001 at 11:13:16AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 508 Lines: 14 On Sat, Jul 21, 2001 at 11:13:16AM -0700, H . J . Lu wrote: > On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote: > > The problem I ran into was making NFS as a kernel module. The resulting > > sunrpc.o module crashed when insmod was run over it. Ralf's fix that all > > compiles and links use -G 0 worked for me. > > In that case, it is no linker bug. I believe -G 0 is required for > mips kernel modules. Actually for all code; we don't support GP optimization in any of our code models. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 12:03:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LJ36c29060 for linux-mips-outgoing; Sat, 21 Jul 2001 12:03:06 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LJ33V29057; Sat, 21 Jul 2001 12:03:03 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id D2B04125BA; Sat, 21 Jul 2001 12:03:02 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 5D081EC2D; Sat, 21 Jul 2001 12:03:02 -0700 (PDT) Date: Sat, 21 Jul 2001 12:03:02 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Greg Satz , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010721120302.A10173@lucon.org> References: <20010721104144.A17894@lucon.org> <20010721111315.A9479@lucon.org> <20010721205659.B25928@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: <20010721205659.B25928@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 21, 2001 at 08:56:59PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 932 Lines: 22 On Sat, Jul 21, 2001 at 08:56:59PM +0200, Ralf Baechle wrote: > On Sat, Jul 21, 2001 at 11:13:16AM -0700, H . J . Lu wrote: > > > On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote: > > > The problem I ran into was making NFS as a kernel module. The resulting > > > sunrpc.o module crashed when insmod was run over it. Ralf's fix that all > > > compiles and links use -G 0 worked for me. > > > > In that case, it is no linker bug. I believe -G 0 is required for > > mips kernel modules. > > Actually for all code; we don't support GP optimization in any of our code > models. Even for the user space code? Do you have a testcase to show what should be the desired behavior? As I understand, the SHN_MIPS_SCOMMON section only appears in the relocatable files. You won't see it in executables nor DSOs. Are there any problems with SHN_MIPS_SCOMMON in .o files? Can we always pass `-G 0' to the assemebler for Linux. H.J. From owner-linux-mips@oss.sgi.com Sat Jul 21 12:07:45 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LJ7jh29237 for linux-mips-outgoing; Sat, 21 Jul 2001 12:07:45 -0700 Received: from dea.waldorf-gmbh.de (u-151-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LJ7gV29234 for ; Sat, 21 Jul 2001 12:07:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LJ7bR26639; Sat, 21 Jul 2001 21:07:37 +0200 Date: Sat, 21 Jul 2001 21:07:37 +0200 From: Ralf Baechle To: Lars Munch Christensen Cc: linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010721210737.D25928@bacchus.dhis.org> References: <20010721112715.C2335@tuxedo.skovlyporten.dk> <20010721172309.A25467@bacchus.dhis.org> <20010721181733.A3591@tuxedo.skovlyporten.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010721181733.A3591@tuxedo.skovlyporten.dk>; from c948114@student.dtu.dk on Sat, Jul 21, 2001 at 06:17:33PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 247 Lines: 8 On Sat, Jul 21, 2001 at 06:17:33PM +0200, Lars Munch Christensen wrote: > Thanks...What should I do now? Change my code to mips32 or are there some > patches to binutils that I can use, to get it working? Depends on what you want to do? Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 13:52:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LKq8m04778 for linux-mips-outgoing; Sat, 21 Jul 2001 13:52:08 -0700 Received: from colo.asti-usa.com (IDENT:root@colo.asti-usa.com [205.252.89.99]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LKq7V04775 for ; Sat, 21 Jul 2001 13:52:07 -0700 Received: from lineo.com (raven.lineo.com [64.50.107.47]) by colo.asti-usa.com (8.9.3/8.9.3) with ESMTP id RAA05483 for ; Sat, 21 Jul 2001 17:00:51 -0400 Message-ID: <3B59FC0D.6CAD443C@lineo.com> Date: Sat, 21 Jul 2001 23:02:53 +0100 From: Steve Papacharalambous Organization: Lineo Inc X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@oss.sgi.com Subject: Interrupts in modules Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 286 Lines: 12 Hi All, Are there any limitations or precautions needed with interrupt handlers in loadable modules? The reason for asking is that I have an interrupt handler which works fine when compiled into the kernel, but causes the kernel to crash when it is a loadable module, Thanks, Steve From owner-linux-mips@oss.sgi.com Sat Jul 21 16:20:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6LNKoB16673 for linux-mips-outgoing; Sat, 21 Jul 2001 16:20:50 -0700 Received: from dea.waldorf-gmbh.de (u-151-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.151]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6LNKkV16659 for ; Sat, 21 Jul 2001 16:20:47 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6LNKGj27609; Sun, 22 Jul 2001 01:20:16 +0200 Date: Sun, 22 Jul 2001 01:20:16 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Greg Satz , linux-mips@oss.sgi.com Subject: Re: SHN_MIPS_SCOMMON Message-ID: <20010722012016.I25928@bacchus.dhis.org> References: <20010721104144.A17894@lucon.org> <20010721111315.A9479@lucon.org> <20010721205659.B25928@bacchus.dhis.org> <20010721120302.A10173@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010721120302.A10173@lucon.org>; from hjl@lucon.org on Sat, Jul 21, 2001 at 12:03:02PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1076 Lines: 26 On Sat, Jul 21, 2001 at 12:03:02PM -0700, H . J . Lu wrote: > > Actually for all code; we don't support GP optimization in any of our code > > models. > > Even for the user space code? Yes. GP optimization isn't comparible with SVR4 PIC code. I don't see a fundamental problem to get that to work but gcc refuses the use of -G with PIC code. What would limit the value of the GP optimization is that for alot of code a single 64kb GP data segment is not large enough; the IRIX compiler and Alpha binutils afaik support a multi-gp code model already. > Do you have a testcase to show what should be the desired behavior? As I > understand, the SHN_MIPS_SCOMMON section only appears in the relocatable > files. You won't see it in > executables nor DSOs. Are there any problems with SHN_MIPS_SCOMMON > in .o files? Can we always pass `-G 0' to the assemebler for Linux. It's already guanteed that we never use GP optimization. The particular case which was reported by the user was caused ld directly which defaults to -G 8. That's not an issue for userspace. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 21 18:17:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6M1HdI26139 for linux-mips-outgoing; Sat, 21 Jul 2001 18:17:39 -0700 Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6M1HaV26133 for ; Sat, 21 Jul 2001 18:17:37 -0700 Received: (qmail 3184 invoked from network); 22 Jul 2001 01:17:31 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 22 Jul 2001 01:17:31 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Steve Papacharalambous cc: linux-mips@oss.sgi.com Subject: Re: Interrupts in modules In-reply-to: Your message of "Sat, 21 Jul 2001 23:02:53 +0100." <3B59FC0D.6CAD443C@lineo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Jul 2001 11:17:29 +1000 Message-ID: <1052.995764649@ocs3.ocs-net> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 987 Lines: 22 On Sat, 21 Jul 2001 23:02:53 +0100, Steve Papacharalambous wrote: >Are there any limitations or precautions needed with interrupt handlers >in loadable modules? There is a potential race condition when removing the module. rmmod will remove a module when its use count is zero. If the interrupt handler is invoked after the use count is tested but before the module cleanup routine is entered then the code can be removed while the interrupt handler is running. The 2.5 module load/unload system will remove this race. In 2.4, your best option is to set a can_unload() function in the module. Unregister the interrupt handler in can_unload(), wait until the interrupt count goes to zero (might be running on another cpu) then return 0. See drivers/char/ftape/compressor/zftape-compress.c for an example. Alternatively keep a use count for opens on the device. This assumes that the device does not generate interrupts while it is not open, not always true. From owner-linux-mips@oss.sgi.com Sat Jul 21 18:33:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6M1XQd27107 for linux-mips-outgoing; Sat, 21 Jul 2001 18:33:26 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6M1XOV27104 for ; Sat, 21 Jul 2001 18:33:25 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 04D007D9; Sun, 22 Jul 2001 03:33:22 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3FB8A43E8; Sun, 22 Jul 2001 03:30:38 +0200 (CEST) Date: Sun, 22 Jul 2001 03:30:38 +0200 From: Florian Lohoff To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? Message-ID: <20010722033038.B10591@paradigm.rfc822.org> References: <200107201749.KAA05236@saturn.mikemac.com> <20010720220155.D16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010720220155.D16278@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, Jul 20, 2001 at 10:01:55PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 722 Lines: 18 On Fri, Jul 20, 2001 at 10:01:55PM +0200, Thiemo Seufer wrote: > processes crash due to unaligned access/illegal instruction in > kernel space. The serial console drops characters on high > throughput. This is true for all sgis IMHO - I have seen this before on the Indy and Indigo2 - This is a bug in the sgiserial.c - I have tried to find it before but havent been successfull. Another bug lets the serial to freeze completely which prevents serial console machines from reboot as the and print to the console blocks. This has been fixed somewhere in the 2.4 area. Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Sat Jul 21 19:33:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6M2Xrx32379 for linux-mips-outgoing; Sat, 21 Jul 2001 19:33:53 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6M2XpV32376 for ; Sat, 21 Jul 2001 19:33:51 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id EAA25424 for ; Sun, 22 Jul 2001 04:33:50 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15O93z-0000x1-00 for ; Sun, 22 Jul 2001 04:33:47 +0200 Date: Sun, 22 Jul 2001 04:33:47 +0200 To: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? Message-ID: <20010722043347.J16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010722033038.B10591@paradigm.rfc822.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 857 Lines: 26 Florian Lohoff wrote: > On Fri, Jul 20, 2001 at 10:01:55PM +0200, Thiemo Seufer wrote: > > processes crash due to unaligned access/illegal instruction in > > kernel space. The serial console drops characters on high > > throughput. I've tested the serial console now with 38400 baud also, the characteristics of the dropouts didn't change. > This is true for all sgis IMHO - I have seen this before on the > Indy and Indigo2 - This is a bug in the sgiserial.c - I have tried > to find it before but havent been successfull. Well, then it's at least not a bug of mine. :-) > Another bug lets > the serial to freeze completely which prevents serial console > machines from reboot as the and print to the console blocks. > > This has been fixed somewhere in the 2.4 area. I haven't encountered this yet, so the fix seems to work for 64bit, too. Thiemo From owner-linux-mips@oss.sgi.com Sun Jul 22 02:39:33 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6M9dXm05927 for linux-mips-outgoing; Sun, 22 Jul 2001 02:39:33 -0700 Received: from fe070.worldonline.dk (fe070.worldonline.dk [212.54.64.208]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6M9dVV05919 for ; Sun, 22 Jul 2001 02:39:32 -0700 Received: (qmail 16487 invoked by uid 0); 22 Jul 2001 09:39:24 -0000 Received: from unknown (HELO tuxedo.skovlyporten.dk) (213.237.49.98) by fe070.worldonline.dk with SMTP; 22 Jul 2001 09:39:24 -0000 Received: by tuxedo.skovlyporten.dk (Postfix, from userid 501) id 75B192608F; Sun, 22 Jul 2001 11:39:23 +0200 (CEST) Date: Sun, 22 Jul 2001 11:39:23 +0200 From: Lars Munch Christensen To: Ralf Baechle Cc: Lars Munch Christensen , linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010722113923.A17752@tuxedo.skovlyporten.dk> References: <20010721112715.C2335@tuxedo.skovlyporten.dk> <20010721172309.A25467@bacchus.dhis.org> <20010721181733.A3591@tuxedo.skovlyporten.dk> <20010721210737.D25928@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: <20010721210737.D25928@bacchus.dhis.org>; from ralf@oss.sgi.com on Sat, Jul 21, 2001 at 09:07:37PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 795 Lines: 20 On Sat, Jul 21, 2001 at 09:07:37PM +0200, Ralf Baechle wrote: > On Sat, Jul 21, 2001 at 06:17:33PM +0200, Lars Munch Christensen wrote: > > > Thanks...What should I do now? Change my code to mips32 or are there some > > patches to binutils that I can use, to get it working? > > Depends on what you want to do? I'm working on a very small, single address space, microkernel and I have the MIPS Malta with a 5Kc CPU to develop it on. The 5Kc is compatible with mips32 but I must admit, I really like to have my kernel running 64bit :). Is there a working binutils for 64 bit code floating around somewhere or should I stick with the mips32 stuff? I tried the binutil from ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/ but they where unable to compile with target mips64-linux. Thanks Lars Munch From owner-linux-mips@oss.sgi.com Sun Jul 22 02:55:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6M9ttR07053 for linux-mips-outgoing; Sun, 22 Jul 2001 02:55:55 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6M9tpV07043; Sun, 22 Jul 2001 02:55:51 -0700 Received: from rose.sonytel.be (rose.sonytel.be [10.17.0.5]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA12054; Sun, 22 Jul 2001 11:55:50 +0200 (MET DST) Date: Sun, 22 Jul 2001 11:55:25 +0200 (MET DST) From: Geert Uytterhoeven To: Ralf Baechle cc: Jun Sun , Fuxin Zhang , "linux-mips@oss.sgi.com" Subject: Re: help on linux-mipsel frame buffer In-Reply-To: <20010721172518.B25467@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 712 Lines: 22 On Sat, 21 Jul 2001, Ralf Baechle wrote: > On Sat, Jul 21, 2001 at 12:53:52PM +0200, Geert Uytterhoeven wrote: > > That's because matroxfb is one of the few frame buffer devices that know how > > to initialize uninitialized cards. > > Is that true for all of the Matrox PCI cards or which would be your > recommendation? I think so. I know not all features are supported for the latest Matrox cards, but these are AGP only anyway. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Sun Jul 22 03:35:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MAZYZ10679 for linux-mips-outgoing; Sun, 22 Jul 2001 03:35:34 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MAZWV10674 for ; Sun, 22 Jul 2001 03:35:32 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id MAA30016 for ; Sun, 22 Jul 2001 12:35:31 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15OGa7-0003hV-00 for ; Sun, 22 Jul 2001 12:35:27 +0200 Date: Sun, 22 Jul 2001 12:35:26 +0200 To: linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010722123526.K16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010722113923.A17752@tuxedo.skovlyporten.dk> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1190 Lines: 32 Lars Munch Christensen wrote: > On Sat, Jul 21, 2001 at 09:07:37PM +0200, Ralf Baechle wrote: > > On Sat, Jul 21, 2001 at 06:17:33PM +0200, Lars Munch Christensen wrote: > > > > > Thanks...What should I do now? Change my code to mips32 or are there some > > > patches to binutils that I can use, to get it working? > > > > Depends on what you want to do? > > I'm working on a very small, single address space, microkernel and I have > the MIPS Malta with a 5Kc CPU to develop it on. The 5Kc is compatible > with mips32 but I must admit, I really like to have my kernel > running 64bit :). An Kernel with 64bit addresses is less compact and likely to run slower. OTOH, a 64bit Kernel has certainly some hack value. :-) > Is there a working binutils for 64 bit code floating > around somewhere or should I stick with the mips32 stuff? Using 32bit is surely the easier way to go. You might try the toolchain I use for my mips64-linux development. Be warned: It's barely good enough to compile a linux kernel, no pic code and therefore no libc. You have to compile it yourself, the source is available at http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/ Have fun. :-) Thiemo From owner-linux-mips@oss.sgi.com Sun Jul 22 03:58:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MAwcT12663 for linux-mips-outgoing; Sun, 22 Jul 2001 03:58:38 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MAwbV12660 for ; Sun, 22 Jul 2001 03:58:37 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA27423; Sun, 22 Jul 2001 03:57:56 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA05118; Sun, 22 Jul 2001 03:57:52 -0700 (PDT) Message-ID: <007301c1129d$cdf908e0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Thiemo Seufer" References: <20010722123526.K16278@rembrandt.csv.ica.uni-stuttgart.de> Subject: Re: mips64 linker bug? Date: Sun, 22 Jul 2001 13:02:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 917 Lines: 23 > > > > Thanks...What should I do now? Change my code to mips32 or are there some > > > > patches to binutils that I can use, to get it working? > > > > > > Depends on what you want to do? > > > > I'm working on a very small, single address space, microkernel and I have > > the MIPS Malta with a 5Kc CPU to develop it on. The 5Kc is compatible > > with mips32 but I must admit, I really like to have my kernel > > running 64bit :). > > An Kernel with 64bit addresses is less compact and likely to run slower. > OTOH, a 64bit Kernel has certainly some hack value. :-) Note that the 5Kc is one of the new generation of MIPS64 parts that can enable 64-bit integer and floating point instructions without requiring that 64-bit addressing also be enabled in the kernel. Making Linux kernel support for this capability available is one of the things that we're working on. But it's not there yet. Kevin K. From owner-linux-mips@oss.sgi.com Sun Jul 22 04:07:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MB7g113501 for linux-mips-outgoing; Sun, 22 Jul 2001 04:07:42 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MB7dV13495 for ; Sun, 22 Jul 2001 04:07:40 -0700 Received: from scotty.mgnet.de (pD957B5B4.dip.t-dialin.net [217.87.181.180]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id NAA27005 for ; Sun, 22 Jul 2001 13:07:37 +0200 (MET DST) Received: (qmail 24496 invoked from network); 22 Jul 2001 11:07:36 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 22 Jul 2001 11:07:36 -0000 Date: Sun, 22 Jul 2001 13:07:29 +0200 (CEST) From: Klaus Naumann To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: I2 R10K status? In-Reply-To: <20010722043347.J16278@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 812 Lines: 26 On Sun, 22 Jul 2001, Thiemo Seufer wrote: > Florian Lohoff wrote: > > On Fri, Jul 20, 2001 at 10:01:55PM +0200, Thiemo Seufer wrote: > > > processes crash due to unaligned access/illegal instruction in > > > kernel space. The serial console drops characters on high > > > throughput. > > I've tested the serial console now with 38400 baud also, > the characteristics of the dropouts didn't change. ok - when I have time next week I'll read through sgiserial.c and clean it up a bit ... maybe I find the bug ... > Well, then it's at least not a bug of mine. :-) No. :-) -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Sun Jul 22 04:15:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MBFSx14057 for linux-mips-outgoing; Sun, 22 Jul 2001 04:15:28 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MBFRV14051 for ; Sun, 22 Jul 2001 04:15:27 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id NAA30828 for ; Sun, 22 Jul 2001 13:15:25 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15OHCn-0005mZ-00 for ; Sun, 22 Jul 2001 13:15:25 +0200 Date: Sun, 22 Jul 2001 13:15:25 +0200 To: linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010722131525.L16278@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007301c1129d$cdf908e0$0deca8c0@Ulysses> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 623 Lines: 19 Kevin D. Kissell wrote: [snip] > > An Kernel with 64bit addresses is less compact and likely to run slower. > > OTOH, a 64bit Kernel has certainly some hack value. :-) > > Note that the 5Kc is one of the new generation of MIPS64 parts > that can enable 64-bit integer and floating point instructions without > requiring that 64-bit addressing also be enabled in the kernel. Sorry, but I can't see what's new here. AFAICS this possibility existed already in MIPS III. > Making Linux kernel support for this capability available is > one of the things that we're working on. But it's not there yet. I know. :-) Thiemo From owner-linux-mips@oss.sgi.com Sun Jul 22 04:40:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MBekZ20431 for linux-mips-outgoing; Sun, 22 Jul 2001 04:40:46 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MBejV20426 for ; Sun, 22 Jul 2001 04:40:45 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA27510; Sun, 22 Jul 2001 04:40:04 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA05843; Sun, 22 Jul 2001 04:40:01 -0700 (PDT) Message-ID: <007d01c112a3$b10134a0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Thiemo Seufer" References: <20010722131525.L16278@rembrandt.csv.ica.uni-stuttgart.de> Subject: Re: mips64 linker bug? Date: Sun, 22 Jul 2001 13:44:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1061 Lines: 26 > Kevin D. Kissell wrote: > [snip] > > > An Kernel with 64bit addresses is less compact and likely to run slower. > > > OTOH, a 64bit Kernel has certainly some hack value. :-) > > > > Note that the 5Kc is one of the new generation of MIPS64 parts > > that can enable 64-bit integer and floating point instructions without > > requiring that 64-bit addressing also be enabled in the kernel. > > Sorry, but I can't see what's new here. AFAICS this possibility existed > already in MIPS III. Sorry if I wasn't clear. It is only the newer parts that can enable the use of the 64-bit instructions *in user mode* without also enabling 64-bit addressng. It's true that MIPS III/IV parts provide access to those instructions in kernel regardless of the state of the Status.KX bit, but in user mode they are only available if the Status.UX bit is set, enabling 64-bit addressing. MIPS64 CPU's have an additional bit in the Status register (Bit 23, "PX") to enable 64-bit instructions without enabling 64-bit addressing. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Sun Jul 22 11:28:41 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MISfg02738 for linux-mips-outgoing; Sun, 22 Jul 2001 11:28:41 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MISeV02735 for ; Sun, 22 Jul 2001 11:28:40 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id DAB8A125BA; Sun, 22 Jul 2001 11:28:38 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id EA0B0EC2D; Sun, 22 Jul 2001 11:28:37 -0700 (PDT) Date: Sun, 22 Jul 2001 11:28:37 -0700 From: "H . J . Lu" To: Steve Papacharalambous Cc: linux-mips@oss.sgi.com Subject: Re: Interrupts in modules Message-ID: <20010722112837.A22440@lucon.org> References: <3B59FC0D.6CAD443C@lineo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B59FC0D.6CAD443C@lineo.com>; from stevep@lineo.com on Sat, Jul 21, 2001 at 11:02:53PM +0100 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 512 Lines: 16 On Sat, Jul 21, 2001 at 11:02:53PM +0100, Steve Papacharalambous wrote: > Hi All, > > Are there any limitations or precautions needed with interrupt handlers > in loadable modules? > > The reason for asking is that I have an interrupt handler which works > fine when compiled into the kernel, but causes the kernel to crash when > it is a loadable module, There are some gas bugs which may generate the bad binary code. It happened to me with the tulip driver. The current Linux binutils should be ok. H.J. From owner-linux-mips@oss.sgi.com Sun Jul 22 14:23:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MLNBt08596 for linux-mips-outgoing; Sun, 22 Jul 2001 14:23:11 -0700 Received: from dea.waldorf-gmbh.de (u-133-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.133]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MLN8V08593 for ; Sun, 22 Jul 2001 14:23:08 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6MLN1p13823; Sun, 22 Jul 2001 23:23:01 +0200 Date: Sun, 22 Jul 2001 23:23:01 +0200 From: Ralf Baechle To: Lars Munch Christensen Cc: linux-mips@oss.sgi.com Subject: Re: mips64 linker bug? Message-ID: <20010722232301.B13551@bacchus.dhis.org> References: <20010721112715.C2335@tuxedo.skovlyporten.dk> <20010721172309.A25467@bacchus.dhis.org> <20010721181733.A3591@tuxedo.skovlyporten.dk> <20010721210737.D25928@bacchus.dhis.org> <20010722113923.A17752@tuxedo.skovlyporten.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010722113923.A17752@tuxedo.skovlyporten.dk>; from c948114@student.dtu.dk on Sun, Jul 22, 2001 at 11:39:23AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1005 Lines: 20 On Sun, Jul 22, 2001 at 11:39:23AM +0200, Lars Munch Christensen wrote: > I'm working on a very small, single address space, microkernel and I have > the MIPS Malta with a 5Kc CPU to develop it on. The 5Kc is compatible > with mips32 but I must admit, I really like to have my kernel > running 64bit :). Is there a working binutils for 64 bit code floating > around somewhere or should I stick with the mips32 stuff? > > I tried the binutil from ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/ but > they where unable to compile with target mips64-linux. Afaik the mips64-linux binutils are the only one that more (or more less ;) work for building a 64-bit kernel. What we have to do to get around the bugs and missing features is building a 64-bit kernel but passing -32 to the assembler so we never use 64-bit ELF. In the end we convert the resulting 32-bit ELF executable into 64-ELF using objcopy. That's about as much as 64-bit binutils are usable for. For details see arch/mips64/Makefile. Ralf From owner-linux-mips@oss.sgi.com Sun Jul 22 15:23:29 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MMNTe13544 for linux-mips-outgoing; Sun, 22 Jul 2001 15:23:29 -0700 Received: from ex-mail-server.sctcn.com (nszx104.119.szptt.net.cn [202.104.119.148] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MMNRV13539 for ; Sun, 22 Jul 2001 15:23:28 -0700 Message-Id: <200107222223.f6MMNRV13539@oss.sgi.com> Received: from plain (202.105.16.164 [202.105.16.164]) by ex-mail-server.sctcn.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NHBDJPTQ; Mon, 23 Jul 2001 02:07:13 +0800 From: travelincentives@yahoo.com To: ggjem12345@aol.com Subject: Re: Winning Confirmation 444 Date: Mon, 23 Jul 2001 01:55:24 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 529 Lines: 15 You have been specially selected to qualify for the following: Premium Vacation Package and Pentium PC Giveaway To review the details of the please click on the link with the confirmation number below: http://www.1chn.com/wintrip Confirmation Number#Lh340 Please confirm your entry within 24 hours of receipt of this confirmation. Wishing you a fun filled vacation! If you should have any additional questions or cann't connect to the site do not hesitate to contact me direct: mailto:vacation@btamail.net.cn?subject=Help! From owner-linux-mips@oss.sgi.com Sun Jul 22 15:52:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6MMqkV16384 for linux-mips-outgoing; Sun, 22 Jul 2001 15:52:46 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6MMqhV16377 for ; Sun, 22 Jul 2001 15:52:44 -0700 Received: from scotty.mgnet.de (pD957B5B4.dip.t-dialin.net [217.87.181.180]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id AAA09969 for ; Mon, 23 Jul 2001 00:52:37 +0200 (MET DST) Received: (qmail 28833 invoked from network); 22 Jul 2001 22:52:32 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 22 Jul 2001 22:52:32 -0000 Date: Mon, 23 Jul 2001 00:52:26 +0200 (CEST) From: Klaus Naumann To: Linux/MIPS list Subject: Workaround for Multiple Disk Problem Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811071-1968279449-995842346=:15244" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3518 Lines: 72 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463811071-1968279449-995842346=:15244 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, the attached patch is a _WORK-AROUND_ for the Multiple Disk Problem which is one of the biggest show stoppers on Indy/Indigo2 systems. It disables DMA transfers to the SCSI bus. I'm not sure if this is much slower. Please consider this a work around for machines which have small disks and need them all to make up a decent build machine or so ... The patch implements a new config option right below SGI WD33C93 SCSI Support in the SCSI Devices Configuration. Activate it and recompile your kernel (you may have to do make distclean to recompile). The driver will display a warning at boot time that this kernel has DMA disabled. I also know that this C code is the kind of C code which is really bad. It's somewhat like the stuff your mother has warned you before when you were young ... But well it's a hack so I don't care. Enjoy, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt ---1463811071-1968279449-995842346=:15244 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sgiwd93_nodma.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="sgiwd93_nodma.patch" LS0tIGN2cy9saW51eC9kcml2ZXJzL3Njc2kvQ29uZmlnLmluCVN1biBBcHIg MTUgMTc6MTY6MDcgMjAwMQ0KKysrIGxpbnV4LmJ1aWxkL2RyaXZlcnMvc2Nz aS9Db25maWcuaW4JU3VuIEp1bCAyMiAyMzo1MToxOSAyMDAxDQpAQCAtMzQs NiArMzQsOSBAQA0KIA0KIGlmIFsgIiRDT05GSUdfU0dJX0lQMjIiID0gInki IF07IHRoZW4NCiAgICBkZXBfdHJpc3RhdGUgJ1NHSSBXRDkzQzkzIFNDU0kg RHJpdmVyJyBDT05GSUdfU0dJV0Q5M19TQ1NJICRDT05GSUdfU0NTSQ0KKyAg IGlmIFsgIiRDT05GSUdfU0dJV0Q5M19TQ1NJIiAhPSAibiIgXTsgdGhlbg0K KyAgICAgIGJvb2wgJyAgRGlzYWJsZSBETUEgZm9yIFNHSSBXRDMzQzkzIFND U0kgRHJpdmVyJyBDT05GSUdfU0dJV0Q5M19TQ1NJX05PRE1BDQorICAgZmkN CiBmaQ0KIGlmIFsgIiRDT05GSUdfREVDU1RBVElPTiIgPSAieSIgXTsgdGhl bg0KICAgIGlmIFsgIiRDT05GSUdfVEMiID0gInkiIF07IHRoZW4NCi0tLSBj dnMvbGludXgvZHJpdmVycy9zY3NpL3NnaXdkOTMuYwlUdWUgTWFyIDI3IDAw OjExOjQ5IDIwMDENCisrKyBsaW51eC5idWlsZC9kcml2ZXJzL3Njc2kvc2dp d2Q5My5jCVN1biBKdWwgMjIgMjM6NTk6NTYgMjAwMQ0KQEAgLTEwMiw2ICsx MDIsMjEgQEANCiAJd2QzM2M5M19yZWdzICpyZWdwID0gaGRhdGEtPnJlZ3A7 DQogCXN0cnVjdCBocGMzX3Njc2lyZWdzICpocmVncyA9IChzdHJ1Y3QgaHBj M19zY3NpcmVncyAqKSBjbWQtPmhvc3QtPmJhc2U7DQogCXN0cnVjdCBocGNf Y2h1bmsgKmhjcCA9IChzdHJ1Y3QgaHBjX2NodW5rICopIGhkYXRhLT5kbWFf Ym91bmNlX2J1ZmZlcjsNCisjaWZkZWYgQ09ORklHX1NHSVdEOTNfU0NTSV9O T0RNQQ0KKwlzdGF0aWMgaW50IHByaW50d2FybmluZyA9IDA7DQorI2VuZGlm DQorDQorLyogS2xhdXMgTmF1bWFubiAtIHRoaXMgaXMgYSB0ZW1wb3Jhcnkg d29ya2Fyb3VuZCB1bnRpbA0KK3dlIHNvcnRlZCBvdXQgdGhlIERNQSBidWcg d2hpY2ggb2Njb3VycyBpZiB0d28gZGlza3MgYXJlDQorY29ubmVjdGVkIHRv IHRoZSBzYW1lIFNDU0kgYnVzLg0KKyovDQorI2lmZGVmIENPTkZJR19TR0lX RDkzX1NDU0lfTk9ETUENCisJaWYocHJpbnR3YXJuaW5nID09IDApIHsNCisJ CXByaW50aygiXG5cbiAtLS0gV0FSTklORyAtLS0gRE1BIGlzIGRpc2FibGVk IC0tLSBXQVJOSU5HIC0tLVxuXG5cbiIpOw0KKwkJcHJpbnR3YXJuaW5nID0g MTsNCisJfQ0KKwlyZXR1cm4gVFJVRTsNCisjZW5kaWYNCiANCiAjaWZkZWYg REVCVUdfRE1BDQogCXByaW50aygiZG1hX3NldHVwOiBkYXRhaW5wPCVkPiBo Y3A8JXA+ICIsDQo= ---1463811071-1968279449-995842346=:15244-- From owner-linux-mips@oss.sgi.com Sun Jul 22 23:51:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6N6pQn11239 for linux-mips-outgoing; Sun, 22 Jul 2001 23:51:26 -0700 Received: from web13905.mail.yahoo.com (web13905.mail.yahoo.com [216.136.175.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6N6pPV11236 for ; Sun, 22 Jul 2001 23:51:25 -0700 Message-ID: <20010723065125.26642.qmail@web13905.mail.yahoo.com> Received: from [61.133.135.16] by web13905.mail.yahoo.com via HTTP; Sun, 22 Jul 2001 23:51:25 PDT Date: Sun, 22 Jul 2001 23:51:25 -0700 (PDT) From: Barry Wu Subject: about serial console problem To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 676 Lines: 21 Hi, all, I am porting linux 2.4.3 to our mipsel evaluation board. Now I meet a problem. Because I use edown to download the linux kernel to evaluation board. I update the serial baud rate to 115200. I use serial 0 as our console, and I can use printk to print debug messages on serial port. But after kernel call /sbin/init, I can not see "INIT ... ..." messages on serial port. I suppose perhaps I make some mistakes. But when I use 2.2.12 kernel, it ok. If someone knows, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Mon Jul 23 00:13:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6N7DCi12111 for linux-mips-outgoing; Mon, 23 Jul 2001 00:13:12 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6N7DBV12108 for ; Mon, 23 Jul 2001 00:13:11 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id AAA05617 for ; Mon, 23 Jul 2001 00:12:52 -0700 (PDT) mail_from (kaos@melbourne.sgi.com) 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 RAA28097; Mon, 23 Jul 2001 17:11:38 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Barry Wu cc: linux-mips@oss.sgi.com Subject: Re: about serial console problem In-reply-to: Your message of "Sun, 22 Jul 2001 23:51:25 MST." <20010723065125.26642.qmail@web13905.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 17:11:38 +1000 Message-ID: <13590.995872298@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 676 Lines: 16 On Sun, 22 Jul 2001 23:51:25 -0700 (PDT), Barry Wu wrote: >I am porting linux 2.4.3 to our mipsel evaluation >board. Now I meet a problem. Because I use edown >to download the linux kernel to evaluation board. >I update the serial baud rate to 115200. >I use serial 0 as our console, and I can use >printk to print debug messages on serial port. >But after kernel call /sbin/init, I can not >see "INIT ... ..." messages on serial port. Probably you did not code the console boot parameters correctly. In LILO, append="console=tty0 console=ttyS0,115200". printk is written to all consoles, init messages are only written to the last console specified. From owner-linux-mips@oss.sgi.com Mon Jul 23 02:02:06 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6N926w15978 for linux-mips-outgoing; Mon, 23 Jul 2001 02:02:06 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6N924V15975 for ; Mon, 23 Jul 2001 02:02:04 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6N921423438; Mon, 23 Jul 2001 10:02:01 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id KAA03595; Mon, 23 Jul 2001 10:02:00 +0100 (BST) Message-ID: <006b01c11356$227ae880$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "James Simmons" Cc: "Linux-MIPS" Subject: Re: ATI Victoria on Malta Date: Mon, 23 Jul 2001 10:02:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 312 Lines: 11 >> There does seem to be some code for the ATI Rage XL hardware (as used on the >> card) in v2.4.6 of the kernel. > >I don't have this board but give the atyfb framebuffer a try. This is what I tried. Sadly it locks up at various places and I don't have a logic analyser or any documentation. Andrew Thornton From owner-linux-mips@oss.sgi.com Mon Jul 23 03:01:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NA1kO17512 for linux-mips-outgoing; Mon, 23 Jul 2001 03:01:46 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NA1hV17509 for ; Mon, 23 Jul 2001 03:01:44 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 23 Jul 2001 10:01:45 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) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 23 03:08:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NA88Q17707 for linux-mips-outgoing; Mon, 23 Jul 2001 03:08:08 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NA86V17704 for ; Mon, 23 Jul 2001 03:08:07 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 23 Jul 2001 10:08:08 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) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 23 03:22:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NAMFq18271 for linux-mips-outgoing; Mon, 23 Jul 2001 03:22:15 -0700 Received: from topsns.toshiba-tops.co.jp (topsns.toshiba-tops.co.jp [202.230.225.5]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NAMDV18268 for ; Mon, 23 Jul 2001 03:22:13 -0700 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for oss.sgi.com [216.32.174.27]) with SMTP; 23 Jul 2001 10:22:14 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) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 23 05:16:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NCGJp25738 for linux-mips-outgoing; Mon, 23 Jul 2001 05:16:19 -0700 Received: from storm.physik.tu-cottbus.de (storm.physik.TU-Cottbus.De [141.43.75.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NCGIV25734 for ; Mon, 23 Jul 2001 05:16:18 -0700 Received: by storm.physik.tu-cottbus.de (Postfix, from userid 7215) id A74356004F; Mon, 23 Jul 2001 14:16:09 +0200 (CEST) Date: Mon, 23 Jul 2001 14:16:09 +0200 To: Debian boot mailing list Cc: Linux/MIPS list , debian-mips@lists.debian.org Subject: new root.bin and root.tar.gz Message-ID: <20010723141609.A29649@physik.tu-cottbus.de> Mail-Followup-To: heinold@physik.tu-cottbus.de, Debian boot mailing list , Linux/MIPS list , debian-mips@lists.debian.org References: <20010722155210.A6818@kyllikki.infodorm.north.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010722155210.A6818@kyllikki.infodorm.north.de> User-Agent: Mutt/1.3.18i From: heinold@physik.tu-cottbus.de (H.Heinold) Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 441 Lines: 19 hi, I made new debian-bootfloppies root.bin and root.tar.gz with the actual cvs including the patch from Martin Schulze. Please download and test it when you can http://www.physik.tu-cottbus.de/users/heinold/mipsel/root.bin http://www.physik.tu-cottbus.de/users/heinold/mipsel/root.tar.gz root.bin is the debian-initrd, which normaly is on the second bootfloppy(1,44 size). root.tar.gz is a nfs-root enviroment -- Henning Heinold From owner-linux-mips@oss.sgi.com Mon Jul 23 07:30:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NEU5Y02842 for linux-mips-outgoing; Mon, 23 Jul 2001 07:30:05 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NEU3V02824 for ; Mon, 23 Jul 2001 07:30:03 -0700 Received: from [192.168.1.167] (192.168.1.167 [192.168.1.167]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PJLG2B7W; Mon, 23 Jul 2001 10:29:56 -0400 Subject: Re: about serial console problem From: Marc Karasek To: Barry Wu Cc: linux-mips@oss.sgi.com In-Reply-To: <20010723065125.26642.qmail@web13905.mail.yahoo.com> References: <20010723065125.26642.qmail@web13905.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.10.99 (Preview Release) Date: 23 Jul 2001 10:29:20 -0400 Message-Id: <995898583.1139.2.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1628 Lines: 50 This sounds like a problem I ran into on another processor/platform. What are you using for a ramdisk? Is it busybox? There was a bug in 0.51 busybox that would not let it accept input from a console on a serial port. It had to do with the init for the serial port. You can check the patch file below to see the problem that was in busybox... --- init.c.orig Sat Apr 21 17:46:57 2001 +++ init.c Sat Apr 21 17:46:31 2001 @@ -276,7 +276,7 @@ /* Make it be sane */ tty.c_cflag &= CBAUD|CBAUDEX|CSIZE|CSTOPB|PARENB|PARODD; - tty.c_cflag |= HUPCL|CLOCAL; + tty.c_cflag |= CREAD|HUPCL|CLOCAL; /* input modes */ tty.c_iflag = ICRNL | IXON | IXOFF; On 22 Jul 2001 23:51:25 -0700, Barry Wu wrote: > > Hi, all, > > I am porting linux 2.4.3 to our mipsel evaluation > board. Now I meet a problem. Because I use edown > to download the linux kernel to evaluation board. > I update the serial baud rate to 115200. > I use serial 0 as our console, and I can use > printk to print debug messages on serial port. > But after kernel call /sbin/init, I can not > see "INIT ... ..." messages on serial port. > I suppose perhaps I make some mistakes. But when > I use 2.2.12 kernel, it ok. > If someone knows, please help me. Thanks! > > Barry > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Mon Jul 23 10:26:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NHQK212207 for linux-mips-outgoing; Mon, 23 Jul 2001 10:26:20 -0700 Received: from dea.waldorf-gmbh.de (u-223-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.223]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NHQGa12204 for ; Mon, 23 Jul 2001 10:26:17 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 owner-linux-mips@oss.sgi.com Mon Jul 23 10:26:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NHQhG12258 for linux-mips-outgoing; Mon, 23 Jul 2001 10:26:43 -0700 Received: from dea.waldorf-gmbh.de (u-223-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.223]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NHQda12249 for ; Mon, 23 Jul 2001 10:26:39 -0700 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk 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 From owner-linux-mips@oss.sgi.com Mon Jul 23 13:15:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NKFFS01219 for linux-mips-outgoing; Mon, 23 Jul 2001 13:15:15 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NKFDX01215 for ; Mon, 23 Jul 2001 13:15:13 -0700 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA04586 for ; Mon, 23 Jul 2001 12:57:01 -0700 (PDT) mail_from (airlied@csn.ul.ie) Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id 054B82B3EF; Mon, 23 Jul 2001 20:57:07 +0100 (IST) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 6454CA8A6; Mon, 23 Jul 2001 20:56:56 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id 5FA4FA8A5; Mon, 23 Jul 2001 20:56:56 +0100 (IST) Date: Mon, 23 Jul 2001 20:56:56 +0100 (IST) From: Dave Airlie X-X-Sender: To: Marc Karasek Cc: Barry Wu , Subject: Re: about serial console problem In-Reply-To: <995898583.1139.2.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2038 Lines: 69 Cool, this patch fixed a problem we were seeing with busybox on the Linux/VAX project, that I hadn't time to look at... thanks Dave. On 23 Jul 2001, Marc Karasek wrote: > This sounds like a problem I ran into on another processor/platform. > What are you using for a ramdisk? Is it busybox? There was a bug in > 0.51 busybox that would not let it accept input from a console on a > serial port. It had to do with the init for the serial port. You can > check the patch file below to see the problem that was in busybox... > > --- init.c.orig Sat Apr 21 17:46:57 2001 > +++ init.c Sat Apr 21 17:46:31 2001 > @@ -276,7 +276,7 @@ > > /* Make it be sane */ > tty.c_cflag &= CBAUD|CBAUDEX|CSIZE|CSTOPB|PARENB|PARODD; > - tty.c_cflag |= HUPCL|CLOCAL; > + tty.c_cflag |= CREAD|HUPCL|CLOCAL; > > /* input modes */ > tty.c_iflag = ICRNL | IXON | IXOFF; > > On 22 Jul 2001 23:51:25 -0700, Barry Wu wrote: > > > > Hi, all, > > > > I am porting linux 2.4.3 to our mipsel evaluation > > board. Now I meet a problem. Because I use edown > > to download the linux kernel to evaluation board. > > I update the serial baud rate to 115200. > > I use serial 0 as our console, and I can use > > printk to print debug messages on serial port. > > But after kernel call /sbin/init, I can not > > see "INIT ... ..." messages on serial port. > > I suppose perhaps I make some mistakes. But when > > I use 2.2.12 kernel, it ok. > > If someone knows, please help me. Thanks! > > > > Barry > > > > __________________________________________________ > > Do You Yahoo!? > > Make international calls for as low as $.04/minute with Yahoo! Messenger > > http://phonecard.yahoo.com/ > -- > /************************* > Marc Karasek > Sr. Firmware Engineer > iVivity Inc. > marc_karasek@ivivity.com > (770) 986-8925 > (770) 986-8926 Fax > *************************/ > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Mon Jul 23 13:19:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NKJqo01495 for linux-mips-outgoing; Mon, 23 Jul 2001 13:19:52 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NKJcX01490 for ; Mon, 23 Jul 2001 13:19:38 -0700 Received: from www.transvirtual.com (www.transvirtual.com [206.14.214.140]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA01369 for ; Mon, 23 Jul 2001 12:03:14 -0700 (PDT) mail_from (jsimmons@transvirtual.com) Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6NJ3Bc1030414; Mon, 23 Jul 2001 12:03:11 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6NJ3A7d030410; Mon, 23 Jul 2001 12:03:11 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Mon, 23 Jul 2001 12:03:10 -0700 (PDT) From: James Simmons To: Andrew Thornton cc: Linux-MIPS Subject: Re: ATI Victoria on Malta In-Reply-To: <006b01c11356$227ae880$d11110ac@snow.isltd.insignia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 403 Lines: 19 > >> There does seem to be some code for the ATI Rage XL hardware (as used on > the > >> card) in v2.4.6 of the kernel. > > > >I don't have this board but give the atyfb framebuffer a try. > > This is what I tried. Sadly it locks up at various places and I don't have a > logic analyser or any documentation. Turn on debugging in atyfb.c and post the results. /* * Debug flags. */ #undef DEBUG From owner-linux-mips@oss.sgi.com Mon Jul 23 13:31:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NKVUt02177 for linux-mips-outgoing; Mon, 23 Jul 2001 13:31:30 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NKVTX02174 for ; Mon, 23 Jul 2001 13:31:29 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA06919 for ; Mon, 23 Jul 2001 10:48:23 -0700 (PDT) mail_from (agx@gandalf.physik.uni-konstanz.de) Received: from galadriel.physik.uni-konstanz.de [134.34.144.79] (8) by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian)) id 15Ojok-0001z5-00; Mon, 23 Jul 2001 19:48:30 +0200 Received: from agx by galadriel.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15Ojok-0002M9-00; Mon, 23 Jul 2001 19:48:30 +0200 Date: Mon, 23 Jul 2001 19:48:30 +0200 From: Guido Guenther To: linux-mips@oss.sgi.com Subject: Segfaults on r4600 Message-ID: <20010723194830.A9033@galadriel.physik.uni-konstanz.de> Mail-Followup-To: linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 468 Lines: 9 I'm seeing various segfaults especially with perl on an R4600 Indy. R4000 I2 with identical debian packages works fine though. I have tried various kernels (cvs head as from two days ago(natively and crosscompiled) and 2.4.3-r4k-ip22 from rfc822.org. Interesting enough the segfaults disappear when using "strace -o/dev/null segfaulting_binary". I also tried to investigate the core file but gdb dies when loading it(gdb is 5.0-3 debian package). Any ideas, -- Guido From owner-linux-mips@oss.sgi.com Mon Jul 23 16:04:02 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NN42J21680 for linux-mips-outgoing; Mon, 23 Jul 2001 16:04:02 -0700 Received: from kuolema.infodrom.north.de (postfix@kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NN3wO21670 for ; Mon, 23 Jul 2001 16:03:59 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id 3AFC84D73E for ; Tue, 24 Jul 2001 01:03:47 +0200 (CEST) Received: by finlandia.infodrom.north.de (Postfix, from userid 501) id 2C88A109D3; Tue, 24 Jul 2001 01:03:43 +0200 (CEST) Date: Tue, 24 Jul 2001 01:03:43 +0200 From: Martin Schulze To: linux-mips@oss.sgi.com Subject: Question about ioctls.h Message-ID: <20010724010342.R31470@finlandia.infodrom.north.de> Reply-To: Martin Schulze Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.12i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 428 Lines: 17 Quoting : > #if defined(__USE_MISC) || defined (__KERNEL__) > #define tIOC ('t' << 8) > #endif Could somebody try to explain this to me? I'm especially interested in the #if part. Why isn't tIOC defined normally? It is used later. in the file - and it is used externally by rp-pppoe for example. Regards, Joey -- All language designers are arrogant. Goes with the territory... -- Larry Wall From owner-linux-mips@oss.sgi.com Mon Jul 23 16:28:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NNSIQ25207 for linux-mips-outgoing; Mon, 23 Jul 2001 16:28:18 -0700 Received: from dea.waldorf-gmbh.de (u-223-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.223]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NNSEO25189 for ; Mon, 23 Jul 2001 16:28:15 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6NNRwH05015; Tue, 24 Jul 2001 01:27:58 +0200 Date: Tue, 24 Jul 2001 01:27:58 +0200 From: Ralf Baechle To: Martin Schulze Cc: linux-mips@oss.sgi.com Subject: Re: Question about ioctls.h Message-ID: <20010724012757.A4953@bacchus.dhis.org> References: <20010724010342.R31470@finlandia.infodrom.north.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724010342.R31470@finlandia.infodrom.north.de>; from joey@finlandia.infodrom.north.de on Tue, Jul 24, 2001 at 01:03:43AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 499 Lines: 16 On Tue, Jul 24, 2001 at 01:03:43AM +0200, Martin Schulze wrote: > Quoting : > > > #if defined(__USE_MISC) || defined (__KERNEL__) > > #define tIOC ('t' << 8) > > #endif > > Could somebody try to explain this to me? I'm especially interested > in the #if part. Why isn't tIOC defined normally? It is used later. > in the file - and it is used externally by rp-pppoe for example. Overly paranoid attempt at keeping the namespace cleaner than Mr Proper himself. Ralf From owner-linux-mips@oss.sgi.com Mon Jul 23 16:56:42 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6NNugg28416 for linux-mips-outgoing; Mon, 23 Jul 2001 16:56:42 -0700 Received: from dea.waldorf-gmbh.de (u-223-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.223]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6NNuPO28407 for ; Mon, 23 Jul 2001 16:56:26 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6NNuBq10012; Tue, 24 Jul 2001 01:56:11 +0200 Date: Tue, 24 Jul 2001 01:56:11 +0200 From: Ralf Baechle To: Martin Schulze Cc: linux-mips@oss.sgi.com Subject: Re: Question about ioctls.h Message-ID: <20010724015611.A10007@bacchus.dhis.org> References: <20010724010342.R31470@finlandia.infodrom.north.de> <20010724012757.A4953@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: <20010724012757.A4953@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jul 24, 2001 at 01:27:58AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 9082 Lines: 233 On Tue, Jul 24, 2001 at 01:27:58AM +0200, Ralf Baechle wrote: > > Could somebody try to explain this to me? I'm especially interested > > in the #if part. Why isn't tIOC defined normally? It is used later. > > in the file - and it is used externally by rp-pppoe for example. > > Overly paranoid attempt at keeping the namespace cleaner than Mr Proper > himself. Try the patch below. Ralf Index: include/asm-mips64/ioctls.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips64/ioctls.h,v retrieving revision 1.2 diff -u -r1.2 ioctls.h --- include/asm-mips64/ioctls.h 2001/07/09 00:25:38 1.2 +++ include/asm-mips64/ioctls.h 2001/07/23 23:55:09 @@ -3,17 +3,14 @@ * License. See the file "COPYING" in the main directory of this archive * for more details. * - * Copyright (C) 1995, 1996, 1999 by Ralf Baechle + * Copyright (C) 1995, 1996, 2001 Ralf Baechle + * Copyright (C) 2001 MIPS Technologies, Inc. */ -#ifndef _ASM_IOCTLS_H -#define _ASM_IOCTLS_H +#ifndef __ASM_IOCTLS_H +#define __ASM_IOCTLS_H #include -#if defined(__USE_MISC) || defined (__KERNEL__) -#define tIOC ('t' << 8) -#endif - #define TCGETA 0x5401 #define TCSETA 0x5402 #define TCSETAW 0x5403 @@ -37,31 +34,27 @@ #define TIOCMBIC 0x741c /* bic modem bits */ #define TIOCMSET 0x741a /* set all modem bits */ #define TIOCPKT 0x5470 /* pty: set/clear packet mode */ -#define TIOCPKT_DATA 0x00 /* data packet */ -#define TIOCPKT_FLUSHREAD 0x01 /* flush packet */ -#define TIOCPKT_FLUSHWRITE 0x02 /* flush packet */ -#define TIOCPKT_STOP 0x04 /* stop output */ -#define TIOCPKT_START 0x08 /* start output */ -#define TIOCPKT_NOSTOP 0x10 /* no more ^S, ^Q */ -#define TIOCPKT_DOSTOP 0x20 /* now do ^S ^Q */ -#if 0 -#define TIOCPKT_IOCTL 0x40 /* state change of pty driver */ -#endif +#define TIOCPKT_DATA 0x00 /* data packet */ +#define TIOCPKT_FLUSHREAD 0x01 /* flush packet */ +#define TIOCPKT_FLUSHWRITE 0x02 /* flush packet */ +#define TIOCPKT_STOP 0x04 /* stop output */ +#define TIOCPKT_START 0x08 /* start output */ +#define TIOCPKT_NOSTOP 0x10 /* no more ^S, ^Q */ +#define TIOCPKT_DOSTOP 0x20 /* now do ^S ^Q */ +/* #define TIOCPKT_IOCTL 0x40 state change of pty driver */ #define TIOCSWINSZ _IOW('t', 103, struct winsize) /* set window size */ #define TIOCGWINSZ _IOR('t', 104, struct winsize) /* get window size */ #define TIOCNOTTY 0x5471 /* void tty association */ -#define TIOCSETD (tIOC | 1) -#define TIOCGETD (tIOC | 0) +#define TIOCSETD 0x7401 +#define TIOCGETD 0x7400 #define FIOCLEX 0x6601 #define FIONCLEX 0x6602 /* these numbers need to be adjusted. */ #define FIOASYNC 0x667d #define FIONBIO 0x667e -#if defined(__USE_MISC) || defined (__KERNEL__) -#define TIOCGLTC (tIOC | 116) /* get special local chars */ -#define TIOCSLTC (tIOC | 117) /* set special local chars */ -#endif +#define TIOCGLTC 0x7474 /* get special local chars */ +#define TIOCSLTC 0x7475 /* set special local chars */ #define TIOCSPGRP _IOW('t', 118, int) /* set pgrp of tty */ #define TIOCGPGRP _IOR('t', 119, int) /* get pgrp of tty */ #define TIOCCONS _IOW('t', 120, int) /* become virtual console */ @@ -69,20 +62,16 @@ #define FIONREAD 0x467f #define TIOCINQ FIONREAD -#if defined(__USE_MISC) || defined (__KERNEL__) -#define TIOCGETP (tIOC | 8) -#define TIOCSETP (tIOC | 9) -#define TIOCSETN (tIOC | 10) /* TIOCSETP wo flush */ -#endif +#define TIOCGETP 0x7408 +#define TIOCSETP 0x7409 +#define TIOCSETN 0x740a /* TIOCSETP wo flush */ -#if 0 -#define TIOCSETA _IOW('t', 20, struct termios) /* set termios struct */ -#define TIOCSETAW _IOW('t', 21, struct termios) /* drain output, set */ -#define TIOCSETAF _IOW('t', 22, struct termios) /* drn out, fls in, set */ -#define TIOCGETD _IOR('t', 26, int) /* get line discipline */ -#define TIOCSETD _IOW('t', 27, int) /* set line discipline */ +/* #define TIOCSETA _IOW('t', 20, struct termios) set termios struct */ +/* #define TIOCSETAW _IOW('t', 21, struct termios) drain output, set */ +/* #define TIOCSETAF _IOW('t', 22, struct termios) drn out, fls in, set */ +/* #define TIOCGETD _IOR('t', 26, int) get line discipline */ +/* #define TIOCSETD _IOW('t', 27, int) set line discipline */ /* 127-124 compat */ -#endif /* I hope the range from 0x5480 on is free ... */ #define TIOCSCTTY 0x5480 /* become controlling tty */ @@ -114,4 +103,4 @@ #define TIOCGHAYESESP 0x5493 /* Get Hayes ESP configuration */ #define TIOCSHAYESESP 0x5494 /* Set Hayes ESP configuration */ -#endif /* _ASM_IOCTLS_H */ +#endif /* __ASM_IOCTLS_H */ Index: include/asm-mips/ioctls.h =================================================================== RCS file: /home/pub/cvs/linux/include/asm-mips/ioctls.h,v retrieving revision 1.8 diff -u -r1.8 ioctls.h --- include/asm-mips/ioctls.h 1998/08/25 09:21:56 1.8 +++ include/asm-mips/ioctls.h 2001/07/23 23:55:09 @@ -1,20 +1,16 @@ -/* $Id: ioctls.h,v 1.5 1998/08/19 21:58:11 ralf Exp $ - * +/* * This file is subject to the terms and conditions of the GNU General Public * License. See the file "COPYING" in the main directory of this archive * for more details. * - * Copyright (C) 1995, 1996 by Ralf Baechle + * Copyright (C) 1995, 1996, 2001 Ralf Baechle + * Copyright (C) 2001 MIPS Technologies, Inc. */ -#ifndef __ASM_MIPS_IOCTLS_H -#define __ASM_MIPS_IOCTLS_H +#ifndef __ASM_IOCTLS_H +#define __ASM_IOCTLS_H #include -#if defined(__USE_MISC) || defined (__KERNEL__) -#define tIOC ('t' << 8) -#endif - #define TCGETA 0x5401 #define TCSETA 0x5402 #define TCSETAW 0x5403 @@ -38,31 +34,27 @@ #define TIOCMBIC 0x741c /* bic modem bits */ #define TIOCMSET 0x741a /* set all modem bits */ #define TIOCPKT 0x5470 /* pty: set/clear packet mode */ -#define TIOCPKT_DATA 0x00 /* data packet */ -#define TIOCPKT_FLUSHREAD 0x01 /* flush packet */ -#define TIOCPKT_FLUSHWRITE 0x02 /* flush packet */ -#define TIOCPKT_STOP 0x04 /* stop output */ -#define TIOCPKT_START 0x08 /* start output */ -#define TIOCPKT_NOSTOP 0x10 /* no more ^S, ^Q */ -#define TIOCPKT_DOSTOP 0x20 /* now do ^S ^Q */ -#if 0 -#define TIOCPKT_IOCTL 0x40 /* state change of pty driver */ -#endif +#define TIOCPKT_DATA 0x00 /* data packet */ +#define TIOCPKT_FLUSHREAD 0x01 /* flush packet */ +#define TIOCPKT_FLUSHWRITE 0x02 /* flush packet */ +#define TIOCPKT_STOP 0x04 /* stop output */ +#define TIOCPKT_START 0x08 /* start output */ +#define TIOCPKT_NOSTOP 0x10 /* no more ^S, ^Q */ +#define TIOCPKT_DOSTOP 0x20 /* now do ^S ^Q */ +/* #define TIOCPKT_IOCTL 0x40 state change of pty driver */ #define TIOCSWINSZ _IOW('t', 103, struct winsize) /* set window size */ #define TIOCGWINSZ _IOR('t', 104, struct winsize) /* get window size */ #define TIOCNOTTY 0x5471 /* void tty association */ -#define TIOCSETD (tIOC | 1) -#define TIOCGETD (tIOC | 0) +#define TIOCSETD 0x7401 +#define TIOCGETD 0x7400 #define FIOCLEX 0x6601 #define FIONCLEX 0x6602 /* these numbers need to be adjusted. */ #define FIOASYNC 0x667d #define FIONBIO 0x667e -#if defined(__USE_MISC) || defined (__KERNEL__) -#define TIOCGLTC (tIOC | 116) /* get special local chars */ -#define TIOCSLTC (tIOC | 117) /* set special local chars */ -#endif +#define TIOCGLTC 0x7474 /* get special local chars */ +#define TIOCSLTC 0x7475 /* set special local chars */ #define TIOCSPGRP _IOW('t', 118, int) /* set pgrp of tty */ #define TIOCGPGRP _IOR('t', 119, int) /* get pgrp of tty */ #define TIOCCONS _IOW('t', 120, int) /* become virtual console */ @@ -70,20 +62,16 @@ #define FIONREAD 0x467f #define TIOCINQ FIONREAD -#if defined(__USE_MISC) || defined (__KERNEL__) -#define TIOCGETP (tIOC | 8) -#define TIOCSETP (tIOC | 9) -#define TIOCSETN (tIOC | 10) /* TIOCSETP wo flush */ -#endif +#define TIOCGETP 0x7408 +#define TIOCSETP 0x7409 +#define TIOCSETN 0x740a /* TIOCSETP wo flush */ -#if 0 -#define TIOCSETA _IOW('t', 20, struct termios) /* set termios struct */ -#define TIOCSETAW _IOW('t', 21, struct termios) /* drain output, set */ -#define TIOCSETAF _IOW('t', 22, struct termios) /* drn out, fls in, set */ -#define TIOCGETD _IOR('t', 26, int) /* get line discipline */ -#define TIOCSETD _IOW('t', 27, int) /* set line discipline */ +/* #define TIOCSETA _IOW('t', 20, struct termios) set termios struct */ +/* #define TIOCSETAW _IOW('t', 21, struct termios) drain output, set */ +/* #define TIOCSETAF _IOW('t', 22, struct termios) drn out, fls in, set */ +/* #define TIOCGETD _IOR('t', 26, int) get line discipline */ +/* #define TIOCSETD _IOW('t', 27, int) set line discipline */ /* 127-124 compat */ -#endif /* I hope the range from 0x5480 on is free ... */ #define TIOCSCTTY 0x5480 /* become controlling tty */ @@ -115,4 +103,4 @@ #define TIOCGHAYESESP 0x5493 /* Get Hayes ESP configuration */ #define TIOCSHAYESESP 0x5494 /* Set Hayes ESP configuration */ -#endif /* __ASM_MIPS_IOCTLS_H */ +#endif /* __ASM_IOCTLS_H */ From owner-linux-mips@oss.sgi.com Mon Jul 23 19:41:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O2fSt07770 for linux-mips-outgoing; Mon, 23 Jul 2001 19:41:28 -0700 Received: from viditec-netmedia.com.tw (61-220-240-70.HINET-IP.hinet.net [61.220.240.70]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O2fJO07762 for ; Mon, 23 Jul 2001 19:41:19 -0700 Received: from kjlin ([61.220.240.66]) by viditec-netmedia.com.tw (8.10.0/8.10.0) with SMTP id f6O4j0v16641 for ; Tue, 24 Jul 2001 12:45:00 +0800 Message-ID: <01b701c113e7$9cbba1c0$056aaac0@kjlin> From: "kjlin" To: References: <016701c110c6$a371d580$056aaac0@kjlin> Subject: Re: weird printf problem Date: Tue, 24 Jul 2001 10:23:22 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01C1142A.AA6963A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 8879 Lines: 237 This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C1142A.AA6963A0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable My kernel version is 2.4.1 and the processor is an MIPS R4000 style = embedded processor. I ues the serial port as my console. I found that the reason why the printf message will not be completely = outputed is the process of my testing program will not be selected again = by the schedular after outputing some message. Its "state" is TASK_INTERRUPTIBLE but the return value of = signal_pending(prev) is zero. Therefore, it is deleted from running queue in schedul() and never wake = up. asmlinkage void schedule(void) { ... ... move_rr_back: switch (prev->state) { case TASK_INTERRUPTIBLE: if (signal_pending(prev)) { prev->state =3D TASK_RUNNING; break; } default: del_from_runqueue(prev); (<---- Be = deleted here!) case TASK_RUNNING: } ... ... } I am not familiar with the machanism of tty_write(). Can any body tell me where should be chceked over? My serial driver is modified based on drivers/char/serial.c Thanks. ----- Original Message -----=20 From: kjlin=20 To: linux-mips@oss.sgi.com=20 Sent: Friday, July 20, 2001 10:49 AM Subject: weird printf problem Hi all, I ported linux to my embeded board and encountered a weird "printf" = problem. The library i used is uClibc. I made the kernel to run a testing program directly after boot up. In my case, less "printf" work well but more will fail. Here is my testing program: main() { int i=3D0; while(i<200) { printf("Hello World=3D%d\n",i); i++; } } =20 The output message will die at "Hello World=3D10" or "Hello = World=3D168" or "Hello World=3D76" ........ Every times the message dies at different place but it will never = successfully be outputed "200" times. However, if the condition is changed to "while(i<100)", then = everything is fine. It is so weird!! Why too much "printf" will cause the program to die? Is it the problem of uClibc or kernel? Does the compiler for my testing program concern this weird problem? Can anybody give me some hints? Thanks, KJ ------=_NextPart_000_01B4_01C1142A.AA6963A0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
My kernel version is 2.4.1 and the processor is an = MIPS R4000=20 style embedded processor.
I ues the serial port as my console.
I found that the reason why the printf message will = not be=20 completely outputed is the process of my testing program will not be = selected=20 again by the schedular after outputing some message.
Its "state" is TASK_INTERRUPTIBLE but the return = value of=20 signal_pending(prev) is zero.
Therefore, it is deleted from running = queue in=20 schedul() and never wake up.
 
asmlinkage void schedule(void)
{
...
...
move_rr_back:

         = switch=20 (prev->state)=20 {
           &n= bsp;    =20 case=20 TASK_INTERRUPTIBLE:
        &n= bsp;           &nb= sp;   =20 if (signal_pending(prev))=20 {
           &n= bsp;           &nb= sp;        =20 prev->state =3D=20 TASK_RUNNING;
         &n= bsp;           &nb= sp;          =20 break;
          &nbs= p;            = ; =20 }
           &n= bsp;    =20 default:
          &= nbsp;           &n= bsp; =20 del_from_runqueue(prev);       (<--= -- Be=20 deleted=20 here!)
         =        =20 case TASK_RUNNING:
       =20 }
...
...
}
 
I am not familiar with the machanism of=20 tty_write().
Can any body tell me where should be chceked=20 over?
My serial driver is modified based on=20 drivers/char/serial.c
 
Thanks.
----- Original = Message -----
From:=20 kjlin
To: linux-mips@oss.sgi.com
Sent: Friday, = July 20, 2001 10:49 AM
Subject: weird = printf problem

Hi all,
 
I ported linux to my embeded board and = encountered=20 a weird "printf" problem.
The library i used is uClibc.
I made the kernel to run a testing program = directly after=20 boot up.
In my case, less "printf" work well but more = will=20 fail.
Here is my testing program:
 
main()
{
    int i=3D0;
 
   =20 = while(i<200)
    {
    &= nbsp;          =20 printf("Hello=20 = World=3D%d\n",i);
        &nbs= p;      =20 i++;
    }
}
 
The output message will die at "Hello = World=3D10" or=20 "Hello World=3D168" or "Hello World=3D76" ........
Every times the message dies at different = place but it will never successfully be outputed "200"=20 times.
However, if the condition is changed to = "while(i<100)",=20 then everything is fine.
It is so weird!!
Why too much "printf" will cause the program to=20 die?
Is it the problem of uClibc or = kernel?
Does the compiler for my testing program concern this weird=20 problem?
Can anybody give me some hints?
 
Thanks,
KJ
------=_NextPart_000_01B4_01C1142A.AA6963A0-- From owner-linux-mips@oss.sgi.com Mon Jul 23 20:24:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O3OqJ10796 for linux-mips-outgoing; Mon, 23 Jul 2001 20:24:52 -0700 Received: from dea.waldorf-gmbh.de (u-223-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.223]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O3OnO10790 for ; Mon, 23 Jul 2001 20:24:50 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6O3Ogl25223; Tue, 24 Jul 2001 05:24:42 +0200 Date: Tue, 24 Jul 2001 05:24:42 +0200 From: Ralf Baechle To: Guido Guenther Cc: linux-mips@oss.sgi.com Subject: Re: Segfaults on r4600 Message-ID: <20010724052441.A25160@bacchus.dhis.org> References: <20010723194830.A9033@galadriel.physik.uni-konstanz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010723194830.A9033@galadriel.physik.uni-konstanz.de>; from guido.guenther@gmx.net on Mon, Jul 23, 2001 at 07:48:30PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 692 Lines: 15 On Mon, Jul 23, 2001 at 07:48:30PM +0200, Guido Guenther wrote: > I'm seeing various segfaults especially with perl on an R4600 Indy. > R4000 I2 with identical debian packages works fine though. I have tried > various kernels (cvs head as from two days ago(natively and > crosscompiled) and 2.4.3-r4k-ip22 from rfc822.org. Interesting enough > the segfaults disappear when using "strace -o/dev/null > segfaulting_binary". I also tried to investigate the core file but gdb > dies when loading it(gdb is 5.0-3 debian package). Strace uses ptrace(2) which does enormous numbers of cache flushes. Are those segfault non-deterministic? Do the perl script you're running do alot of I/O? Ralf From owner-linux-mips@oss.sgi.com Mon Jul 23 23:04:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O64Hl18403 for linux-mips-outgoing; Mon, 23 Jul 2001 23:04:17 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O64FO18400 for ; Mon, 23 Jul 2001 23:04:15 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id IAA61301 for ; Tue, 24 Jul 2001 08:04:13 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15OvIh-0002Qb-00 for ; Tue, 24 Jul 2001 08:04:11 +0200 Date: Tue, 24 Jul 2001 08:04:11 +0200 To: linux-mips@oss.sgi.com Subject: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c Message-ID: <20010724080411.G14821@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1264 Lines: 44 Hi All, somebody made wrong assumptions about how compute_return_epc() works. It does not return the epc but stores it in the register struct. Return value is -EFAULT or zero. I've speculated below how the right solution might look, but I don't know enough about signal handling to be sure. Thiemo diff -BurPX /bigdisk/src/dontdiff linux-orig/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c --- linux-orig/arch/mips/kernel/traps.c Sat Jul 14 18:49:46 2001 +++ linux/arch/mips/kernel/traps.c Sun Jul 22 08:44:57 2001 @@ -378,8 +378,11 @@ else info.si_code = FPE_INTOVF; info.si_signo = SIGFPE; - info.si_errno = 0; - info.si_addr = (void *)compute_return_epc(regs); + info.si_errno = compute_return_epc(regs); + if (info.si_errno) + info.si_addr = NULL; + else + info.si_addr = (void *)regs->cp0_epc; force_sig_info(SIGFPE, &info, current); break; default: @@ -418,8 +421,11 @@ else info.si_code = FPE_INTOVF; info.si_signo = SIGFPE; - info.si_errno = 0; - info.si_addr = (void *)compute_return_epc(regs); + info.si_errno = compute_return_epc(regs); + if (info.si_errno) + info.si_addr = NULL; + else + info.si_addr = (void *)regs->cp0_epc; force_sig_info(SIGFPE, &info, current); break; default: From owner-linux-mips@oss.sgi.com Tue Jul 24 01:04:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O84RT23869 for linux-mips-outgoing; Tue, 24 Jul 2001 01:04:27 -0700 Received: from kuolema.infodrom.north.de (postfix@kuolema.infodrom.north.de [217.89.86.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O84NO23862; Tue, 24 Jul 2001 01:04:23 -0700 Received: from finlandia.infodrom.north.de (finlandia.Infodrom.North.DE [217.89.86.34]) by kuolema.infodrom.north.de (Postfix) with ESMTP id C406A4D73F; Tue, 24 Jul 2001 10:04:18 +0200 (CEST) Received: by finlandia.infodrom.north.de (Postfix, from userid 501) id 93423108DF; Tue, 24 Jul 2001 10:04:18 +0200 (CEST) Date: Tue, 24 Jul 2001 10:04:18 +0200 From: Martin Schulze To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Question about ioctls.h Message-ID: <20010724100418.W31470@finlandia.infodrom.north.de> Reply-To: Martin Schulze References: <20010724010342.R31470@finlandia.infodrom.north.de> <20010724012757.A4953@bacchus.dhis.org> <20010724015611.A10007@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010724015611.A10007@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jul 24, 2001 at 01:56:11AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 588 Lines: 20 Ralf Baechle wrote: > On Tue, Jul 24, 2001 at 01:27:58AM +0200, Ralf Baechle wrote: > > > > Could somebody try to explain this to me? I'm especially interested > > > in the #if part. Why isn't tIOC defined normally? It is used later. > > > in the file - and it is used externally by rp-pppoe for example. > > > > Overly paranoid attempt at keeping the namespace cleaner than Mr Proper > > himself. > > Try the patch below. Thanks, looks good and works well. Somebody should commit it. Regards, Joey -- In the beginning was the word, and the word was content-type: text/plain From owner-linux-mips@oss.sgi.com Tue Jul 24 01:24:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6O8OuL24865 for linux-mips-outgoing; Tue, 24 Jul 2001 01:24:56 -0700 Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6O8OcO24855; Tue, 24 Jul 2001 01:24:39 -0700 Received: from agx by gandalf.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian)) id 15OxUb-0000df-00; Tue, 24 Jul 2001 10:24:37 +0200 Date: Tue, 24 Jul 2001 10:24:37 +0200 From: Guido Guenther To: Ralf Baechle Cc: linux-mips@oss.sgi.com Subject: Re: Segfaults on r4600 Message-ID: <20010724102436.A1101@gandalf.physik.uni-konstanz.de> Mail-Followup-To: Ralf Baechle , linux-mips@oss.sgi.com References: <20010723194830.A9033@galadriel.physik.uni-konstanz.de> <20010724052441.A25160@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: <20010724052441.A25160@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jul 24, 2001 at 05:24:42AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 999 Lines: 19 On Tue, Jul 24, 2001 at 05:24:42AM +0200, Ralf Baechle wrote: > On Mon, Jul 23, 2001 at 07:48:30PM +0200, Guido Guenther wrote: > > > I'm seeing various segfaults especially with perl on an R4600 Indy. > > R4000 I2 with identical debian packages works fine though. I have tried > > various kernels (cvs head as from two days ago(natively and > > crosscompiled) and 2.4.3-r4k-ip22 from rfc822.org. Interesting enough > > the segfaults disappear when using "strace -o/dev/null > > segfaulting_binary". I also tried to investigate the core file but gdb > > dies when loading it(gdb is 5.0-3 debian package). > > Strace uses ptrace(2) which does enormous numbers of cache flushes. > Are those segfault non-deterministic? Do the perl script you're running > do alot of I/O? No extensive I/O and perfectly deterministic. Another interesting fact is, that some of these scripts fail when executed from a shells script but work perfectly well when exactly the same call is typed into a shell. -- Guido From owner-linux-mips@oss.sgi.com Tue Jul 24 04:12:01 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OBC1t01491 for linux-mips-outgoing; Tue, 24 Jul 2001 04:12:01 -0700 Received: from mail2.infineon.com (mail2.infineon.com [192.35.17.230]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OBC0O01484 for ; Tue, 24 Jul 2001 04:12:00 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id f6OBBwp10571 for ; Tue, 24 Jul 2001 13:11:58 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PR2RGWY0; Tue, 24 Jul 2001 13:11:55 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Tue, 24 Jul 2001 13:11:27 +0200 (W. Europe Daylight Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 13:14:52 +0200 Message-ID: <86048F07C015D311864100902760F1DDFF000E@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: GCC and Modules Date: Tue, 24 Jul 2001 13:14:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 438 Lines: 19 Hi. As I understand the current stable release of binutils and gcc is not able to compile functional modules. Sadly I am not able to use the CVS (Thanks to our super-secure admins, who lock every port possible). So here is my question: Does anybody provide snapshots of the CVS (or maybe binaries for x86 that support modules) for download? Thanks. Best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Tue Jul 24 04:24:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OBO5W02197 for linux-mips-outgoing; Tue, 24 Jul 2001 04:24:05 -0700 Received: from dea.waldorf-gmbh.de (u-241-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OBO1O02188 for ; Tue, 24 Jul 2001 04:24:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6OBNcQ26196; Tue, 24 Jul 2001 13:23:38 +0200 Date: Tue, 24 Jul 2001 13:23:38 +0200 From: Ralf Baechle To: Martin Schulze Cc: linux-mips@oss.sgi.com Subject: Re: Question about ioctls.h Message-ID: <20010724132338.A26049@bacchus.dhis.org> References: <20010724010342.R31470@finlandia.infodrom.north.de> <20010724012757.A4953@bacchus.dhis.org> <20010724015611.A10007@bacchus.dhis.org> <20010724100418.W31470@finlandia.infodrom.north.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724100418.W31470@finlandia.infodrom.north.de>; from joey@finlandia.infodrom.north.de on Tue, Jul 24, 2001 at 10:04:18AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 668 Lines: 18 On Tue, Jul 24, 2001 at 10:04:18AM +0200, Martin Schulze wrote: > > > > Could somebody try to explain this to me? I'm especially interested > > > > in the #if part. Why isn't tIOC defined normally? It is used later. > > > > in the file - and it is used externally by rp-pppoe for example. > > > > > > Overly paranoid attempt at keeping the namespace cleaner than Mr Proper > > > himself. > > > > Try the patch below. > > Thanks, looks good and works well. Somebody should commit it. I immediately commited it for both 2.2 and 2.4, mips and mips64. You can follow the commits on the linux-cvs@oss.sgi.com mailing lists. Just subscribe via Majordomo. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 24 06:24:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ODOLm08900 for linux-mips-outgoing; Tue, 24 Jul 2001 06:24:21 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ODOJO08896 for ; Tue, 24 Jul 2001 06:24:19 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6ODOH437365; Tue, 24 Jul 2001 14:24:17 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id OAA18577; Tue, 24 Jul 2001 14:24:16 +0100 (BST) Message-ID: <00b201c11443$f02eae40$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "James Simmons" Cc: "Linux-MIPS" Subject: Re: ATI Victoria on Malta Date: Tue, 24 Jul 2001 14:24:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1087 Lines: 34 >Turn on debugging in atyfb.c and post the results. > >/* > * Debug flags. > */ >#undef DEBUG OK. I'm afraid I haven't got that much time to spare on this, which is why I asked if anyone else had managed this! What I've got is linux-2.4.3.mips-src-01.00.tar.gz (from ftp.mips.com) patched to make the FPU emulator work reliably (taken from the mail list), aty.h and atyfb.c from linux-2.4.6.tar.gz (from ftp.kernel.org) with DEBUG defined. The kernel is configured for a little endian Malta board, virtual terminal, framebuffer, ATI Mach64, PS2 keyboard (I had to change the MIPS config.in for this), GDB debugging. The relevant console output is: atyfb: 3D RAGE (XL) [0x4752 rev 0x65] 512K SGRAM, 14.31818 MHz XTAL, 230 MHz PLL , 120 Mhz MCLK BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF 80000001 06010000 00085838 00000081 04000000 00000000 00000000 PLL ac ac 24 df f6 04 00 fd 8e 9e 65 05 00 00 00 00 It hangs here. Adding printk()'s, it seems that one of the places it hangs is in wait_for_fifo() reading FIFO_STAT. Andrew Thornton From owner-linux-mips@oss.sgi.com Tue Jul 24 06:53:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ODrH110975 for linux-mips-outgoing; Tue, 24 Jul 2001 06:53:17 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ODrFO10967 for ; Tue, 24 Jul 2001 06:53:15 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA24406; Tue, 24 Jul 2001 15:53:05 +0200 (MET DST) Date: Tue, 24 Jul 2001 15:53:05 +0200 (MEST) From: Geert Uytterhoeven To: Andrew Thornton cc: James Simmons , Linux-MIPS Subject: Re: ATI Victoria on Malta In-Reply-To: <00b201c11443$f02eae40$d11110ac@snow.isltd.insignia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1980 Lines: 58 On Tue, 24 Jul 2001, Andrew Thornton wrote: > >Turn on debugging in atyfb.c and post the results. > > > >/* > > * Debug flags. > > */ > >#undef DEBUG > > OK. I'm afraid I haven't got that much time to spare on this, which is why I > asked if anyone else had managed this! > > What I've got is linux-2.4.3.mips-src-01.00.tar.gz (from ftp.mips.com) > patched to make the FPU emulator work reliably (taken from the mail list), > aty.h and atyfb.c from linux-2.4.6.tar.gz (from ftp.kernel.org) with DEBUG > defined. The kernel is configured for a little endian Malta board, virtual > terminal, framebuffer, ATI Mach64, PS2 keyboard (I had to change the MIPS > config.in for this), GDB debugging. > > The relevant console output is: > > atyfb: 3D RAGE (XL) [0x4752 rev 0x65] 512K SGRAM, 14.31818 MHz XTAL, 230 MHz > PLL > , 120 Mhz MCLK > BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF > 80000001 06010000 00085838 00000081 04000000 00000000 00000000 > PLL ac ac 24 df f6 04 00 fd 8e 9e 65 05 00 00 00 00 > > It hangs here. > > Adding printk()'s, it seems that one of the places it hangs is in > wait_for_fifo() reading FIFO_STAT. Using `atydebug' (from tools in CVS module atyfb at http://www.sourceforge.net/projects/linux-fbdev/), the PLL debug values mean: | tux$ ./atydebug ac ac 24 df f6 04 00 fd 8e 9e 65 05 00 00 00 00 | PLL rate = 417.901480 MHz (guessed) | bad MCLK post divider 5 | VCLK0 = 414.623821 MHz | VCLK1 = 232.713765 MHz | VCLK2 = 86.311678 MHz | VCLK3 = 165.521763 MHz | tux$ Which looks a bit odd. The same for the 512 K SGRAM. So I guess the Malta firmware hasn't initialized the RAGE XL yet. And atyfb requires an initialized chip. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jul 24 08:20:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OFKOl18695 for linux-mips-outgoing; Tue, 24 Jul 2001 08:20:24 -0700 Received: from web13903.mail.yahoo.com (web13903.mail.yahoo.com [216.136.175.29]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OFKNO18690 for ; Tue, 24 Jul 2001 08:20:23 -0700 Message-ID: <20010724152021.81248.qmail@web13903.mail.yahoo.com> Received: from [61.133.136.12] by web13903.mail.yahoo.com; Tue, 24 Jul 2001 08:20:21 PDT Date: Tue, 24 Jul 2001 08:20:21 -0700 (PDT) From: Barry Wu Subject: Q: port serial driver from 2.2 to 2.4 To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 574 Lines: 20 Hi, all, I am porting serial console driver from kenel 2.2.12 to kernel 2.4.3. I can use printk and prom_printf to print messages on serial terminal. But when the kernel call autoconfig() function, the output on serial terminal is stop. I check the autoconfig() function, it stop at serial_outp(info, UART_LCR, 0xBF); /* set up for StarTech test */ Why? If someone knows, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Tue Jul 24 08:40:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OFe7v20821 for linux-mips-outgoing; Tue, 24 Jul 2001 08:40:07 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OFe6O20818 for ; Tue, 24 Jul 2001 08:40:06 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 568BA125BA; Tue, 24 Jul 2001 08:40:05 -0700 (PDT) Date: Tue, 24 Jul 2001 08:40:05 -0700 From: "H . J . Lu" To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010724084005.A20319@lucon.org> References: <86048F07C015D311864100902760F1DDFF000E@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DDFF000E@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Tue, Jul 24, 2001 at 01:14:42PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 310 Lines: 12 On Tue, Jul 24, 2001 at 01:14:42PM +0200, Andre.Messerschmidt@infineon.com wrote: > Hi. > > As I understand the current stable release of binutils and gcc is not able > to compile functional modules. What are you talking about? My mips toolchain is as stable/good as the x86 version for RedHat 7.1. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 24 08:51:18 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OFpIc21732 for linux-mips-outgoing; Tue, 24 Jul 2001 08:51:18 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OFpHO21727 for ; Tue, 24 Jul 2001 08:51:17 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6OFpF439191; Tue, 24 Jul 2001 16:51:15 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id QAA23185; Tue, 24 Jul 2001 16:51:14 +0100 (BST) Message-ID: <013401c11458$7813b6c0$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "Geert Uytterhoeven" Cc: "James Simmons" , "Linux-MIPS" Subject: Re: ATI Victoria on Malta Date: Tue, 24 Jul 2001 16:51:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 647 Lines: 25 Geert, >Using `atydebug' (from tools in CVS module atyfb at >http://www.sourceforge.net/projects/linux-fbdev/), the PLL debug values mean: > >| tux$ ./atydebug ac ac 24 df f6 04 00 fd 8e 9e 65 05 00 00 00 00 >| PLL rate = 417.901480 MHz (guessed) >| bad MCLK post divider 5 >| VCLK0 = 414.623821 MHz >| VCLK1 = 232.713765 MHz >| VCLK2 = 86.311678 MHz >| VCLK3 = 165.521763 MHz >| tux$ > >Which looks a bit odd. The same for the 512 K SGRAM. > >So I guess the Malta firmware hasn't initialized the RAGE XL yet. And atyfb >requires an initialized chip. I guess this is not surprising because the Malta firmware isn't a PC BIOS. Andrew Thornton From owner-linux-mips@oss.sgi.com Tue Jul 24 08:55:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OFtli22141 for linux-mips-outgoing; Tue, 24 Jul 2001 08:55:47 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OFtiO22136 for ; Tue, 24 Jul 2001 08:55:45 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA01480; Tue, 24 Jul 2001 17:55:34 +0200 (MET DST) Date: Tue, 24 Jul 2001 17:55:34 +0200 (MEST) From: Geert Uytterhoeven To: Andrew Thornton cc: James Simmons , Linux-MIPS Subject: Re: ATI Victoria on Malta In-Reply-To: <013401c11458$7813b6c0$d11110ac@snow.isltd.insignia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1322 Lines: 37 On Tue, 24 Jul 2001, Andrew Thornton wrote: > >Using `atydebug' (from tools in CVS module atyfb at > >http://www.sourceforge.net/projects/linux-fbdev/), the PLL debug values > mean: > > > >| tux$ ./atydebug ac ac 24 df f6 04 00 fd 8e 9e 65 05 00 00 00 00 > >| PLL rate = 417.901480 MHz (guessed) > >| bad MCLK post divider 5 > >| VCLK0 = 414.623821 MHz > >| VCLK1 = 232.713765 MHz > >| VCLK2 = 86.311678 MHz > >| VCLK3 = 165.521763 MHz > >| tux$ > > > >Which looks a bit odd. The same for the 512 K SGRAM. > > > >So I guess the Malta firmware hasn't initialized the RAGE XL yet. And atyfb > >requires an initialized chip. > > I guess this is not surprising because the Malta firmware isn't a PC BIOS. If the RAGE XL is the officially supported video board for the Malta, I wouldn't have been surprised if its firmware would have contained code to initialize the RAGE XL. But unfortunately this doesn't seem to be the case. Next question: is there sample code available (e.g. with the `supported' OS for the Malta) to initialize the RAGE XL? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jul 24 09:15:47 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGFl223175 for linux-mips-outgoing; Tue, 24 Jul 2001 09:15:47 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGFkO23171 for ; Tue, 24 Jul 2001 09:15:46 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6OGFi439494; Tue, 24 Jul 2001 17:15:44 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id RAA23814; Tue, 24 Jul 2001 17:15:44 +0100 (BST) Message-ID: <013f01c1145b$e41dc420$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "Geert Uytterhoeven" Cc: "James Simmons" , "Linux-MIPS" Subject: Re: ATI Victoria on Malta Date: Tue, 24 Jul 2001 17:15:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 685 Lines: 22 Geert, >> I guess this is not surprising because the Malta firmware isn't a PC BIOS. > >If the RAGE XL is the officially supported video board for the Malta, I >wouldn't have been surprised if its firmware would have contained code to >initialize the RAGE XL. But unfortunately this doesn't seem to be the case. I don't know if YAMON supports anything other than a serial terminal for its console. >Next question: is there sample code available (e.g. with the `supported' OS for >the Malta) to initialize the RAGE XL? It has been pointed out to me that there is some source code, but this originates from a non-suitable source for use in Linux. Need I say more? Andrew Thornton From owner-linux-mips@oss.sgi.com Tue Jul 24 09:21:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGLkn23352 for linux-mips-outgoing; Tue, 24 Jul 2001 09:21:46 -0700 Received: from dea.waldorf-gmbh.de (u-69-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGLhO23347 for ; Tue, 24 Jul 2001 09:21:43 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6OGKvU30857; Tue, 24 Jul 2001 18:20:57 +0200 Date: Tue, 24 Jul 2001 18:20:57 +0200 From: Ralf Baechle To: "H . J . Lu" Cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010724182057.D27225@bacchus.dhis.org> References: <86048F07C015D311864100902760F1DDFF000E@dlfw003a.dus.infineon.com> <20010724084005.A20319@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010724084005.A20319@lucon.org>; from hjl@lucon.org on Tue, Jul 24, 2001 at 08:40:05AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 387 Lines: 12 On Tue, Jul 24, 2001 at 08:40:05AM -0700, H . J . Lu wrote: > > As I understand the current stable release of binutils and gcc is not able > > to compile functional modules. > > What are you talking about? My mips toolchain is as stable/good as the > x86 version for RedHat 7.1. He's refering to the last official release of binutils which indeed wasn't usable for modutils. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 24 09:23:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGNW123570 for linux-mips-outgoing; Tue, 24 Jul 2001 09:23:32 -0700 Received: from dea.waldorf-gmbh.de (u-69-10.karlsruhe.ipdial.viaginterkom.de [62.180.10.69]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGNUO23565 for ; Tue, 24 Jul 2001 09:23:30 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6OGNCV30868; Tue, 24 Jul 2001 18:23:12 +0200 Date: Tue, 24 Jul 2001 18:23:12 +0200 From: Ralf Baechle To: Andrew Thornton Cc: James Simmons , Linux-MIPS Subject: Re: ATI Victoria on Malta Message-ID: <20010724182312.E27225@bacchus.dhis.org> References: <00b201c11443$f02eae40$d11110ac@snow.isltd.insignia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00b201c11443$f02eae40$d11110ac@snow.isltd.insignia.com>; from andrew.thornton@insignia.com on Tue, Jul 24, 2001 at 02:24:16PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 456 Lines: 12 On Tue, Jul 24, 2001 at 02:24:16PM +0100, Andrew Thornton wrote: > OK. I'm afraid I haven't got that much time to spare on this, which is why I > asked if anyone else had managed this! > > What I've got is linux-2.4.3.mips-src-01.00.tar.gz (from ftp.mips.com) > patched to make the FPU emulator work reliably (taken from the mail list), Sorry to destroy your illusions but we've got still a bunch of rather tricky bugs in the fp emulation code. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 24 09:31:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGV5223853 for linux-mips-outgoing; Tue, 24 Jul 2001 09:31:05 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGUvO23846; Tue, 24 Jul 2001 09:30:57 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 6AD44125BA; Tue, 24 Jul 2001 09:30:56 -0700 (PDT) Date: Tue, 24 Jul 2001 09:30:56 -0700 From: "H . J . Lu" To: Ralf Baechle Cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010724093056.A21216@lucon.org> References: <86048F07C015D311864100902760F1DDFF000E@dlfw003a.dus.infineon.com> <20010724084005.A20319@lucon.org> <20010724182057.D27225@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: <20010724182057.D27225@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Jul 24, 2001 at 06:20:57PM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 692 Lines: 19 On Tue, Jul 24, 2001 at 06:20:57PM +0200, Ralf Baechle wrote: > On Tue, Jul 24, 2001 at 08:40:05AM -0700, H . J . Lu wrote: > > > > As I understand the current stable release of binutils and gcc is not able > > > to compile functional modules. > > > > What are you talking about? My mips toolchain is as stable/good as the > > x86 version for RedHat 7.1. > > He's refering to the last official release of binutils which indeed wasn't > usable for modutils. What official release of binutils? Are we talking about the FSF official release? Since when did Linux use those? They won't even work right on Linux/x86. You should either use the Linux binutils or try your luck with CVS. H.J. From owner-linux-mips@oss.sgi.com Tue Jul 24 09:32:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGWs323950 for linux-mips-outgoing; Tue, 24 Jul 2001 09:32:54 -0700 Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.217.222.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGWpO23945; Tue, 24 Jul 2001 09:32:51 -0700 Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [172.16.1.3]) by highland.isltd.insignia.com (8.11.3/8.11.3/check_local4.2) with ESMTP id f6OGWm439704; Tue, 24 Jul 2001 17:32:48 +0100 (BST) Received: from snow (snow.isltd.insignia.com [172.16.17.209]) by wolf.isltd.insignia.com (8.9.3/8.9.3) with SMTP id RAA24279; Tue, 24 Jul 2001 17:32:47 +0100 (BST) Message-ID: <017201c1145e$463feb40$d11110ac@snow.isltd.insignia.com> From: "Andrew Thornton" To: "Ralf Baechle" Cc: "James Simmons" , "Linux-MIPS" Subject: Re: ATI Victoria on Malta Date: Tue, 24 Jul 2001 17:32:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 353 Lines: 14 Ralf, >> What I've got is linux-2.4.3.mips-src-01.00.tar.gz (from ftp.mips.com) >> patched to make the FPU emulator work reliably (taken from the mail list), > >Sorry to destroy your illusions but we've got still a bunch of rather >tricky bugs in the fp emulation code. OK then, patched to make the FPU emulator work more reliably. Andrew Thornton From owner-linux-mips@oss.sgi.com Tue Jul 24 09:40:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OGev324410 for linux-mips-outgoing; Tue, 24 Jul 2001 09:40:57 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OGesO24407; Tue, 24 Jul 2001 09:40:54 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA17932; Tue, 24 Jul 2001 09:40:47 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA13093; Tue, 24 Jul 2001 09:40:45 -0700 (PDT) Message-ID: <01ce01c11460$07f50a80$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" , "Andrew Thornton" Cc: "James Simmons" , "Linux-MIPS" References: <00b201c11443$f02eae40$d11110ac@snow.isltd.insignia.com> <20010724182312.E27225@bacchus.dhis.org> Subject: Re: ATI Victoria on Malta Date: Tue, 24 Jul 2001 18:45:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 615 Lines: 18 > > > OK. I'm afraid I haven't got that much time to spare on this, which is why I > > asked if anyone else had managed this! > > > > What I've got is linux-2.4.3.mips-src-01.00.tar.gz (from ftp.mips.com) > > patched to make the FPU emulator work reliably (taken from the mail list), > > Sorry to destroy your illusions but we've got still a bunch of rather > tricky bugs in the fp emulation code. Note, however, that all known bugs have to deal with catching and handling signals during certain emulation sequences - if you're doing "straight-line" FP computation, you're probably OK. ;-) Kevin K. From owner-linux-mips@oss.sgi.com Tue Jul 24 13:25:39 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OKPdS01497 for linux-mips-outgoing; Tue, 24 Jul 2001 13:25:39 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OKPZO01491 for ; Tue, 24 Jul 2001 13:25:36 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id ED610125BA; Tue, 24 Jul 2001 13:25:34 -0700 (PDT) Date: Tue, 24 Jul 2001 13:25:34 -0700 From: "H . J . Lu" To: Marc Karasek Cc: linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010724132534.A25416@lucon.org> References: <25369470B6F0D41194820002B328BDD27D2E@ATLOPS> <20010724085544.A20610@lucon.org> <995995907.1331.5.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <995995907.1331.5.camel@localhost.localdomain>; from marc_karasek@ivivity.com on Tue, Jul 24, 2001 at 01:31:41PM -0400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 953 Lines: 29 On Tue, Jul 24, 2001 at 01:31:41PM -0400, Marc Karasek wrote: > The way to see this bug is just try to compile the MIPS kernel (either > 2.4.1 or 2.4.3) as follows: > > 1) make distclean > 2) copy linux/arch/mips/defconfig-malta linux/.config > 3) make oldconfig > 4) make menuconfig > 5) change the endianess from little to big > 6) make dep > 7) make zImage > That is a kernel bug. The code only works on littl endian by accident Here is a patch. H.J. --- arch/mips/mips-boards/generic/time.c.int64 Tue Jul 24 13:21:21 2001 +++ arch/mips/mips-boards/generic/time.c Tue Jul 24 13:22:02 2001 @@ -275,7 +275,7 @@ void __init time_init(void) /* This is for machines which generate the exact clock. */ #define USECS_PER_JIFFY (1000000/HZ) -#define USECS_PER_JIFFY_FRAC (0x100000000*1000000/HZ&0xffffffff) +#define USECS_PER_JIFFY_FRAC ((long) (0x100000000*1000000/HZ&0xffffffff)) /* Cycle counter value at the previous timer interrupt.. */ From owner-linux-mips@oss.sgi.com Tue Jul 24 14:09:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6OL9Z603728 for linux-mips-outgoing; Tue, 24 Jul 2001 14:09:35 -0700 Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6OL9XO03725 for ; Tue, 24 Jul 2001 14:09:33 -0700 Received: from [192.168.1.167] (192.168.1.167 [192.168.1.167]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PJLG2CMW; Tue, 24 Jul 2001 17:09:27 -0400 Subject: Re: GCC and Modules From: Marc Karasek To: "H . J . Lu" Cc: linux-mips@oss.sgi.com In-Reply-To: <20010724132534.A25416@lucon.org> References: <25369470B6F0D41194820002B328BDD27D2E@ATLOPS> <20010724085544.A20610@lucon.org> <995995907.1331.5.camel@localhost.localdomain> <20010724132534.A25416@lucon.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.11 (Beta Release) Date: 24 Jul 2001 17:09:03 -0400 Message-Id: <996008951.1387.7.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1309 Lines: 43 I will patch and give this a try... prob will not be until Thursday or Friday.. On 24 Jul 2001 13:25:34 -0700, H . J . Lu wrote: > On Tue, Jul 24, 2001 at 01:31:41PM -0400, Marc Karasek wrote: > > The way to see this bug is just try to compile the MIPS kernel (either > > 2.4.1 or 2.4.3) as follows: > > > > 1) make distclean > > 2) copy linux/arch/mips/defconfig-malta linux/.config > > 3) make oldconfig > > 4) make menuconfig > > 5) change the endianess from little to big > > 6) make dep > > 7) make zImage > > > > That is a kernel bug. The code only works on littl endian by accident > Here is a patch. > > > H.J. > --- arch/mips/mips-boards/generic/time.c.int64 Tue Jul 24 13:21:21 2001 > +++ arch/mips/mips-boards/generic/time.c Tue Jul 24 13:22:02 2001 > @@ -275,7 +275,7 @@ void __init time_init(void) > > /* This is for machines which generate the exact clock. */ > #define USECS_PER_JIFFY (1000000/HZ) > -#define USECS_PER_JIFFY_FRAC (0x100000000*1000000/HZ&0xffffffff) > +#define USECS_PER_JIFFY_FRAC ((long) (0x100000000*1000000/HZ&0xffffffff)) > > /* Cycle counter value at the previous timer interrupt.. */ > -- /************************* Marc Karasek Sr. Firmware Engineer iVivity Inc. marc_karasek@ivivity.com (770) 986-8925 (770) 986-8926 Fax *************************/ From owner-linux-mips@oss.sgi.com Wed Jul 25 00:47:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6P7lQn03248 for linux-mips-outgoing; Wed, 25 Jul 2001 00:47:26 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6P7lPO03245 for ; Wed, 25 Jul 2001 00:47:25 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id AAA26805; Wed, 25 Jul 2001 00:45:39 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id AAA02627; Wed, 25 Jul 2001 00:45:40 -0700 (PDT) Received: from mips.com (copsun17 [192.168.205.27]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6P7iSa25576; Wed, 25 Jul 2001 09:44:29 +0200 (MEST) Message-ID: <3B5E78DB.70F7D97F@mips.com> Date: Wed, 25 Jul 2001 09:44:27 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Thornton CC: Geert Uytterhoeven , James Simmons , Linux-MIPS Subject: Re: ATI Victoria on Malta References: <013f01c1145b$e41dc420$d11110ac@snow.isltd.insignia.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1279 Lines: 40 Andrew Thornton wrote: > Geert, > > >> I guess this is not surprising because the Malta firmware isn't a PC > BIOS. > > > >If the RAGE XL is the officially supported video board for the Malta, I > >wouldn't have been surprised if its firmware would have contained code to > >initialize the RAGE XL. But unfortunately this doesn't seem to be the case. > > I don't know if YAMON supports anything other than a serial terminal for its > console. YAMON doesn't initialize the RAGE XL as it is a PCI plug-in card. The video driver in the 'supported' OS initialize the card. > > >Next question: is there sample code available (e.g. with the `supported' OS > for > >the Malta) to initialize the RAGE XL? > > It has been pointed out to me that there is some source code, but this > originates from a non-suitable source for use in Linux. Need I say more? I'm afraid we can't provide you with the sources, you need to contact the OS vendor yourself. > > Andrew Thornton -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From owner-linux-mips@oss.sgi.com Wed Jul 25 02:10:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6P9A5u10929 for linux-mips-outgoing; Wed, 25 Jul 2001 02:10:05 -0700 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6P9A1O10914; Wed, 25 Jul 2001 02:10:01 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f6P99x211748; Wed, 25 Jul 2001 11:09:59 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PTHN1GPV; Wed, 25 Jul 2001 11:09:54 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Wed, 25 Jul 2001 11:09:21 +0200 (W. Europe Daylight Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 11:12:48 +0200 Message-ID: <86048F07C015D311864100902760F1DDFF0016@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: AW: GCC and Modules Date: Wed, 25 Jul 2001 11:12:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 846 Lines: 34 Hi. > He's refering to the last official release of binutils which indeed wasn't > usable for modutils. > I compiled the tools by myself but the problems remain. My module should only print a message using printk, but I can't get it to run. Here are my results: > insmod module.o insmod: unresolved symbol _gp_disp Module compiled with -mno-abicalls and -no-half-pic (as someone in the archives mentioned) > insmod module.o Warning: unhandled reloc 9 insmod: Unhandled relocation of type 9 for Warning: unhandled reloc 11 insmod: Unhandled relocation of type 11 for printk Warning: unhandled reloc 9 insmod: Unhandled relocation of type 9 for Warning: unhandled reloc 11 insmod: Unhandled relocation of type 11 for printk Does anybody know what the problem is? regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Wed Jul 25 04:25:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PBP9w22235 for linux-mips-outgoing; Wed, 25 Jul 2001 04:25:09 -0700 Received: from dea.waldorf-gmbh.de (u-138-18.karlsruhe.ipdial.viaginterkom.de [62.180.18.138]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PBP6O22221 for ; Wed, 25 Jul 2001 04:25:06 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6PBOt902987; Wed, 25 Jul 2001 13:24:55 +0200 Date: Wed, 25 Jul 2001 13:24:55 +0200 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: GCC and Modules Message-ID: <20010725132455.A2662@bacchus.dhis.org> References: <86048F07C015D311864100902760F1DDFF0016@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DDFF0016@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Wed, Jul 25, 2001 at 11:12:47AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 471 Lines: 16 On Wed, Jul 25, 2001 at 11:12:47AM +0200, Andre.Messerschmidt@infineon.com wrote: > I compiled the tools by myself but the problems remain. > My module should only print a message using printk, but I can't get it to > run. > > Here are my results: > > insmod module.o > insmod: unresolved symbol _gp_disp > > Module compiled with -mno-abicalls and -no-half-pic (as someone in the > archives mentioned) -fno-pic you mean. Half PIC is meaningless under Linux. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 25 04:45:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PBj5424677 for linux-mips-outgoing; Wed, 25 Jul 2001 04:45:05 -0700 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PBj1O24672; Wed, 25 Jul 2001 04:45:01 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f6PBj0228499; Wed, 25 Jul 2001 13:45:00 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PTHN1SVJ; Wed, 25 Jul 2001 13:44:55 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Wed, 25 Jul 2001 13:44:06 +0200 (W. Europe Daylight Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 13:43:41 +0200 Message-ID: <86048F07C015D311864100902760F1DDFF0019@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: ralf@oss.sgi.com Cc: linux-mips@oss.sgi.com Subject: AW: GCC and Modules Date: Wed, 25 Jul 2001 13:43:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 228 Lines: 9 > -fno-pic you mean. Half PIC is meaningless under Linux. > I must confess that I don't know what these options actually do. Nevertheless even with this option the result is the same. :-( Any other ideas? best regards Andre From owner-linux-mips@oss.sgi.com Wed Jul 25 06:58:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PDw9M06888 for linux-mips-outgoing; Wed, 25 Jul 2001 06:58:09 -0700 Received: from lntex.lineo.com ([38.211.144.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PDw5O06879; Wed, 25 Jul 2001 06:58:06 -0700 Received: from lineo.com ([38.211.144.16]) by lntex.lineo.com (Lotus Domino Release 5.0.8) with ESMTP id 2001072508575162:55 ; Wed, 25 Jul 2001 08:57:51 -0500 Message-ID: <3B5ED17F.6D50331F@lineo.com> Date: Wed, 25 Jul 2001 15:02:39 +0100 From: Ian Soanes Organization: Lineo UK X-Accept-Language: en MIME-Version: 1.0 To: Andre.Messerschmidt@infineon.com CC: ralf@oss.sgi.com, linux-mips@oss.sgi.com Subject: Re: AW: GCC and Modules References: <86048F07C015D311864100902760F1DDFF0016@dlfw003a.dus.infineon.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1390 Lines: 44 Andre.Messerschmidt@infineon.com wrote: > > Hi. > > > He's refering to the last official release of binutils which indeed wasn't > > usable for modutils. > > > I compiled the tools by myself but the problems remain. > My module should only print a message using printk, but I can't get it to > run. > > Here are my results: > > insmod module.o > insmod: unresolved symbol _gp_disp > > Module compiled with -mno-abicalls and -no-half-pic (as someone in the > archives mentioned) > > insmod module.o > Warning: unhandled reloc 9 > insmod: Unhandled relocation of type 9 for > Warning: unhandled reloc 11 > insmod: Unhandled relocation of type 11 for printk > Warning: unhandled reloc 9 > insmod: Unhandled relocation of type 9 for > Warning: unhandled reloc 11 > insmod: Unhandled relocation of type 11 for printk > > Does anybody know what the problem is? > Hi Andre, This may be a little out of date, but compiling with the module with -mlong-calls worked for me when I had similar problems loading modules a while back. Relinking the module with 'ld -r -o new_mod.o orig_mod.o' was useful too ...it worked around some 'exceeds local_symtab_size' messages. At the time I was using modutils 2.4.5 and an older version of binutils (sorry I'm not near the relevant box to check exactly which version), so maybe some of this is not relevant any more. Hope this helps in some way, Ian From owner-linux-mips@oss.sgi.com Wed Jul 25 10:01:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PH10a17484 for linux-mips-outgoing; Wed, 25 Jul 2001 10:01:00 -0700 Received: from dea.waldorf-gmbh.de (u-46-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PH0vO17481 for ; Wed, 25 Jul 2001 10:00:57 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6PH0kN01574; Wed, 25 Jul 2001 19:00:46 +0200 Date: Wed, 25 Jul 2001 19:00:46 +0200 From: Ralf Baechle To: Ian Soanes Cc: Andre.Messerschmidt@infineon.com, linux-mips@oss.sgi.com Subject: Re: AW: GCC and Modules Message-ID: <20010725190046.A1391@bacchus.dhis.org> References: <86048F07C015D311864100902760F1DDFF0016@dlfw003a.dus.infineon.com> <3B5ED17F.6D50331F@lineo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5ED17F.6D50331F@lineo.com>; from ians@lineo.com on Wed, Jul 25, 2001 at 03:02:39PM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 788 Lines: 19 On Wed, Jul 25, 2001 at 03:02:39PM +0100, Ian Soanes wrote: > This may be a little out of date, but compiling with the module with > -mlong-calls worked for me when I had similar problems loading modules a > while back. Relinking the module with 'ld -r -o new_mod.o orig_mod.o' > was useful too ...it worked around some 'exceeds local_symtab_size' > messages. The local_symtab_size symtab is caused by the fine differences between IRIX ELF and ABI ELF. More recent binutils versions switched to ABI ELF as the default. Not using -mlong-calls results in ``Relocation overflow'' messages. That's not the case here, so this option probably was used. Error messages about _gp_disp proof that the module contains PIC code that is has not been built using -mno-abicalls -fno-pic. Ralf From owner-linux-mips@oss.sgi.com Wed Jul 25 13:38:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PKcSx27196 for linux-mips-outgoing; Wed, 25 Jul 2001 13:38:28 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PKcSO27192 for ; Wed, 25 Jul 2001 13:38:28 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6PKbnc1018077; Wed, 25 Jul 2001 13:37:49 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6PKbild018073; Wed, 25 Jul 2001 13:37:45 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Wed, 25 Jul 2001 13:37:44 -0700 (PDT) From: James Simmons To: Carsten Langgaard cc: Andrew Thornton , Geert Uytterhoeven , Linux-MIPS Subject: Re: ATI Victoria on Malta In-Reply-To: <3B5E78DB.70F7D97F@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 319 Lines: 9 > > It has been pointed out to me that there is some source code, but this > > originates from a non-suitable source for use in Linux. Need I say more? > > I'm afraid we can't provide you with the sources, you need to contact the > OS vendor yourself. I really wish ATI would open up about intializing their cards. From owner-linux-mips@oss.sgi.com Wed Jul 25 14:33:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PLX7n00793 for linux-mips-outgoing; Wed, 25 Jul 2001 14:33:07 -0700 Received: from myth1.Stanford.EDU (myth1.Stanford.EDU [171.64.15.14]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PLX3O00787 for ; Wed, 25 Jul 2001 14:33:03 -0700 Received: (from johnd@localhost) by myth1.Stanford.EDU (8.11.1/8.11.1) id f6PLWqH29366; Wed, 25 Jul 2001 14:32:52 -0700 (PDT) Date: Wed, 25 Jul 2001 14:32:52 -0700 (PDT) From: "John D. Davis" To: Debian MIPS list , SGI MIPS list Subject: Replacing the Console driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 630 Lines: 13 I am modifying the linux kernel to be able to be run by a simulator. I need to modify the console driver and interrupt handler. I have been going through the various files, console.*, tty.* and the serial files to see how to interface to the console. I have also read some kernel korner articles, but they seem a little out of date. Is there any other recommended documentation on the console driver and how it works on an indy? I am trying to sort out the low-level interfaces from the higher-level ones. I just need to change the low-level interface from using the hardware to using the simulator interface. thanks, john From owner-linux-mips@oss.sgi.com Wed Jul 25 15:11:27 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PMBRB05745 for linux-mips-outgoing; Wed, 25 Jul 2001 15:11:27 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PMBPO05741 for ; Wed, 25 Jul 2001 15:11:25 -0700 Received: from ayrnetworks.com (IDENT:phil@bagpipe.ayrnetworks.com [10.1.1.149]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6PMA7r16209; Wed, 25 Jul 2001 15:10:07 -0700 Message-ID: <3B5F43EC.2B03E744@ayrnetworks.com> Date: Wed, 25 Jul 2001 15:10:52 -0700 From: Phil Hopely X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: "John D. Davis" CC: Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1475 Lines: 39 I do not know if you have examined any of the current open source emulation projects that exist, but I believe you might be interested to examine www.mame.net or mess.emuverse.com? They have a cpu core for mips emulation, I believe it may only be r3000 though?.. Also, there exist numerous open-source playstation emulators, which I believe are r3000 based too... The mame & mess projects are matured open-source projects that have been ported across the universe, they're really pretty cool, this work would be a likely fit with the mess project. If you implement by way of pure emulation, you'd not need to change the kernel at all? Phil "John D. Davis" wrote: > I am modifying the linux kernel to be able to be run by a simulator. I > need to modify the console driver and interrupt handler. I have been > going through the various files, console.*, tty.* and the serial files to > see how to interface to the console. I have also read some kernel korner > articles, but they seem a little out of date. Is there any other > recommended documentation on the console driver and how it works on an > indy? I am trying to sort out the low-level interfaces from the > higher-level ones. I just need to change the low-level interface from > using the hardware to using the simulator interface. > > thanks, > john > > -- > To UNSUBSCRIBE, email to debian-mips-request@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org From owner-linux-mips@oss.sgi.com Wed Jul 25 16:13:40 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6PNDe714616 for linux-mips-outgoing; Wed, 25 Jul 2001 16:13:40 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6PNDcO14607 for ; Wed, 25 Jul 2001 16:13:38 -0700 Received: from localhost (wjhun@localhost) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6PNCRb17172; Wed, 25 Jul 2001 16:12:27 -0700 Date: Wed, 25 Jul 2001 16:12:27 -0700 (PDT) From: William Jhun To: Phil Hopely cc: "John D. Davis" , Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver In-Reply-To: <3B5F43EC.2B03E744@ayrnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2282 Lines: 57 Hi Phil :o), The only problem with pure emulation is writing a good emulator for an MMU. I wrote a SPARC V8 instruction set emulator a year ago and stopped around the time I had to face the fact that a direct virtual->physical mapping would no longer be of any use. (also the semester started again :o). Not that it's not possible, but it's difficult and would require a mapping with every memory access (being very slow). However, a little creative help from the kernel and some creative mmap()ing might do the job (you can request a specific linear address with mmap()). If anyone knows some good methods for doing this, please inform! (and I might finish that emulator :o) William On Wed, 25 Jul 2001, Phil Hopely wrote: > > I do not know if you have examined any of the current open source emulation > projects that exist, but I believe > you might be interested to examine www.mame.net or mess.emuverse.com? > > They have a cpu core for mips emulation, I believe it may only be r3000 > though?.. > > Also, there exist numerous open-source playstation emulators, which I believe > are r3000 based too... > > The mame & mess projects are matured open-source projects that have been ported > across the universe, they're really pretty cool, this work would be a likely fit > with the mess project. > > If you implement by way of pure emulation, you'd not need to change the kernel > at all? > > Phil > > "John D. Davis" wrote: > > > I am modifying the linux kernel to be able to be run by a simulator. I > > need to modify the console driver and interrupt handler. I have been > > going through the various files, console.*, tty.* and the serial files to > > see how to interface to the console. I have also read some kernel korner > > articles, but they seem a little out of date. Is there any other > > recommended documentation on the console driver and how it works on an > > indy? I am trying to sort out the low-level interfaces from the > > higher-level ones. I just need to change the low-level interface from > > using the hardware to using the simulator interface. > > > > thanks, > > john > > > > -- > > To UNSUBSCRIBE, email to debian-mips-request@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > From owner-linux-mips@oss.sgi.com Wed Jul 25 17:16:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q0GUK22097 for linux-mips-outgoing; Wed, 25 Jul 2001 17:16:30 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q0GSO22093 for ; Wed, 25 Jul 2001 17:16:28 -0700 Received: from ayrnetworks.com (IDENT:phil@bagpipe.ayrnetworks.com [10.1.1.149]) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6PNihr17703; Wed, 25 Jul 2001 16:44:43 -0700 Message-ID: <3B5F5A18.F94328CB@ayrnetworks.com> Date: Wed, 25 Jul 2001 16:45:28 -0700 From: Phil Hopely X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: William Jhun CC: "John D. Davis" , Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3098 Lines: 78 William Jhun wrote: > Hi Phil :o), > > The only problem with pure emulation is writing a good emulator for an > MMU. I wrote a SPARC V8 instruction set emulator a year ago and stopped > around the time I had to face the fact that a direct virtual->physical > mapping would no longer be of any use. (also the semester started again > :o). Not that it's not possible, but it's difficult and would require a > mapping with every memory access (being very slow). However, a little > creative help from the kernel and some creative mmap()ing might do the job > (you can request a specific linear address with mmap()). If anyone knows > some good methods for doing this, please inform! (and I might finish that > emulator :o) > > William > :) yep, you are right - the r3000 core in the mame sources I am perusing do not implement an mmu (the playstation and williams standups use "a custom r3000a by LSI Logic" - see src/cpu/mips/mips.c - no cache mechanism either). Poking around the mame sources (I've got xmame b13 r1 - ancient really, from sometime late 1999 I think), it appears that the z180 cpu is the only core that has some kind of mmu emulation. The z8k & m68k also have mmu instructions, but those were not emulated in this version of mame... I haven't checked more recent versions, but I think recent mess (uses same cpu cores as mame) supports early macs, so there may be an implementation example there?.. Phil > > On Wed, 25 Jul 2001, Phil Hopely wrote: > > > > > I do not know if you have examined any of the current open source emulation > > projects that exist, but I believe > > you might be interested to examine www.mame.net or mess.emuverse.com? > > > > They have a cpu core for mips emulation, I believe it may only be r3000 > > though?.. > > > > Also, there exist numerous open-source playstation emulators, which I believe > > are r3000 based too... > > > > The mame & mess projects are matured open-source projects that have been ported > > across the universe, they're really pretty cool, this work would be a likely fit > > with the mess project. > > > > If you implement by way of pure emulation, you'd not need to change the kernel > > at all? > > > > Phil > > > > "John D. Davis" wrote: > > > > > I am modifying the linux kernel to be able to be run by a simulator. I > > > need to modify the console driver and interrupt handler. I have been > > > going through the various files, console.*, tty.* and the serial files to > > > see how to interface to the console. I have also read some kernel korner > > > articles, but they seem a little out of date. Is there any other > > > recommended documentation on the console driver and how it works on an > > > indy? I am trying to sort out the low-level interfaces from the > > > higher-level ones. I just need to change the low-level interface from > > > using the hardware to using the simulator interface. > > > > > > thanks, > > > john > > > > > > -- > > > To UNSUBSCRIBE, email to debian-mips-request@lists.debian.org > > > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > > From owner-linux-mips@oss.sgi.com Wed Jul 25 17:20:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q0Kba22806 for linux-mips-outgoing; Wed, 25 Jul 2001 17:20:37 -0700 Received: from the-village.bc.nu (router-100M.swansea.linux.org.uk [194.168.151.17]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q0KZO22803 for ; Wed, 25 Jul 2001 17:20:36 -0700 Received: from alan by the-village.bc.nu with local (Exim 3.22 #1) id 15PYt1-0002wX-00; Thu, 26 Jul 2001 01:20:19 +0100 Subject: Re: Replacing the Console driver To: phil@ayrnetworks.com (Phil Hopely) Date: Thu, 26 Jul 2001 01:20:19 +0100 (BST) Cc: wjhun@ayrnetworks.com (William Jhun), johnd@stanford.edu (John D. Davis), debian-mips@lists.debian.org (Debian MIPS list), linux-mips@oss.sgi.com (SGI MIPS list) In-Reply-To: from "Phil Hopely" at Jul 25, 2001 04:45:28 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 324 Lines: 7 > I haven't checked more recent versions, but I think recent mess (uses same cpu cores > as mame) supports early macs, so there may be an implementation example there?.. Early macintosh doesn't have an MMU as standard, The MacII had an optional MMU (for running A/UX) and it became standard on the later Mac systems. Alan From owner-linux-mips@oss.sgi.com Wed Jul 25 18:34:04 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q1Y4n31438 for linux-mips-outgoing; Wed, 25 Jul 2001 18:34:04 -0700 Received: from dea.waldorf-gmbh.de (u-46-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q1Y1V31434 for ; Wed, 25 Jul 2001 18:34:01 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6Q1WU808400; Thu, 26 Jul 2001 03:32:30 +0200 Date: Thu, 26 Jul 2001 03:32:30 +0200 From: Ralf Baechle To: Alan Cox Cc: Phil Hopely , William Jhun , "John D. Davis" , Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver Message-ID: <20010726033230.B7478@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 alan@lxorguk.ukuu.org.uk on Thu, Jul 26, 2001 at 01:20:19AM +0100 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 405 Lines: 11 On Thu, Jul 26, 2001 at 01:20:19AM +0100, Alan Cox wrote: > > I haven't checked more recent versions, but I think recent mess (uses same cpu cores > > as mame) supports early macs, so there may be an implementation example there?.. > > Early macintosh doesn't have an MMU as standard, The MacII had an optional > MMU (for running A/UX) and it became standard on the later Mac systems. MC68851? Ralf From owner-linux-mips@oss.sgi.com Wed Jul 25 18:52:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q1q7i00438 for linux-mips-outgoing; Wed, 25 Jul 2001 18:52:07 -0700 Received: from earth.ayrnetworks.com (earth.ayrnetworks.com [64.166.72.139]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q1q3V00434; Wed, 25 Jul 2001 18:52:03 -0700 Received: from localhost (wjhun@localhost) by earth.ayrnetworks.com (8.11.0/8.8.7) with ESMTP id f6Q1p7d19776; Wed, 25 Jul 2001 18:51:07 -0700 Date: Wed, 25 Jul 2001 18:51:07 -0700 (PDT) From: William Jhun To: Ralf Baechle cc: Alan Cox , Phil Hopely , "John D. Davis" , Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver In-Reply-To: <20010726033230.B7478@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1255 Lines: 33 On Thu, 26 Jul 2001, Ralf Baechle wrote: > On Thu, Jul 26, 2001 at 01:20:19AM +0100, Alan Cox wrote: > > > > I haven't checked more recent versions, but I think recent mess (uses same cpu cores > > > as mame) supports early macs, so there may be an implementation example there?.. > > > > Early macintosh doesn't have an MMU as standard, The MacII had an optional > > MMU (for running A/UX) and it became standard on the later Mac systems. > > MC68851? Yeah, but most home computers based on M68k didn't contain these (and they probably weren't that cheap). The 68030 had it built in (except the 68EC030). Most of the 68k home computer OSes, like AmigaDOS (and probably MacOS and Atari ST too) didn't come built with support for an MMU, so even if you had one, it would only be useful for either running some UNIX variant or advanced debugging tools (Amiga users remember good 'ol Enforcer?). Anyway, like I said, if anyone sees software emulation routines for a somewhat modern MMU, I'd be interested. I'm sure it's been done (though I'd like to see some routines that make use of the native MMU via some kernel interface). It might be slow but it'd make for a killer general-purpose debugging system. Or gobs of geeky fun. Will > > Ralf > From owner-linux-mips@oss.sgi.com Thu Jul 26 00:40:03 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q7e3U01460 for linux-mips-outgoing; Thu, 26 Jul 2001 00:40:03 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q7e0V01447 for ; Thu, 26 Jul 2001 00:40:01 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA00511; Thu, 26 Jul 2001 09:39:10 +0200 (MET DST) Date: Thu, 26 Jul 2001 09:39:05 +0200 (MEST) From: Geert Uytterhoeven To: "John D. Davis" cc: Debian MIPS list , SGI MIPS list Subject: Re: Replacing the Console driver In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1177 Lines: 30 On Wed, 25 Jul 2001, John D. Davis wrote: > I am modifying the linux kernel to be able to be run by a simulator. I > need to modify the console driver and interrupt handler. I have been > going through the various files, console.*, tty.* and the serial files to > see how to interface to the console. I have also read some kernel korner > articles, but they seem a little out of date. Is there any other > recommended documentation on the console driver and how it works on an > indy? I am trying to sort out the low-level interfaces from the > higher-level ones. I just need to change the low-level interface from > using the hardware to using the simulator interface. The interface to the console is specified in . So write your own console implementation, and set conswitchp = &consw_for_your_emulator in early kernel initialization code. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From owner-linux-mips@oss.sgi.com Thu Jul 26 02:10:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6Q9AHk08566 for linux-mips-outgoing; Thu, 26 Jul 2001 02:10:17 -0700 Received: from mail1.infineon.com (mail1.infineon.com [192.35.17.229]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6Q9AFV08557 for ; Thu, 26 Jul 2001 02:10:15 -0700 X-Envelope-Sender-Is: Andre.Messerschmidt@infineon.com (at relayer mail1.infineon.com) Received: from mchb0b1w.muc.infineon.com ([172.31.102.53]) by mail1.infineon.com (8.11.1/8.11.1) with ESMTP id f6Q9AD210228 for ; Thu, 26 Jul 2001 11:10:13 +0200 (MET DST) Received: from mchb0b5w.muc.infineon.com ([172.31.102.49]) by mchb0b1w.muc.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PTHNGSJF; Thu, 26 Jul 2001 11:10:06 +0200 Received: from 172.29.128.3 by mchb0b5w.muc.infineon.com (InterScan E-Mail VirusWall NT); Thu, 26 Jul 2001 11:09:34 +0200 (W. Europe Daylight Time) Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 11:09:38 +0200 Message-ID: <86048F07C015D311864100902760F1DDFF0021@dlfw003a.dus.infineon.com> From: Andre.Messerschmidt@infineon.com To: linux-mips@oss.sgi.com Subject: glibc problem Date: Thu, 26 Jul 2001 11:09:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 749 Lines: 22 Hi. During compilation of glibc 2.2.3 I get the following error: Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file format Someone in the archives meant that -D__PIC__ should be included to the CFLAGS to resolve this problem, but it seams that I am too dumb to do this. I tried several locations to set the variable in the Makefiles and used the configparms file to set it, but nothing worked. Then I tried to define it in the file where the error occured, just to realize that there are more locations where this define is needed, so I reckon it would be the best to define it from the beginning. Can anybody tell me how to get it right? best regards -- Andre Messerschmidt Application Engineer Infineon Technologies AG From owner-linux-mips@oss.sgi.com Thu Jul 26 06:47:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6QDlHp05764 for linux-mips-outgoing; Thu, 26 Jul 2001 06:47:17 -0700 Received: from dea.waldorf-gmbh.de (u-167-19.karlsruhe.ipdial.viaginterkom.de [62.180.19.167]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6QDlBV05757 for ; Thu, 26 Jul 2001 06:47:12 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6QDku011285; Thu, 26 Jul 2001 15:46:56 +0200 Date: Thu, 26 Jul 2001 15:46:56 +0200 From: Ralf Baechle To: Andre.Messerschmidt@infineon.com Cc: linux-mips@oss.sgi.com Subject: Re: glibc problem Message-ID: <20010726154655.B10790@bacchus.dhis.org> References: <86048F07C015D311864100902760F1DDFF0021@dlfw003a.dus.infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <86048F07C015D311864100902760F1DDFF0021@dlfw003a.dus.infineon.com>; from Andre.Messerschmidt@infineon.com on Thu, Jul 26, 2001 at 11:09:37AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 921 Lines: 19 On Thu, Jul 26, 2001 at 11:09:37AM +0200, Andre.Messerschmidt@infineon.com wrote: > During compilation of glibc 2.2.3 I get the following error: > Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file > format > > Someone in the archives meant that -D__PIC__ should be included to the > CFLAGS to resolve this problem, but it seams that I am too dumb to do this. > I tried several locations to set the variable in the Makefiles and used the > configparms file to set it, but nothing worked. Then I tried to define it in > the file where the error occured, just to realize that there are more > locations where this define is needed, so I reckon it would be the best to > define it from the beginning. > Can anybody tell me how to get it right? Adding -D__PIC__ is a kludge; the compiler should do it by default. It means you're using some non-Linux/MIPS compiler which you should replace. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 26 10:50:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6QHoFF17673 for linux-mips-outgoing; Thu, 26 Jul 2001 10:50:15 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6QHoEV17667 for ; Thu, 26 Jul 2001 10:50:14 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA01154 for ; Thu, 26 Jul 2001 10:49:57 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15Pp6Y-0001jp-00; Thu, 26 Jul 2001 10:39:22 -0700 Date: Thu, 26 Jul 2001 10:39:22 -0700 From: Daniel Jacobowitz To: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Subject: [patch] fix profiling in glibc for Linux/MIPS Message-ID: <20010726103922.A6643@nevyn.them.org> Mail-Followup-To: libc-alpha@sources.redhat.com, linux-mips@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1679 Lines: 51 _mcount was doing awful things to its caller's stack frame. Theoretically, we can get by with 16 bytes less of stack than I now allocate, but GCC still considers functions that call _mcount to be leaf functions, so that doesn't work. I think this is close enough; it only adds one instruction. Is this OK? Do I need a "nop" after the subu? My MIPS assembly knowledge is not that thorough. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer --- glibc-2.2.3/sysdeps/mips/machine-gmon.h.orig Wed Jul 25 20:09:20 2001 +++ glibc-2.2.3/sysdeps/mips/machine-gmon.h Wed Jul 25 21:14:09 2001 @@ -35,22 +35,23 @@ ".set noreorder;" \ ".set noat;" \ CPLOAD \ - "sw $4,8($29);" \ - "sw $5,12($29);" \ - "sw $6,16($29);" \ - "sw $7,20($29);" \ - "sw $1,0($29);" \ - "sw $31,4($29);" \ + "subu $29,$29,40;" \ + "sw $4,24($29);" \ + "sw $5,28($29);" \ + "sw $6,32($29);" \ + "sw $7,36($29);" \ + "sw $1,16($29);" \ + "sw $31,20($29);" \ "move $5,$31;" \ "jal __mcount;" \ "move $4,$1;" \ - "lw $4,8($29);" \ - "lw $5,12($29);" \ - "lw $6,16($29);" \ - "lw $7,20($29);" \ - "lw $31,4($29);" \ - "lw $1,0($29);" \ - "addu $29,$29,8;" \ + "lw $4,24($29);" \ + "lw $5,28($29);" \ + "lw $6,32($29);" \ + "lw $7,36($29);" \ + "lw $31,20($29);" \ + "lw $1,16($29);" \ + "addu $29,$29,48;" \ "j $31;" \ "move $31,$1;" \ ".set reorder;" \ From owner-linux-mips@oss.sgi.com Thu Jul 26 14:03:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6QL3S118529 for linux-mips-outgoing; Thu, 26 Jul 2001 14:03:28 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6QL3RV18523 for ; Thu, 26 Jul 2001 14:03:27 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR1R8M>; Thu, 26 Jul 2001 16:03:15 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BC1@ATVX> From: "Siders, Keith" To: "'linux-mips@oss.sgi.com'" Subject: Linux 2.4.6 Date: Thu, 26 Jul 2001 16:02:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1023 Lines: 30 I've made changes to the plain vanilla Linux 2.4.6 to port to our TX49H2 core on one of our EVB's. Which version of the compiler and binutils should I use? The binutils-xx-2.8.1-2 and egcs-xx-1.1.2-4 worked for the 2.2.19 port, but I'm getting errors in the shell scripts when I run 'make config'. I get the same errors with the same tools with the generic 2.4.6 as well. Looks like bash-2.04$ cd linux bash-2.04$ make config rm -f include/asm ( cd include ; ln -sf asm-mips asm) /bin/sh scripts/Configure arch/mips/config.in : command not found 'cripts/Configure: line 68: syntax error near unexpected token `{ 'cripts/Configure: line 68: `function mainmenu_option () { make: *** [config] Error 2 bash-2.04$ Not sure where to go from here as the scripts didn't change significantly between 2.2.19 and 2.4.6. Keith Siders Software Engineer Toshiba America Consumer Products, Inc. Advanced Television Technology Center 801 Royal Parkway, Suite 100 Nashville, Tennessee 37214 Phone: (615) 257-4050 Fax: (615) 453-7880 From owner-linux-mips@oss.sgi.com Thu Jul 26 17:48:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R0mOx24000 for linux-mips-outgoing; Thu, 26 Jul 2001 17:48:24 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R0mMV23989 for ; Thu, 26 Jul 2001 17:48:22 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id CAA29081 for ; Fri, 27 Jul 2001 02:48:21 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15Pvng-0000z6-00 for ; Fri, 27 Jul 2001 02:48:20 +0200 Date: Fri, 27 Jul 2001 02:48:20 +0200 To: linux-mips@oss.sgi.com Subject: Re: [patch] fix profiling in glibc for Linux/MIPS Message-ID: <20010727024820.B27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010726103922.A6643@nevyn.them.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 910 Lines: 34 Daniel Jacobowitz wrote: > _mcount was doing awful things to its caller's stack frame. Maybe I'm missing something, but both the old and the new code add 8 byte more to sp than they subtracted before. How is this supposed to work? [snip] > I think this is close enough; it only adds > one instruction. Is this OK? Why do you save and restore $6, $7, seemingly without using them? > Do I need a "nop" after the subu? It works here since it is expanded in an addiu $29,$29,-40 which is executed in one cycle. The usual suspects for hazards to be NOPed are load/store insns and branches. [snip] > + "sw $31,20($29);" \ > "move $5,$31;" \ > "jal __mcount;" \ > "move $4,$1;" \ ^ Some stylistic issue: In ".set noreorder" assembly it helps to indent the insns in a branch delay slot by one blank to avoid confusion about their non-sequential nature. Thiemo From owner-linux-mips@oss.sgi.com Thu Jul 26 18:32:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R1W0i30295 for linux-mips-outgoing; Thu, 26 Jul 2001 18:32:00 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R1VxV30291 for ; Thu, 26 Jul 2001 18:31:59 -0700 Received: from nevyn.them.org (gateway-1237.mvista.com [12.44.186.158]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA25151 for ; Thu, 26 Jul 2001 18:31:43 -0700 (PDT) mail_from (drow@crack.them.org) Received: from drow by nevyn.them.org with local (Exim 3.22 #1 (Debian)) id 15PwG5-00026O-00; Thu, 26 Jul 2001 18:17:41 -0700 Date: Thu, 26 Jul 2001 18:17:41 -0700 From: Daniel Jacobowitz To: Thiemo Seufer Cc: linux-mips@oss.sgi.com, linux-alpha@sources.redhat.com Subject: Re: [patch] fix profiling in glibc for Linux/MIPS Message-ID: <20010726181740.A8070@nevyn.them.org> References: <20010726103922.A6643@nevyn.them.org> <20010727024820.B27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <20010727024820.B27008@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, Jul 27, 2001 at 02:48:20AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1410 Lines: 44 On Fri, Jul 27, 2001 at 02:48:20AM +0200, Thiemo Seufer wrote: > Daniel Jacobowitz wrote: > > _mcount was doing awful things to its caller's stack frame. > > Maybe I'm missing something, but both the old and the new code > add 8 byte more to sp than they subtracted before. How is this > supposed to work? It's supposed to do that, according to GCC. Build something with -S -pg and look at it. > [snip] > > I think this is close enough; it only adds > > one instruction. Is this OK? > > Why do you save and restore $6, $7, seemingly without using them? Because they were already there; I was trying to keep this patch minimal. My MIPS assembly knowledge, as I said, is a little scanty. > > Do I need a "nop" after the subu? > > It works here since it is expanded in an > > addiu $29,$29,-40 > > which is executed in one cycle. The usual suspects for hazards > to be NOPed are load/store insns and branches. Ahh, OK. I see. > [snip] > > + "sw $31,20($29);" \ > > "move $5,$31;" \ > > "jal __mcount;" \ > > "move $4,$1;" \ > ^ > Some stylistic issue: In ".set noreorder" assembly it helps to > indent the insns in a branch delay slot by one blank to avoid > confusion about their non-sequential nature. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From owner-linux-mips@oss.sgi.com Thu Jul 26 19:21:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R2Lwl02980 for linux-mips-outgoing; Thu, 26 Jul 2001 19:21:58 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R2LuV02974 for ; Thu, 26 Jul 2001 19:21:56 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id EAA29260 for ; Fri, 27 Jul 2001 04:21:55 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15PxGF-0004mx-00 for ; Fri, 27 Jul 2001 04:21:55 +0200 Date: Fri, 27 Jul 2001 04:21:55 +0200 To: linux-mips@oss.sgi.com Subject: Re: [patch] fix profiling in glibc for Linux/MIPS Message-ID: <20010727042155.C27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010726181740.A8070@nevyn.them.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2338 Lines: 52 Daniel Jacobowitz wrote: [snip] > > Maybe I'm missing something, but both the old and the new code > > add 8 byte more to sp than they subtracted before. How is this > > supposed to work? > > It's supposed to do that, according to GCC. Build something with -S > -pg and look at it. Well, I don't have a 32bit compiler here ATM, only a highly experimental 64bit one. :-) But I found in the GCC Code this snippet in /config/mips.mips.h: /* Output assembler code to FILE to increment profiler label # LABELNO for profiling a function entry. */ #define FUNCTION_PROFILER(FILE, LABELNO) \ { \ if (TARGET_MIPS16) \ sorry ("mips16 function profiling"); \ fprintf (FILE, "\t.set\tnoreorder\n"); \ fprintf (FILE, "\t.set\tnoat\n"); \ fprintf (FILE, "\tmove\t%s,%s\t\t# save current return address\n", \ reg_names[GP_REG_FIRST + 1], reg_names[GP_REG_FIRST + 31]); \ fprintf (FILE, "\tjal\t_mcount\n"); \ fprintf (FILE, \ "\t%s\t%s,%s,%d\t\t# _mcount pops 2 words from stack\n", \ TARGET_64BIT ? "dsubu" : "subu", \ reg_names[STACK_POINTER_REGNUM], \ reg_names[STACK_POINTER_REGNUM], \ Pmode == DImode ? 16 : 8); \ fprintf (FILE, "\t.set\treorder\n"); \ fprintf (FILE, "\t.set\tat\n"); \ } This means, 8 byte is indeed ok for 32bit targets, a 64bit one would differ by 16 byte (and won't work with the code you've changed anyway). Nevertheless, IHMO it would be a good idea to support both targets. [snip] > > Why do you save and restore $6, $7, seemingly without using them? > > Because they were already there; I was trying to keep this patch > minimal. My MIPS assembly knowledge, as I said, is a little scanty. Hm, and I have too little knowledge about the profiler to give helpful advice here. Thiemo From owner-linux-mips@oss.sgi.com Thu Jul 26 20:04:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R34ZH05740 for linux-mips-outgoing; Thu, 26 Jul 2001 20:04:35 -0700 Received: from dea.waldorf-gmbh.de (u-179-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.179]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R34WV05737 for ; Thu, 26 Jul 2001 20:04:33 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6R34N115089; Fri, 27 Jul 2001 05:04:23 +0200 Date: Fri, 27 Jul 2001 05:04:23 +0200 From: Ralf Baechle To: "Siders, Keith" Cc: "'linux-mips@oss.sgi.com'" Subject: Re: Linux 2.4.6 Message-ID: <20010727050423.A14716@bacchus.dhis.org> References: <7DF7BFDC95ECD411B4010090278A44CA0A3BC1@ATVX> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7DF7BFDC95ECD411B4010090278A44CA0A3BC1@ATVX>; from keith_siders@toshibatv.com on Thu, Jul 26, 2001 at 04:02:04PM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 910 Lines: 25 On Thu, Jul 26, 2001 at 04:02:04PM -0500, Siders, Keith wrote: > I've made changes to the plain vanilla Linux 2.4.6 to port to our TX49H2 Stock kernel won't work. See http://oss.sgi.com/mips/mips-howto.html for how to get the latest MIPS kernel. > core on one of our EVB's. Which version of the compiler and binutils should > I use? The binutils-xx-2.8.1-2 and egcs-xx-1.1.2-4 worked for the 2.2.19 > port, but I'm getting errors in the shell scripts when I run 'make config'. > I get the same errors with the same tools with the generic 2.4.6 as well. > Looks like > > bash-2.04$ cd linux > bash-2.04$ make config > rm -f include/asm > ( cd include ; ln -sf asm-mips asm) > /bin/sh scripts/Configure arch/mips/config.in > : command not found > 'cripts/Configure: line 68: syntax error near unexpected token `{ > 'cripts/Configure: line 68: `function mainmenu_option () { Is /bin/sh bash at all? Ralf From owner-linux-mips@oss.sgi.com Thu Jul 26 20:18:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R3Ib906665 for linux-mips-outgoing; Thu, 26 Jul 2001 20:18:37 -0700 Received: from dea.waldorf-gmbh.de (u-179-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.179]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R3IYV06660 for ; Thu, 26 Jul 2001 20:18:35 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6R3IOC15151; Fri, 27 Jul 2001 05:18:24 +0200 Date: Fri, 27 Jul 2001 05:18:24 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: [patch] fix profiling in glibc for Linux/MIPS Message-ID: <20010727051823.B14716@bacchus.dhis.org> References: <20010726103922.A6643@nevyn.them.org> <20010727024820.B27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010727024820.B27008@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, Jul 27, 2001 at 02:48:20AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 701 Lines: 18 On Fri, Jul 27, 2001 at 02:48:20AM +0200, Thiemo Seufer wrote: > Date: Fri, 27 Jul 2001 02:48:20 +0200 > To: linux-mips@oss.sgi.com > Subject: Re: [patch] fix profiling in glibc for Linux/MIPS > From: Thiemo Seufer > > Daniel Jacobowitz wrote: > > _mcount was doing awful things to its caller's stack frame. > > Maybe I'm missing something, but both the old and the new code > add 8 byte more to sp than they subtracted before. How is this > supposed to work? _mcount has some odd special calling convention. I don't recall any official standard that defines _mcount's calling convention but gcc uses it the same way as the proprietary compiler I tried. Ralf From owner-linux-mips@oss.sgi.com Thu Jul 26 20:59:05 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6R3x5a09390 for linux-mips-outgoing; Thu, 26 Jul 2001 20:59:05 -0700 Received: from ms.gv.com.tw (ms.gv.com.tw [203.75.221.23]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6R3x2V09375 for ; Thu, 26 Jul 2001 20:59:02 -0700 Received: from jmt1 ([192.72.4.131]) by ms.gv.com.tw (8.9.3/8.9.3) with SMTP id MAA11248; Fri, 27 Jul 2001 12:04:23 +0800 Message-ID: <004a01c11651$07e206e0$830448c0@gv.com.tw> From: "Ž¿¬L©ú" To: "Siders, Keith" , References: <7DF7BFDC95ECD411B4010090278A44CA0A3BC1@ATVX> Subject: Re: Linux 2.4.6 Date: Fri, 27 Jul 2001 12:03:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1216 Lines: 39 bash v2.03 should help ----- Original Message ----- From: "Siders, Keith" To: Sent: Friday, July 27, 2001 5:02 AM Subject: Linux 2.4.6 I've made changes to the plain vanilla Linux 2.4.6 to port to our TX49H2 core on one of our EVB's. Which version of the compiler and binutils should I use? The binutils-xx-2.8.1-2 and egcs-xx-1.1.2-4 worked for the 2.2.19 port, but I'm getting errors in the shell scripts when I run 'make config'. I get the same errors with the same tools with the generic 2.4.6 as well. Looks like bash-2.04$ cd linux bash-2.04$ make config rm -f include/asm ( cd include ; ln -sf asm-mips asm) /bin/sh scripts/Configure arch/mips/config.in : command not found 'cripts/Configure: line 68: syntax error near unexpected token `{ 'cripts/Configure: line 68: `function mainmenu_option () { make: *** [config] Error 2 bash-2.04$ Not sure where to go from here as the scripts didn't change significantly between 2.2.19 and 2.4.6. Keith Siders Software Engineer Toshiba America Consumer Products, Inc. Advanced Television Technology Center 801 Royal Parkway, Suite 100 Nashville, Tennessee 37214 Phone: (615) 257-4050 Fax: (615) 453-7880 From owner-linux-mips@oss.sgi.com Fri Jul 27 06:40:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RDeaJ11604 for linux-mips-outgoing; Fri, 27 Jul 2001 06:40:36 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RDeZV11600 for ; Fri, 27 Jul 2001 06:40:35 -0700 Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA17466 for ; Fri, 27 Jul 2001 15:40:31 +0200 (MET DST) Received: (from tea@localhost) by ginger.sonytel.be (8.9.3+Sun/8.9.3) id PAA10230 for linux-mips@oss.sgi.com; Fri, 27 Jul 2001 15:40:30 +0200 (MEST) X-Authentication-Warning: ginger.sonytel.be: tea set sender to tea@sonycom.com using -f Date: Fri, 27 Jul 2001 15:40:30 +0200 From: Tom Appermont To: linux-mips@oss.sgi.com Subject: measuring time intervals in kernel Message-ID: <20010727154030.A10219@sonycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 248 Lines: 8 Howdy, Are there patches/applications/tools for mips that allow to measure time intervals in kernel paths? I'm thinking of something like timepeg (http://www.uow.edu.au/~andrewm/linux/) but prefer something that is running on mips already. Tom From owner-linux-mips@oss.sgi.com Fri Jul 27 07:03:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RE3b511950 for linux-mips-outgoing; Fri, 27 Jul 2001 07:03:37 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RE3QV11947; Fri, 27 Jul 2001 07:03:26 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR1SFL>; Fri, 27 Jul 2001 09:03:14 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BC2@ATVX> From: "Siders, Keith" To: "'Ralf Baechle'" Cc: "'linux-mips@oss.sgi.com'" Subject: RE: Linux 2.4.6 Date: Fri, 27 Jul 2001 09:02:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 549 Lines: 18 -> Stock kernel won't work. See http://oss.sgi.com/mips/mips-howto.html -> for how to get the latest MIPS kernel. Well I don't know how stock it is anymore. Over the last two weeks I made changes to about 139 files and had to add in another 116. %*O I just downloaded the 2.4.3 kernel from the MIPS Inc. site so I'll have a look at it. -> Is /bin/sh bash at all? -> -> Ralf -> I'll double check it. I think it was aliased, or maybe softlinked, but I'm currently running NT so I'll have to reboot to get back to the Linux side and see. Keith From owner-linux-mips@oss.sgi.com Fri Jul 27 07:05:49 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RE5n812030 for linux-mips-outgoing; Fri, 27 Jul 2001 07:05:49 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RE5mV12027 for ; Fri, 27 Jul 2001 07:05:48 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR1SFQ>; Fri, 27 Jul 2001 09:05:36 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BC3@ATVX> From: "Siders, Keith" To: "'L'" , linux-mips@oss.sgi.com Subject: RE: Linux 2.4.6 Date: Fri, 27 Jul 2001 09:04:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="big5" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 267 Lines: 8 -> bash v2.03 should help Well the curious thing is that bash 2.04 worked fine on scripts that were basically the same to compile 2.2.19. Bash 2.04 came with the RedHat 7.1 so I'd have to back up to the earlier version and hope it works under the 2.4.2-2 kernel. K From owner-linux-mips@oss.sgi.com Fri Jul 27 09:05:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RG5GO14977 for linux-mips-outgoing; Fri, 27 Jul 2001 09:05:16 -0700 Received: from server3.toshibatv.com ([207.152.29.75]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RG5AV14969; Fri, 27 Jul 2001 09:05:11 -0700 Received: by SERVER3 with Internet Mail Service (5.5.2650.21) id <3MTR1S2K>; Fri, 27 Jul 2001 11:04:57 -0500 Message-ID: <7DF7BFDC95ECD411B4010090278A44CA0A3BC4@ATVX> From: "Siders, Keith" To: "Siders, Keith" , "'Ralf Baechle'" Cc: "'linux-mips@oss.sgi.com'" Subject: RE: Linux 2.4.6 Date: Fri, 27 Jul 2001 11:03:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 297 Lines: 17 -> -> Is /bin/sh bash at all? -> -> -> -> Ralf -> -> -> -> I'll double check it. I think it was aliased, or maybe -> softlinked, but I'm -> currently running NT so I'll have to reboot to get back to -> the Linux side -> and see. -> -> Keith -> Verified the softlink... /bin/sh -> bash K From owner-linux-mips@oss.sgi.com Fri Jul 27 10:12:21 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6RHCLN16019 for linux-mips-outgoing; Fri, 27 Jul 2001 10:12:21 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6RHCAV16014 for ; Fri, 27 Jul 2001 10:12:10 -0700 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 f6RGAsW29970; Fri, 27 Jul 2001 09:10:54 -0700 Message-ID: <3B619FBB.C9F53A65@mvista.com> Date: Fri, 27 Jul 2001 10:07:07 -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: Tom Appermont CC: linux-mips@oss.sgi.com Subject: Re: measuring time intervals in kernel References: <20010727154030.A10219@sonycom.com> Content-Type: multipart/mixed; boundary="------------F9799E7F614F2D223D4D915C" Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 21121 Lines: 710 This is a multi-part message in MIME format. --------------F9799E7F614F2D223D4D915C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Appermont wrote: > > Howdy, > > Are there patches/applications/tools for mips that allow to > measure time intervals in kernel paths? I'm thinking of > something like timepeg (http://www.uow.edu.au/~andrewm/linux/) > but prefer something that is running on mips already. > > Tom I wrote the original intlat patch for intel and ppc. There is a half-way ported MIPS patch you might be interested. The patch is aginst mvista HHL2.0 kernel. YOu can find the source in the journeyman edit/Malta cross lsp rpm package from the ftp site. You may also need to download the perfview user program by following the www.mvista.com/realtime. Jun --------------F9799E7F614F2D223D4D915C Content-Type: text/plain; charset=us-ascii; name="lat-measurement-mips-partial.0106xxx.010623.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lat-measurement-mips-partial.0106xxx.010623.patch" This patch is obtained by mirroring ppc patch. Two things need to be done: 1. get CPU counter frequency 2. do_IRQ() does not apply readily to Malta board. Either work harder to get it right (under arch/mips/mips-boards/Malta/int.c, roughly), or pick another board. Jun Sun 010623 diff -Nru linux/arch/mips/kernel/Makefile.orig linux/arch/mips/kernel/Makefile --- linux/arch/mips/kernel/Makefile.orig Wed May 30 11:53:23 2001 +++ linux/arch/mips/kernel/Makefile Fri Jun 22 12:09:03 2001 @@ -20,7 +20,8 @@ obj-y += branch.o process.o signal.o entry.o \ traps.o ptrace.o vm86.o ioport.o reset.o \ semaphore.o setup.o syscall.o sysmips.o \ - ipc.o scall_o32.o unaligned.o fast-sysmips.o + ipc.o scall_o32.o unaligned.o fast-sysmips.o\ + intr_blocking.o ktprocentry.o intlatsamps.o obj-$(CONFIG_MODULES) += mips_ksyms.o ifdef CONFIG_CPU_R3000 diff -Nru linux/arch/mips/kernel/intlatsamps.c.orig linux/arch/mips/kernel/intlatsamps.c --- linux/arch/mips/kernel/intlatsamps.c.orig Fri Jun 22 12:19:47 2001 +++ linux/arch/mips/kernel/intlatsamps.c Fri Jun 22 13:20:59 2001 @@ -0,0 +1,159 @@ +/*++++++++++++++ +Change the INTLAT_CPU_KHZ to the processor clock in your setup. +--------------*/ +#include +#include +#include +#include +#include +#include +#include + +#define BUCKETS 30 +#define INTLAT_CPU_KHZ NEED_TO_FIND_OUT + +unsigned long cpu_khz = INTLAT_CPU_KHZ; /* number of rdtsc ticks per second/1000 */ + +unsigned bucketlog [2][BUCKETS] = { + { 2, 4, 6, 8, 10, 15, 20, 30, 40, 50, 75, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 700, 800, 900, 1000, 2000, 5000, 9000}, /* thresholds*/ + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } /* number of samples in the bucket *ssociated to a threshold */ +}; + +unsigned long total_samples; /* total number of samples collected so far in this boot session */ + +asmlinkage void inthoff_logentry(unsigned diff) +{ + unsigned sampletime = diff / (cpu_khz / 1000); + + if (sampletime < bucketlog [0][0] ) + bucketlog[1][0]++; + else if (sampletime < bucketlog [0][1] ) + bucketlog[1][1]++; + else if (sampletime < bucketlog [0][2] ) + bucketlog[1][2]++; + else if (sampletime < bucketlog [0][3] ) + bucketlog[1][3]++; + else if (sampletime < bucketlog [0][4] ) + bucketlog[1][4]++; + else if (sampletime < bucketlog [0][5] ) + bucketlog[1][5]++; + else if (sampletime < bucketlog [0][6] ) + bucketlog[1][6]++; + else if (sampletime < bucketlog [0][7] ) + bucketlog[1][7]++; + else if (sampletime < bucketlog [0][8] ) + bucketlog[1][8]++; + else if (sampletime < bucketlog [0][9] ) + bucketlog[1][9]++; + else if (sampletime < bucketlog [0][10] ) + bucketlog[1][10]++; + else if (sampletime < bucketlog [0][11] ) + bucketlog[1][11]++; + else if (sampletime < bucketlog [0][12] ) + bucketlog[1][12]++; + else if (sampletime < bucketlog [0][13] ) + bucketlog[1][13]++; + else if (sampletime < bucketlog [0][14] ) + bucketlog[1][14]++; + else if (sampletime < bucketlog [0][15] ) + bucketlog[1][15]++; + else if (sampletime < bucketlog [0][16] ) + bucketlog[1][16]++; + else if (sampletime < bucketlog [0][17] ) + bucketlog[1][17]++; + else if (sampletime < bucketlog [0][18] ) + bucketlog[1][18]++; + else if (sampletime < bucketlog [0][19] ) + bucketlog[1][19]++; + else if (sampletime < bucketlog [0][20] ) + bucketlog[1][20]++; + else if (sampletime < bucketlog [0][21] ) + bucketlog[1][21]++; + else if (sampletime < bucketlog [0][22] ) + bucketlog[1][22]++; + else if (sampletime < bucketlog [0][23] ) + bucketlog[1][23]++; + else if (sampletime < bucketlog [0][24] ) + bucketlog[1][24]++; + else if (sampletime < bucketlog [0][25] ) + bucketlog[1][25]++; + else if (sampletime < bucketlog [0][26] ) + bucketlog[1][26]++; + else if (sampletime < bucketlog [0][27] ) + bucketlog[1][27]++; + else if (sampletime < bucketlog [0][28] ) + bucketlog[1][28]++; + else + bucketlog[1][29]++; + + total_samples++; + + return; +} + +static int g_read_completed = 0; + +static int ktimes_read_proc( + char *page_buffer, + char **my_first_byte, + off_t virtual_start, + int length, + int *eof, + void *data) +{ + int my_buffer_offset = 0; + char * const my_base = page_buffer; + int i; + if (virtual_start == 0){ + /* Just been opened so display the header information also stop logging */ + /* BUGBUG: stop logging while we are reading*/ + /* initialize the index numbers in the log array */ + + g_read_completed = 0; + + my_buffer_offset += + sprintf(my_base+my_buffer_offset, + "Bucketing of samples for the total of %ld samples logged during this boot session\n" + "CPU clock measured %ld KHz.\n" + " Threshold (usec)\t\t Number of samples\n", + total_samples,cpu_khz); + + }else if (g_read_completed == BUCKETS){ + *eof = 1; + /* BUGBUG: start logging again */ + return 0; + } + + /* dump the sample log on the screen */ + for (i = 0; i < (BUCKETS-1); i++) { + my_buffer_offset += + sprintf(my_base + my_buffer_offset, + " Less than %3u\t\t\t%10u\n", + bucketlog[0][i], + bucketlog[1][i]); + g_read_completed++; + } + my_buffer_offset += + sprintf(my_base + my_buffer_offset, + " Above %3u\t\t\t%10u\n", + bucketlog[0][i], + bucketlog[1][i]); + g_read_completed++; + + *my_first_byte = page_buffer; + return my_buffer_offset; +} + + +int __init +inthoffsamps_init(void) +{ + printk("Interrupt holdoff times measurement enabled.\n"); + create_proc_read_entry("inthoffsamps", 0, 0, ktimes_read_proc, 0); + return 0; +} + + +__initcall(inthoffsamps_init); + + diff -Nru linux/arch/mips/kernel/intr_blocking.c.orig linux/arch/mips/kernel/intr_blocking.c --- linux/arch/mips/kernel/intr_blocking.c.orig Fri Jun 22 13:22:17 2001 +++ linux/arch/mips/kernel/intr_blocking.c Fri Jun 22 13:25:11 2001 @@ -0,0 +1,258 @@ +#include + +extern void inthoff_logentry(unsigned); + +/**** platform ****/ +#include +#define readclock(low) \ + read_32bit_cp0_register(CP0_COUNT) + +/**** configure ****/ +#define NUM_LOG_ENTRY 8 +#define INTR_IENABLE 1 + +struct IntrData { + /* count interrupt and iret */ + int breakCount; + + /* the test name */ + const char * testName; + + /* flag to control logging */ + unsigned logFlag; /* 0 - no logging; 1 - logging */ + + /* panic flag - set to 1 if something is realy wrong */ + unsigned panicFlag; + + /* for synchro between start and end */ + unsigned syncFlag; + + /* we only log interrupts within certain range */ + unsigned rangeLow; + unsigned rangeHigh; + + /* count the total number interrupts and intrs in range*/ + unsigned numIntrs; + unsigned numInRangeIntrs; + + + /* error accounting */ + unsigned skipSti; + unsigned skipCli; + unsigned syncStiError; + unsigned syncCliError; + unsigned stiBreakError; + unsigned restoreSti; + unsigned restoreCli; + + struct { + /* worst blocking time */ + unsigned blockingTime; + + const char * startFileName; + unsigned startFileLine; + unsigned startCount; + + const char *endFileName; + unsigned endFileLine; + unsigned endCount; + } count[NUM_LOG_ENTRY]; +}; + +struct IntrData intrData = { + 0, + "interrupt latency test for PPC (8 distinctive entries)", + 0, + 0, + 0, + + 1, + 0xffffffff, + + 0, + 0, + + 0, + 0, + 0, + 0, + 0, + 0, + 0 +}; + +static const char *intrStartFileName; +static unsigned intrStartFileLine; +static unsigned intrStartCount; + +/* strategy : + * if it is true "cli", i.e., clearing the IF, we remember + * everything, and clear breakCount. + */ +int intr_cli(const char *fname, unsigned lineno) +{ + unsigned flag; + int retValue = 0; + + __save_flags(flag); + + __intr_cli(); + + /* if we are not logging or we have an error, do nothing */ + if ((intrData.logFlag == 0) || ( intrData.panicFlag != 0)) { + return retValue; + } + + /* do nothing we had IF cleared before we call this function */ + if ((flag & INTR_IENABLE) == 0) { + intrData.skipCli ++; + return retValue; + } + + /* debug */ + if (intrData.syncFlag == 1) { + intrData.syncCliError ++; + } + intrData.syncFlag = 1; + + intrData.breakCount = 0; + + /* Read the Time Stamp Counter */ + intrStartFileName = fname; + intrStartFileLine = lineno; + readclock(intrStartCount); + + return retValue; +} + +/* strategy: + * we do a count only if + * 1. syncFlag is 1 (a valid cli() was called) + * 2. breakCount is 0 (no iret is called between cli() and this sti() + */ +void intr_sti(const char *fname, unsigned lineno) +{ + unsigned flag; + unsigned endCount; + unsigned diff; + int i; + + __save_flags(flag); + + /* if we are not logging or we have an error, do nothing */ + if ((intrData.logFlag == 0) || ( intrData.panicFlag != 0)) { + __intr_sti(); + return; + } + + + /* check if this is a real sti() */ + if ((flag & INTR_IENABLE) != 0) { + intrData.skipSti ++; + __intr_sti(); + return; + } + + + /* check 1*/ + if (intrData.syncFlag != 1) { + intrData.syncStiError ++; + __intr_sti(); + return; + } + + /* check 2 */ + if (intrData.breakCount != 0) { + intrData.stiBreakError ++; + __intr_sti(); + return; + } + + /* read count again */ + readclock(endCount); + + intrData.syncFlag = 0; + + diff = endCount - intrStartCount; + + if ((diff >= intrData.rangeLow) && (diff <= intrData.rangeHigh)) { + unsigned lowest=0xffffffff; + unsigned lowestIndex; + unsigned sameIndex = 0xffffffff; + + intrData.numInRangeIntrs++; + + /* check if we need to log this event */ + for (i=0; i< NUM_LOG_ENTRY; i++) { + + if (lowest > intrData.count[i].blockingTime) { + lowest = intrData.count[i].blockingTime; + lowestIndex = i; + } + + if ( (lineno == intrData.count[i].endFileLine) && + (intrStartFileLine == intrData.count[i].startFileLine) && + (fname[0] == intrData.count[i].endFileName[0]) && + (intrStartFileName[0] == intrData.count[i].startFileName[0]) ) { + /* if the line numbers are same, the first chars in + * both file names are same, we consider it is the same + * entry. */ + sameIndex = i; + } + } + + if (sameIndex == 0xffffffff) { + i = lowestIndex; + } else { + i = sameIndex; + } + + if (diff > intrData.count[i].blockingTime) { + intrData.count[i].blockingTime = diff; + intrData.count[i].endFileName = fname; + intrData.count[i].endFileLine = lineno; + intrData.count[i].endCount = endCount; + intrData.count[i].startFileName = intrStartFileName; + intrData.count[i].startFileLine = intrStartFileLine; + intrData.count[i].startCount = intrStartCount; + } + } + inthoff_logentry(diff); + intrData.numIntrs++; + __intr_sti(); +} + +void intr_restore_flags(const char *fname, unsigned lineno, unsigned x) +{ + unsigned flag; + + /* if we are not logging or we have an error, do nothing */ + if ((intrData.logFlag == 0) || ( intrData.panicFlag != 0)) { + __intr_restore_flags(x); + return; + } + + __save_flags(flag); + + if (((flag & INTR_IENABLE) == 0) && + ((x & INTR_IENABLE) != 0) ) { + intrData.restoreSti ++; + intr_sti(fname, lineno); + } + + if ( ((flag & INTR_IENABLE) != 0) && + ((x & INTR_IENABLE) == 0) ) { + intrData.restoreCli ++; + intr_cli(fname, lineno); + } + + __intr_restore_flags(x); +} + +#include + +asmlinkage int sys_get_intrData(void ** ptr) +{ + return put_user(&intrData, ptr); +} + diff -Nru linux/arch/mips/kernel/ktprocentry.c.orig linux/arch/mips/kernel/ktprocentry.c --- linux/arch/mips/kernel/ktprocentry.c.orig Fri Jun 22 13:32:33 2001 +++ linux/arch/mips/kernel/ktprocentry.c Fri Jun 22 13:52:22 2001 @@ -0,0 +1,156 @@ +/*++++++++++++++ +Change the KTIME_CPU_KHZ to the processor clock in your setup. +--------------*/ +#include +#include +#include +#include +#include +#include +#include + +#include +#define readclock(low) \ + read_32bit_cp0_register(CP0_COUNT) + +#define NUM_LOG_ENTRY 16 +#define KTIME_CPU_KHZ NEED_TO_FIGURE_OUT + +static unsigned kTimeStartCount; /* count when interrupt processing started in the kernel */ +static unsigned startIrq; /* irq number we are measuring the latency for, used to take care */ + /* of nested interrupt. */ +struct log_entry { + unsigned irqNumber; /* irq being handled */ + unsigned kTime; /* Time spent in kernel before calling the last handler in the list */ + unsigned startCount; /* count when do_IRQ was handed control to process the interrupt */ + unsigned endCount; /* count when last handler in the list was called */ +}; + +struct kTimeData { + unsigned logFlag; /* 0 - no logging; 1 - logging */ + struct log_entry entry[NUM_LOG_ENTRY]; /* Samples where processing time in the kernel was max*/ +}; + +struct kTimeData ktimeData = { + logFlag: 1, +}; + +void ktime_logentry(unsigned kTimeEndCount, unsigned irqnum) +{ + unsigned diff; + + diff = kTimeEndCount - kTimeStartCount; + + /* If this sample for this irq is greater than the previous one logged then replace it */ + if(diff > ktimeData.entry[irqnum].kTime) + { + ktimeData.entry[irqnum].irqNumber = irqnum; + ktimeData.entry[irqnum].kTime = diff; + ktimeData.entry[irqnum].startCount = kTimeStartCount; + ktimeData.entry[irqnum].endCount = kTimeEndCount; + } + kTimeStartCount = 0; + return; +} + +asmlinkage void ktime_end(unsigned irqnum) +{ + unsigned kTimeEndCount; + + /* if we are not logging or kTimeStartCount is zero (which should never happen) do nothing */ + if(ktimeData.logFlag == 0 || kTimeStartCount == 0 || startIrq != irqnum) + { + return; + } + + /* read timestamp counter again */ + readclock(kTimeEndCount); + + /* log the entry if appropriate */ + ktime_logentry(kTimeEndCount, irqnum); +} + +asmlinkage void ktime_start(unsigned irqnum) +{ + /* If we are not logging, do nothing */ + if(ktimeData.logFlag == 0 || kTimeStartCount != 0) + { + return; + } + + /* remember the irq we are monitoring */ + startIrq = irqnum; + + /* read timestamp counter */ + readclock(kTimeStartCount); + + return; +} + +static int g_read_completed = 0; + +static int ktimes_read_proc( + char *page_buffer, + char **my_first_byte, + off_t virtual_start, + int length, + int *eof, + void *data) +{ + int my_buffer_offset = 0; + char * const my_base = page_buffer; + int i; + unsigned long cpu_khz = KTIME_CPU_KHZ; + + if (virtual_start == 0){ + /* Just been opened so display the header information also stop logging */ + ktimeData.logFlag = 0; /* stop logging while we are reading*/ + /* initialize the index numbers in the log array */ + for (i=0;i; Fri, 27 Jul 2001 17:03:54 -0700 Message-ID: <20010728000354.84537.qmail@web13908.mail.yahoo.com> Received: from [61.187.62.84] by web13908.mail.yahoo.com; Fri, 27 Jul 2001 17:03:54 PDT Date: Fri, 27 Jul 2001 17:03:54 -0700 (PDT) From: Barry Wu Subject: serial console startup problem To: linux-mips@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 911 Lines: 35 Hi,all, When linux 2.4.3 startup, our serial console can not work. I use another serial port to print some debug messages, it likes following: hda: 16841664 sectorsp: (8623 MB)p: w/512KiB Cachep:, CHS=16708/16/63p: Partition check: hda:[PTBL] [1048/255/63] hda1 hda4 Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ SERIAL_PCI e nabled ttyS00 at 0xb8000000 (irq = 2) is a 16550A ttyS01 at 0xb8100000 (irq = 3) is a 16550A VFS: Mounted root (ext2 filesystem) readonly. Freeing prom memory: 1020kb freed Freeing unused kernel memory: 52k freed kernel BUG at page_alloc.c:191! kernel BUG at page_alloc.c:191! kernel BUG at page_alloc.c:191! Do someone know what's problem it is? If you know, please help me. Thanks! Barry __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-linux-mips@oss.sgi.com Sat Jul 28 04:51:08 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SBp8o20143 for linux-mips-outgoing; Sat, 28 Jul 2001 04:51:08 -0700 Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SBp6V20137 for ; Sat, 28 Jul 2001 04:51:07 -0700 Received: from fwd01.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15QScZ-0004c5-03; Sat, 28 Jul 2001 13:51:03 +0200 Received: from erich (520031278902-0001@[62.155.142.221]) by fmrl01.sul.t-online.com with esmtp id 15QScM-1eMrpYC; Sat, 28 Jul 2001 13:50:50 +0200 Received: by erich (Postfix, from userid 1000) id 3565C4822B; Wed, 25 Jul 2001 23:59:24 +0200 (CEST) Date: Wed, 25 Jul 2001 23:59:24 +0200 From: Erich Schubert To: Debian MIPS list , SGI MIPS list Subject: Sound on SGI Indy? Message-ID: <20010725235924.A2124@erich.xmldesign.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i X-GPG: 4B3A135C 6073 C874 8488 BCDA A6A9 B761 9ED0 78EF 4B3A 135C X-Sender: 520031278902-0001@t-dialin.net Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 519 Lines: 16 did anyone get sound to run on a Indy? As far as i've read, alsa does contain drivers which should play sound correctly. So i checked out current cvs kernel, compiled it, compiled alsa and tried to load the modules - and got a kernel oops. Can someone point me to some recent information about sound on sgi indy? Greetings, Erich P.S. I've currently not subscribed the SGI Mips list, only the debian mips list - so please do not reply to the list only. Thanks. Please do not crosspost replys to both lists. Thanks. From owner-linux-mips@oss.sgi.com Sat Jul 28 08:58:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SFwPI10273 for linux-mips-outgoing; Sat, 28 Jul 2001 08:58:25 -0700 Received: from trasno.org (congress234.linuxsymposium.org [209.151.18.234]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SFwLV10267 for ; Sat, 28 Jul 2001 08:58:21 -0700 Received: by trasno.org (Postfix, from userid 501) id A1E535470; Sat, 28 Jul 2001 14:23:44 +0200 (CEST) To: Jun Sun Cc: Tom Appermont , linux-mips@oss.sgi.com Subject: Re: measuring time intervals in kernel References: <20010727154030.A10219@sonycom.com> <3B619FBB.C9F53A65@mvista.com> X-Url: http://www.lfcia.org/~quintela From: Juan Quintela In-Reply-To: <3B619FBB.C9F53A65@mvista.com> Date: 28 Jul 2001 14:23:44 +0200 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6236 Lines: 199 >>>>> "jun" == Jun Sun writes: Hi could you look at this changes, no change in functionality, only better readability, jun> +asmlinkage void inthoff_logentry(unsigned diff) jun> +{ jun> + unsigned sampletime = diff / (cpu_khz / 1000); jun> + jun> + if (sampletime < bucketlog [0][0] ) jun> + bucketlog[1][0]++; jun> + else if (sampletime < bucketlog [0][1] ) jun> + bucketlog[1][1]++; jun> + else if (sampletime < bucketlog [0][2] ) jun> + bucketlog[1][2]++; jun> + else if (sampletime < bucketlog [0][3] ) jun> + bucketlog[1][3]++; jun> + else if (sampletime < bucketlog [0][4] ) jun> + bucketlog[1][4]++; jun> + else if (sampletime < bucketlog [0][5] ) jun> + bucketlog[1][5]++; jun> + else if (sampletime < bucketlog [0][6] ) jun> + bucketlog[1][6]++; jun> + else if (sampletime < bucketlog [0][7] ) jun> + bucketlog[1][7]++; jun> + else if (sampletime < bucketlog [0][8] ) jun> + bucketlog[1][8]++; jun> + else if (sampletime < bucketlog [0][9] ) jun> + bucketlog[1][9]++; jun> + else if (sampletime < bucketlog [0][10] ) jun> + bucketlog[1][10]++; jun> + else if (sampletime < bucketlog [0][11] ) jun> + bucketlog[1][11]++; jun> + else if (sampletime < bucketlog [0][12] ) jun> + bucketlog[1][12]++; jun> + else if (sampletime < bucketlog [0][13] ) jun> + bucketlog[1][13]++; jun> + else if (sampletime < bucketlog [0][14] ) jun> + bucketlog[1][14]++; jun> + else if (sampletime < bucketlog [0][15] ) jun> + bucketlog[1][15]++; jun> + else if (sampletime < bucketlog [0][16] ) jun> + bucketlog[1][16]++; jun> + else if (sampletime < bucketlog [0][17] ) jun> + bucketlog[1][17]++; jun> + else if (sampletime < bucketlog [0][18] ) jun> + bucketlog[1][18]++; jun> + else if (sampletime < bucketlog [0][19] ) jun> + bucketlog[1][19]++; jun> + else if (sampletime < bucketlog [0][20] ) jun> + bucketlog[1][20]++; jun> + else if (sampletime < bucketlog [0][21] ) jun> + bucketlog[1][21]++; jun> + else if (sampletime < bucketlog [0][22] ) jun> + bucketlog[1][22]++; jun> + else if (sampletime < bucketlog [0][23] ) jun> + bucketlog[1][23]++; jun> + else if (sampletime < bucketlog [0][24] ) jun> + bucketlog[1][24]++; jun> + else if (sampletime < bucketlog [0][25] ) jun> + bucketlog[1][25]++; jun> + else if (sampletime < bucketlog [0][26] ) jun> + bucketlog[1][26]++; jun> + else if (sampletime < bucketlog [0][27] ) jun> + bucketlog[1][27]++; jun> + else if (sampletime < bucketlog [0][28] ) jun> + bucketlog[1][28]++; jun> + else jun> + bucketlog[1][29]++; jun> + jun> + total_samples++; jun> + jun> + return; jun> +} Any reason for not changing that to something like this? asmlinkage void inthoff_logentry(unsigned diff) { unsigned sampletime = diff / (cpu_khz / 1000); int i = 0; while ((i < BUCKETS-1) && (sampletime >= bucketlog [0][i])) i++; bucketlog[1][i]++; total_samples++; return; } jun> +struct IntrData intrData = { jun> + 0, jun> + "interrupt latency test for PPC (8 distinctive entries)", jun> + 0, jun> + 0, jun> + 0, jun> + jun> + 1, jun> + 0xffffffff, jun> + jun> + 0, jun> + 0, jun> + jun> + 0, jun> + 0, jun> + 0, jun> + 0, jun> + 0, jun> + 0, jun> + 0 jun> +}; struct IntrData intrData = { testname: "interrupt latency test for PPC (8 distinctive entries)", rangeLow: 1, rangeHigh: 0xffffffff, } jun> + * we do a count only if jun> + * 1. syncFlag is 1 (a valid cli() was called) jun> + * 2. breakCount is 0 (no iret is called between cli() and this sti() jun> + */ Move this commets to their position in the code (not sure what is better, but /* check 1 */ /* check 2 */ comments are missleading, and don't show clearly in diffs :((( jun> +void intr_sti(const char *fname, unsigned lineno) jun> +{ [...] jun> + jun> + /* check 1*/ here jun> + if (intrData.syncFlag != 1) { jun> + intrData.syncStiError ++; jun> + __intr_sti(); jun> + return; jun> + } jun> + jun> + /* check 2 */ and here jun> + if (intrData.breakCount != 0) { jun> + intrData.stiBreakError ++; jun> + __intr_sti(); jun> + return; jun> + } I miss read this two tests the first time, how about a change like that (I assume that the the check with (x & INT_IENABLE) means interrupts enabled, otherwise change the names of the vars. jun> +void intr_restore_flags(const char *fname, unsigned lineno, unsigned x) jun> +{ jun> + unsigned flag; unsigned flag_int_enabled; unsigned x_int_enabled; jun> + jun> + /* if we are not logging or we have an error, do nothing */ jun> + if ((intrData.logFlag == 0) || ( intrData.panicFlag != 0)) { jun> + __intr_restore_flags(x); jun> + return; jun> + } jun> + jun> + __save_flags(flag); flag_int_enabled = (flag & INTR_IENABLE) != 0; x_int_enabled = (x & INTR_IENABLE) != 0; jun> + if (((flag & INTR_IENABLE) == 0) && jun> + ((x & INTR_IENABLE) != 0) ) { if (!flag_int_enabled && x_int_enabled) { jun> + intrData.restoreSti ++; jun> + intr_sti(fname, lineno); jun> + } jun> + jun> + if ( ((flag & INTR_IENABLE) != 0) && jun> + ((x & INTR_IENABLE) == 0) ) { if (flag_int_enabled && !x_int_enabled) { jun> + intrData.restoreCli ++; jun> + intr_cli(fname, lineno); jun> + } jun> + jun> + __intr_restore_flags(x); jun> +} /me decides that he has been enough pedantic today. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From owner-linux-mips@oss.sgi.com Sat Jul 28 12:41:20 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SJfK619701 for linux-mips-outgoing; Sat, 28 Jul 2001 12:41:20 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SJfGV19686 for ; Sat, 28 Jul 2001 12:41:17 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id C9813C4FE; Sat, 28 Jul 2001 21:41:14 +0200 (CEST) Date: Sat, 28 Jul 2001 21:41:14 +0200 From: Jan-Benedict Glaw To: SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: [long] Lance on DS5k/200 Message-ID: <20010728214114.C27316@lug-owl.de> Mail-Followup-To: SGI MIPS list , Debian MIPS list , engel@unix-ag.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 5719 Lines: 166 Hi! I'm tryin' to get a DS5000/200 to work. Currently, I see that declance.c wasn't complete wrt. this system. Problem: ring buffer pointers not initialized, Oops. I've copied that part from {PMAX_LANCE,ASIC_LANCE}, but that seems not to be enough. So now, the kernel loops infinitive when trying to send a bootp packet. Here's what I did: static int __init dec_lance_init(struct net_device *dev, const int type) { [...] switch (type) { [...] case PMAD_LANCE: slot = search_tc_card("PMAD-AA"); claim_tc_card(slot); dev->mem_start = get_tc_base_addr(slot); dev->base_addr = dev->mem_start + 0x100000; dev->irq = get_tc_irq_nr(slot); esar_base = dev->mem_start + 0x1c0002; /* * setup the pointer arrays, this sucks [tm] :-( */ for (i = 0; i < RX_RING_SIZE; i++) { lp->rx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU + 2 * i * RX_BUFF_SIZE); printk("lp->rx_buf_ptr_cpu[%d]=%p\n", i, lp->rx_buf_ptr_cpu[i] ); lp->rx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC + i * RX_BUFF_SIZE); printk("lp->rx_buf_ptr_lnc[%d]=%p\n", i, lp->rx_buf_ptr_lnc[i] ); } for (i = 0; i < TX_RING_SIZE; i++) { lp->tx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU + 2 * RX_RING_SIZE * RX_BUFF_SIZE + 2 * i * TX_BUFF_SIZE); printk("lp->tx_buf_ptr_cpu[%d]=%p\n", i, lp->tx_buf_ptr_cpu[i] ); lp->tx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC + RX_RING_SIZE * RX_BUFF_SIZE + i * TX_BUFF_SIZE); printk("lp->tx_buf_ptr_lnc[%d]=%p\n", i, lp->tx_buf_ptr_lnc[i] ); } break; [...] } However, the chip actually does not transmit the frame. Please look at it because I don't have a clue about the lance chip. Especially, I see there problems: - lp->tx_buf_ptr_lnc[i] and lp->rx_buf_ptr_lnc[i] are quite low addresses. Is this correct? Are they relative to some other address (TC slot address?) - while kernel's bootp tries to send the packet, only buffers [0] to [5] are used. Why are not all 16 buffers used? It would be *very* nice if the people who originally wrote this driver could help me... Here's the serial console's output: >>boot 6/tftp console=ttyS3 root=/dev/nfs ip=bootp rw 1630208+139264+146848 This DECstation is a DS5000/200 Loading R[23]000 MMU routines. [...] TURBOchannel rev. 1 at 25.0 MHz (without parity) slot 5: DEC PMAZ-AA V5.3b slot 6: DEC PMAD-AA V5.3a [...] declance.c: v0.008 by Linux Mips DECstation task force lp->rx_buf_ptr_cpu[0]=bf800240 lp->rx_buf_ptr_lnc[0]=00000120 lp->rx_buf_ptr_cpu[1]=bf800e40 lp->rx_buf_ptr_lnc[1]=00000720 lp->rx_buf_ptr_cpu[2]=bf801a40 lp->rx_buf_ptr_lnc[2]=00000d20 lp->rx_buf_ptr_cpu[3]=bf802640 lp->rx_buf_ptr_lnc[3]=00001320 lp->rx_buf_ptr_cpu[4]=bf803240 lp->rx_buf_ptr_lnc[4]=00001920 lp->rx_buf_ptr_cpu[5]=bf803e40 lp->rx_buf_ptr_lnc[5]=00001f20 lp->rx_buf_ptr_cpu[6]=bf804a40 lp->rx_buf_ptr_lnc[6]=00002520 lp->rx_buf_ptr_cpu[7]=bf805640 lp->rx_buf_ptr_lnc[7]=00002b20 lp->rx_buf_ptr_cpu[8]=bf806240 lp->rx_buf_ptr_lnc[8]=00003120 lp->rx_buf_ptr_cpu[9]=bf806e40 lp->rx_buf_ptr_lnc[9]=00003720 lp->rx_buf_ptr_cpu[10]=bf807a40 lp->rx_buf_ptr_lnc[10]=00003d20 lp->rx_buf_ptr_cpu[11]=bf808640 lp->rx_buf_ptr_lnc[11]=00004320 lp->rx_buf_ptr_cpu[12]=bf809240 lp->rx_buf_ptr_lnc[12]=00004920 lp->rx_buf_ptr_cpu[13]=bf809e40 lp->rx_buf_ptr_lnc[13]=00004f20 lp->rx_buf_ptr_cpu[14]=bf80aa40 lp->rx_buf_ptr_lnc[14]=00005520 lp->rx_buf_ptr_cpu[15]=bf80b640 lp->rx_buf_ptr_lnc[15]=00005b20 lp->tx_buf_ptr_cpu[0]=bf80c240 lp->tx_buf_ptr_lnc[0]=00006120 lp->tx_buf_ptr_cpu[1]=bf80ce40 lp->tx_buf_ptr_lnc[1]=00006720 lp->tx_buf_ptr_cpu[2]=bf80da40 lp->tx_buf_ptr_lnc[2]=00006d20 lp->tx_buf_ptr_cpu[3]=bf80e640 lp->tx_buf_ptr_lnc[3]=00007320 lp->tx_buf_ptr_cpu[4]=bf80f240 lp->tx_buf_ptr_lnc[4]=00007920 lp->tx_buf_ptr_cpu[5]=bf80fe40 lp->tx_buf_ptr_lnc[5]=00007f20 lp->tx_buf_ptr_cpu[6]=bf810a40 lp->tx_buf_ptr_lnc[6]=00008520 lp->tx_buf_ptr_cpu[7]=bf811640 lp->tx_buf_ptr_lnc[7]=00008b20 lp->tx_buf_ptr_cpu[8]=bf812240 lp->tx_buf_ptr_lnc[8]=00009120 lp->tx_buf_ptr_cpu[9]=bf812e40 lp->tx_buf_ptr_lnc[9]=00009720 lp->tx_buf_ptr_cpu[10]=bf813a40 lp->tx_buf_ptr_lnc[10]=00009d20 lp->tx_buf_ptr_cpu[11]=bf814640 lp->tx_buf_ptr_lnc[11]=0000a320 lp->tx_buf_ptr_cpu[12]=bf815240 lp->tx_buf_ptr_lnc[12]=0000a920 lp->tx_buf_ptr_cpu[13]=bf815e40 lp->tx_buf_ptr_lnc[13]=0000af20 lp->tx_buf_ptr_cpu[14]=bf816a40 lp->tx_buf_ptr_lnc[14]=0000b520 lp->tx_buf_ptr_cpu[15]=bf817640 lp->tx_buf_ptr_lnc[15]=0000bb20 eth0: PMAD-AA, addr = 08:00:2b:1c:44:ee, irq = 3 [...] Sending BOOTP requests .lance_start_xmit:882: entry=0 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=1 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[1]=bf80ce40, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=2 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[2]=bf80da40, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=3 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[3]=bf80e640, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=4 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[4]=bf80f240, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=5 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[5]=bf80fe40, skb->data=8022c402, skblen=590) timed out! IP-Config: Retrying forever (NFS root)... Sending BOOTP requests .lance_start_xmit:882: entry=0 lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590) .lance_start_xmit:882: entry=1 [...] From owner-linux-mips@oss.sgi.com Sat Jul 28 14:02:11 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6SL2BZ30886 for linux-mips-outgoing; Sat, 28 Jul 2001 14:02:11 -0700 Received: from dea.waldorf-gmbh.de (u-135-20.karlsruhe.ipdial.viaginterkom.de [62.180.20.135]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6SL22V30853 for ; Sat, 28 Jul 2001 14:02:03 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6SL1WS18790; Sat, 28 Jul 2001 23:01:32 +0200 Date: Sat, 28 Jul 2001 23:01:32 +0200 From: Ralf Baechle To: Erich Schubert Cc: Debian MIPS list , SGI MIPS list Subject: Re: Sound on SGI Indy? Message-ID: <20010728230132.B13030@bacchus.dhis.org> References: <20010725235924.A2124@erich.xmldesign.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010725235924.A2124@erich.xmldesign.de>; from erich.schubert@mucl.de on Wed, Jul 25, 2001 at 11:59:24PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 507 Lines: 16 On Wed, Jul 25, 2001 at 11:59:24PM +0200, Erich Schubert wrote: > did anyone get sound to run on a Indy? > As far as i've read, alsa does contain drivers which should play sound > correctly. > > So i checked out current cvs kernel, compiled it, compiled alsa and > tried to load the modules - and got a kernel oops. You made sure you have latest binutils and modutils? > Can someone point me to some recent information about sound on sgi indy? Ulf said the ALSA driver is entirely out of date. Ralf From owner-linux-mips@oss.sgi.com Sat Jul 28 17:14:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6T0EFH29480 for linux-mips-outgoing; Sat, 28 Jul 2001 17:14:15 -0700 Received: from noose.gt.owl.de (postfix@noose.gt.owl.de [62.52.19.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6T0ECV29465 for ; Sat, 28 Jul 2001 17:14:13 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id D881A881; Sun, 29 Jul 2001 02:14:10 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id C6C9C4375; Sun, 29 Jul 2001 02:14:00 +0200 (CEST) Date: Sun, 29 Jul 2001 02:14:00 +0200 From: Florian Lohoff To: SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 Message-ID: <20010729021400.C6113@paradigm.rfc822.org> References: <20010728214114.C27316@lug-owl.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010728214114.C27316@lug-owl.de>; from jbglaw@lug-owl.de on Sat, Jul 28, 2001 at 09:41:14PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 805 Lines: 22 On Sat, Jul 28, 2001 at 09:41:14PM +0200, Jan-Benedict Glaw wrote: > However, the chip actually does not transmit the frame. Please look > at it because I don't have a clue about the lance chip. Especially, > I see there problems: > - lp->tx_buf_ptr_lnc[i] and lp->rx_buf_ptr_lnc[i] are > quite low addresses. Is this correct? Are they relative > to some other address (TC slot address?) If its a TC base address all addresses must be below 128*1024 as a TC Slot IIRC has a 128K Window. > - while kernel's bootp tries to send the packet, only > buffers [0] to [5] are used. Why are not all 16 buffers > used? Split between TX and RX ? Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 Why is it called "common sense" when nobody seems to have any? From owner-linux-mips@oss.sgi.com Sun Jul 29 01:34:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6T8YkW10679 for linux-mips-outgoing; Sun, 29 Jul 2001 01:34:46 -0700 Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6T8YiV10674 for ; Sun, 29 Jul 2001 01:34:44 -0700 Received: from scotty.mgnet.de (pD90247AA.dip.t-dialin.net [217.2.71.170]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id KAA00479 for ; Sun, 29 Jul 2001 10:34:42 +0200 (MET DST) Received: (qmail 19169 invoked from network); 29 Jul 2001 08:34:41 -0000 Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP; 29 Jul 2001 08:34:41 -0000 Date: Sun, 29 Jul 2001 10:34:41 +0200 (CEST) From: Klaus Naumann To: Ralf Baechle cc: Erich Schubert , Debian MIPS list , SGI MIPS list Subject: Re: Sound on SGI Indy? In-Reply-To: <20010728230132.B13030@bacchus.dhis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1321 Lines: 36 On Sat, 28 Jul 2001, Ralf Baechle wrote: > On Wed, Jul 25, 2001 at 11:59:24PM +0200, Erich Schubert wrote: > > > did anyone get sound to run on a Indy? > > As far as i've read, alsa does contain drivers which should play sound > > correctly. > > > > So i checked out current cvs kernel, compiled it, compiled alsa and > > tried to load the modules - and got a kernel oops. > > You made sure you have latest binutils and modutils? Don't waste the time ... current cvs will _never_ support the old alsa modules. I'm working on getting the ALSA stuff to work, but it's not too easy and currently the Power Supply Fan of my workstation is broken so I need to get a new one first and then we'll see ... Also one of the problems is finding a working current cvs kernel ;) > > Can someone point me to some recent information about sound on sgi indy? > Ulf said the ALSA driver is entirely out of date. I think I once got it to work a bit under 2.2.10 or something like that. Everything newer, like 2.4 is a big no no. Hmmm, my Power Supply smells again ... cu later guys Bye, Klaus -- Full Name : Klaus Naumann | (http://www.mgnet.de/) (Germany) Nickname : Spock | Org.: Mad Guys Network Phone / FAX : ++49/177/7862964 | E-Mail: (spock@mgnet.de) PGP Key : www.mgnet.de/keys/key_spock.txt From owner-linux-mips@oss.sgi.com Sun Jul 29 06:17:07 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6TDH7821844 for linux-mips-outgoing; Sun, 29 Jul 2001 06:17:07 -0700 Received: from holly.csn.ul.ie (holly.csn.ul.ie [136.201.105.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6TDH3V21825 for ; Sun, 29 Jul 2001 06:17:03 -0700 Received: from skynet.csn.ul.ie (skynet [136.201.105.2]) by holly.csn.ul.ie (Postfix) with ESMTP id A00462B303; Sun, 29 Jul 2001 14:16:56 +0100 (IST) Received: by skynet.csn.ul.ie (Postfix, from userid 2139) id 07886A8A5; Sun, 29 Jul 2001 14:16:37 +0100 (IST) Received: from localhost (localhost [127.0.0.1]) by skynet.csn.ul.ie (Postfix) with ESMTP id EA587A8A4; Sun, 29 Jul 2001 14:16:37 +0100 (IST) Date: Sun, 29 Jul 2001 14:16:37 +0100 (IST) From: Dave Airlie X-X-Sender: To: Jan-Benedict Glaw Cc: SGI MIPS list , Debian MIPS list , Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010728214114.C27316@lug-owl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 6535 Lines: 188 You really should read around before hacking :-) http://www.skynet.ie/~airlied/mips/declance_2_3_48.c is the declance driver for the DS5000/200, I'm not sure it still works but it did the last time I looked at it .. the declance.c in the same dir is for 2.2 kernel.. I must rename them someday.. Dave. On Sat, 28 Jul 2001, Jan-Benedict Glaw wrote: > Hi! > > I'm tryin' to get a DS5000/200 to work. Currently, I see that declance.c > wasn't complete wrt. this system. Problem: ring buffer pointers not > initialized, Oops. I've copied that part from {PMAX_LANCE,ASIC_LANCE}, > but that seems not to be enough. So now, the kernel loops infinitive > when trying to send a bootp packet. > > Here's what I did: > > static int __init dec_lance_init(struct net_device *dev, const int type) > { > [...] > switch (type) { > [...] > case PMAD_LANCE: > slot = search_tc_card("PMAD-AA"); > claim_tc_card(slot); > > dev->mem_start = get_tc_base_addr(slot); > dev->base_addr = dev->mem_start + 0x100000; > dev->irq = get_tc_irq_nr(slot); > esar_base = dev->mem_start + 0x1c0002; > /* > * setup the pointer arrays, this sucks [tm] :-( > */ > for (i = 0; i < RX_RING_SIZE; i++) { > lp->rx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU > + 2 * i * RX_BUFF_SIZE); > printk("lp->rx_buf_ptr_cpu[%d]=%p\n", > i, lp->rx_buf_ptr_cpu[i] > ); > lp->rx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC > + i * RX_BUFF_SIZE); > printk("lp->rx_buf_ptr_lnc[%d]=%p\n", > i, lp->rx_buf_ptr_lnc[i] > ); > } > for (i = 0; i < TX_RING_SIZE; i++) { > lp->tx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU > + 2 * RX_RING_SIZE * RX_BUFF_SIZE > + 2 * i * TX_BUFF_SIZE); > printk("lp->tx_buf_ptr_cpu[%d]=%p\n", > i, lp->tx_buf_ptr_cpu[i] > ); > lp->tx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC > + RX_RING_SIZE * RX_BUFF_SIZE > + i * TX_BUFF_SIZE); > printk("lp->tx_buf_ptr_lnc[%d]=%p\n", > i, lp->tx_buf_ptr_lnc[i] > ); > } > > break; > [...] > } > > However, the chip actually does not transmit the frame. Please look > at it because I don't have a clue about the lance chip. Especially, > I see there problems: > - lp->tx_buf_ptr_lnc[i] and lp->rx_buf_ptr_lnc[i] are > quite low addresses. Is this correct? Are they relative > to some other address (TC slot address?) > - while kernel's bootp tries to send the packet, only > buffers [0] to [5] are used. Why are not all 16 buffers > used? > > It would be *very* nice if the people who originally wrote this > driver could help me... > > Here's the serial console's output: > > >>boot 6/tftp console=ttyS3 root=/dev/nfs ip=bootp rw > 1630208+139264+146848 > This DECstation is a DS5000/200 > Loading R[23]000 MMU routines. > [...] > TURBOchannel rev. 1 at 25.0 MHz (without parity) > slot 5: DEC PMAZ-AA V5.3b > slot 6: DEC PMAD-AA V5.3a > [...] > declance.c: v0.008 by Linux Mips DECstation task force > lp->rx_buf_ptr_cpu[0]=bf800240 > lp->rx_buf_ptr_lnc[0]=00000120 > lp->rx_buf_ptr_cpu[1]=bf800e40 > lp->rx_buf_ptr_lnc[1]=00000720 > lp->rx_buf_ptr_cpu[2]=bf801a40 > lp->rx_buf_ptr_lnc[2]=00000d20 > lp->rx_buf_ptr_cpu[3]=bf802640 > lp->rx_buf_ptr_lnc[3]=00001320 > lp->rx_buf_ptr_cpu[4]=bf803240 > lp->rx_buf_ptr_lnc[4]=00001920 > lp->rx_buf_ptr_cpu[5]=bf803e40 > lp->rx_buf_ptr_lnc[5]=00001f20 > lp->rx_buf_ptr_cpu[6]=bf804a40 > lp->rx_buf_ptr_lnc[6]=00002520 > lp->rx_buf_ptr_cpu[7]=bf805640 > lp->rx_buf_ptr_lnc[7]=00002b20 > lp->rx_buf_ptr_cpu[8]=bf806240 > lp->rx_buf_ptr_lnc[8]=00003120 > lp->rx_buf_ptr_cpu[9]=bf806e40 > lp->rx_buf_ptr_lnc[9]=00003720 > lp->rx_buf_ptr_cpu[10]=bf807a40 > lp->rx_buf_ptr_lnc[10]=00003d20 > lp->rx_buf_ptr_cpu[11]=bf808640 > lp->rx_buf_ptr_lnc[11]=00004320 > lp->rx_buf_ptr_cpu[12]=bf809240 > lp->rx_buf_ptr_lnc[12]=00004920 > lp->rx_buf_ptr_cpu[13]=bf809e40 > lp->rx_buf_ptr_lnc[13]=00004f20 > lp->rx_buf_ptr_cpu[14]=bf80aa40 > lp->rx_buf_ptr_lnc[14]=00005520 > lp->rx_buf_ptr_cpu[15]=bf80b640 > lp->rx_buf_ptr_lnc[15]=00005b20 > lp->tx_buf_ptr_cpu[0]=bf80c240 > lp->tx_buf_ptr_lnc[0]=00006120 > lp->tx_buf_ptr_cpu[1]=bf80ce40 > lp->tx_buf_ptr_lnc[1]=00006720 > lp->tx_buf_ptr_cpu[2]=bf80da40 > lp->tx_buf_ptr_lnc[2]=00006d20 > lp->tx_buf_ptr_cpu[3]=bf80e640 > lp->tx_buf_ptr_lnc[3]=00007320 > lp->tx_buf_ptr_cpu[4]=bf80f240 > lp->tx_buf_ptr_lnc[4]=00007920 > lp->tx_buf_ptr_cpu[5]=bf80fe40 > lp->tx_buf_ptr_lnc[5]=00007f20 > lp->tx_buf_ptr_cpu[6]=bf810a40 > lp->tx_buf_ptr_lnc[6]=00008520 > lp->tx_buf_ptr_cpu[7]=bf811640 > lp->tx_buf_ptr_lnc[7]=00008b20 > lp->tx_buf_ptr_cpu[8]=bf812240 > lp->tx_buf_ptr_lnc[8]=00009120 > lp->tx_buf_ptr_cpu[9]=bf812e40 > lp->tx_buf_ptr_lnc[9]=00009720 > lp->tx_buf_ptr_cpu[10]=bf813a40 > lp->tx_buf_ptr_lnc[10]=00009d20 > lp->tx_buf_ptr_cpu[11]=bf814640 > lp->tx_buf_ptr_lnc[11]=0000a320 > lp->tx_buf_ptr_cpu[12]=bf815240 > lp->tx_buf_ptr_lnc[12]=0000a920 > lp->tx_buf_ptr_cpu[13]=bf815e40 > lp->tx_buf_ptr_lnc[13]=0000af20 > lp->tx_buf_ptr_cpu[14]=bf816a40 > lp->tx_buf_ptr_lnc[14]=0000b520 > lp->tx_buf_ptr_cpu[15]=bf817640 > lp->tx_buf_ptr_lnc[15]=0000bb20 > eth0: PMAD-AA, addr = 08:00:2b:1c:44:ee, irq = 3 > [...] > Sending BOOTP requests .lance_start_xmit:882: entry=0 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=1 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[1]=bf80ce40, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=2 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[2]=bf80da40, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=3 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[3]=bf80e640, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=4 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[4]=bf80f240, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=5 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[5]=bf80fe40, skb->data=8022c402, skblen=590) > timed out! > IP-Config: Retrying forever (NFS root)... > Sending BOOTP requests .lance_start_xmit:882: entry=0 > lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590) > .lance_start_xmit:882: entry=1 > [...] > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied@skynet.ie pam_smb / Linux DecStation / Linux VAX / ILUG person From owner-linux-mips@oss.sgi.com Sun Jul 29 08:52:23 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6TFqNm01496 for linux-mips-outgoing; Sun, 29 Jul 2001 08:52:23 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6TFqBV01478 for ; Sun, 29 Jul 2001 08:52:11 -0700 Received: from lucon.org (lake.in.lucon.org [192.168.0.2]) by ocean.lucon.org (Postfix) with ESMTP id CEC08125C0; Sun, 29 Jul 2001 08:52:06 -0700 (PDT) Received: by lucon.org (Postfix, from userid 1000) id 42270EFBD; Sun, 29 Jul 2001 08:51:55 -0700 (PDT) Date: Sun, 29 Jul 2001 08:51:55 -0700 From: "H . J . Lu" To: linux-gcc@vger.kernel.org, gcc@gcc.gnu.org, GNU C Library , Kenneth Albanowski , Mat Hostetter , Andy Dougherty , Warner Losh , linux-mips@oss.sgi.com, Ron Guilmette , "Polstra; John" , "Hazelwood; Galen" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" Subject: The Linux binutils 2.11.90.0.25 is released. Message-ID: <20010729085155.A8610@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 13119 Lines: 469 This is the beta release of binutils 2.11.90.0.25 for Linux, which is based on binutils 2001 0726 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux. The Linux/mips support is added. You have to use # rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz to build it. Or you can read mips/README in the source tree to apply the mips patches and build it by hand. FYI, the binutils man pages now are generated from the texinfo files during the build. As the result, those man pages may be changed for each build even if you only have done # ..../configure ... # make That means you may have many failures on the man pages when you apply the binutils diffs next time. Those failures can be safely ignored. You should remove all those man pages from your source tree by # find -name *.1 | xargs rm -f # find -name *.1.rej | xargs rm -f # find -name *.man | xargs rm -f # find -name *.man.rej | xargs rm -f I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.11.90.0.25 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.11.90.0.24: 1. Update from binutils 2001 0726. 2. Fix an x86 assembler bug. 3. "make check" in the windres test in binutils may call uudecode. We are working on it. 4. "make check" fails the windres test in binutils if the i386/pe is enabled in bfd. Fixed in the next release. 5. "make check" has 2 failures in the ld-selective test in ld on Linux/alpha. They should be marked xfail. Fixed in the next release. Changes from binutils 2.11.90.0.23: 1. Update from binutils 2001 0714. 2. Fix Sparc/ElF for Linux/sparc. 3. Fix Alpha/ELF for gcc 3.0. Changes from binutils 2.11.90.0.19: 1. Update from binutils 2001 0706. 2. Fix objcopy/strip broken by accident. 3. Avoid COPY relocs on ia32. 4. Fix the ia64 assembler. 5. This release may not work on Linux/sparc due to the unaligned relocation changes, which are not handled by all versions of glibc. The current glibc in CVS on sourceware should be ok. The last known working binutils for Linux/sparc is 2.11.90.0.8. We are working on it. Changes from binutils 2.11.90.0.15: 1. Update from binutils 2001 0620. 2. Fix a static linking the PIC object files on ia32. 3. Add the verion script support for --export-dynamic. It can be used to selectively export dynamic symbols from the executables. Changes from binutils 2.11.90.0.8: 1. Update from binutils 2001 0610. 2. Fix a gas bug for gcc 3.0. Changes from binutils 2.11.90.0.7: 1. Update from binutils 2001 0512. 2. Fix some P/III SSE 2 assembler bugs. 3. Fix DT_NEEDED and symbol version bugs. 4. Support hidden versioned symbols in DSOs. Changes from binutils 2.11.90.0.6: 1. Update from binutils 2001 0427. 2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5. Changes from binutils 2.11.90.0.5: 1. Update from binutils 2001 0425. 2. Update "ld --multilib-dir PATH". Changes from binutils 2.11.90.0.4: 1. Update from binutils 2001 0414. 2. Fix an ia64 assembler bug. 3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI. since there are no supports for the IRIX ABI in glibc. The current Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified for this change. Changes from binutils 2.11.90.0.1: 1. Update from binutils 2001 0401. 2. Fix a gas bug for the gcc from the CVS main trunk. It involves some changes in gas. I compiled kernel 2.2.18, gcc and glibc under Linux/ia32. The resulting binaries work fine. 3. Fix the linker core dump on unsupported ELF binaries. Changes from binutils 2.10.91.0.4: 1. Update from binutils 2001 0309. Changes from binutils 2.10.91.0.2: 1. Update from binutils 2001 0223. 2. More ia64 bug fixes. Changes from binutils 2.10.1.0.7: 1. Update from binutils 2001 0215. 2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64. 3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32. Changes from binutils 2.10.1.0.4: 1. Update from binutils 2001 0206. 2. Enable the IA64 support. 3. Now you need to use # ld --oformat TARGET instead of # ld -oformat TARGET The Linux kernel build may be affected. BTW # ld --oformat TARGET should work with all previous releases of binutils. Changes from binutils 2.10.1.0.2: 1. Update from binutils 2000 1221. Changes from binutils 2.10.0.33: 1. Update from binutils 2000 1119. 2. It has some symbol versioning related updates. Changes from binutils 2.10.0.32: 1. Update from binutils 2000 1018. 2. A proper ELF/PPC visibility fix. 3. m68k-a.out is supposed to be fixed. Changes from binutils 2.10.0.31: 1. Update from binutils 2000 1014. 2. An ELF/PPC weak symbol bug fix. 3. A new linkonce section name approach. 4. m68k-a.out is still broken. To be fixed. Changes from binutils 2.10.0.29: 1. Update from binutils 2000 1011. 2. Back out the linkonce section name change so that C++ will work. A different approach is being worked on. 3. m68k-a.out is known to be broken. To be fixed. Changes from binutils 2.10.0.26: 1. Update from binutils 2000 1008. Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.11.90.0.25.tar.gz. Source code. 2. binutils-2.11.90.0.24-2.11.90.0.25.diff.gz. Patch against the previous beta source code. 3. binutils-2.11.90.0.25-1.i386.rpm. IA-32 binary RPM for RedHat 7.1. There is no separate source rpm. You can do # rpm -ta binutils-2.11.90.0.25.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.kernel.org/pub/linux/devel/binutils/ Thanks. H.J. Lu hjl@lucon.org 07/29/2001 From owner-linux-mips@oss.sgi.com Mon Jul 30 00:17:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6U7H9l29199 for linux-mips-outgoing; Mon, 30 Jul 2001 00:17:09 -0700 Received: from smtp.huawei.com (sz135.szptt.net.cn [202.96.135.132] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6U7GvV29191 for ; Mon, 30 Jul 2001 00:17:04 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GH9YLH02.D2L for ; Mon, 30 Jul 2001 15:10:29 +0800 Message-ID: <000901c118c7$b9bcc800$8021690a@huawei.com> From: "machael thailer" To: References: <20010728000354.84537.qmail@web13908.mail.yahoo.com> Subject: Embed linux-mips problems... Date: Mon, 30 Jul 2001 15:17:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 927 Lines: 27 Hello, all: Now I will plan to port linux on our custom mips-based board. Since this will be the first time I use linux on mips CPU and I am a newbie for mips RC32334, I have several questions to ask: 1 What's the current stable linux kernel version for mips that you are using?Especially, which version can support IDT mips RC32334 CPU now? If linux can not support RC32334 for the time being,which familys of Mips should I take as example and what modifications should I do? 2 What IDE tools for Mips are you using to debug linux kernel and APPs ? 3 Are there any sample boot codes which can be burnt into BOOTROM and which will initialize the mip-based boards when power-on and then load the linux-kernel to RAM via network or flash? 4 Is it possible to use RTLinux for mips now? If so, which rtlinux version should I take? Any suggestions will be highly appreciated. Thank you very much. machael thailer From owner-linux-mips@oss.sgi.com Mon Jul 30 06:45:35 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UDjZJ04195 for linux-mips-outgoing; Mon, 30 Jul 2001 06:45:35 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UDjXV04192 for ; Mon, 30 Jul 2001 06:45:33 -0700 Message-Id: <200107301345.f6UDjXV04192@oss.sgi.com> Received: (qmail 22784 invoked from network); 30 Jul 2001 13:40:39 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 30 Jul 2001 13:40:39 -0000 Date: Mon, 30 Jul 2001 21:48:20 +0800 From: Fuxin Zhang To: "linux-mips@oss.sgi.com" Subject: X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1134 Lines: 35 hello,linux-mips I am porting support of Algorithmics P6032 evalution board from 2.2 kernel to 2.4. I started with the kernel 2.4.3 from hardhat2.0 distribution.Now I am able to boot the kernel but it hangs up when trying to exec /sbin/init.The error message is something like: Init: Kernel panic: trying to kill init Init:error loading libc.so.6, undefined symbol _sec0 But if i let the kernel execute /bin/ash.static directly,it can give me a shell while complaining something like" no tty found,job control disabled". Then I can use most commands such as ls,passwd,cat.So the libc.so.6 can't be a corrupted one. The test environment is: Algorithmics P6032 with a idt79RC64474 CPU IDE hard disk(IBM Deskstar 40M,7200rpm) Kernel options: pci,ide(with/without dma,multimode) enabled serial console enabled What can be the cause? I suspect the ide driver first.But disabling dma doesn't help and it seems to work quite well under ash. I am investigating the cause,if you want,I can provide more information. Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Jul 30 07:13:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UEDQq05171 for linux-mips-outgoing; Mon, 30 Jul 2001 07:13:26 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UEDPV05167 for ; Mon, 30 Jul 2001 07:13:25 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA10027; Mon, 30 Jul 2001 07:13:17 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA00182; Mon, 30 Jul 2001 07:13:09 -0700 (PDT) Message-ID: <075901c11902$6a27b260$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Fuxin Zhang" , References: <200107301345.f6UDjXV04192@oss.sgi.com> Subject: Re:/sbin/init problem in HH2.0 distro Date: Mon, 30 Jul 2001 16:17:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1475 Lines: 49 Well, if you can run "passwd", can you run "nm" or some other utility to see if libc.so.6 does in fact define the symbol _sec0? Kevin K. ----- Original Message ----- From: "Fuxin Zhang" To: Sent: Monday, July 30, 2001 3:48 PM > hello,linux-mips > I am porting support of Algorithmics P6032 evalution board from > 2.2 kernel to 2.4. I started with the kernel 2.4.3 from hardhat2.0 > distribution.Now I am able to boot the kernel but it hangs up when > trying to exec /sbin/init.The error message is something like: > Init: Kernel panic: trying to kill init > Init:error loading libc.so.6, undefined symbol _sec0 > > But if i let the kernel execute /bin/ash.static directly,it can give me > a shell while complaining something like" no tty found,job control disabled". Then I can use most commands such as ls,passwd,cat.So the > libc.so.6 can't be a corrupted one. > > The test environment is: > Algorithmics P6032 with a idt79RC64474 CPU > IDE hard disk(IBM Deskstar 40M,7200rpm) > Kernel options: > pci,ide(with/without dma,multimode) enabled > serial console enabled > > What can be the cause? > > I suspect the ide driver first.But disabling dma doesn't help and it > seems to work quite well under ash. > > I am investigating the cause,if you want,I can provide more > information. > > > > > > Regards > Fuxin Zhang > fxzhang@ict.ac.cn > From owner-linux-mips@oss.sgi.com Mon Jul 30 07:34:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UEYQ905870 for linux-mips-outgoing; Mon, 30 Jul 2001 07:34:26 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UEYOV05867 for ; Mon, 30 Jul 2001 07:34:24 -0700 Message-Id: <200107301434.f6UEYOV05867@oss.sgi.com> Received: (qmail 25215 invoked from network); 30 Jul 2001 14:29:31 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 30 Jul 2001 14:29:31 -0000 Date: Mon, 30 Jul 2001 22:37:14 +0800 From: Fuxin Zhang To: "Kevin D. Kissell" CC: "linux-mips@oss.sgi.com" Subject: Re: Re:/sbin/init problem in HH2.0 distro X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6UEYOV05868 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1696 Lines: 57 hello,Kevin 2001-07-30 16:17:00£º >Well, if you can run "passwd", can you run "nm" >or some other utility to see if libc.so.6 does >in fact define the symbol _sec0? Yes,I can. And there is no such symbol,so I suspect the disk drive first > > Kevin K. > >----- Original Message ----- >From: "Fuxin Zhang" >To: >Sent: Monday, July 30, 2001 3:48 PM > > >> hello,linux-mips >> I am porting support of Algorithmics P6032 evalution board from >> 2.2 kernel to 2.4. I started with the kernel 2.4.3 from hardhat2.0 >> distribution.Now I am able to boot the kernel but it hangs up when >> trying to exec /sbin/init.The error message is something like: >> Init: Kernel panic: trying to kill init >> Init:error loading libc.so.6, undefined symbol _sec0 >> >> But if i let the kernel execute /bin/ash.static directly,it can give me >> a shell while complaining something like" no tty found,job control >disabled". Then I can use most commands such as ls,passwd,cat.So the >> libc.so.6 can't be a corrupted one. >> >> The test environment is: >> Algorithmics P6032 with a idt79RC64474 CPU >> IDE hard disk(IBM Deskstar 40M,7200rpm) >> Kernel options: >> pci,ide(with/without dma,multimode) enabled >> serial console enabled >> >> What can be the cause? >> >> I suspect the ide driver first.But disabling dma doesn't help and it >> seems to work quite well under ash. >> >> I am investigating the cause,if you want,I can provide more >> information. >> >> >> >> >> >> Regards >> Fuxin Zhang >> fxzhang@ict.ac.cn >> Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Jul 30 07:56:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UEusR06290 for linux-mips-outgoing; Mon, 30 Jul 2001 07:56:54 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UEuqV06287 for ; Mon, 30 Jul 2001 07:56:52 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA10320; Mon, 30 Jul 2001 07:56:45 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id HAA00563; Mon, 30 Jul 2001 07:56:39 -0700 (PDT) Message-ID: <076101c11908$7d0e3380$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Fuxin Zhang" Cc: References: <200107301434.f6UEYOV05867@oss.sgi.com> Subject: Re: Re:/sbin/init problem in HH2.0 distro Date: Mon, 30 Jul 2001 17:01:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIME-Autoconverted: from 8bit to quoted-printable by mx.mips.com id HAA10320 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6UEuqV06288 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2355 Lines: 69 > 2001-07-30 16:17:00£º > >Well, if you can run "passwd", can you run "nm" > >or some other utility to see if libc.so.6 does > >in fact define the symbol _sec0? > > Yes,I can. And there is no such symbol,so I suspect the disk drive first It's always possible that there's something wrong with your disk or your driver, but the fact that you're able to run other commands fairly reliably makes me suspect that your problem is elsewhere. Since nm works, you should likewise be able to verify that there's a reference to _sec0 in the image of /sbin/init. If there isn't, something subtle and nasty is wrong. If there is, maybe you've simply got an /sbin/init image that was built against a different version of libc.so.6 than the one on your disk. I'm actually a little suprised that /sbin/init isn't static. Kevin K. > >----- Original Message ----- > >From: "Fuxin Zhang" > >To: > >Sent: Monday, July 30, 2001 3:48 PM > > > > > >> hello,linux-mips > >> I am porting support of Algorithmics P6032 evalution board from > >> 2.2 kernel to 2.4. I started with the kernel 2.4.3 from hardhat2.0 > >> distribution.Now I am able to boot the kernel but it hangs up when > >> trying to exec /sbin/init.The error message is something like: > >> Init: Kernel panic: trying to kill init > >> Init:error loading libc.so.6, undefined symbol _sec0 > >> > >> But if i let the kernel execute /bin/ash.static directly,it can give me > >> a shell while complaining something like" no tty found,job control > >disabled". Then I can use most commands such as ls,passwd,cat.So the > >> libc.so.6 can't be a corrupted one. > >> > >> The test environment is: > >> Algorithmics P6032 with a idt79RC64474 CPU > >> IDE hard disk(IBM Deskstar 40M,7200rpm) > >> Kernel options: > >> pci,ide(with/without dma,multimode) enabled > >> serial console enabled > >> > >> What can be the cause? > >> > >> I suspect the ide driver first.But disabling dma doesn't help and it > >> seems to work quite well under ash. > >> > >> I am investigating the cause,if you want,I can provide more > >> information. > >> > >> > >> > >> > >> > >> Regards > >> Fuxin Zhang > >> fxzhang@ict.ac.cn > >> > > Regards > Fuxin Zhang > fxzhang@ict.ac.cn > From owner-linux-mips@oss.sgi.com Mon Jul 30 08:53:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UFrtt07252 for linux-mips-outgoing; Mon, 30 Jul 2001 08:53:55 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UFrqV07249 for ; Mon, 30 Jul 2001 08:53:53 -0700 Message-Id: <200107301553.f6UFrqV07249@oss.sgi.com> Received: (qmail 28576 invoked from network); 30 Jul 2001 15:49:00 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 30 Jul 2001 15:49:00 -0000 Date: Mon, 30 Jul 2001 23:56:42 +0800 From: Fuxin Zhang To: "linux-mips@oss.sgi.com" Subject: Re: Re: Re:/sbin/init problem in HH2.0 distro X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6UFrrV07250 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2643 Lines: 82 hello,Kevin I have found out the cause: the P6032 on board cache make all these subtle errors! Thank you for your attention. 2001-07-30 17:01:00£º >> 2001-07-30 16:17:00£º >> >Well, if you can run "passwd", can you run "nm" >> >or some other utility to see if libc.so.6 does >> >in fact define the symbol _sec0? >> >> Yes,I can. And there is no such symbol,so I suspect the disk drive first > >It's always possible that there's something wrong with >your disk or your driver, but the fact that you're able >to run other commands fairly reliably makes me suspect >that your problem is elsewhere. Since nm works, you >should likewise be able to verify that there's a reference >to _sec0 in the image of /sbin/init. If there isn't, >something subtle and nasty is wrong. If there is, maybe >you've simply got an /sbin/init image that was built against >a different version of libc.so.6 than the one on your disk. >I'm actually a little suprised that /sbin/init isn't static. > > Kevin K. > > >> >----- Original Message ----- >> >From: "Fuxin Zhang" >> >To: >> >Sent: Monday, July 30, 2001 3:48 PM >> > >> > >> >> hello,linux-mips >> >> I am porting support of Algorithmics P6032 evalution board from >> >> 2.2 kernel to 2.4. I started with the kernel 2.4.3 from hardhat2.0 >> >> distribution.Now I am able to boot the kernel but it hangs up when >> >> trying to exec /sbin/init.The error message is something like: >> >> Init: Kernel panic: trying to kill init >> >> Init:error loading libc.so.6, undefined symbol _sec0 >> >> >> >> But if i let the kernel execute /bin/ash.static directly,it can give me >> >> a shell while complaining something like" no tty found,job control >> >disabled". Then I can use most commands such as ls,passwd,cat.So the >> >> libc.so.6 can't be a corrupted one. >> >> >> >> The test environment is: >> >> Algorithmics P6032 with a idt79RC64474 CPU >> >> IDE hard disk(IBM Deskstar 40M,7200rpm) >> >> Kernel options: >> >> pci,ide(with/without dma,multimode) enabled >> >> serial console enabled >> >> >> >> What can be the cause? >> >> >> >> I suspect the ide driver first.But disabling dma doesn't help and it >> >> seems to work quite well under ash. >> >> >> >> I am investigating the cause,if you want,I can provide more >> >> information. >> >> >> >> >> >> >> >> >> >> >> >> Regards >> >> Fuxin Zhang >> >> fxzhang@ict.ac.cn >> >> >> >> Regards >> Fuxin Zhang >> fxzhang@ict.ac.cn >> Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Mon Jul 30 11:44:24 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UIiOR09852 for linux-mips-outgoing; Mon, 30 Jul 2001 11:44:24 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UIiJV09847 for ; Mon, 30 Jul 2001 11:44:20 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA18909; Mon, 30 Jul 2001 20:46:08 +0200 (MET DST) Date: Mon, 30 Jul 2001 20:46:07 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle , Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c In-Reply-To: <20010724080411.G14821@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1779 Lines: 48 On Tue, 24 Jul 2001, Thiemo Seufer wrote: > somebody made wrong assumptions about how compute_return_epc() works. It was me, I admit... Thanks for pointing it out. > I've speculated below how the right solution might look, but I > don't know enough about signal handling to be sure. I think the following fix is sufficient -- let's just pass EPC and let the userland handle it. You don't normally want a "break" in a branch delay slot -- such a sequence is of questionable utility. But if it is to be handled, the KISS approach gives the userland a chance to handle an exception gracefully. One may want to emulate overflows somehow, for example. Also the code is shorter. Ralf, please apply it. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.5-20010730-break-1 diff -up --recursive --new-file linux.macro/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c --- linux.macro/arch/mips/kernel/traps.c Tue Jul 24 04:26:34 2001 +++ linux/arch/mips/kernel/traps.c Mon Jul 30 18:26:03 2001 @@ -378,7 +378,7 @@ asmlinkage void do_bp(struct pt_regs *re info.si_code = FPE_INTOVF; info.si_signo = SIGFPE; info.si_errno = 0; - info.si_addr = (void *)compute_return_epc(regs); + info.si_addr = (void *)regs->cp0_epc; force_sig_info(SIGFPE, &info, current); break; default: @@ -418,7 +418,7 @@ asmlinkage void do_tr(struct pt_regs *re info.si_code = FPE_INTOVF; info.si_signo = SIGFPE; info.si_errno = 0; - info.si_addr = (void *)compute_return_epc(regs); + info.si_addr = (void *)regs->cp0_epc; force_sig_info(SIGFPE, &info, current); break; default: From owner-linux-mips@oss.sgi.com Mon Jul 30 13:02:50 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UK2oe11267 for linux-mips-outgoing; Mon, 30 Jul 2001 13:02:50 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UK2mV11264 for ; Mon, 30 Jul 2001 13:02:48 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA20045; Mon, 30 Jul 2001 22:05:00 +0200 (MET DST) Date: Mon, 30 Jul 2001 22:04:59 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Florian Lohoff cc: SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010729021400.C6113@paradigm.rfc822.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 549 Lines: 14 On Sun, 29 Jul 2001, Florian Lohoff wrote: > If its a TC base address all addresses must be below 128*1024 as > a TC Slot IIRC has a 128K Window. Nope, it's system-dependent, with 1MB being the minimum specified (and 4MB being the real minimum implemented, IIRC). There actually exist TC boards that make use of more than 1MB of address space. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 13:04:28 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UK4Sn11353 for linux-mips-outgoing; Mon, 30 Jul 2001 13:04:28 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UK4QV11347 for ; Mon, 30 Jul 2001 13:04:26 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA20090; Mon, 30 Jul 2001 22:06:45 +0200 (MET DST) Date: Mon, 30 Jul 2001 22:06:45 +0200 (MET DST) From: "Maciej W. Rozycki" To: Dave Airlie cc: Jan-Benedict Glaw , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 679 Lines: 18 On Sun, 29 Jul 2001, Dave Airlie wrote: > You really should read around before hacking :-) > > http://www.skynet.ie/~airlied/mips/declance_2_3_48.c > > is the declance driver for the DS5000/200, I'm not sure it still works but > it did the last time I looked at it .. the declance.c in the same dir is > for 2.2 kernel.. I must rename them someday.. How about merging it into official sources? This way your work won't get lost and others won't try to reinvent the wheel. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 13:09:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UK9tP11503 for linux-mips-outgoing; Mon, 30 Jul 2001 13:09:55 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UK9rV11500 for ; Mon, 30 Jul 2001 13:09:53 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA14209; Mon, 30 Jul 2001 13:09:44 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA10048; Mon, 30 Jul 2001 13:09:29 -0700 (PDT) Message-ID: <07dd01c11934$32334860$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Ralf Baechle" , "Thiemo Seufer" Cc: References: Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c Date: Mon, 30 Jul 2001 22:13:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3892 Lines: 95 Many years ago, I went to a lot of effort to see to it that FP exceptions on the Fairchild Clipper passed enough information up through SIGFPE to allow full userland emulation or fixup and replay-on-return of the operation on floating point faults (entertaining because there was a seperate FP PC). And of course no one ever used it! ;-) I missed the beginning of this thread, but it looks from the patch as if this is really about handling integer overflow exceptions, not FP exceptions. That's unfortunate. To begin with you are correct in that we should be passing the EPC value at the exception (and certainly not the result of invoking compute_return_epc(), much less its side effects!), and the state of the BD bit from the Cause register, either abstracted into a variable in the info structure or as a flat-out copy of the Cause register. I would recommend the former as being less of a security hole. Yes, we could blow that off and make the user decode for branches himself, but it's tacky. But what's more pernicious is the fact that, being an integer exception, it could have resulted from an overflow of any of the GPRs, including those that will be used by the low-level library code dispatching the signal to the user, and in the generated code of the user's own signal handler. If we actually want to allow the user to fix the operation and saturate (or whatever) the destination register, enough of the trap context needs to be passed up to the signal handler *and* back down on the signal return to allow that manipulation, followed by a resumption of execution at the instruction following the one that generated the trap. Been there, done that, got the coffee mug, Kevin K. ----- Original Message ----- From: "Maciej W. Rozycki" To: "Ralf Baechle" ; "Thiemo Seufer" Cc: Sent: Monday, July 30, 2001 8:46 PM Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c > On Tue, 24 Jul 2001, Thiemo Seufer wrote: > > > somebody made wrong assumptions about how compute_return_epc() works. > > It was me, I admit... Thanks for pointing it out. > > > I've speculated below how the right solution might look, but I > > don't know enough about signal handling to be sure. > > I think the following fix is sufficient -- let's just pass EPC and let > the userland handle it. You don't normally want a "break" in a branch > delay slot -- such a sequence is of questionable utility. But if it is to > be handled, the KISS approach gives the userland a chance to handle an > exception gracefully. One may want to emulate overflows somehow, for > example. Also the code is shorter. > > Ralf, please apply it. > > Maciej > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > patch-mips-2.4.5-20010730-break-1 > diff -up --recursive --new-file linux.macro/arch/mips/kernel/traps.c linux/arch/mips/kernel/traps.c > --- linux.macro/arch/mips/kernel/traps.c Tue Jul 24 04:26:34 2001 > +++ linux/arch/mips/kernel/traps.c Mon Jul 30 18:26:03 2001 > @@ -378,7 +378,7 @@ asmlinkage void do_bp(struct pt_regs *re > info.si_code = FPE_INTOVF; > info.si_signo = SIGFPE; > info.si_errno = 0; > - info.si_addr = (void *)compute_return_epc(regs); > + info.si_addr = (void *)regs->cp0_epc; > force_sig_info(SIGFPE, &info, current); > break; > default: > @@ -418,7 +418,7 @@ asmlinkage void do_tr(struct pt_regs *re > info.si_code = FPE_INTOVF; > info.si_signo = SIGFPE; > info.si_errno = 0; > - info.si_addr = (void *)compute_return_epc(regs); > + info.si_addr = (void *)regs->cp0_epc; > force_sig_info(SIGFPE, &info, current); > break; > default: > From owner-linux-mips@oss.sgi.com Mon Jul 30 13:39:00 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UKd0b12200 for linux-mips-outgoing; Mon, 30 Jul 2001 13:39:00 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UKcvV12197 for ; Mon, 30 Jul 2001 13:38:57 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA20442; Mon, 30 Jul 2001 22:41:05 +0200 (MET DST) Date: Mon, 30 Jul 2001 22:41:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Ralf Baechle , Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c In-Reply-To: <07dd01c11934$32334860$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2770 Lines: 57 On Mon, 30 Jul 2001, Kevin D. Kissell wrote: > Many years ago, I went to a lot of effort to see to it that > FP exceptions on the Fairchild Clipper passed enough > information up through SIGFPE to allow full userland > emulation or fixup and replay-on-return of the operation > on floating point faults (entertaining because there was > a seperate FP PC). And of course no one ever used it! ;-) That's why I took the KISS approach. Current code is cheap and satisfies the specs I use, i.e. glibc's info pages. If anyone needs anything more one is free to improve handlers. > I missed the beginning of this thread, but it looks from the > patch as if this is really about handling integer overflow > exceptions, not FP exceptions. That's unfortunate. The patch is about break and trap instruction handlers, indeed. > To begin with you are correct in that we should be > passing the EPC value at the exception (and certainly not > the result of invoking compute_return_epc(), much less > its side effects!), and the state of the BD bit from the > Cause register, either abstracted into a variable in the > info structure or as a flat-out copy of the Cause register. I don't think passing BD is needed here. Enough information is available. A SIGFPE due to a branch or a jump instruction is impossible. Unless you have a chip on fire, in which case problems with signal handlers are insignificant. > I would recommend the former as being less of a security > hole. Yes, we could blow that off and make the user > decode for branches himself, but it's tacky. But what's > more pernicious is the fact that, being an integer exception, > it could have resulted from an overflow of any of the GPRs, > including those that will be used by the low-level library > code dispatching the signal to the user, and in the generated > code of the user's own signal handler. If we actually want > to allow the user to fix the operation and saturate (or whatever) > the destination register, enough of the trap context needs > to be passed up to the signal handler *and* back down > on the signal return to allow that manipulation, followed > by a resumption of execution at the instruction following > the one that generated the trap. Let's just leave it as an excercise to one writing some emulation code. A general-purpose handler in the kernel or libc (which no one will probably use) is an overkill and by defining own strict coding rules (be it a calling convention, shadow registers or whatever) one can create software that suits one's specific needs. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 14:44:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6ULiPM13316 for linux-mips-outgoing; Mon, 30 Jul 2001 14:44:25 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6ULiOV13313 for ; Mon, 30 Jul 2001 14:44:24 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA15257; Mon, 30 Jul 2001 14:44:15 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA12486; Mon, 30 Jul 2001 14:44:09 -0700 (PDT) Message-ID: <07f601c11941$6ade3280$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: "Ralf Baechle" , "Thiemo Seufer" , References: Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c Date: Mon, 30 Jul 2001 23:48:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3878 Lines: 78 > That's why I took the KISS approach. Current code is cheap and satisfies > the specs I use, i.e. glibc's info pages. If anyone needs anything more > one is free to improve handlers. The handlers cannot spontaneously generate information known only to the kernel. > > I missed the beginning of this thread, but it looks from the > > patch as if this is really about handling integer overflow > > exceptions, not FP exceptions. That's unfortunate. > > The patch is about break and trap instruction handlers, indeed. > > > To begin with you are correct in that we should be > > passing the EPC value at the exception (and certainly not > > the result of invoking compute_return_epc(), much less > > its side effects!), and the state of the BD bit from the > > Cause register, either abstracted into a variable in the > > info structure or as a flat-out copy of the Cause register. > > I don't think passing BD is needed here. Enough information is > available. A SIGFPE due to a branch or a jump instruction is impossible. > Unless you have a chip on fire, in which case problems with signal > handlers are insignificant. > > > I would recommend the former as being less of a security > > hole. Yes, we could blow that off and make the user > > decode for branches himself, but it's tacky. But what's > > more pernicious is the fact that, being an integer exception, > > it could have resulted from an overflow of any of the GPRs, > > including those that will be used by the low-level library > > code dispatching the signal to the user, and in the generated > > code of the user's own signal handler. If we actually want > > to allow the user to fix the operation and saturate (or whatever) > > the destination register, enough of the trap context needs > > to be passed up to the signal handler *and* back down > > on the signal return to allow that manipulation, followed > > by a resumption of execution at the instruction following > > the one that generated the trap. > > Let's just leave it as an excercise to one writing some emulation code. An excercise much akin to squaring the circle. Think about it. Your program has overflowed on an operation on a0. The signal is sent, and your signal routine is called, trashing a0 with the first argument. For greater amusement, assume that the instruction was "add a0, a0, a1" (which is what could easily happen in a C function that begins by summing its first two arguments). I simply do not see how user level code can determine whether the overflow was postive or negative without knowlege of the inputs, and those inputs may well have existed only in the registers. And even assuming that one could deduce the correct value, how would you propose patching it back into the execution stream, particularly in the presence of delayed branches? > A general-purpose handler in the kernel or libc (which no one will > probably use) is an overkill and by defining own strict coding rules (be > it a calling convention, shadow registers or whatever) one can create > software that suits one's specific needs. Yeah. Right. Shadow registers will allow you to be certain that you haven't trashed your inputs. They won't help you resume execution with a corrected value in the destination register of the faulting instruction. I have no problem with declaring that signals cannot be used to handle overflow exceptions. I do have a problem with falsely pretending to support such handling. We can decide (for now) that the problem doesn't need to be solved. We can decide to call it a "TODO" for some time when we're old and grey. We can solve it now. I really don't care. But it's dishonest to say that the current code solves it, even to a first order of approximation. To trot out an overused Einstein quote, "Everything should be as simple as possible. But not simpler". Kevin K. From owner-linux-mips@oss.sgi.com Mon Jul 30 15:21:55 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMLtp13857 for linux-mips-outgoing; Mon, 30 Jul 2001 15:21:55 -0700 Received: from ocean.lucon.org (c1473286-a.stcla1.sfba.home.com [24.176.137.160]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMLsV13854 for ; Mon, 30 Jul 2001 15:21:54 -0700 Received: by ocean.lucon.org (Postfix, from userid 1000) id 02A63125C0; Mon, 30 Jul 2001 15:21:51 -0700 (PDT) Date: Mon, 30 Jul 2001 15:21:51 -0700 From: "H . J . Lu" To: linux-mips@oss.sgi.com Subject: Update for RedHat 7.1/mips Message-ID: <20010730152151.A27066@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 906 Lines: 29 FYI, I made many updates for RedHat 7.1/mips. I have added enough stuff so that you put tegother a functional Linux server with it. H.J. ---- My mini-port of RedHat 7.1 is at ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/ you should be able to put a small RedHat 7.1 on the mips/mipsel box and compile the rest of RedHat 7.1 yourselves. Here are something you should know: 1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a toolchain rpm. The binary rpms for the mips and mipsel cross compilers are included. You will need glibc 2.2.3-11 or above to use those rpms. The glibc x86 binary rpms under RPMS/i386 should be ok. 2. You have to find a way to put those rpms on your machine. I use network boot and NFS root to do it. 3. install.tar.bz2 has some scripts to prepare NFS root and install RedHat 7.1 on a hard drive. 4. baseline.tar.bz2 contains the cross build tree. Thanks. H.J. From owner-linux-mips@oss.sgi.com Mon Jul 30 15:24:26 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMOQd13967 for linux-mips-outgoing; Mon, 30 Jul 2001 15:24:26 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMONV13964 for ; Mon, 30 Jul 2001 15:24:24 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id D48E3C4FE; Tue, 31 Jul 2001 00:24:21 +0200 (CEST) Date: Tue, 31 Jul 2001 00:24:21 +0200 From: Jan-Benedict Glaw To: "Maciej W. Rozycki" Cc: Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 Message-ID: <20010731002421.A19713@lug-owl.de> Mail-Followup-To: "Maciej W. Rozycki" , Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.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 30, 2001 at 10:06:45PM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 2422 Lines: 58 On Mon, Jul 30, 2001 at 10:06:45PM +0200, Maciej W. Rozycki wrote: > On Sun, 29 Jul 2001, Dave Airlie wrote: > > You really should read around before hacking :-) > > > > http://www.skynet.ie/~airlied/mips/declance_2_3_48.c > > > > is the declance driver for the DS5000/200, I'm not sure it still works but > > it did the last time I looked at it .. the declance.c in the same dir is > > for 2.2 kernel.. I must rename them someday.. > > How about merging it into official sources? This way your work won't get > lost and others won't try to reinvent the wheel. Of course. I wouldn't even *try* to do sth other. In fact, I'm looking around for various specs of various implementations (as seen from the bus) of the LANCE chip to see if I could manage the job to unify them all together: Driver file | Mentioned Chip ----------------------------------------------+-------------------- ./drivers/net/declance.c ./xxx/declance.c # as for DS5k/200 ./drivers/net/bagetlance.c none mentioned ./drivers/net/sk_g16.c Am7990 ./drivers/net/ni65.c ni6510 aka Am7990 ./drivers/net/ewk3.c Am7990 ./drivers/net/sk_mca.c Am7990 ./drivers/net/sunlance.c NCR92c990 `-> Father of declance.c as I think ./drivers/net/sunhme.c none mentioned `-> *some* cards seem to be compatible?! ./drivers/net/a2065.c Am7990 ./drivers/net/ariadne.c Am79c960 ./drivers/net/atarilance.c none mentioned ./drivers/net/sunqu.c "looks like LANCE" ./drivers/net/atari_pamsnet.c none mentioned ./drivers/net/lance.c Am7990, Am79c970A ./drivers/net/pcnet32.c none mentioned ./drivers/net/sgiseeq.c Seeq8003 (different buffer layout for speed) ./drivers/net/am79c961a.c Am79c961A ./drivers/net/sun3lance.c none mentioned, but adopted from sunlance.c ./drivers/net/pcmcia/nmclan_cs.c Am79c90 ./drivers/net/ibmlana.c "start of LANCE" ./drivers/net/7990.c *** GENERIC ROUTINES!!! *** ./drivers/net/hplance.c Uses 7990.c! ./drivers/net/mvme147.c Uses 7990.c! I really *hate* to see so many different implementations. That counts to about 21..25 pieces of code, always written for the same thing. Well, I'll start off in merging in those two declance drivers. But this will come no earlier that in two weeks or so. I'll first do the serial keyboard with dz.c. MfG, JBG PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to *BSD :-) Who will ever attempt to clean up? From owner-linux-mips@oss.sgi.com Mon Jul 30 15:29:16 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMTGR14193 for linux-mips-outgoing; Mon, 30 Jul 2001 15:29:16 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMTDV14184 for ; Mon, 30 Jul 2001 15:29:13 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA22038; Tue, 31 Jul 2001 00:31:24 +0200 (MET DST) Date: Tue, 31 Jul 2001 00:31:24 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Ralf Baechle , Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: [PATCH] wrong use of compute_return_epc() in /mips/kernel/traps.c In-Reply-To: <07f601c11941$6ade3280$0deca8c0@Ulysses> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 3242 Lines: 69 On Mon, 30 Jul 2001, Kevin D. Kissell wrote: > > That's why I took the KISS approach. Current code is cheap and satisfies > > the specs I use, i.e. glibc's info pages. If anyone needs anything more > > one is free to improve handlers. > > The handlers cannot spontaneously generate information known > only to the kernel. I'm not sure what you mean here. Could you please elaborate? > An excercise much akin to squaring the circle. Think > about it. Your program has overflowed on an operation > on a0. The signal is sent, and your signal routine is called, > trashing a0 with the first argument. For greater amusement, > assume that the instruction was "add a0, a0, a1" (which > is what could easily happen in a C function that begins > by summing its first two arguments). I simply do not see > how user level code can determine whether the overflow > was postive or negative without knowlege of the inputs, > and those inputs may well have existed only in the registers. > And even assuming that one could deduce the correct value, > how would you propose patching it back into the execution > stream, particularly in the presence of delayed branches? Sure, you are writing of the general case. That's not solvable given current interfaces. > Yeah. Right. Shadow registers will allow you to be certain > that you haven't trashed your inputs. They won't help you > resume execution with a corrected value in the destination > register of the faulting instruction. I have no problem with It actually depends on how you specify your requirements. > declaring that signals cannot be used to handle overflow > exceptions. I do have a problem with falsely pretending to > support such handling. We can decide (for now) that the problem > doesn't need to be solved. We can decide to call it a "TODO" > for some time when we're old and grey. We can solve it now. Si_addr in the siginfo struct is specified to contain a faulting instruction's reference. My patch fixes the code to fullfill the specification. The code was meant to do it already when I submitted it last year. Somehow I made a bug and now I'm only fixing it. We do nowhere pretend to support handling of overflow exceptions to the extent that permits emulating of faulting instructions. Check the docs, namely the "Program Error Signals" node of glibc's info pages. It seems my handler's example was a bit unfortunate, sigh... > I really don't care. But it's dishonest to say that the current code > solves it, even to a first order of approximation. To trot out an > overused Einstein quote, > > "Everything should be as simple as possible. But not simpler". Yes, sure, we may hardcode a zero here, but what the gain would be? Providing a real value instead makes us adhere to the spec, it's only marginally slower and it may be useful for anything, not only extending precision. For example one may print the address involved for user's (developer's) feedback and abort the affected function only as opposed to dumping a core. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 15:42:53 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMgro14354 for linux-mips-outgoing; Mon, 30 Jul 2001 15:42:53 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMgoV14351 for ; Mon, 30 Jul 2001 15:42:51 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id AAA22415; Tue, 31 Jul 2001 00:45:10 +0200 (MET DST) Date: Tue, 31 Jul 2001 00:45:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010731002421.A19713@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1513 Lines: 38 On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote: > Of course. I wouldn't even *try* to do sth other. In fact, I'm looking > around for various specs of various implementations (as seen from > the bus) of the LANCE chip to see if I could manage the job to > unify them all together: Yep, that would really be desireable, but there are quirks such as third-party DMA controllers that must be taken into account when writing generic chip support functions. In the DECstation's case the DMA controller is the I/O ASIC. It's probably doable by writing a generic backend and various interfaces (see e.g. the 8390 driver), but much care must be taken. And one must work on the generic tree -- e.g. the Alan's one -- as otherwise changes will be impossible to test by most of people. > Well, I'll start off in merging in those two declance drivers. But Excellent. > this will come no earlier that in two weeks or so. I'll first do > the serial keyboard with dz.c. Excellent. > PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to > *BSD :-) Who will ever attempt to clean up? Z8530 is on my to-do list. Our driver really sucks: neither DMA (the I/O ASIC again) nor sychronous mode, just basic asynchronous support. I'm going to look at LANCE one day, too, but it's lower on the list. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 15:45:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMjxo14442 for linux-mips-outgoing; Mon, 30 Jul 2001 15:45:59 -0700 Received: from dvmwest.gt.owl.de (postfix@dvmwest.gt.owl.de [62.52.24.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMjwV14439 for ; Mon, 30 Jul 2001 15:45:58 -0700 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id B5B84C4FE; Tue, 31 Jul 2001 00:45:56 +0200 (CEST) Date: Tue, 31 Jul 2001 00:45:56 +0200 From: Jan-Benedict Glaw To: "Maciej W. Rozycki" Cc: Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 Message-ID: <20010731004556.C19713@lug-owl.de> Mail-Followup-To: "Maciej W. Rozycki" , Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org References: <20010731002421.A19713@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: ; from macro@ds2.pg.gda.pl on Tue, Jul 31, 2001 at 12:45:10AM +0200 X-Operating-System: Linux mail 2.4.5 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 607 Lines: 14 On Tue, Jul 31, 2001 at 12:45:10AM +0200, Maciej W. Rozycki wrote: > On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote: > > PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to > > *BSD :-) Who will ever attempt to clean up? > > Z8530 is on my to-do list. Our driver really sucks: neither DMA (the I/O > ASIC again) nor sychronous mode, just basic asynchronous support. I'm > going to look at LANCE one day, too, but it's lower on the list. You you facing towards all those Z8530 implementation or only to "ours"? MfG, JBG (who can't even *believe* that there are *23* LANCE drivers) From owner-linux-mips@oss.sgi.com Mon Jul 30 15:57:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6UMvso14656 for linux-mips-outgoing; Mon, 30 Jul 2001 15:57:54 -0700 Received: from delta.ds2.pg.gda.pl (macro@delta.ds2.pg.gda.pl [213.192.72.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6UMvqV14650 for ; Mon, 30 Jul 2001 15:57:52 -0700 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id BAA22733; Tue, 31 Jul 2001 01:00:16 +0200 (MET DST) Date: Tue, 31 Jul 2001 01:00:16 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jan-Benedict Glaw cc: Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010731004556.C19713@lug-owl.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 677 Lines: 18 On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote: > You you facing towards all those Z8530 implementation or only to > "ours"? I'd like to merge all of them, of course. Especially as working on a single driver only might prevent me from seeing certain device-specific quirks that have to be handled in a non-conflicting way. For example the Z8530 application as used by DEC has a few "interesting" details when it comes to chip's wiring. Don't hold your breath, though... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From owner-linux-mips@oss.sgi.com Mon Jul 30 17:34:17 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V0YHw18330 for linux-mips-outgoing; Mon, 30 Jul 2001 17:34:17 -0700 Received: from solo.franken.de (pD9054444.dip.t-dialin.net [217.5.68.68]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V0YFV18327 for ; Mon, 30 Jul 2001 17:34:16 -0700 Received: (from tsbogend@localhost) by solo.franken.de (8.9.3/8.9.3) id CAA06404; Tue, 31 Jul 2001 02:32:45 +0200 Date: Tue, 31 Jul 2001 02:32:45 +0200 From: Thomas Bogendoerfer To: Jan-Benedict Glaw Cc: "Maciej W. Rozycki" , Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 Message-ID: <20010731023245.A6371@solo.franken.de> References: <20010731002421.A19713@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: <20010731002421.A19713@lug-owl.de>; from jbglaw@lug-owl.de on Tue, Jul 31, 2001 at 12:24:21AM +0200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 745 Lines: 18 On Tue, Jul 31, 2001 at 12:24:21AM +0200, Jan-Benedict Glaw wrote: > Of course. I wouldn't even *try* to do sth other. In fact, I'm looking > around for various specs of various implementations (as seen from > the bus) of the LANCE chip to see if I could manage the job to > unify them all together: > ./drivers/net/pcnet32.c none mentioned even if it's based on the lance design from AMD (and it support a lance compatible mode), you won't be able to unify this driver with other lance drivers since the driver uses the 32bit mode of the pcnet32 chip familiy 79C97[0-8]). Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ Alexander Viro on linux-kernel ] From owner-linux-mips@oss.sgi.com Mon Jul 30 20:43:46 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V3hke27155 for linux-mips-outgoing; Mon, 30 Jul 2001 20:43:46 -0700 Received: from smtp.huawei.com (sz135.szptt.net.cn [202.96.135.132] (may be forged)) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V3hXV27148 for ; Mon, 30 Jul 2001 20:43:33 -0700 Received: from hechendong11752 ([10.105.33.128]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GHBJDT01.517; Tue, 31 Jul 2001 11:37:05 +0800 Message-ID: <005e01c11973$1622d700$8021690a@huawei.com> From: "machael thailer" To: "Ian Soanes" Cc: References: <3AE44D0A.9080003@jungo.com> <20010423170425.F4623@bacchus.dhis.org> <3AE541B0.410FDF8A@lineo.com> Subject: Need your help:about RC32334 questions? Date: Tue, 31 Jul 2001 11:44:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1254 Lines: 37 > Hi Fabrice, > > This may not be totally relevant, but I'm currently trying to get > gdbserver working on a RC32334 IDT board. I've been having some issues > with single stepping, but am making a bit of progress. > > 1/ I started with a mips gdbserver port kindly supplied by Martin > Rivers. It mostly works well but had some problems single stepping > through conditional branches (the problem may have been due to a > different target than Martin was using, or me... I am kind of new to > this :) > > 2/ Previously I've had some luck single stepping kernel and module code > with the kernel gdbstub (arch/mips/kernel/gdb-stub.c), so I ported the > relevant single stepping code into gdbserver. The results were much > better. The only thing that seems to be wrong now is stepping over > function calls isn't working quite right. I can step into functions OK > though. > > If you're interested I'll let you know how I get on over the next few > days. If not, I won't be offended :) > Hello, Now I plan to port linux on our RC32334-based custom board. But I don't know whether linux support RC32334 now. Can you tell me which kernel version you use on your RC32334 IDT board? And where can i download it? Thanks in advance. machael thailer From owner-linux-mips@oss.sgi.com Mon Jul 30 20:59:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V3x9t27970 for linux-mips-outgoing; Mon, 30 Jul 2001 20:59:09 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V3x8V27964 for ; Mon, 30 Jul 2001 20:59:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA08595 for ; Mon, 30 Jul 2001 20:56:53 -0700 (PDT) mail_from (kaos@ocs.com.au) 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 NAA23176; Tue, 31 Jul 2001 13:57:45 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Thiemo Seufer cc: linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips In-reply-to: Your message of "Thu, 28 Jun 2001 16:32:51 +0200." <20010628163250.D28583@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Jul 2001 13:57:45 +1000 Message-ID: <1227.996551865@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 647 Lines: 20 On Thu, 28 Jun 2001 16:32:51 +0200, Thiemo Seufer wrote: >Keith Owens wrote: >[snip] >> >The best option is for a mips64 kernel to indicate that it is 64 bit >> >and its endianess. Instead of printing > >The appended patch introduces the new format in mips64. Maybe this speeds >up agreement about it. :-) I am updating ksymoops now and need some information. Could somebody tell me what this produces on mips? # objdump -h ksymoops | head -8 # objdump -h mips64-lsb-vmlinux | head -8 # objdump -h mips64-msb-vmlinux | head -8 where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB and MSB. From owner-linux-mips@oss.sgi.com Mon Jul 30 21:31:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V4VbP29997 for linux-mips-outgoing; Mon, 30 Jul 2001 21:31:37 -0700 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V4VWV29990 for ; Mon, 30 Jul 2001 21:31:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id GAA358061 for ; Tue, 31 Jul 2001 06:31:09 +0200 (CEST) mail_from (kaos@ocs.com.au) 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 OAA23359; Tue, 31 Jul 2001 14:30:04 +1000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: ksymoops changes for mips In-reply-to: Your message of "Tue, 31 Jul 2001 13:57:45 +1000." <1227.996551865@kao2.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Jul 2001 14:30:04 +1000 Message-ID: <1648.996553804@kao2.melbourne.sgi.com> Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 501 Lines: 15 On Tue, 31 Jul 2001 13:57:45 +1000, Keith Owens wrote: >I am updating ksymoops now and need some information. Could somebody >tell me what this produces on mips? > ># objdump -h ksymoops | head -8 ># objdump -h mips64-lsb-vmlinux | head -8 ># objdump -h mips64-msb-vmlinux | head -8 > >where mips64-[lm]sb-vmlinux are kernels compiled for 64 bit with LSB >and MSB. Sorry, that should have been objdump -x, not objdump -h, I need the architecture type as well as the file format. From owner-linux-mips@oss.sgi.com Mon Jul 30 22:55:37 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V5tbh01426 for linux-mips-outgoing; Mon, 30 Jul 2001 22:55:37 -0700 Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V5taV01423 for ; Mon, 30 Jul 2001 22:55:36 -0700 Received: from pacbell.net ([63.194.214.47]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHB00ACLPSNNP@mta5.snfc21.pbi.net> for linux-mips@oss.sgi.com; Mon, 30 Jul 2001 22:55:35 -0700 (PDT) Date: Mon, 30 Jul 2001 22:55:35 -0700 From: Pete Popov Subject: r4600 flag To: "Kevin D. Kissell" , Ralf Baechle Cc: linux-mips@oss.sgi.com Reply-to: ppopov@pacbell.net Message-id: <3B664857.4040100@pacbell.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 446 Lines: 17 in arch/mips/Makefile, we use the -mcpu=r4600 flag for MIPS32. What's interesting is that the use of this flag can cause the toolchain to generate incorrect code. For example: la k0, 1f nop 1: nop The la macro is split into a lui and a daddiu. The daddiu is not correct for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and the daddiu is then changed addiu. Is there a truly correct -mcpu option for a mips32 cpu? Pete From owner-linux-mips@oss.sgi.com Tue Jul 31 00:04:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V74WG05622 for linux-mips-outgoing; Tue, 31 Jul 2001 00:04:32 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V74VV05619 for ; Tue, 31 Jul 2001 00:04:31 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA22597; Tue, 31 Jul 2001 09:03:19 +0200 (MET DST) Date: Tue, 31 Jul 2001 09:03:18 +0200 (MEST) From: Geert Uytterhoeven To: Jan-Benedict Glaw cc: SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010728214114.C27316@lug-owl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 763 Lines: 20 On Sat, 28 Jul 2001, Jan-Benedict Glaw wrote: > However, the chip actually does not transmit the frame. Please look > at it because I don't have a clue about the lance chip. Especially, > I see there problems: > - lp->tx_buf_ptr_lnc[i] and lp->rx_buf_ptr_lnc[i] are > quite low addresses. Is this correct? Are they relative > to some other address (TC slot address?) Are these the addresses that link the ring buffers? If yes, they are adresses from the LANCE's point of view. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jul 31 00:09:10 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V79AY05833 for linux-mips-outgoing; Tue, 31 Jul 2001 00:09:10 -0700 Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V797V05826 for ; Tue, 31 Jul 2001 00:09:08 -0700 Received: from mullein.sonytel.be (mullein.sonytel.be [10.34.64.30]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA22962; Tue, 31 Jul 2001 09:08:31 +0200 (MET DST) Date: Tue, 31 Jul 2001 09:08:31 +0200 (MEST) From: Geert Uytterhoeven To: Jan-Benedict Glaw cc: "Maciej W. Rozycki" , Dave Airlie , SGI MIPS list , Debian MIPS list , engel@unix-ag.org Subject: Re: [long] Lance on DS5k/200 In-Reply-To: <20010731002421.A19713@lug-owl.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.sonytel.be id JAA22962 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6V798V05830 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1668 Lines: 48 On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote: > On Mon, Jul 30, 2001 at 10:06:45PM +0200, Maciej W. Rozycki wrote: > > How about merging it into official sources? This way your work won't get > > lost and others won't try to reinvent the wheel. > > Of course. I wouldn't even *try* to do sth other. In fact, I'm looking > around for various specs of various implementations (as seen from > the bus) of the LANCE chip to see if I could manage the job to > unify them all together: > > Driver file | Mentioned Chip > ----------------------------------------------+-------------------- [...] > ./drivers/net/a2065.c Am7990 When I wrote this one, I based it on ariadne.ce, but thanks to Jes Sørensen it should look quite similar to sunlance now. > ./drivers/net/ariadne.c Am79c960 The Ariadne is a bit special, because it byteswaps the data bus of the Am79c960 (PC-Net ISA, hence little endian) by hardware so the big endian m68k/PPC Amiga doesn't have to swap packet data. But that does mean that non-packet data has to be byteswapped. [...] > I really *hate* to see so many different implementations. That counts > to about 21..25 pieces of code, always written for the same thing. So this quote from my quote database is still valid ;-) There are more Lance drivers than there are architectures -- Geert Uytterhoeven on linux-kernel Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE) Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55 Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium From owner-linux-mips@oss.sgi.com Tue Jul 31 00:28:30 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V7SUL06968 for linux-mips-outgoing; Tue, 31 Jul 2001 00:28:30 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V7SSV06965 for ; Tue, 31 Jul 2001 00:28:29 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id JAA91378 for ; Tue, 31 Jul 2001 09:28:25 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15RTx0-0008FR-00 for ; Tue, 31 Jul 2001 09:28:22 +0200 Date: Tue, 31 Jul 2001 09:28:22 +0200 To: linux-mips@oss.sgi.com Subject: Re: r4600 flag Message-ID: <20010731092822.L27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B664857.4040100@pacbell.net> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 920 Lines: 32 Pete Popov wrote: > in arch/mips/Makefile, we use the -mcpu=r4600 flag for MIPS32. What's > interesting is that the use of this flag can cause the toolchain to > generate incorrect code. Which toolchain versions, what patches applied to it? > For example: > > la k0, 1f > nop > 1: nop > > > The la macro is split into a lui and a daddiu. The daddiu is not correct > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > the daddiu is then changed addiu. This is IIRC a known bug in at least current binutils CVS, a patch to fix it really was already discussed. > Is there a truly correct -mcpu option for a mips32 cpu? In theory, no -mcpu option (which is to be deprecated in favor of -march/-mtune) and -mips32 as ISA flag _should_ work. In practice, the patch which adds this to gas was discussed on the binutils list the last days and is likely to go in CVS today or tomorrow. Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 31 01:02:22 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6V82MQ08763 for linux-mips-outgoing; Tue, 31 Jul 2001 01:02:22 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6V82KV08754 for ; Tue, 31 Jul 2001 01:02:20 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA19555; Tue, 31 Jul 2001 01:02:11 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA22349; Tue, 31 Jul 2001 01:02:08 -0700 (PDT) Message-ID: <001f01c11997$bf9a4880$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: , "Ralf Baechle" Cc: References: <3B664857.4040100@pacbell.net> Subject: Re: r4600 flag Date: Tue, 31 Jul 2001 10:06:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1852 Lines: 44 > in arch/mips/Makefile, we use the -mcpu=r4600 flag for MIPS32. What's > interesting is that the use of this flag can cause the toolchain to > generate incorrect code. For example: > > la k0, 1f > nop > 1: nop > > > The la macro is split into a lui and a daddiu. The daddiu is not correct > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > the daddiu is then changed addiu. Using mips-linux-gcc from egcs-2.91.66, I don't see exactly this behavior in the test case above. I *do* see that *if* I have -mcpu=4600 set *and* I have not otherwise set the ISA level to be MIPS I or MIPS II (-mips1, -mips2), 64-bit instructions will be emitted. But that's to be expected. To generate 32-bit code for an R4600-like platform, you need to specify both the ISA level (to deal with issues like the above) and the R4600 pipeline (to get the MAD instruction). One place where care must be exercised is in MIPS32 exception handlers, where eret must be used. Prior to MIPS32, eret implied MIPS III which implied a 64-bit CPU, and the Linux compilers still see things that way. If the whole module is built with -mips3, one does risk seeing some cursed macro expansions. Until we get proper support for MIPS32 integrated into the standard Linux tool chain (see below), the most correct option would be to build with -mips2 and to use explicit ".set mips3/.set mips0" directives. > Is there a truly correct -mcpu option for a mips32 cpu? It's "-mips32", which is sort of a -mips option and a -mcpu option rolled into one. It's supported by several gnu distributions, notably those of Algorithmics and Cygnus/Red Hat. I believe that someone at MIPS or Algorithmics succeeded in building a Linux kernel of some description using the Algorithmics SDE, but I don't know the details. Regards, Kevin K. From owner-linux-mips@oss.sgi.com Tue Jul 31 03:40:58 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VAewl16848 for linux-mips-outgoing; Tue, 31 Jul 2001 03:40:58 -0700 Received: from mail.ict.ac.cn ([159.226.39.4]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VAevV16845 for ; Tue, 31 Jul 2001 03:40:57 -0700 Message-Id: <200107311040.f6VAevV16845@oss.sgi.com> Received: (qmail 12403 invoked from network); 31 Jul 2001 10:35:12 -0000 Received: from unknown (HELO heart1) (159.226.39.162) by 159.226.39.4 with SMTP; 31 Jul 2001 10:35:12 -0000 Date: Tue, 31 Jul 2001 18:43:45 +0800 From: Fuxin Zhang To: "linux-mips@oss.sgi.com" Subject: Re: Re: r4600 flag X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f6VAevV16846 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 621 Lines: 19 hello, 2001-07-31 10:06:00£º >It's "-mips32", which is sort of a -mips option and a -mcpu >option rolled into one. It's supported by several gnu distributions, >notably those of Algorithmics and Cygnus/Red Hat. I believe >that someone at MIPS or Algorithmics succeeded in building >a Linux kernel of some description using the Algorithmics >SDE, but I don't know the details. Yes,Algorithmics' linux kernel is built using their sde.And it works for our idt64474(essentially a R4600,they told me) too. > > Regards, > > Kevin K. Regards Fuxin Zhang fxzhang@ict.ac.cn From owner-linux-mips@oss.sgi.com Tue Jul 31 04:27:12 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VBRCt19554 for linux-mips-outgoing; Tue, 31 Jul 2001 04:27:12 -0700 Received: from dea.waldorf-gmbh.de (u-145-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VBR5V19547 for ; Tue, 31 Jul 2001 04:27:06 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6V9PVQ12732; Tue, 31 Jul 2001 11:25:31 +0200 Date: Tue, 31 Jul 2001 11:25:31 +0200 From: Ralf Baechle To: Thiemo Seufer Cc: linux-mips@oss.sgi.com Subject: Re: r4600 flag Message-ID: <20010731112530.A12409@bacchus.dhis.org> References: <3B664857.4040100@pacbell.net> <20010731092822.L27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010731092822.L27008@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Tue, Jul 31, 2001 at 09:28:22AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1050 Lines: 28 On Tue, Jul 31, 2001 at 09:28:22AM +0200, Thiemo Seufer wrote: > > The la macro is split into a lui and a daddiu. The daddiu is not correct > > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > > the daddiu is then changed addiu. > > This is IIRC a known bug in at least current binutils CVS, a patch > to fix it really was already discussed. Is this macro expaned by the compiler or assembler? Just -mcpu=r4600 should not make cc1 generate any instructions beyond MIPS I. In the past we already had inline assembler fragments that left the assembler in .misp3 mode thus resulting the rest of the file bein assembled in mips3 mode. > > Is there a truly correct -mcpu option for a mips32 cpu? None is really good, none is really bad ... > In theory, no -mcpu option (which is to be deprecated in > favor of -march/-mtune) and -mips32 as ISA flag _should_ work. > > In practice, the patch which adds this to gas was discussed on the > binutils list the last days and is likely to go in CVS > today or tomorrow. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 31 04:29:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VBTcY19765 for linux-mips-outgoing; Tue, 31 Jul 2001 04:29:38 -0700 Received: from dea.waldorf-gmbh.de (u-145-21.karlsruhe.ipdial.viaginterkom.de [62.180.21.145]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VBTMV19745 for ; Tue, 31 Jul 2001 04:29:25 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f6V9VLu12772; Tue, 31 Jul 2001 11:31:21 +0200 Date: Tue, 31 Jul 2001 11:31:21 +0200 From: Ralf Baechle To: "Kevin D. Kissell" Cc: ppopov@pacbell.net, linux-mips@oss.sgi.com Subject: Re: r4600 flag Message-ID: <20010731113120.B12409@bacchus.dhis.org> References: <3B664857.4040100@pacbell.net> <001f01c11997$bf9a4880$0deca8c0@Ulysses> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001f01c11997$bf9a4880$0deca8c0@Ulysses>; from kevink@mips.com on Tue, Jul 31, 2001 at 10:06:35AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1917 Lines: 45 On Tue, Jul 31, 2001 at 10:06:35AM +0200, Kevin D. Kissell wrote: > Using mips-linux-gcc from egcs-2.91.66, I don't see exactly this > behavior in the test case above. I *do* see that *if* I have -mcpu=4600 > set *and* I have not otherwise set the ISA level to be MIPS I or > MIPS II (-mips1, -mips2), 64-bit instructions will be emitted. > But that's to be expected. No, it contradict the GCC documentation: `-mcpu=CPU TYPE' Assume the defaults for the machine type CPU TYPE when scheduling instructions. The choices for CPU TYPE are `r2000', `r3000', `r3900', `r4000', `r4100', `r4300', `r4400', `r4600', `r4650', `r5000', `r6000', `r8000', and `orion'. Additionally, the `r2000', `r3000', `r4000', `r5000', and `r6000' can be abbreviated as `r2k' (or `r2K'), `r3k', etc. While picking a specific CPU TYPE will schedule things appropriately for that particular chip, the compiler will not generate any code that does not meet level 1 of the MIPS ISA (instruction set architecture) without a `-mipsX' or `-mabi' switch being used. > To generate 32-bit code for an > R4600-like platform, you need to specify both the ISA level > (to deal with issues like the above) and the R4600 pipeline > (to get the MAD instruction). No MAD on R4600. Again it would be in contradiction with above document- ation. Mad you get with: `-mmad' `-mno-mad' Permit use of the `mad', `madu' and `mul' instructions, as on the `r4650' chip. > > Is there a truly correct -mcpu option for a mips32 cpu? > > It's "-mips32", which is sort of a -mips option and a -mcpu > option rolled into one. It's supported by several gnu distributions, > notably those of Algorithmics and Cygnus/Red Hat. I believe > that someone at MIPS or Algorithmics succeeded in building > a Linux kernel of some description using the Algorithmics > SDE, but I don't know the details. Ralf From owner-linux-mips@oss.sgi.com Tue Jul 31 04:36:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VBahK20285 for linux-mips-outgoing; Tue, 31 Jul 2001 04:36:43 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VBadV20281; Tue, 31 Jul 2001 04:36:39 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA20734; Tue, 31 Jul 2001 04:36:26 -0700 (PDT) Received: from Ulysses (ulysses [192.168.236.13]) by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA24401; Tue, 31 Jul 2001 04:36:20 -0700 (PDT) Message-ID: <006901c119b5$ac8ecfe0$0deca8c0@Ulysses> From: "Kevin D. Kissell" To: "Ralf Baechle" Cc: , References: <3B664857.4040100@pacbell.net> <001f01c11997$bf9a4880$0deca8c0@Ulysses> <20010731113120.B12409@bacchus.dhis.org> Subject: Re: r4600 flag Date: Tue, 31 Jul 2001 13:40:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1711 Lines: 38 > > Using mips-linux-gcc from egcs-2.91.66, I don't see exactly this > > behavior in the test case above. I *do* see that *if* I have -mcpu=4600 > > set *and* I have not otherwise set the ISA level to be MIPS I or > > MIPS II (-mips1, -mips2), 64-bit instructions will be emitted. > > But that's to be expected. > > No, it contradict the GCC documentation: > > `-mcpu=CPU TYPE' > Assume the defaults for the machine type CPU TYPE when scheduling > instructions. The choices for CPU TYPE are `r2000', `r3000', > `r3900', `r4000', `r4100', `r4300', `r4400', `r4600', `r4650', > `r5000', `r6000', `r8000', and `orion'. Additionally, the > `r2000', `r3000', `r4000', `r5000', and `r6000' can be abbreviated > as `r2k' (or `r2K'), `r3k', etc. While picking a specific CPU > TYPE will schedule things appropriately for that particular chip, > the compiler will not generate any code that does not meet level 1 > of the MIPS ISA (instruction set architecture) without a `-mipsX' > or `-mabi' switch being used. In that case, the tools that I've been using are technically broken. Surprise surprise. Because -mcpu=4600 is most assuredly setting the ISA level, even if it doesn't override one explicitly set! > > To generate 32-bit code for an > > R4600-like platform, you need to specify both the ISA level > > (to deal with issues like the above) and the R4600 pipeline > > (to get the MAD instruction). > > No MAD on R4600. Again it would be in contradiction with above document- > ation. Mad you get with: Right. Sorry. I got the 4600 and 4650 confused. I no longer understand why "4600" and not "4650" is the model for MIPS32. Kevin K. From owner-linux-mips@oss.sgi.com Tue Jul 31 05:58:54 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VCwsq25415 for linux-mips-outgoing; Tue, 31 Jul 2001 05:58:54 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VCwqV25411 for ; Tue, 31 Jul 2001 05:58:52 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id OAA94906 for ; Tue, 31 Jul 2001 14:58:50 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15RZ6o-00006w-00 for ; Tue, 31 Jul 2001 14:58:50 +0200 Date: Tue, 31 Jul 2001 14:58:50 +0200 To: linux-mips@oss.sgi.com Subject: Re: r4600 flag Message-ID: <20010731145850.N27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010731112530.A12409@bacchus.dhis.org> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 736 Lines: 19 Ralf Baechle wrote: > On Tue, Jul 31, 2001 at 09:28:22AM +0200, Thiemo Seufer wrote: > > > > The la macro is split into a lui and a daddiu. The daddiu is not correct > > > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > > > the daddiu is then changed addiu. > > > > This is IIRC a known bug in at least current binutils CVS, a patch > > to fix it really was already discussed. > > Is this macro expaned by the compiler or assembler? Just -mcpu=r4600 > should not make cc1 generate any instructions beyond MIPS I. It's the assembler, -mcpu does not only affect scheduling in gas. To clean this up -march and -tune were introduced recently to obsolete -mcpu and -m (in both binutils and gcc). Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 31 06:08:32 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VD8W926127 for linux-mips-outgoing; Tue, 31 Jul 2001 06:08:32 -0700 Received: from iris1.csv.ica.uni-stuttgart.de (iris1.csv.ica.uni-stuttgart.de [129.69.118.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VD8VV26121 for ; Tue, 31 Jul 2001 06:08:31 -0700 Received: from rembrandt.csv.ica.uni-stuttgart.de (rembrandt.csv.ica.uni-stuttgart.de [129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de (8.9.3/8.9.3) with ESMTP id PAA94638 for ; Tue, 31 Jul 2001 15:08:29 +0200 (MDT) Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.22 #1 (Debian)) id 15RZG9-00008W-00 for ; Tue, 31 Jul 2001 15:08:29 +0200 Date: Tue, 31 Jul 2001 15:08:29 +0200 To: linux-mips@oss.sgi.com Subject: Re: r4600 flag Message-ID: <20010731150829.O27008@rembrandt.csv.ica.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006901c119b5$ac8ecfe0$0deca8c0@Ulysses> User-Agent: Mutt/1.3.18i From: Thiemo Seufer Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1570 Lines: 36 Kevin D. Kissell wrote: [snip] > > `-mcpu=CPU TYPE' > > Assume the defaults for the machine type CPU TYPE when scheduling > > instructions. The choices for CPU TYPE are `r2000', `r3000', > > `r3900', `r4000', `r4100', `r4300', `r4400', `r4600', `r4650', > > `r5000', `r6000', `r8000', and `orion'. Additionally, the > > `r2000', `r3000', `r4000', `r5000', and `r6000' can be abbreviated > > as `r2k' (or `r2K'), `r3k', etc. While picking a specific CPU > > TYPE will schedule things appropriately for that particular chip, > > the compiler will not generate any code that does not meet level 1 > > of the MIPS ISA (instruction set architecture) without a `-mipsX' > > or `-mabi' switch being used. > > In that case, the tools that I've been using are technically > broken. Surprise surprise. Because -mcpu=4600 is > most assuredly setting the ISA level, even if it doesn't > override one explicitly set! gas and gcc have different meanings for this option, gas uses the cpu's default ISA (if none specified) while gcc uses MIPS I. In current binutils/gcc CVS, there was -march and -mtune introduced as a replacement for -mcpu and -m, which were kept for backward compatibility only. [snip] > > No MAD on R4600. Again it would be in contradiction with above document- > > ation. Mad you get with: > > Right. Sorry. I got the 4600 and 4650 confused. I no longer > understand why "4600" and not "4650" is the model for MIPS32. At least for the CVS binutils gas it is Generic-MIPS32, not 4600. Thiemo From owner-linux-mips@oss.sgi.com Tue Jul 31 06:37:34 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VDbY927614 for linux-mips-outgoing; Tue, 31 Jul 2001 06:37:34 -0700 Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VDbVV27611; Tue, 31 Jul 2001 06:37:31 -0700 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA21635; Tue, 31 Jul 2001 06:37:22 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA26287; Tue, 31 Jul 2001 06:37:22 -0700 (PDT) Received: from mips.com (coppccl [172.17.27.2]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id f6VDa7a26933; Tue, 31 Jul 2001 15:36:08 +0200 (MEST) Message-ID: <3B66B4E6.70B80D21@mips.com> Date: Tue, 31 Jul 2001 15:38:46 +0200 From: Carsten Langgaard Organization: MIPS Technologies X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Thiemo Seufer , linux-mips@oss.sgi.com Subject: Re: r4600 flag References: <3B664857.4040100@pacbell.net> <20010731092822.L27008@rembrandt.csv.ica.uni-stuttgart.de> <20010731112530.A12409@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1219 Lines: 37 Ralf Baechle wrote: > On Tue, Jul 31, 2001 at 09:28:22AM +0200, Thiemo Seufer wrote: > > > > The la macro is split into a lui and a daddiu. The daddiu is not correct > > > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > > > the daddiu is then changed addiu. > > > > This is IIRC a known bug in at least current binutils CVS, a patch > > to fix it really was already discussed. > > Is this macro expaned by the compiler or assembler? Just -mcpu=r4600 > should not make cc1 generate any instructions beyond MIPS I. > > In the past we already had inline assembler fragments that left the assembler > in .misp3 mode thus resulting the rest of the file bein assembled in > mips3 mode. Yes, and I'm sure I fixed that so it worked on MIPS32 CPUs, only leaving the "eret" instructions. > > > > Is there a truly correct -mcpu option for a mips32 cpu? > > None is really good, none is really bad ... > > > In theory, no -mcpu option (which is to be deprecated in > > favor of -march/-mtune) and -mips32 as ISA flag _should_ work. > > > > In practice, the patch which adds this to gas was discussed on the > > binutils list the last days and is likely to go in CVS > > today or tomorrow. > > Ralf From owner-linux-mips@oss.sgi.com Tue Jul 31 06:51:15 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VDpFk28656 for linux-mips-outgoing; Tue, 31 Jul 2001 06:51:15 -0700 Received: from real.realitydiluted.com (real.realitydiluted.com [208.242.241.164]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VDpCV28646 for ; Tue, 31 Jul 2001 06:51:12 -0700 Received: from real.realitydiluted.com ([208.242.241.164] helo=cotw.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 15RZuu-0002a6-00; Tue, 31 Jul 2001 08:50:36 -0500 Message-ID: <3B66B5F3.79D6AAB8@cotw.com> Date: Tue, 31 Jul 2001 08:43:15 -0500 From: "Steven J. Hill" Reply-To: sjhill@cotw.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.7-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: debian-mips@lists.debian.org, linux-mips@oss.sgi.com Subject: Horrible X and kernel crashes under mipsel RH7.1... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 4453 Lines: 125 Greetings. Well, the X server is giving me fits with the new RH7.1 packages. This is a rather long email, so hold on. WHAT WORKS ---------- If I use MontaVista's older toolchain with a glibc-2.0.6 based root filesystem with my 2.4.5 MIPS kernel and framebuffer and compile X from CVS things work great. WHAT DOES NOT WORK ------------------ If I use a new cross toolchain with latest binutils from HJLu, gcc-3.0 and glibc-2.2.3 and the RH7.1 mipsel based distribution, X cross compiled form CVS crashes and takes the kernel with it. I have not tested anything under the Debian distros yet. CRASH OUTPUT ------------ I did three different runs which gave me different results. Here is the first one. I know that I had plenty of memory to handle the 2^5 = (32) 4KB pages = 128KB allocation. root@localhost:/home/sjhill$ /usr/X11R6/bin/Xfbdev __alloc_pages: 5-order allocation failed. __alloc_pages: 5-order allocation failed. Unable to handle kernel paging request at virtual address 00000000, epc == 00000 000, ra == 80167750 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 801f0000 b30003f0 000000bb $4 : 0000000c 0000006b 809d3bc0 00006b18 $8 : 00000020 801658f0 801cbc98 801c5000 $12: 00000001 00000040 00000003 81f6eea0 $16: 801dbf18 801cbe60 00000001 801d60cc $20: 801d0a3c 809d3bc0 00000000 806e3620 $24: 00000001 2ac99d90 $28: 813f2000 813f3de0 00000000 80167750 epc : 00000000 Status: b001f003 Cause : 00000008 Process Xfbdev (pid: 596, stackpage=813f2000) *************** The next one I printed out the memory usage as well as the attempt to run startx and xinit first. The page alloc messages aren't printed, but the kernel still dies a horrible death. root@localhost:~$ free total used free shared buffers cached Mem: 30340 26700 3640 0 3992 15536 -/+ buffers/cache: 7172 23168 Swap: 66016 2368 63648 root@localhost:~$ /usr/X11R6/bin/startx giving up. xinit: Connection refused (errno 146): unable to connect to X server xinit: No such process (errno 3): Server error. root@localhost:~$ free total used free shared buffers cached Mem: 30340 27424 2916 0 4052 16188 -/+ buffers/cache: 7184 23156 Swap: 66016 2368 63648 root@localhost:~$ xinit free giving up. xinit: Connection refused (errno 146): unable to connect to X server xinit: No such process (errno 3): Server error. root@localhost:~$ free total used free shared buffers cached Mem: 30340 27428 2912 0 4052 16188 -/+ buffers/cache: 7188 23152 Swap: 66016 2368 63648 root@localhost:~$ /usr/X11R6/bin/Xfbdev [Xfbdev:522] Illegal instruction 801cbe60 at 801980a4 ra=80167750 Unable to handle kernel paging request at virtual address 00000000, epc == 80198 0b4, ra == 80167750 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 801f0000 b30003f0 000000bb $4 : 0000000c 00000001 809b1c20 00006b18 $8 : 00000020 801658f0 801cbc98 801c5000 $12: 00000001 00000040 00000003 814b2e20 $16: 801dbf18 801cbe60 00000001 801d60cc $20: 801d0a3c 809b1c20 00000000 80758840 $24: 00000001 2ac99d90 $28: 8119e000 8119fde0 00000000 80167750 epc : 801980b4 Status: b001f003 Cause : 00000008 Process Xfbdev (pid: 522, stackpage=8119e000) *************** This one gives a little more output and screams about illegal instructions. root@localhost:~$ /usr/X11R6/bin/Xfbdev [Xfbdev:513] Illegal instruction 801cbe60 at 801980b8 ra=80167750 [Xfbdev:513] Illegal instruction 801cbe60 at 801980d0 ra=80167750 [Xfbdev:513] Illegal instruction 801cbe60 at 801980e8 ra=80167750 Unable to handle kernel paging request at virtual address 00000000, epc == 00000 000, ra == 80167750 Oops in fault.c:do_page_fault, line 172: $0 : 00000000 801f0000 b30003f0 000000bb $4 : 0000000c 00000001 80e84480 00006b18 $8 : 00000020 801658f0 801cbc98 801c5000 $12: 00000001 00000040 00000003 81659920 $16: 801dbf18 801cbe60 00000001 00000000 $20: 801d0a3c 80e84480 00000000 809369c0 $24: 00000001 2ac99d90 $28: 816a2000 816a3de0 00000000 80167750 epc : 00000000 Status: b001f003 Cause : 00000008 Process Xfbdev (pid: 513, stackpage=816a2000) *************** If anyone has had success or similar problems please comment. Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer From owner-linux-mips@oss.sgi.com Tue Jul 31 08:29:19 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VFTJ500635 for linux-mips-outgoing; Tue, 31 Jul 2001 08:29:19 -0700 Received: from epic8.Stanford.EDU (epic8.Stanford.EDU [171.64.15.41]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VFTIV00631 for ; Tue, 31 Jul 2001 08:29:18 -0700 Received: (from johnd@localhost) by epic8.Stanford.EDU (8.11.1/8.11.1) id f6VFTCp28904; Tue, 31 Jul 2001 08:29:12 -0700 (PDT) Date: Tue, 31 Jul 2001 08:29:12 -0700 (PDT) From: "John D. Davis" To: Carsten Langgaard cc: SGI MIPS list Subject: Re: r4600 flag In-Reply-To: <3B66B4E6.70B80D21@mips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 1751 Lines: 51 Looking at the system map from the generic build of 2.4.3, it looks like the code is 64 bit. The upper 32 bits are "f" instead of 0. I built it using the R4600 flag. This differs from the system map for 2.4.0-test9 where the upper 32 bits are 0. For the indy, do I specify mips2 to generate 32 bit code? objdump says it is ELF32, but it doesn't look like that. I would like to generate 32bit. thanks, john On Tue, 31 Jul 2001, Carsten Langgaard wrote: > > > Ralf Baechle wrote: > > > On Tue, Jul 31, 2001 at 09:28:22AM +0200, Thiemo Seufer wrote: > > > > > > The la macro is split into a lui and a daddiu. The daddiu is not correct > > > > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and > > > > the daddiu is then changed addiu. > > > > > > This is IIRC a known bug in at least current binutils CVS, a patch > > > to fix it really was already discussed. > > > > Is this macro expaned by the compiler or assembler? Just -mcpu=r4600 > > should not make cc1 generate any instructions beyond MIPS I. > > > > In the past we already had inline assembler fragments that left the assembler > > in .misp3 mode thus resulting the rest of the file bein assembled in > > mips3 mode. > > Yes, and I'm sure I fixed that so it worked on MIPS32 CPUs, only leaving the > "eret" instructions. > > > > > > > Is there a truly correct -mcpu option for a mips32 cpu? > > > > None is really good, none is really bad ... > > > > > In theory, no -mcpu option (which is to be deprecated in > > > favor of -march/-mtune) and -mips32 as ISA flag _should_ work. > > > > > > In practice, the patch which adds this to gas was discussed on the > > > binutils list the last days and is likely to go in CVS > > > today or tomorrow. > > > > Ralf > > From owner-linux-mips@oss.sgi.com Tue Jul 31 13:53:52 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VKrq411103 for linux-mips-outgoing; Tue, 31 Jul 2001 13:53:52 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VKrpV11100 for ; Tue, 31 Jul 2001 13:53:51 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VKrjTv032516; Tue, 31 Jul 2001 13:53:45 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VKriFt032512; Tue, 31 Jul 2001 13:53:45 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 31 Jul 2001 13:53:44 -0700 (PDT) From: James Simmons To: linux-mips-kernel@lists.sourceforge.net cc: linux-mips@oss.sgi.com Subject: Mips Cobalt cube distro Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 465 Lines: 15 Hi! We just have created a debian distro from the latest packages using a 2.4.5 kernel for tthe MIPS cobalt cube. You can grab the image from http://www.pocketlinux.com/~samc/debian-cobalt Just read the README and have fun. ----------------------------------------------------------------------------- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ Alexander Viro on linux-kernel ] From owner-linux-mips@oss.sgi.com Tue Jul 31 13:59:59 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VKxxo11445 for linux-mips-outgoing; Tue, 31 Jul 2001 13:59:59 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VKxxV11442 for ; Tue, 31 Jul 2001 13:59:59 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VKxrTv032688; Tue, 31 Jul 2001 13:59:53 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VKxrVD032684; Tue, 31 Jul 2001 13:59:53 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 31 Jul 2001 13:59:53 -0700 (PDT) From: James Simmons To: linux-mips@oss.sgi.com cc: linux-mips-kernel@lists.sourceforge.net Subject: sys_mips problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 283 Lines: 9 Since I was having problems with everything sefaulting due to the sys_mips bug I tried the patch floating around. It fixed the segfault problem but instead I get this error. Anyone knows why? : error while loading shared libraries: libc.so.6: cannot stat shared object: Error 14 From owner-linux-mips@oss.sgi.com Tue Jul 31 14:11:14 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLBEI11761 for linux-mips-outgoing; Tue, 31 Jul 2001 14:11:14 -0700 Received: from we-24-31-32-201.we.mediaone.net (root@we-24-31-32-201.we.mediaone.net [24.31.32.201]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLBDV11758 for ; Tue, 31 Jul 2001 14:11:13 -0700 Received: from webninja.com (caleb@[192.168.1.234]) by we-24-31-32-201.we.mediaone.net (8.9.3/8.9.3) with ESMTP id NAA21214; Tue, 31 Jul 2001 13:12:26 -0700 Message-ID: <3B671E27.3080808@webninja.com> Date: Tue, 31 Jul 2001 14:07:51 -0700 From: Caleb Shay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628 X-Accept-Language: en-us MIME-Version: 1.0 To: James Simmons CC: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: Mips Cobalt cube distro References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 895 Lines: 27 Ummm, what README? All I see is this. base-contents.txt 31-Jul-2001 13:40 5k base.tar.bz2 31-Jul-2001 13:40 19.0M vmlinux.gz 31-Jul-2001 13:40 824k James Simmons wrote: >Hi! > > We just have created a debian distro from the latest packages using a >2.4.5 kernel for tthe MIPS cobalt cube. You can grab the image from > >http://www.pocketlinux.com/~samc/debian-cobalt > >Just read the README and have fun. > > >----------------------------------------------------------------------------- >Crap can work. Given enough thrust pigs will fly, but it's not necessary a >good idea. [ Alexander Viro on linux-kernel ] > From owner-linux-mips@oss.sgi.com Tue Jul 31 14:11:57 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLBvg11815 for linux-mips-outgoing; Tue, 31 Jul 2001 14:11:57 -0700 Received: from hermes.mvista.com (gateway-1237.mvista.com [12.44.186.158]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLBvV11812 for ; Tue, 31 Jul 2001 14:11:57 -0700 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 f6VLHBE01520; Tue, 31 Jul 2001 14:17:11 -0700 Message-ID: <3B671DFC.3999437D@mvista.com> Date: Tue, 31 Jul 2001 14:07:08 -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: James Simmons CC: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: sys_mips problems References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 387 Lines: 12 James Simmons wrote: > > Since I was having problems with everything sefaulting due to the sys_mips > bug I tried the patch floating around. It fixed the segfault problem but > instead I get this error. Anyone knows why? > > : error while loading shared libraries: libc.so.6: cannot stat shared > object: Error 14 Which patch did you use? Does your CPU have ll/sc instructions? Jun From owner-linux-mips@oss.sgi.com Tue Jul 31 14:25:43 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLPhs12380 for linux-mips-outgoing; Tue, 31 Jul 2001 14:25:43 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLPhV12376 for ; Tue, 31 Jul 2001 14:25:43 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VLPaTv001077; Tue, 31 Jul 2001 14:25:36 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VLPaHR001073; Tue, 31 Jul 2001 14:25:36 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 31 Jul 2001 14:25:36 -0700 (PDT) From: James Simmons To: Caleb Shay cc: linux-mips-kernel@lists.sourceforge.net, linux-mips@oss.sgi.com Subject: Re: Mips Cobalt cube distro In-Reply-To: <3B671E27.3080808@webninja.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 554 Lines: 13 Oops. A small problem with the web server. Sorry aboput that. Now when you go to that web page it will be appended so you can read it via the web. > Ummm, what README? > All I see is this. > > base-contents.txt 31-Jul-2001 13:40 5k > base.tar.bz2 31-Jul-2001 13:40 19.0M > vmlinux.gz 31-Jul-2001 13:40 824k From owner-linux-mips@oss.sgi.com Tue Jul 31 14:43:09 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VLh9p12833 for linux-mips-outgoing; Tue, 31 Jul 2001 14:43:09 -0700 Received: from www.transvirtual.com (root@www.transvirtual.com [206.14.214.140]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VLh8V12830 for ; Tue, 31 Jul 2001 14:43:08 -0700 Received: from www.transvirtual.com (jsimmons@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VLh1Tv002150; Tue, 31 Jul 2001 14:43:01 -0700 Received: from localhost (jsimmons@localhost) by www.transvirtual.com (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6VLh1db002146; Tue, 31 Jul 2001 14:43:01 -0700 X-Authentication-Warning: www.transvirtual.com: jsimmons owned process doing -bs Date: Tue, 31 Jul 2001 14:43:01 -0700 (PDT) From: James Simmons To: Jun Sun cc: linux-mips@oss.sgi.com, linux-mips-kernel@lists.sourceforge.net Subject: Re: sys_mips problems In-Reply-To: <3B671DFC.3999437D@mvista.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Content-Length: 561 Lines: 18 > > Since I was having problems with everything sefaulting due to the sys_mips > > bug I tried the patch floating around. It fixed the segfault problem but > > instead I get this error. Anyone knows why? > > > > : error while loading shared libraries: libc.so.6: cannot stat shared > > object: Error 14 > > Which patch did you use? The fast_sysmips one. > Does your CPU have ll/sc instructions? I have a cobalt cube which has a MIPS Nevada chip which is a R52xx chip. I don't know if it does. By default I have ll/sc and lld/scd instructions enabled.