From atulsrivastava9@rediffmail.com Mon Sep 2 15:02:47 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 15:02:47 +0200 (CEST) Received: from webmail22.rediffmail.com ([203.199.83.144]:33000 "HELO webmail22.rediffmail.com") by linux-mips.org with SMTP id ; Mon, 2 Sep 2002 15:02:47 +0200 Received: (qmail 4045 invoked by uid 510); 2 Sep 2002 13:02:31 -0000 Date: 2 Sep 2002 13:02:31 -0000 Message-ID: <20020902130231.4044.qmail@webmail22.rediffmail.com> Received: from unknown (202.54.89.89) by rediffmail.com via HTTP; 02 Sep 2002 13:02:31 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: big endian ramdisk availibility..? Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 47 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello, does anybody know about the availibility of readymade big endian ramdisk for mips ? also where to find a working big endian tool set. i downloaded from "mips source page" both little endian and big endian. while little endian worked fine but big endian one fails due to one or another reason.. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From macro@ds2.pg.gda.pl Mon Sep 2 16:02:21 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 16:02:22 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:14807 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 16:02:21 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA29641; Mon, 2 Sep 2002 16:02:43 +0200 (MET DST) Date: Mon, 2 Sep 2002 16:02:42 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: [patch] 2.4.19-pre1: RTC: fix memory-mapped configuration support In-Reply-To: <20020831023724.C11364@bacchus.dhis.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 48 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Sat, 31 Aug 2002, Ralf Baechle wrote: > Looks good to me. Done. Also for the trunk which has a newer version of the driver. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Mon Sep 2 16:04:37 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 16:04:38 +0200 (CEST) Received: from p508B7CE7.dip.t-dialin.net ([80.139.124.231]:19072 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 16:04:37 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82F4L612973; Mon, 2 Sep 2002 17:04:21 +0200 Date: Mon, 2 Sep 2002 17:04:21 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: [patch] 2.4.19-pre1: RTC: fix memory-mapped configuration support Message-ID: <20020902170421.A12959@linux-mips.org> References: <20020831023724.C11364@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Mon, Sep 02, 2002 at 04:02:42PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 49 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 02, 2002 at 04:02:42PM +0200, Maciej W. Rozycki wrote: > > Looks good to me. > > Done. Also for the trunk which has a newer version of the driver. Excellent, thanks. Ralf From c3sinha@hotmail.com Mon Sep 2 16:38:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 16:38:13 +0200 (CEST) Received: from [200.185.109.22] ([200.185.109.22]:46061 "HELO bario.k8.com.br") by linux-mips.org with SMTP id ; Mon, 2 Sep 2002 16:38:12 +0200 Received: (qmail 345 invoked from network); 2 Sep 2002 14:36:20 -0000 Received: from 200-158-13-102.dsl.telesp.net.br (HELO localhost) (200.158.13.102) by 200.185.109.22 with SMTP; 2 Sep 2002 14:36:20 -0000 X-Sender: c3sinha@hotmail.com From: VAPT! VUPT! - Jogos To: linux-mips@linux-mips.org Date: Mon, 02 Sep 2002 11:29:47 -0300 Subject: VAPT! VUPT! - Links diretos para Jogos MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20020902143812Z1122963-9213+36@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 50 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: c3sinha@hotmail.com Precedence: bulk X-list: linux-mips JOGOS COMPLETOS PARA DOWNLOAD, SEM ENROLACAO...... Clique no link abaixo http://www.vaptvupt.cjb.net abraco, Equipe VAPT! VUPT! From ralf@linux-mips.org Mon Sep 2 17:31:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 17:31:15 +0200 (CEST) Received: from p508B7CE7.dip.t-dialin.net ([80.139.124.231]:16513 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 17:31:14 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82GUr219081; Mon, 2 Sep 2002 18:30:53 +0200 Date: Mon, 2 Sep 2002 18:30:53 +0200 From: Ralf Baechle To: Jun Sun Cc: Matthew Dharm , Linux-MIPS Subject: Re: time.c CP0_COMPARE Message-ID: <20020902183053.E15618@linux-mips.org> References: <20020829142133.A3905@bacchus.dhis.org> <3D6E5C58.405@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D6E5C58.405@mvista.com>; from jsun@mvista.com on Thu, Aug 29, 2002 at 10:39:36AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 51 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Aug 29, 2002 at 10:39:36AM -0700, Jun Sun wrote: > Ralf Baechle wrote: > > c0_compare = c0_count + mips_counter_frequency / HZ. > > > > That's what the individual boards are currently doing themselves though that > > should be done in generic code. > > > > Good idea. > > The attached patch attempts to set the first interrupt. It should be benign > even if a system is not using CPU counter as timer interrupt. > > I also updated the time.README, including a new section about implementation > on a SMP machine. Applied though I think that this should also be done via start_secondary that is we'll need some per_cpu_time_init analog to per_cpu_trap_init. Also of course your change makes some cleanup possible as the initialization no happens twice for a bunch of platforms. Ralf From agx@gandalf.physik.uni-konstanz.de Mon Sep 2 17:59:11 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 17:59:12 +0200 (CEST) Received: from gandalf.physik.uni-konstanz.de ([134.34.144.69]:26382 "HELO gandalf.physik.uni-konstanz.de") by linux-mips.org with SMTP id ; Mon, 2 Sep 2002 17:59:11 +0200 Received: by gandalf.physik.uni-konstanz.de (Postfix, from userid 501) id 7D1CF8D37; Mon, 2 Sep 2002 17:59:02 +0200 (CEST) Date: Mon, 2 Sep 2002 17:59:02 +0200 From: Guido Guenther To: atul srivastava Cc: linux-mips@linux-mips.org Subject: Re: big endian ramdisk availibility..? Message-ID: <20020902175901.B8610@gandalf.physik.uni-konstanz.de> References: <20020902130231.4044.qmail@webmail22.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020902130231.4044.qmail@webmail22.rediffmail.com>; from atulsrivastava9@rediffmail.com on Mon, Sep 02, 2002 at 01:02:31PM -0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 52 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: agx@sigxcpu.org Precedence: bulk X-list: linux-mips On Mon, Sep 02, 2002 at 01:02:31PM -0000, atul srivastava wrote: > does anybody know about the availibility of readymade big endian > ramdisk for mips ? ftp://ftp.debian.org:/debian/dists/woody/main/disks-mips/3.0.23-2002-05-21/root.bin is the one Debian currently uses. -- Guido From ralf@linux-mips.org Mon Sep 2 18:00:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 18:00:54 +0200 (CEST) Received: from p508B7CE7.dip.t-dialin.net ([80.139.124.231]:37761 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 18:00:53 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82H0c828716; Mon, 2 Sep 2002 19:00:38 +0200 Date: Mon, 2 Sep 2002 19:00:38 +0200 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board Message-ID: <20020902190038.F15618@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mdharm@momenco.com on Tue, Aug 27, 2002 at 04:00:51PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 53 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Aug 27, 2002 at 04:00:51PM -0700, Matthew Dharm wrote: > The attached two patches and small tar archive (I can't figure out how > to make CVS do the equivalent of a diff -N) add support to the 2.4 > branch for the Ocelot-G board (RM7000 processor with GT-64240 bridge). > > I've gone ahead and created an linux/arch/mips/momenco directory, as > we've got another board almost ready to add to the repository (the > Ocelot-C and -CS), and we've got concrete plans to port to our > RM9000x2 board (Jaguar), which has at least a couple of varieties. I > figured getting all this organized under one directory would be wise. > > Presuming this gets accepted, there are a few more patches in this > series... some updates to the MTD probing address for these boards, as > well as a new ethernet driver for the GT-64240 on-board ethernet. > > Ralf, please apply these to the CVS repository. As a note - most boards are now selectable for the 32-bit and 64-bit kernel. For a board like the Ocelot having a 64-bit kernel certainly makes sense ... Ralf From sma@2m.dk Mon Sep 2 19:19:43 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 19:19:44 +0200 (CEST) Received: from www.2m.dk ([194.239.1.24]:38408 "HELO 2m.dk") by linux-mips.org with SMTP id ; Mon, 2 Sep 2002 19:19:43 +0200 Received: by 2m.dk (Postfix, from userid 1) id A74BC1285; Mon, 2 Sep 2002 19:19:36 +0200 (CEST) Received: from LarsN (unknown [194.239.1.62]) by 2m.dk (Postfix) with SMTP id CF8A312A5 for ; Mon, 2 Sep 2002 17:19:34 +0000 (/etc/localtime) Message-ID: <00c301c252a4$9a802a00$016d100a@2m.dk> From: "Stephen Mose Aaskov" To: Subject: MTD drivers and byte/word mode Date: Mon, 2 Sep 2002 19:17:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C252B5.5DD69F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 54 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sma@2m.dk Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C252B5.5DD69F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I=B4m working on a 2.4 port to a design with FLASH devices connected = through a 16 bit bus. The FLASH (AMD) is set to word mode. I have quite a hard time trying to understand the FLASH geometry = settings and calculations of the addresses used for CFI query etc. It looks as if the adresses calculated by cfi_build_cmd_addr() is the = double of what my FLASH chips are using. eg. the CFI query is written to 0xaa where my chip in word mode expects = the query command to be written to 0x55 Is there any direct support in the MTD driver for differentiating = between word/byte mode ? The buswidth is set to 16 bits (=3D2), and interleave to 1 (I have two = chips sharing the bus, not in parallel) Stephen Mose Aaskov Engineer, R&D 2M ELECTRONIC A/S Malervej 10, DK-2630 Taastrup Denmark Tel: +45 43300555 Fax: +45 43300567 ------=_NextPart_000_00C0_01C252B5.5DD69F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=B4m working on a 2.4 port to a design = with FLASH=20 devices connected through a 16 bit bus.
The FLASH (AMD) is set to word = mode.
 
I have quite a hard time trying to = understand the=20 FLASH geometry settings and calculations of the addresses used for CFI = query=20 etc.
It looks as if the adresses calculated = by=20 cfi_build_cmd_addr() is the double of what my FLASH chips are=20 using.
eg. the CFI query is written to 0xaa = where my chip=20 in word mode expects the query command to be written to = 0x55
 
Is there any direct support in the MTD = driver for=20 differentiating between word/byte mode ?
 
The buswidth is set to 16 bits (=3D2), = and interleave=20 to 1 (I have two chips sharing the bus, not in parallel)
 
 
 
Stephen Mose Aaskov
Engineer, = R&D
2M=20 ELECTRONIC A/S
Malervej 10, DK-2630 Taastrup
Denmark
Tel: +45=20 43300555  Fax: +45 43300567
------=_NextPart_000_00C0_01C252B5.5DD69F60-- From mdharm@host099.momenco.com Mon Sep 2 21:39:01 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 21:39:02 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:63237 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 21:39:01 +0200 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g82Jco828191; Mon, 2 Sep 2002 12:38:50 -0700 Date: Mon, 2 Sep 2002 12:38:50 -0700 From: Matthew Dharm To: Ralf Baechle Cc: Linux-MIPS Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board Message-ID: <20020902123850.A28171@momenco.com> References: <20020902190038.F15618@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020902190038.F15618@linux-mips.org>; from ralf@linux-mips.org on Mon, Sep 02, 2002 at 07:00:38PM +0200 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 55 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Oh, I agree that a 64-bit kernel makes sense. I'm just not sure what is needed to get from where I am now to where I want to be. There is _much_ interest from our customers for 64-bit linux. Especially if the toolchain catches up so that we can have 64-bit userspace. Anyone have some quick pointers on how to get from here to there? Matt On Mon, Sep 02, 2002 at 07:00:38PM +0200, Ralf Baechle wrote: > On Tue, Aug 27, 2002 at 04:00:51PM -0700, Matthew Dharm wrote: > > > The attached two patches and small tar archive (I can't figure out how > > to make CVS do the equivalent of a diff -N) add support to the 2.4 > > branch for the Ocelot-G board (RM7000 processor with GT-64240 bridge). > > > > I've gone ahead and created an linux/arch/mips/momenco directory, as > > we've got another board almost ready to add to the repository (the > > Ocelot-C and -CS), and we've got concrete plans to port to our > > RM9000x2 board (Jaguar), which has at least a couple of varieties. I > > figured getting all this organized under one directory would be wise. > > > > Presuming this gets accepted, there are a few more patches in this > > series... some updates to the MTD probing address for these boards, as > > well as a new ethernet driver for the GT-64240 on-board ethernet. > > > > Ralf, please apply these to the CVS repository. > > As a note - most boards are now selectable for the 32-bit and 64-bit kernel. > For a board like the Ocelot having a 64-bit kernel certainly makes sense ... > > Ralf -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From ralf@linux-mips.org Mon Sep 2 21:46:31 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 21:46:31 +0200 (CEST) Received: from p508B7CE7.dip.t-dialin.net ([80.139.124.231]:47749 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 21:46:31 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82KkFW18147; Mon, 2 Sep 2002 22:46:15 +0200 Date: Mon, 2 Sep 2002 22:46:15 +0200 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board Message-ID: <20020902224615.A17378@linux-mips.org> References: <20020902190038.F15618@linux-mips.org> <20020902123850.A28171@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020902123850.A28171@momenco.com>; from mdharm@momenco.com on Mon, Sep 02, 2002 at 12:38:50PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 56 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 02, 2002 at 12:38:50PM -0700, Matthew Dharm wrote: > Oh, I agree that a 64-bit kernel makes sense. I'm just not sure what is > needed to get from where I am now to where I want to be. > > There is _much_ interest from our customers for 64-bit linux. Especially > if the toolchain catches up so that we can have 64-bit userspace. The toolchain stuff is being worked on. Hold your breath but cheat every once in a while when your face turns blue ;-) > Anyone have some quick pointers on how to get from here to there? The basic receipe is easy. The 64-bit kernel has a binary compatibility layer that allows you to use 32-bit software with no changes. Just use a 64-bit compiler, for now that's probably still the egcs 1.1.2 / binutils 2.9.5 based mips64-linux / mips64el-linux tool chain. Using your old .config file do a "make ARCH=mips64 oldconfig" etc. The resulting binary file will be a 32-bit ELF file so you can just feed that to your firmware for booting as usual. Problems may be hit along the way ;-) Ralf From mdharm@host099.momenco.com Mon Sep 2 22:41:00 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 22:41:01 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:65029 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 22:41:00 +0200 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g82KerX28367; Mon, 2 Sep 2002 13:40:53 -0700 Date: Mon, 2 Sep 2002 13:40:53 -0700 From: Matthew Dharm To: Ralf Baechle Cc: Linux-MIPS Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board Message-ID: <20020902134053.A28347@momenco.com> References: <20020902190038.F15618@linux-mips.org> <20020902123850.A28171@momenco.com> <20020902224615.A17378@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020902224615.A17378@linux-mips.org>; from ralf@linux-mips.org on Mon, Sep 02, 2002 at 10:46:15PM +0200 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 57 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Hrm... okay... first question, where do I get the 64-bit toolchain? Right now, I'm using HJ's toolchain RPMs (from over a year ago -- I should update those). Second, what about all those nifty extras? Things like the fact that kseg0/1 (well, their 64-bit equivalents) are now larger (how big are they, anyway) so they can map all of my SDRAM as well as most (all?) of my I/O space... I guess for that I need to reprogram all my address decoders, and then that sort of thing must be what the arch/mips64/* stuff is for. Yes? No? Or am I smoking something too strong again? The 64/32 mixed-mode linux is certainly of some interest to our customers, but full 64-bit is really where the demand is. Is there anything that a non-compiler guy can do to help the effort along? Matt On Mon, Sep 02, 2002 at 10:46:15PM +0200, Ralf Baechle wrote: > On Mon, Sep 02, 2002 at 12:38:50PM -0700, Matthew Dharm wrote: > > > Oh, I agree that a 64-bit kernel makes sense. I'm just not sure what is > > needed to get from where I am now to where I want to be. > > > > There is _much_ interest from our customers for 64-bit linux. Especially > > if the toolchain catches up so that we can have 64-bit userspace. > > The toolchain stuff is being worked on. Hold your breath but cheat every > once in a while when your face turns blue ;-) > > > Anyone have some quick pointers on how to get from here to there? > > The basic receipe is easy. The 64-bit kernel has a binary compatibility > layer that allows you to use 32-bit software with no changes. Just use > a 64-bit compiler, for now that's probably still the egcs 1.1.2 / > binutils 2.9.5 based mips64-linux / mips64el-linux tool chain. Using your > old .config file do a "make ARCH=mips64 oldconfig" etc. The resulting > binary file will be a 32-bit ELF file so you can just feed that to your > firmware for booting as usual. Problems may be hit along the way ;-) > > Ralf -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From werkt@csh.rit.edu Mon Sep 2 22:44:21 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 02 Sep 2002 22:44:21 +0200 (CEST) Received: from mcp.csh.rit.edu ([129.21.60.9]:2470 "EHLO mcp.csh.rit.edu") by linux-mips.org with ESMTP id ; Mon, 2 Sep 2002 22:44:21 +0200 Received: from fury.csh.rit.edu (fury.csh.rit.edu [129.21.60.5]) by mcp.csh.rit.edu (Postfix) with ESMTP id 958D84376 for ; Mon, 2 Sep 2002 16:44:08 -0400 (EDT) Date: Mon, 2 Sep 2002 16:43:55 -0400 (EDT) From: George Gensure To: Subject: root-nfs hang and error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 58 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: werkt@csh.rit.edu Precedence: bulk X-list: linux-mips I've got a problem with a diskless install on an Indy. When trying to mount an nfs to install to, I end up with about a 5 minute hang (afterwards, though, all file transfer is seamless). When rebooting to boot from that nfs root I get an rpc error from the Indy and it refuses to mount the root. (obviously it panics). The kernel is 2.4.16 and has nfs v2 and v3 installed, as well as root nfs support. Anyone have any suggestions for getting this root to mount correctly? -George werkt@csh.rit.edu From ralf@linux-mips.org Tue Sep 3 00:03:24 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 00:03:25 +0200 (CEST) Received: from p508B5F13.dip.t-dialin.net ([80.139.95.19]:16521 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 00:03:24 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82M3DN23514; Tue, 3 Sep 2002 00:03:13 +0200 Date: Tue, 3 Sep 2002 00:03:13 +0200 From: Ralf Baechle To: Matthew Dharm Cc: Linux-MIPS Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board Message-ID: <20020903000313.A23265@linux-mips.org> References: <20020902190038.F15618@linux-mips.org> <20020902123850.A28171@momenco.com> <20020902224615.A17378@linux-mips.org> <20020902134053.A28347@momenco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020902134053.A28347@momenco.com>; from mdharm@momenco.com on Mon, Sep 02, 2002 at 01:40:53PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 59 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 02, 2002 at 01:40:53PM -0700, Matthew Dharm wrote: > Hrm... okay... first question, where do I get the 64-bit toolchain? Right > now, I'm using HJ's toolchain RPMs (from over a year ago -- I should update > those). ftp.linux-mips.org:/pub/linux/mips/crossdev/. > Second, what about all those nifty extras? Things like the fact that > kseg0/1 (well, their 64-bit equivalents) are now larger (how big are they, > anyway) Giant. The entire XKPHYS space has a size of 60 Exabyte. Three bits of the address specify one of the caching modes. That leaves punny 59 bits or 512 Petabyte for each of these segments. And simply because that's still a shitload for most applications (unless you want to mmap a decent sized disk array or so ...) most MIPS implementations actually only use a fraction of this space; 1TB is typical but the R10000 family actually supports 16TB and I guess another extension will be due soon ... > so they can map all of my SDRAM as well as most (all?) of my > I/O space... I guess for that I need to reprogram all my address decoders, > and then that sort of thing must be what the arch/mips64/* stuff is for. I've actually eleminated all board support code from arch/mips64. The way Ocelot support was done for 32-bit kernel was mapping all RAM contiguously starting from address 0. That will be the right thing for 64-bit as well. Just all the highmem crap goes away and the ioremap code becomes a trivial 1:1 mapping. > Yes? No? Or am I smoking something too strong again? As long as you don't inhale ;-) > The 64/32 mixed-mode linux is certainly of some interest to our customers, > but full 64-bit is really where the demand is. Is there anything that a > non-compiler guy can do to help the effort along? The lion part of the effort will be the toolchain for this round. Once that part is done we'll have to port libc at which point rebuilding code as N32 or N64 should have become trivial. Ralf From ralf@linux-mips.org Tue Sep 3 00:39:02 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 00:39:03 +0200 (CEST) Received: from p508B5F13.dip.t-dialin.net ([80.139.95.19]:40330 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 00:39:02 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82Mcvv26766 for linux-mips@linux-mips.org; Tue, 3 Sep 2002 00:38:57 +0200 Resent-Message-Id: <200209022238.g82Mcvv26766@dea.linux-mips.net> Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g82MZqV26722; Tue, 3 Sep 2002 00:35:52 +0200 Date: Tue, 3 Sep 2002 00:35:52 +0200 From: Ralf Baechle To: Vivien Chappelier Cc: Brian Murphy , linux-mips@oss.sgi.com Subject: Re: [PATCH 2.5] R5000 secondary cache support Message-ID: <20020903003552.L15618@linux-mips.org> References: <3D5964EF.7040503@murphy.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from vivien.chappelier@enst-bretagne.fr on Mon, Aug 26, 2002 at 09:49:37PM +0200 Resent-From: ralf@linux-mips.org Resent-Date: Tue, 3 Sep 2002 00:38:57 +0200 Resent-To: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 60 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Aug 26, 2002 at 09:49:37PM +0200, Vivien Chappelier wrote: > I've tested and updated Brian Murphy's R5K SC patch to the 2.5 > kernel. I've also changed a few comments, changed Page_Invalidate > operation to R5K_Page_Invalidate_S to be consistent with the naming of R4K > cache ops, and simplified the r5k_dma_cache_inv_sc routine (no need for > two 'while'). And I've also removed the extra crap for in config-shared.in > in Brian's latest diff (removing spaces/formating) :) > > I've also tested this patch at runtime, it runs fine (as far as > a 2.5.8 can run fine :)). This patch is for both 2.5.8/mips64 and > 2.5.8/mips. > > Please comment and/or apply, Mostly ok. I just don't like that you force CONFIG_BOARD_SCACHE on everybody with a R5000 or Nevada. Cobalt Qube 1 for example has a Nevada which never has a second level cache, whatever type. So if you could fix that eventually :-) Ralf From Andre.Messerschmidt@infineon.com Tue Sep 3 09:03:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 09:03:58 +0200 (CEST) Received: from smtp1.infineon.com ([194.175.117.76]:29878 "EHLO smtp1.infineon.com") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 09:03:58 +0200 Received: from mucse012.eu.infineon.com (RFC1918-Host [172.29.27.229] (may be forged)) by smtp1.infineon.com (8.12.2/8.12.2) with ESMTP id g836wMsb007385; Tue, 3 Sep 2002 08:58:26 +0200 (MEST) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 09:03:44 +0200 Received: from dlfw003a.dus.infineon.com ([172.29.128.3]) by mucse012.eu.infineon.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SDVYLY9M; Tue, 3 Sep 2002 09:03:41 +0200 Received: by dlfw003a.dus.infineon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 09:03:35 +0200 From: Andre.Messerschmidt@infineon.com To: werkt@csh.rit.edu Cc: linux-mips@linux-mips.org Message-ID: <86048F07C015D311864100902760F1DD01B5ECE1@dlfw003a.dus.infineon.com> Subject: AW: root-nfs hang and error Date: Tue, 3 Sep 2002 09:03:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 61 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Andre.Messerschmidt@infineon.com Precedence: bulk X-list: linux-mips Hi. > When trying to mount an nfs to install to, I had some problems without "rsize=1024,wsize=1024" but that was not on an Indy, so I do not know if it is the solution here. regards Andre From nemoto@toshiba-tops.co.jp Tue Sep 3 09:35:39 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 09:35:40 +0200 (CEST) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:49687 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Tue, 3 Sep 2002 09:35:39 +0200 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; 3 Sep 2002 07:35:37 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id CBB21B471; Tue, 3 Sep 2002 16:35:28 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id QAA72123; Tue, 3 Sep 2002 16:35:28 +0900 (JST) Date: Tue, 03 Sep 2002 16:37:11 +0900 (JST) Message-Id: <20020903.163711.104027127.nemoto@toshiba-tops.co.jp> To: werkt@csh.rit.edu Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: root-nfs hang and error From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 62 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nemoto@toshiba-tops.co.jp Precedence: bulk X-list: linux-mips >>>>> On Mon, 2 Sep 2002 16:43:55 -0400 (EDT), George Gensure said: werkt> When trying to mount an nfs to install to, I end up with about werkt> a 5 minute hang (afterwards, though, all file transfer is werkt> seamless). It seems the mount is waiting for lockd. On diskless install, dbootstrap try to mount nfs partition without "nolock" option. For workaround, you can do "Execute a Shell" and type # mount -o nolock server:/path /target instead of "Mount a Previously-Initialized Partition" on diskless install. Isn't this a bug of dbootstrap ? Here is a patch. diff -u boot-floppies.org/utilities/dbootstrap/partition_config.c boot-floppies/utilities/dbootstrap/partition_config.c --- boot-floppies.org/utilities/dbootstrap/partition_config.c Mon Sep 2 15:33:34 2002 +++ boot-floppies/utilities/dbootstrap/partition_config.c Mon Sep 2 19:34:02 2002 @@ -862,6 +862,13 @@ if(strcmp(type,"msdos")==0 && !is_filesystem_supported("vfat")) type="vfat"; INFOMSG("Mounting %s partition %s on %s", type, partition->name, real_mount_point); +#ifdef NFSROOT + if (!strncmp(type, "nfs", 4)) + snprintf(prtbuf, sizeof(prtbuf), + "mount -t nfs -o nolock,rsize=8192,wsize=8192 %s %s", + partition->name, real_mount_point); + else +#endif snprintf(prtbuf, sizeof(prtbuf), "mount -t %s %s %s", type, partition->name, real_mount_point); status = execlog(prtbuf, LOG_INFO); } --- --- --- Atsushi Nemoto From Jon_Burgess@eur.3com.com Tue Sep 3 10:29:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 10:29:15 +0200 (CEST) Received: from ip-161-71-171-238.corp-eur.3com.com ([161.71.171.238]:7912 "EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 10:29:14 +0200 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g838UZRG009451; Tue, 3 Sep 2002 09:30:41 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g838TeR07076; Tue, 3 Sep 2002 09:29:41 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256C29.002F1C4D ; Tue, 3 Sep 2002 09:34:34 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: "Stephen Mose Aaskov" cc: linux-mips@linux-mips.org Message-ID: <80256C29.002F1B7C.00@notesmta.eur.3com.com> Date: Tue, 3 Sep 2002 09:28:29 +0100 Subject: Re: MTD drivers and byte/word mode Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 63 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Jon_Burgess@eur.3com.com Precedence: bulk X-list: linux-mips > It looks as if the adresses calculated by > cfi_build_cmd_addr() is the double of what my FLASH > chips are using. > eg. the CFI query is written to 0xaa where my chip > in word mode expects the query command to be written > to 0x55 We have just such a setup working in our product with a 16 bit AMD flash using the CFI diver. The 0xAA address as far as the programmer is concerned looks wrong, but the flash chip is expecting addresses of 16bit data which are shifted 1 address line from the address of 8 bit data. On our board the generic 8/16 bit bus address lines are connected to the 16 bit flash as: Bus A0 -> Unused Bus A1 -> Flash A0, Bus A2 -> Flash A1 etc, When the CPU accesses addres 0xAA the flash will see 0x55. Jon From nop@nop.com Tue Sep 3 14:25:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 14:25:08 +0200 (CEST) Received: from place.org ([65.163.18.18]:8324 "EHLO zachs.place.org") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 14:25:07 +0200 Received: from Jay-Carlsons-Computer.local. (localhost [127.0.0.1]) by zachs.place.org (Postfix) with ESMTP id C9346181B4; Tue, 3 Sep 2002 07:24:57 -0500 (CDT) Date: Tue, 3 Sep 2002 08:26:37 -0400 Subject: soft-float defines in mips-linux gcc config Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Jay Carlson To: linux-mips@linux-mips.org From: Jay Carlson Content-Transfer-Encoding: 7bit Message-Id: <648A6FF8-BF38-11D6-B21F-0030658AB11E@nop.com> X-Mailer: Apple Mail (2.543) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 64 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nop@nop.com Precedence: bulk X-list: linux-mips Right now there is a small bug in how mips-linux configures gcc for softfloat. In gcc/config/mips/t-linux, we set up libgcc to include the soft floating point code, using the GNU names, like __addsi3. But because mips/linux.h includes mips/ecoff.h, gcc produces calls to the GOFAST style names (like dpmul, very namespace-contaminating.) mips/netbsd.h cleans up after mips/elf.h by doing: #undef US_SOFTWARE_GOFAST #undef INIT_SUBTARGET_OPTABS #define INIT_SUBTARGET_OPTABS which would fix the problem for mips/linux.h as well. Jay From atulsrivastava9@rediffmail.com Tue Sep 3 15:25:25 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 15:25:26 +0200 (CEST) Received: from [203.199.83.247] ([203.199.83.247]:63917 "HELO mailweb34.rediffmail.com") by linux-mips.org with SMTP id ; Tue, 3 Sep 2002 15:25:25 +0200 Received: (qmail 23993 invoked by uid 510); 3 Sep 2002 13:25:04 -0000 Date: 3 Sep 2002 13:25:04 -0000 Message-ID: <20020903132504.23992.qmail@mailweb34.rediffmail.com> Received: from unknown (202.54.89.72) by rediffmail.com via HTTP; 03 Sep 2002 13:25:04 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: MIPS-IDT with ramdisk...? Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 65 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Has anybody got MIPS-IDT Big Endian linux port booting with a Ramdisk filesystem.. I have got linux up on this board. also NFS mounting works fine but never Ramdisk support , got working. i have done bacis checks.. 1.checksum on ramdisk ..correct 2.uncompression is o.k. 3.filesystem mounted (root=/dev/ram) o.k whenever i tried to booth with a ramdisk it goes to execing /bin/sh or so and then fails in load_elf_binary() at, /* First of all, some simple consistency checks. */ if(elf_ex.e_type != ET_EXEC && elf_ex.e_type != ET_DYN) for me e_type always reported to be 0x200..and there it fails. while if after mounting ramdisk with command #mount -o loop arch/mips/ramdisk/ramdisk /mnt , and then #file /mnt/bin/sh gives o/p as expected , /mnt/bin/sh: ELF 32-bit MSB mips-1 executable, MIPS R3000_BE, version 1, dynamically linked (uses shared libs), stripped MY boot messages pasted below ------------------------------ Determined physical RAM map: memory: 8000fc00 @ 80000400 (usable) memory: 00ed4210 @ 0012bdf0 (usable) Initial ramdisk at: 0x80103000 (46022 bytes) On node 0 totalpages: 4096 zone(0): 4096 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram console=ttys0,115200n8 init=/bin/sh rw CPU frequency 132.00 MHz Calibrating delay loop... 131.48 BogoMIPS Memory: 14904k/15184k available (748k kernel code, 280k reserved, 107k data, 160k init) Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 block: queued sectors max/low 9834kB/3278kB, 64 slots per queue RAMDISK driver initialized: 16 RAM disks of 2048K size 1024 blocksize RAMDISK: Compressed image found at block 0 gunzip DEBUG:Orig CRC: 3ccbe06c, Computed CRC: 3ccbe06c gunzip DEBUG:Orig len: 147851, Computed len: 147851, RAMDISK: Un-compressed the ramdisk - result: 0 Freeing initrd memory: 44k freed loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x0000 (irq = 0) is a 16550A ttyS01 at 0x0000 (irq = 0) is a 16550A physmap flash device: 400000 at b4000000 Physically mapped flash: Found no CFI device at location zero VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 160k freed DEBUG: Opening the file /dev/ttyS0 DEBUG: File descriptor returned is -2 Warning: unable to open an initial console. also it is unable to open a /dev/ttyS0 but this is included in my ramdisk image. I have taken a precompiled ramdisk image (root.bin) from debian's FTP site. I don't know what to doubt for.... Best Regards, Ashish Anand __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From lembree@metrolink.com Tue Sep 3 16:38:10 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 16:38:11 +0200 (CEST) Received: from [66.31.4.227] ([66.31.4.227]:25460 "EHLO ripple.nh.metrolink.com") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 16:38:10 +0200 Received: (from lembree@localhost) by ripple.nh.metrolink.com (8.11.6/8.11.6) id g83EakD24451; Tue, 3 Sep 2002 10:36:46 -0400 X-Authentication-Warning: ripple.nh.metrolink.com: lembree set sender to lembree@metrolink.com using -f Subject: Re: hints on wait queue bug? From: Rob Lembree To: Robert Lembree Cc: linux-mips@linux-mips.org In-Reply-To: <1030652956.1536.21.camel@ripple.nh.metrolink.com> References: <1030652956.1536.21.camel@ripple.nh.metrolink.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Sep 2002 10:36:46 -0400 Message-Id: <1031063806.11894.16.camel@ripple.nh.metrolink.com> Mime-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 66 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lembree@metrolink.com Precedence: bulk X-list: linux-mips On Thu, 2002-08-29 at 16:29, Rob Lembree wrote: > Hi there, > > I've got a problem where lots of io to the console seems > to break something in the kernel, resulting in a segfault, > along with a kernel error. > > I dove into it, and found that it's related to wait queue > stuff. I turned on the wait queue debugging, and got the > following, just prior to things going off the deep end. > > bad magic 802ccb24 (should be 802ccb2c), kernel BUG at sched.c:729! > > Is there some tutorial on this stuff somewhere (besides > reading the code -- I'm doing that now!) > > Has this stuff changed a great deal since 2.4.5 (when this > code last worked correctly)? Turns out that this is the same problem as the binutils bug referenced back in January /February. An upgrade will fix this. r > thanks, > rob > > -- > > Rob Lembree Metro Link Incorporated > 29 Milk St. lembree@metrolink.com > Nashua, NH 03064-1651 http://www.metrolink.com > Phone: 954.660.2460 Alternate: 603.577.9714 > PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 -- Rob Lembree Metro Link Incorporated 29 Milk St. lembree@metrolink.com Nashua, NH 03064-1651 http://www.metrolink.com Phone: 954.660.2460 Alternate: 603.577.9714 PGP: 1F EE F8 58 30 F1 B1 20 C5 4F 12 21 AD 0D 6B 29 From jsun@mvista.com Tue Sep 3 19:13:03 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 19:13:04 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:16124 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 19:13:03 +0200 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA08296; Tue, 3 Sep 2002 10:10:36 -0700 Message-ID: <3D74EA66.6020906@mvista.com> Date: Tue, 03 Sep 2002 09:59:18 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: Matthew Dharm , Linux-MIPS Subject: Re: time.c CP0_COMPARE (and SMP IPI rambling) References: <20020829142133.A3905@bacchus.dhis.org> <3D6E5C58.405@mvista.com> <20020902183053.E15618@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 67 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Aug 29, 2002 at 10:39:36AM -0700, Jun Sun wrote: > > >>Ralf Baechle wrote: > > >>> c0_compare = c0_count + mips_counter_frequency / HZ. >>> >>>That's what the individual boards are currently doing themselves though that >>>should be done in generic code. >>> >> >>Good idea. >> >>The attached patch attempts to set the first interrupt. It should be benign >>even if a system is not using CPU counter as timer interrupt. >> >>I also updated the time.README, including a new section about implementation >>on a SMP machine. > > > Applied though I think that this should also be done via start_secondary > that is we'll need some per_cpu_time_init analog to per_cpu_trap_init. Right now setting per-cpu timers is totally left to the board-dependent code. Once we see more SMP boxes using this approach, I think it starts to be interesting to make some abstraction and support it in a systematic way, including support for using CPU counter as the per-cpu timer interrupt. Using local_timer_emulation sounds like an attractive alternative to me, as we only need to set up one system-wide timer interrupt. Conceptually it probably takes a little longer to run through timer_interrupt (due to IPI calls). But if the hit on performance is very negligible, the simplicity might make it worthwile. BTW, since I am here, I like to ramble on a little bit further. Currently Linux supports two kinds of IPI (inter-processor interrupt) deliveries: 1) sender waiting for the interrupt handler to start 2) sender waiting for the interrupt handler to start and complete I think we really should the third kind: 3) sender does not wait at all. Just delivers the interrupt. With this support, the emulated local timer approach would have no performance penalty at all. Jun From werkt@csh.rit.edu Tue Sep 3 19:19:41 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 19:19:42 +0200 (CEST) Received: from mcp.csh.rit.edu ([129.21.60.9]:51869 "EHLO mcp.csh.rit.edu") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 19:19:41 +0200 Received: from csh.rit.edu (unknown [129.21.61.133]) by mcp.csh.rit.edu (Postfix) with ESMTP id 8B430437A; Tue, 3 Sep 2002 13:19:03 -0400 (EDT) Message-ID: <3D752698.5040907@csh.rit.edu> Date: Tue, 03 Sep 2002 17:16:08 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: root-nfs hang and error References: <20020903.163711.104027127.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 68 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: werkt@csh.rit.edu Precedence: bulk X-list: linux-mips > > > # mount -o nolock server:/path /target > > > gotcha. That solves the install hang, but the bigger problem is this panic at boot, when all of my portmap calls return 128 (lockd, nfsd, and mountd) on the client. I have no idea why this kernel is able to mount nfs partitions in the install, but not at boot time. -George werkt@csh.rit.edu From drow@false.org Tue Sep 3 21:15:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 03 Sep 2002 21:15:58 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:25866 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Tue, 3 Sep 2002 21:15:57 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mK5R-0000Qr-00; Tue, 03 Sep 2002 15:15:45 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mJ9E-0007aL-00; Tue, 03 Sep 2002 15:15:36 -0400 Date: Tue, 3 Sep 2002 15:15:36 -0400 From: Daniel Jacobowitz To: Jay Carlson Cc: linux-mips@linux-mips.org Subject: Re: soft-float defines in mips-linux gcc config Message-ID: <20020903191536.GA28999@nevyn.them.org> References: <648A6FF8-BF38-11D6-B21F-0030658AB11E@nop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <648A6FF8-BF38-11D6-B21F-0030658AB11E@nop.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 69 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, Sep 03, 2002 at 08:26:37AM -0400, Jay Carlson wrote: > Right now there is a small bug in how mips-linux configures gcc for > softfloat. > > In gcc/config/mips/t-linux, we set up libgcc to include the soft > floating point code, using the GNU names, like __addsi3. But because > mips/linux.h includes mips/ecoff.h, gcc produces calls to the GOFAST > style names (like dpmul, very namespace-contaminating.) > > mips/netbsd.h cleans up after mips/elf.h by doing: > > #undef US_SOFTWARE_GOFAST > #undef INIT_SUBTARGET_OPTABS > #define INIT_SUBTARGET_OPTABS > > which would fix the problem for mips/linux.h as well. When commenting on GCC issues, please say which version you're talking about - I'm pretty sure this is fixed in 3.2, and I know you aren't talking about HEAD, since HEAD hasn't built right on mips-linux in a month (Eric will fix this in a bit). -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mdharm@momenco.com Wed Sep 4 03:10:39 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 03:10:40 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:9479 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 03:10:39 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g841AV602010; Tue, 3 Sep 2002 18:10:31 -0700 From: "Matthew Dharm" To: "Jun Sun" Cc: "Linux-MIPS" Subject: RE: Interrupt handling.... Date: Tue, 3 Sep 2002 18:10:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3D6E87EB.4010000@mvista.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 70 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Okay... I think I've got a problem that isn't covered by the usual examples. I'm now trying to implment a second-level interrupt demuxer. My exception handler, when it sees a certain bit set in the CP0_CAUSE register set, attempts to read from the second-level controller. The problem is, that code looks like this: li t0, 0xfc000000 lb t1, 0xc(t0) Which, as you can see, attempts to access address 0xfc00000c. And then I get: Unable to handle kernel paging request at virtual address fc00000c, epc == 801af2ac, ra == 80102eb8 Oops in fault.c::do_page_fault, line 206: I'm guessing I'm in trouble here. My instincts tell me the the only way out of this might be to add a wired TLB entry to make certain I can always access physical address 0xfc00000c... but I'm hoping there is a better solution than tying up a TLB entry like that. After all, isn't that what ioremap is supposed to do? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun > Sent: Thursday, August 29, 2002 1:46 PM > To: Matthew Dharm > Cc: Linux-MIPS > Subject: Re: Interrupt handling.... > > > Matthew Dharm wrote: > > I've taken it upon myself to re-write some interrupt > handling code. > > It's a mess, and it needs cleaning. > > > > That is usually a right attitude to start ... :=) > > > > > An interrupt handler must be registered with > set_except_vector(0, ...) > > which must return a numeric code in the range of > 0..NR_IRQS -- it can > > do this in any way it wants, including limited function calls (ie > > there is a stack in place). > > > > Interrupt is setup throught request_irq()/setup_irq(). > set_except_vector() > for setting exception handlers, which is different from interrupts. > > > The irq_desc array of irq_desc_t structures is where the magic > > happens. The value returned by the interrupt handler is > used as an > > index into this array to do the dispatch a specific handler. The > > 'status' and 'action' fields are pretty much > self-explanatory. The > > 'handler' field seems to point to a set of function > pointers used for > > enabling/disabling the IRQ. But what is 'depth' for? > Boards seem to > > set it to either 0 or 1 commonly, but I don't see why. > > For nested disabling and enabling of interrupts. > > > I also don't > > see how IRQ sharing is accomplished... > > Yes, it is there. See do_IRQ() and a sub-routine > handle_event() (or something > like that) > > > Is this pretty much how it all works? > > I have a more detailed description in my porting guide. > > http://linux.junsun.net/porting-howto/porting-howto.html#cha pter-interrupt Jun From nemoto@toshiba-tops.co.jp Wed Sep 4 03:34:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 03:34:27 +0200 (CEST) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:43284 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Wed, 4 Sep 2002 03:34:26 +0200 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; 4 Sep 2002 01:34:25 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id A7E41B471; Wed, 4 Sep 2002 10:34:17 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id KAA74293; Wed, 4 Sep 2002 10:34:17 +0900 (JST) Date: Wed, 04 Sep 2002 10:36:01 +0900 (JST) Message-Id: <20020904.103601.74754748.nemoto@toshiba-tops.co.jp> To: werkt@csh.rit.edu Cc: linux-mips@linux-mips.org Subject: Re: root-nfs hang and error From: Atsushi Nemoto In-Reply-To: <3D752698.5040907@csh.rit.edu> References: <20020903.163711.104027127.nemoto@toshiba-tops.co.jp> <3D752698.5040907@csh.rit.edu> X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 71 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nemoto@toshiba-tops.co.jp Precedence: bulk X-list: linux-mips >>>>> On Tue, 03 Sep 2002 17:16:08 -0400, George Gensure said: werkt> I have no idea why this kernel is able to mount nfs partitions werkt> in the install, but not at boot time. On install, rootfs is ramdisk and you will be prompted network parameters by the installer. On diskless boot, kernel ip pnp will be used to configure network. So "ip=" and "nfsroot=" options may be required on diskless boot. But I do not know how to specify these options on Indy boot loader. --- Atsushi Nemoto From dom@mudchute.algor.co.uk Wed Sep 4 11:54:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 11:54:31 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:38638 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 11:54:30 +0200 Received: from mudchute.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g849s1r08509; Wed, 4 Sep 2002 10:54:01 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id KAA17466; Wed, 4 Sep 2002 10:53:55 +0100 (BST) Date: Wed, 4 Sep 2002 10:53:55 +0100 (BST) Message-Id: <200209040953.KAA17466@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matthew Dharm" Cc: "Jun Sun" , "Linux-MIPS" Subject: RE: Interrupt handling.... In-Reply-To: References: <3D6E87EB.4010000@mvista.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 72 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Matthew, > Okay... I think I've got a problem that isn't covered by the usual > examples. Possibly this is too simple an answer and is stuff you know quite well already... > Which, as you can see, attempts to access address 0xfc00000c. But that address is in the MIPS CPU's 'kseg2' region. Addresses there are always translated by the TLB, and you haven't got an entry. Registers from things like the 2nd level interrupt controller are memory mapped I/O locations, and you need to do an uncached access to the appropriate physical address. Most MIPS hardware has registers mapped between 0-512Mbyte (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses to that using the 'kseg1' window, which occupies the 0xa000.0000-0xbfff.ffff (CPU virtual address) 0x0000.0000-0x1fff.ffff (physical address). There are macros defined for translating a physical address into a kseg1 address (just add 0xa000.0000, really). You could read the book ("See MIPS Run")... -- Dominic Sweetman, MIPS Technologies (UK) - formerly Algorithmics The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From macro@ds2.pg.gda.pl Wed Sep 4 12:50:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 12:50:13 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:44437 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 12:50:12 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA10803; Wed, 4 Sep 2002 12:50:26 +0200 (MET DST) Date: Wed, 4 Sep 2002 12:50:25 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , Matthew Dharm , Linux-MIPS Subject: Re: time.c CP0_COMPARE (and SMP IPI rambling) In-Reply-To: <3D74EA66.6020906@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 73 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 3 Sep 2002, Jun Sun wrote: > Right now setting per-cpu timers is totally left to the board-dependent code. > Once we see more SMP boxes using this approach, I think it starts to be > interesting to make some abstraction and support it in a systematic way, > including support for using CPU counter as the per-cpu timer interrupt. > > Using local_timer_emulation sounds like an attractive alternative to me, as we > only need to set up one system-wide timer interrupt. Conceptually it probably > takes a little longer to run through timer_interrupt (due to IPI calls). But > if the hit on performance is very negligible, the simplicity might make it > worthwile. Well, the i386 approach (with a grain of salt, of course, but it's about the most mature, anyway) seems reasonable. A per-CPU local timer for scheduling (no need to stability or high precision) and an external timer interrupt for timekeeping (this one precise) that's delivered to a single CPU at a time. I hope there are no MIPS SMP systems that lack an external timer IRQ source. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Wed Sep 4 14:58:10 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 14:58:10 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:47512 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 14:58:10 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA12867; Wed, 4 Sep 2002 14:58:27 +0200 (MET DST) Date: Wed, 4 Sep 2002 14:58:26 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Dominic Sweetman cc: Matthew Dharm , Jun Sun , Linux-MIPS Subject: RE: Interrupt handling.... In-Reply-To: <200209040953.KAA17466@mudchute.algor.co.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 74 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Dominic Sweetman wrote: > > Which, as you can see, attempts to access address 0xfc00000c. > > But that address is in the MIPS CPU's 'kseg2' region. Addresses there > are always translated by the TLB, and you haven't got an entry. > > Registers from things like the 2nd level interrupt controller are > memory mapped I/O locations, and you need to do an uncached access to > the appropriate physical address. As I understand 0xfc00000c is the physical address. Thus you cannot reach it via KSEG0/1 (although you may use XKPHYS to get there in the 64-bit mode). Still ioremap() already handles the case mapping the area requested in the KSEG2 space, so it should work just fine. > Most MIPS hardware has registers mapped between 0-512Mbyte > (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses > to that using the 'kseg1' window, which occupies the > > 0xa000.0000-0xbfff.ffff (CPU virtual address) > 0x0000.0000-0x1fff.ffff (physical address). As I understand this is an exception. Possibly the system supports more than 512MB of RAM and the designers wanted to avoid holes. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Wed Sep 4 15:57:05 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 15:57:06 +0200 (CEST) Received: from p508B5F93.dip.t-dialin.net ([80.139.95.147]:16776 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 15:57:05 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g84Dujw32398; Wed, 4 Sep 2002 15:56:45 +0200 Date: Wed, 4 Sep 2002 15:56:45 +0200 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: 64-bit and N32 kernel interfaces Message-ID: <20020904155645.A31893@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 75 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips (I bcc'ed this to a few people; please followup to linux-mips@linux-mips.org. I'd like this to be discussed widely before it's cast into stone as everybody will have to live with this for the years to come.) Right now the 64-bit kernel interfaces are still pretty much an ad-hoc approach and can't be considered frozen. There is now some pressure to come up with a stable 64-bit API asap. As first think I want to get rid of all the historic crap we have in our syscall tables for the 64-bit syscalls. Let's start here: #define __NR_syscall (__NR_Linux + 0) Deprecated because can be implemented in userspace. #define __NR_ioperm (__NR_Linux + 101) #define __NR_iopl (__NR_Linux + 110) #define __NR_vm86 (__NR_Linux + 113) i386 braindamage we're never going to support. So why have it in our syscall table? #define __NR_unused59 (__NR_Linux + 59) #define __NR_reserved82 (__NR_Linux + 82) #define __NR_unused109 (__NR_Linux + 109) #define __NR_unused150 (__NR_Linux + 150) Unused entries. Why keep them ... #define __NR_break (__NR_Linux + 17) #define __NR_stty (__NR_Linux + 31) #define __NR_gtty (__NR_Linux + 32) #define __NR_ftime (__NR_Linux + 35) #define __NR_prof (__NR_Linux + 44) #define __NR_signal (__NR_Linux + 48) #define __NR_mpx (__NR_Linux + 56) #define __NR_ulimit (__NR_Linux + 58) #define __NR_readdir (__NR_Linux + 89) #define __NR_profil (__NR_Linux + 98) #define __NR_modify_ldt (__NR_Linux + 123) Slots that data back to day one of UNIX way before Linux was born. #define __NR_socketcall (__NR_Linux + 102) Wrapper syscall, obsoleted since quite a while in the 32-bit kernel. #define __NR_idle (__NR_Linux + 112) Internal syscall, no longer used. #define __NR_ipc (__NR_Linux + 117) Yet another multiplexor syscall and imho another candidate for getting rid of. #define __NR_oldstat (__NR_Linux + 18) #define __NR_umount (__NR_Linux + 22) #define __NR_oldfstat (__NR_Linux + 28) #define __NR_oldlstat (__NR_Linux + 84) Superseeded by newer versions. #define __NR_uselib (__NR_Linux + 86) a.out support. Do we really want that. I probably missed a few. The primary purpose of this posting is to get a discussion about the 64-bit syscall interface started. It's still not cast into stone so we can modify it as we see fit. The entire syscall interface is still open for changes, this includes all structures etc. Along with a 64-bit ABI we'll also have to deciede about a N32 ABI. Suggestions, comments etc? Ralf From macro@ds2.pg.gda.pl Wed Sep 4 16:22:56 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 16:22:57 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:45722 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 16:22:56 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA14149; Wed, 4 Sep 2002 16:14:14 +0200 (MET DST) Date: Wed, 4 Sep 2002 16:14:13 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020904155645.A31893@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 76 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Ralf Baechle wrote: > Right now the 64-bit kernel interfaces are still pretty much an ad-hoc > approach and can't be considered frozen. There is now some pressure to > come up with a stable 64-bit API asap. Well, they are not really used by anything, yet so they are far from being frozen. > As first think I want to get rid of all the historic crap we have in > our syscall tables for the 64-bit syscalls. Let's start here: [...] Definitely. > I probably missed a few. The primary purpose of this posting is to get a > discussion about the 64-bit syscall interface started. It's still not > cast into stone so we can modify it as we see fit. The entire syscall > interface is still open for changes, this includes all structures etc. > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI. It would be nice if we could keep a single set of syscalls for both (n)64 and n32. The address crop for n32 may be handled the Alpha way. I will investigate the topic soon. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Wed Sep 4 16:36:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 16:36:13 +0200 (CEST) Received: from p508B5F93.dip.t-dialin.net ([80.139.95.147]:46984 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 16:36:12 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g84EV1932767; Wed, 4 Sep 2002 16:31:01 +0200 Date: Wed, 4 Sep 2002 16:31:01 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020904163101.C32519@linux-mips.org> References: <20020904155645.A31893@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Sep 04, 2002 at 04:14:13PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 77 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 04:14:13PM +0200, Maciej W. Rozycki wrote: > > I probably missed a few. The primary purpose of this posting is to get a > > discussion about the 64-bit syscall interface started. It's still not > > cast into stone so we can modify it as we see fit. The entire syscall > > interface is still open for changes, this includes all structures etc. > > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI. > > It would be nice if we could keep a single set of syscalls for both (n)64 > and n32. The address crop for n32 may be handled the Alpha way. I will > investigate the topic soon. Can you describe how this is handled on the Alpha? The primary problem is the differnet calling sequence for o32 and N64. As it looks we'll be able to use either the o32 function or the native syscall to implement all of the necessary N32 syscalls. The question is if we want to reserve another 1000 entries in our already huge syscall table for N32 or if we got a better solution ... Ralf From macro@ds2.pg.gda.pl Wed Sep 4 17:19:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 17:19:27 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:9372 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 17:19:26 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15360; Wed, 4 Sep 2002 17:19:51 +0200 (MET DST) Date: Wed, 4 Sep 2002 17:19:51 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020904163101.C32519@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 78 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Ralf Baechle wrote: > > It would be nice if we could keep a single set of syscalls for both (n)64 > > and n32. The address crop for n32 may be handled the Alpha way. I will > > investigate the topic soon. > > Can you describe how this is handled on the Alpha? I'm referring mostly to OSF/1 here as it was first to implement it. Linux followed it in the sense it is able to execute OSF/1 binaries marked as "32-bit", but native ELF binaries used to be fully 64-bit always. I think by a popular demand GNU binutils are now able to create "cropped" Alpha/Linux ELF binaries as well, but this is unverified for sure. The implementation is two-fold. First, the static linker (if given the "-taso" option) maps an executable into the low 31-bit address space (coincidentally, this will probably be suitable for MIPS as well) and sets a special flag in the executable (it does it in a weird place, but this is ECOFF and we have suitable flags in the ELF header already). Second, seeing the "31-bit" flag set, the kernel returns any maps requested within the low 31-bit address space. This way both shared libraries (which thus need not be special, i.e. may be regular 64-bit ones) and areas allocated by mmap() are addressable by the executable. To summarize, nothing much complicated. > The primary problem is the differnet calling sequence for o32 and N64. But we handle that already. > As it looks we'll be able to use either the o32 function or the native > syscall to implement all of the necessary N32 syscalls. The (n)64 versions seem suitable and the o32 ones do not as n32 only crops addresses to 32-bit -- data may still be 64-bit (e.g. file position pointers). > The question is if we want to reserve another 1000 entries in our already > huge syscall table for N32 or if we got a better solution ... Aaarrgh, no more entries, please... -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Wed Sep 4 17:58:17 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 17:58:18 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:59292 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 17:58:17 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA15948; Wed, 4 Sep 2002 17:57:16 +0200 (MET DST) Date: Wed, 4 Sep 2002 17:57:15 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Ralf Baechle , Karsten Merker , linux-mips@linux-mips.org Subject: [patch] 2.4.19: Support R4000 as a distinct CPU type Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 79 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips Hello, Being an early implementation of a CPU family, R4000 contains a number of interesting "features". One of them is a problem that affects a few variations of shift operations (both 32-bit and 64-bit ones) that are executed after multiply or divide instructions. Under certain circumstances the shifts produce incorrect results. This is documented as erratum #28 in "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0" which is available at the MIPS site (I can't quote it here, sorry, as it's copyrighted material and I failed to get permission from MIPS). There is a partial workaround for the problem implemented in gcc which gets activated if the "-mcpu=r4000" option is passed to the compiler. Recent problems with the kernel when run on an affected CPU led me to complete the multiplication part of the workaround (I'm also working on the division part that is less biting). A suitable patch for 2.95.x is available in mipsel-linux and mips64el-linux cross-gcc packages at my site. But to let gcc activate the workaround, kernel Makefiles must pass the mentioned option. Here is a suitable patch. OK to apply? I would like to express my gratitude to Karsten, who patiently tested on his R4000 system a seemingly endless stream of kernels I fed him until I discovered the reason of a mysterious misbehaviour. Without his help I wouldn't be able to resolve the problem. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.19-rc1-20020807-r4000-0 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/Documentation/Configure.help linux-mips-2.4.19-rc1-20020807/Documentation/Configure.help --- linux-mips-2.4.19-rc1-20020807.macro/Documentation/Configure.help 2002-06-27 02:56:15.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/Documentation/Configure.help 2002-09-02 18:32:45.000000000 +0000 @@ -2196,9 +2196,9 @@ CONFIG_PCMCIA_FDOMAIN # Choice: mipstype CPU type -CONFIG_CPU_R3000 +CONFIG_CPU_MIPS32 Please make sure to pick the right CPU type. Linux/MIPS is not - designed to be generic, i.e. Kernels compiled for R3000 CPUs will + designed to be generic, i.e. kernels compiled for R3000 CPUs will *not* work on R4000 machines and vice versa. However, since most of the supported machines have an R4000 (or similar) CPU, R4x00 might be a safe bet. If the resulting kernel does not work, @@ -2210,10 +2210,12 @@ CONFIG_CPU_R3000 R6000 MIPS Technologies R6000-series processors, including the 64474, 64475, 64574 and 64575. + R4000 MIPS Technologies R4000-series processors. + R4300 MIPS Technologies R4300-series processors. - R4x00 MIPS Technologies R4000-series processors other than 4300, - including the 4640, 4650, and 4700. + R4x00 MIPS Technologies R4xxx-series processors other than 4000 + and 4300, including the 4640, 4650, and 4700. R5000 MIPS Technologies R5000-series processors other than the Nevada. @@ -2227,14 +2229,18 @@ CONFIG_CPU_R6000 MIPS Technologies R6000-series processors, including the 64474, 64475, 64574 and 64575. +R4000 +CONFIG_CPU_R4000 + MIPS Technologies R4000-series processors. + R4300 CONFIG_CPU_R4300 MIPS Technologies R4300-series processors. R4x00 CONFIG_CPU_R4X00 - MIPS Technologies R4000-series processors other than 4300, including - the 4640, 4650, and 4700. + MIPS Technologies R4xxx-series processors other than 4000 and 4300, + including the 4640, 4650, and 4700. R5000 CONFIG_CPU_R5000 diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips/Makefile linux-mips-2.4.19-rc1-20020807/arch/mips/Makefile --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips/Makefile 2002-08-07 02:58:14.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips/Makefile 2002-09-02 18:34:52.000000000 +0000 @@ -57,6 +57,9 @@ endif ifdef CONFIG_CPU_R6000 GCCFLAGS += -mcpu=r6000 -mips2 -Wa,--trap endif +ifdef CONFIG_CPU_R4000 +GCCFLAGS += -mcpu=r4000 -mips2 -Wa,--trap +endif ifdef CONFIG_CPU_R4300 GCCFLAGS += -mcpu=r4300 -mips2 -Wa,--trap endif diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips/config-shared.in linux-mips-2.4.19-rc1-20020807/arch/mips/config-shared.in --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips/config-shared.in 2002-08-07 02:58:14.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips/config-shared.in 2002-09-02 18:59:33.000000000 +0000 @@ -413,6 +413,7 @@ choice 'CPU type' \ MIPS64 CONFIG_CPU_MIPS64 \ R3000 CONFIG_CPU_R3000 \ R39XX CONFIG_CPU_TX39XX \ + R4000 CONFIG_CPU_R4000 \ R41xx CONFIG_CPU_VR41XX \ R4300 CONFIG_CPU_R4300 \ R4x00 CONFIG_CPU_R4X00 \ @@ -447,7 +448,8 @@ if [ "$CONFIG_CPU_SB1" = "y" ]; then define_bool CONFIG_CPU_HAS_PREFETCH y fi -if [ "$CONFIG_CPU_R4X00" = "y" -o \ +if [ "$CONFIG_CPU_R4000" = "y" -o \ + "$CONFIG_CPU_R4X00" = "y" -o \ "$CONFIG_CPU_R5000" = "y" -o \ "$CONFIG_CPU_RM7000" = "y" -o \ "$CONFIG_CPU_R10000" = "y" -o \ diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips/dec/prom/init.c linux-mips-2.4.19-rc1-20020807/arch/mips/dec/prom/init.c --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips/dec/prom/init.c 2002-08-06 02:57:08.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips/dec/prom/init.c 2002-09-02 18:38:37.000000000 +0000 @@ -100,7 +100,7 @@ int __init prom_init(int argc, char **ar } #endif -#if defined(CONFIG_CPU_R4X00) +#if defined(CONFIG_CPU_R4000) || defined(CONFIG_CPU_R4X00) if ((mips_cpu.cputype == CPU_R3000) || (mips_cpu.cputype == CPU_R3000A)) { prom_printf("Sorry, this kernel is compiled for the wrong CPU type!\n"); diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips/mm/Makefile linux-mips-2.4.19-rc1-20020807/arch/mips/mm/Makefile --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips/mm/Makefile 2002-06-26 03:04:37.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips/mm/Makefile 2002-09-02 18:41:00.000000000 +0000 @@ -17,6 +17,7 @@ obj-$(CONFIG_CPU_R3000) += pg-r3k.o c-r tlbex-r3k.o obj-$(CONFIG_CPU_TX39XX) += pg-r3k.o c-tx39.o tlb-r3k.o tlbex-r3k.o obj-$(CONFIG_CPU_TX49XX) += pg-r4k.o c-tx49.o tlb-r4k.o tlbex-r4k.o +obj-$(CONFIG_CPU_R4000) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R4300) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_R4X00) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o obj-$(CONFIG_CPU_VR41XX) += pg-r4k.o c-r4k.o tlb-r4k.o tlbex-r4k.o diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips/mm/loadmmu.c linux-mips-2.4.19-rc1-20020807/arch/mips/mm/loadmmu.c --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips/mm/loadmmu.c 2002-08-06 02:57:32.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips/mm/loadmmu.c 2002-09-02 18:42:30.000000000 +0000 @@ -68,9 +68,9 @@ extern void sb1_tlb_init(void); void __init loadmmu(void) { if (mips_cpu.options & MIPS_CPU_4KTLB) { -#if defined(CONFIG_CPU_R4X00) || defined(CONFIG_CPU_VR41XX) || \ - defined(CONFIG_CPU_R4300) || defined(CONFIG_CPU_R5000) || \ - defined(CONFIG_CPU_NEVADA) +#if defined(CONFIG_CPU_R4000) || defined(CONFIG_CPU_VR41XX) || \ + defined(CONFIG_CPU_R4300) || defined(CONFIG_CPU_R4X00) || \ + defined(CONFIG_CPU_R5000) || defined(CONFIG_CPU_NEVADA) ld_mmu_r4xx0(); r4k_tlb_init(); #endif diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/Makefile linux-mips-2.4.19-rc1-20020807/arch/mips64/Makefile --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/Makefile 2002-08-07 02:58:22.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips64/Makefile 2002-09-02 18:45:02.000000000 +0000 @@ -46,6 +46,9 @@ endif # # CPU-dependent compiler/assembler options for optimization. # +ifdef CONFIG_CPU_R4000 +GCCFLAGS += -mcpu=r4000 -mips3 +endif ifdef CONFIG_CPU_R4300 GCCFLAGS += -mcpu=r4300 -mips3 endif diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/mm/Makefile linux-mips-2.4.19-rc1-20020807/arch/mips64/mm/Makefile --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/mm/Makefile 2002-07-25 02:57:02.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips64/mm/Makefile 2002-09-02 18:45:30.000000000 +0000 @@ -9,6 +9,7 @@ O_TARGET := mm.o export-objs += umap.o obj-y := extable.o init.o fault.o loadmmu.o +obj-$(CONFIG_CPU_R4000) += r4xx0.o tlbex-r4k.o tlb-glue-r4k.o obj-$(CONFIG_CPU_R4300) += r4xx0.o tlbex-r4k.o tlb-glue-r4k.o obj-$(CONFIG_CPU_R4X00) += r4xx0.o tlbex-r4k.o tlb-glue-r4k.o obj-$(CONFIG_CPU_R5000) += r4xx0.o tlbex-r4k.o tlb-glue-r4k.o diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/mm/loadmmu.c linux-mips-2.4.19-rc1-20020807/arch/mips64/mm/loadmmu.c --- linux-mips-2.4.19-rc1-20020807.macro/arch/mips64/mm/loadmmu.c 2002-08-06 02:57:39.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/arch/mips64/mm/loadmmu.c 2002-09-02 18:46:37.000000000 +0000 @@ -60,7 +60,8 @@ extern void r4k_tlb_init(void); void __init load_mmu(void) { if (mips_cpu.options & MIPS_CPU_4KTLB) { -#if defined (CONFIG_CPU_R4300) \ +#if defined (CONFIG_CPU_R4000) \ + || defined (CONFIG_CPU_R4300) \ || defined (CONFIG_CPU_R4X00) \ || defined (CONFIG_CPU_R5000) \ || defined (CONFIG_CPU_NEVADA) diff -up --recursive --new-file linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/addrspace.h linux-mips-2.4.19-rc1-20020807/include/asm-mips64/addrspace.h --- linux-mips-2.4.19-rc1-20020807.macro/include/asm-mips64/addrspace.h 2002-08-22 06:18:02.000000000 +0000 +++ linux-mips-2.4.19-rc1-20020807/include/asm-mips64/addrspace.h 2002-09-02 19:00:37.000000000 +0000 @@ -82,7 +82,8 @@ #define CKSSEG 0xffffffffc0000000 #define CKSEG3 0xffffffffe0000000 -#if defined (CONFIG_CPU_R4300) \ +#if defined (CONFIG_CPU_R4000) \ + || defined (CONFIG_CPU_R4300) \ || defined (CONFIG_CPU_R4X00) \ || defined (CONFIG_CPU_R5000) \ || defined (CONFIG_CPU_NEVADA) \ From mdharm@host099.momenco.com Wed Sep 4 18:36:55 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 18:36:55 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:43015 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 18:36:55 +0200 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g84GaST05268; Wed, 4 Sep 2002 09:36:28 -0700 Date: Wed, 4 Sep 2002 09:36:27 -0700 From: Matthew Dharm To: "Maciej W. Rozycki" Cc: Dominic Sweetman , Jun Sun , Linux-MIPS Subject: Re: Interrupt handling.... Message-ID: <20020904093627.A5241@momenco.com> References: <200209040953.KAA17466@mudchute.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Sep 04, 2002 at 02:58:26PM +0200 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 80 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 02:58:26PM +0200, Maciej W. Rozycki wrote: > On Wed, 4 Sep 2002, Dominic Sweetman wrote: > > > > Which, as you can see, attempts to access address 0xfc00000c. > > > > But that address is in the MIPS CPU's 'kseg2' region. Addresses there > > are always translated by the TLB, and you haven't got an entry. > > > > Registers from things like the 2nd level interrupt controller are > > memory mapped I/O locations, and you need to do an uncached access to > > the appropriate physical address. > > As I understand 0xfc00000c is the physical address. Thus you cannot > reach it via KSEG0/1 (although you may use XKPHYS to get there in the > 64-bit mode). Still ioremap() already handles the case mapping the area > requested in the KSEG2 space, so it should work just fine. This is the case. The board itself has up to 1G of SDRAM. Most of the boards we sell have a minimum of 512MB. So our I/O (PCI, external devices, etc.) all have physical addresses in the high-end of the address space. 64-bit mode would be great... and we plan to go there eventually. But, for now, 32-bit is where we are. > > Most MIPS hardware has registers mapped between 0-512Mbyte > > (0-0x1fff.ffff) physical, because a MIPS CPU can do uncached accesses > > to that using the 'kseg1' window, which occupies the > > > > 0xa000.0000-0xbfff.ffff (CPU virtual address) > > 0x0000.0000-0x1fff.ffff (physical address). > > As I understand this is an exception. Possibly the system supports more > than 512MB of RAM and the designers wanted to avoid holes. This is exactly the case. Our organization focuses on high-end computing platforms. 512MB is becoming a minimum amount of memory for us. Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From mdharm@host099.momenco.com Wed Sep 4 18:40:23 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 18:40:24 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:44295 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 18:40:23 +0200 Received: (from mdharm@localhost) by host099.momenco.com (8.11.6/8.11.6) id g84GeEm05306; Wed, 4 Sep 2002 09:40:14 -0700 Date: Wed, 4 Sep 2002 09:40:14 -0700 From: Matthew Dharm To: Dominic Sweetman Cc: Jun Sun , Linux-MIPS Subject: Re: Interrupt handling.... Message-ID: <20020904094014.B5241@momenco.com> References: <3D6E87EB.4010000@mvista.com> <200209040953.KAA17466@mudchute.algor.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200209040953.KAA17466@mudchute.algor.co.uk>; from dom@algor.co.uk on Wed, Sep 04, 2002 at 10:53:55AM +0100 Organization: Momentum Computer, Inc. X-Copyright: (C) 2002 Matthew Dharm, all rights reserved. Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 81 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 10:53:55AM +0100, Dominic Sweetman wrote: > > Matthew, > > > Okay... I think I've got a problem that isn't covered by the usual > > examples. > > Possibly this is too simple an answer and is stuff you know quite well > already... Yeah, it is. See my response to Maciej's posting.... > > Which, as you can see, attempts to access address 0xfc00000c. > > But that address is in the MIPS CPU's 'kseg2' region. Addresses there > are always translated by the TLB, and you haven't got an entry. It's also the physical address. And this is the heart of the problem. I set up an ioremap, so I thought that the TLB exception handler would fix this for me. It looks like that code won't do anything if the exception was generated from an interrupt... Or am I reading it wrong? I'm not an expert on the TLB code... > You could read the book ("See MIPS Run")... I read it quite some time ago. My copy got very dog-eared before I had the majority of the information committed to memory. Nice book, BTW. Matt -- Matthew Dharm Work: mdharm@momenco.com Senior Software Designer, Momentum Computer From macro@ds2.pg.gda.pl Wed Sep 4 19:02:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 19:02:28 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:4766 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 19:02:28 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA17134; Wed, 4 Sep 2002 19:02:45 +0200 (MET DST) Date: Wed, 4 Sep 2002 19:02:45 +0200 (MET DST) From: "Maciej W. Rozycki" To: Matthew Dharm cc: Dominic Sweetman , Jun Sun , Linux-MIPS Subject: Re: Interrupt handling.... In-Reply-To: <20020904094014.B5241@momenco.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 82 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Matthew Dharm wrote: > And this is the heart of the problem. I set up an ioremap, so I thought > that the TLB exception handler would fix this for me. It looks like that > code won't do anything if the exception was generated from an interrupt... > Or am I reading it wrong? I'm not an expert on the TLB code... The kernel memory is unswappable so a PTE is always available. If the TLB refill handler cannot fetch it for some reason, then there is a bug somewhere. It might be helpful if you narrowed it down a bit -- refills work correctly for modules, including interrupt handlers, and they reside in KSEG2. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From werkt@csh.rit.edu Wed Sep 4 19:21:48 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 19:21:49 +0200 (CEST) Received: from [129.21.60.9] ([129.21.60.9]:20460 "EHLO mcp.csh.rit.edu") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 19:21:48 +0200 Received: from csh.rit.edu (unknown [129.21.61.133]) by mcp.csh.rit.edu (Postfix) with ESMTP id 4B31A4376; Wed, 4 Sep 2002 13:21:28 -0400 (EDT) Message-ID: <3D7678C8.3020505@csh.rit.edu> Date: Wed, 04 Sep 2002 17:19:04 -0400 From: George Gensure User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: root-nfs hang and error References: <20020903.163711.104027127.nemoto@toshiba-tops.co.jp> <3D752698.5040907@csh.rit.edu> <20020904.103601.74754748.nemoto@toshiba-tops.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 83 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: werkt@csh.rit.edu Precedence: bulk X-list: linux-mips > > >So "ip=" and "nfsroot=" options may be >required on diskless boot. > I'm actually good for that, I'm using nfsroot=: and the errors that come back correspond to the right host. I know the ramdisk is used on the install, but I'm wondering if your nolock solution corresponds to the problem with the kernel mounting the nfsroot (i.e. it doesn't use it). BTW, the root mounted flawlessly onto target, thanks for the nolock option. -George From jsun@mvista.com Wed Sep 4 19:44:10 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 19:44:10 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:50935 "EHLO av.mvista.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 19:44:10 +0200 Received: from mvista.com (av [127.0.0.1]) by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA23039; Wed, 4 Sep 2002 10:44:01 -0700 Message-ID: <3D7643BA.6090807@mvista.com> Date: Wed, 04 Sep 2002 10:32:42 -0700 From: Jun Sun User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle CC: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces References: <20020904155645.A31893@linux-mips.org> <20020904163101.C32519@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 84 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Wed, Sep 04, 2002 at 04:14:13PM +0200, Maciej W. Rozycki wrote: > > The primary problem is the differnet calling sequence for o32 and N64. > As it looks we'll be able to use either the o32 function or the native > syscall to implement all of the necessary N32 syscalls. For 64bit kernel, do we intend to have one syscall table that support o32, n32 and n64 altogether? Or we will have multiple tables for them? > > The question is if we want to reserve another 1000 entries in our already > huge syscall table for N32 or if we got a better solution ... > It seems n32 can be naturally implemented through n64 syscalls, although I am sure there are some nasty details to work out. Where can I find n32/n64 spec? Jun From macro@ds2.pg.gda.pl Wed Sep 4 19:55:44 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 19:55:45 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:17311 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 19:55:44 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA18246; Wed, 4 Sep 2002 19:56:05 +0200 (MET DST) Date: Wed, 4 Sep 2002 19:56:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <3D7643BA.6090807@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 85 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Jun Sun wrote: > For 64bit kernel, do we intend to have one syscall table that support o32, n32 > and n64 altogether? Or we will have multiple tables for them? There are two tables now, one for o32, currently used when executing o32 userland and the other one ready for native userland. They can't be unified as their semantics differ. > Where can I find n32/n64 spec? Search 'http://techpubs.sgi.com/' and see 'ftp://oss.sgi.com/pub/linux/mips/doc/ABI/'. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From mdharm@momenco.com Wed Sep 4 20:16:55 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 20:16:56 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:58119 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 20:16:55 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g84IGb605836; Wed, 4 Sep 2002 11:16:37 -0700 From: "Matthew Dharm" To: "Maciej W. Rozycki" Cc: "Dominic Sweetman" , "Jun Sun" , "Linux-MIPS" Subject: RE: Interrupt handling.... Date: Wed, 4 Sep 2002 11:16:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 86 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Okay... What type of information do you need? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl] > Sent: Wednesday, September 04, 2002 10:03 AM > To: Matthew Dharm > Cc: Dominic Sweetman; Jun Sun; Linux-MIPS > Subject: Re: Interrupt handling.... > > > On Wed, 4 Sep 2002, Matthew Dharm wrote: > > > And this is the heart of the problem. I set up an > ioremap, so I thought > > that the TLB exception handler would fix this for me. It > looks like that > > code won't do anything if the exception was generated > from an interrupt... > > Or am I reading it wrong? I'm not an expert on the TLB code... > > The kernel memory is unswappable so a PTE is always > available. If the > TLB refill handler cannot fetch it for some reason, then > there is a bug > somewhere. It might be helpful if you narrowed it down a > bit -- refills > work correctly for modules, including interrupt handlers, > and they reside > in KSEG2. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > From nop@nop.com Wed Sep 4 20:19:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 20:19:10 +0200 (CEST) Received: from place.org ([65.163.18.18]:26772 "EHLO zachs.place.org") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 20:19:09 +0200 Received: by zachs.place.org (Postfix, from userid 1002) id BA443181F4; Wed, 4 Sep 2002 13:19:00 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zachs.place.org (Postfix) with ESMTP id B87F8180FD; Wed, 4 Sep 2002 13:19:00 -0500 (CDT) Date: Wed, 4 Sep 2002 13:19:00 -0500 (CDT) From: Jay Carlson X-X-Sender: nop@zachs.place.org To: Daniel Jacobowitz Cc: linux-mips@linux-mips.org Subject: Re: soft-float defines in mips-linux gcc config In-Reply-To: <20020903191536.GA28999@nevyn.them.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 87 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nop@nop.com Precedence: bulk X-list: linux-mips On Tue, 3 Sep 2002, Daniel Jacobowitz wrote: > On Tue, Sep 03, 2002 at 08:26:37AM -0400, Jay Carlson wrote: > > Right now there is a small bug in how mips-linux configures gcc for > > softfloat. > > > > In gcc/config/mips/t-linux, we set up libgcc to include the soft > > floating point code, using the GNU names, like __addsi3. But because > > mips/linux.h includes mips/ecoff.h, gcc produces calls to the GOFAST > > style names (like dpmul, very namespace-contaminating.) > > > > mips/netbsd.h cleans up after mips/elf.h by doing: > > > > #undef US_SOFTWARE_GOFAST > > #undef INIT_SUBTARGET_OPTABS > > #define INIT_SUBTARGET_OPTABS > > > > which would fix the problem for mips/linux.h as well. > > When commenting on GCC issues, please say which version you're talking > about - It was 3.2; was in a hurry to get this written down before I commuted and forgot about it. > I'm pretty sure this is fixed in 3.2, Scene: Jay, the cartoon character, chasing cartoon bug. Bug runs off cliff, disappears from thin air. Jay keeps on running, until he notices the bug's gone, and he's standing on thin air. Oops. After I actually peered at the output of cc1 from 3.2, I agree, you're right, the bug is fixed. I was so used to forward-porting this patch from revision to revision that I applied this without even checking whether it was necessary. What I don't understand is *how* the bug got fixed. It looks like the OPTABS should still set us up for the GOFAST library. Oh well, can't argue with working code. I wish the "-fdata-sections doesn't apply to C++ .bss" bug would get fixed while I'm not looking too...although that one might take some arguing about for people who are stuck on truly ancient binutils. Jay From jensenq@Lineo.COM Wed Sep 4 20:27:33 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 20:27:34 +0200 (CEST) Received: from gk2-ext.lineo.com ([64.50.107.253]:6926 "HELO stereotomy.lineo.com") by linux-mips.org with SMTP id ; Wed, 4 Sep 2002 20:27:33 +0200 Received: from Lineo.COM (vpn1 [10.9.8.1]) by stereotomy.lineo.com (Postfix) with ESMTP id 9AD2F4C2C0 for ; Wed, 4 Sep 2002 12:27:21 -0600 (MDT) Message-ID: <3D765072.60208@Lineo.COM> Date: Wed, 04 Sep 2002 12:26:58 -0600 From: Quinn Jensen Organization: Lineo, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: patch to kaweth.c to align IP header Content-Type: multipart/mixed; boundary="------------010208040308010206050609" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 88 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jensenq@Lineo.COM Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------010208040308010206050609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, The Kawasaki LSI USB Ethernet driver was causing a crash in ipt_do_table() on mips because the address fields in the IP header were not word aligned. Many (all?) other ethernet drivers do an skb_reserve of 2 to word align the address fields, and doing this in kaweth.c fixed my crash. kernel: 2.4.17 hardware: Netgear EA101 USB Ethernet Quinn --------------010208040308010206050609 Content-Type: text/plain; name="linuxtx-kaweth.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linuxtx-kaweth.patch" diff -puN -r -X - linux/drivers/usb/kaweth.c linux.modified/drivers/usb/kaweth.c --- linux/drivers/usb/kaweth.c Tue Nov 13 10:19:41 2001 +++ linux.modified/drivers/usb/kaweth.c Tue Sep 3 16:07:08 2002 @@ -514,6 +514,7 @@ static void kaweth_usb_receive(struct ur skb->dev = net; + skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */ eth_copy_and_sum(skb, kaweth->rx_buf + 2, pkt_len, 0); skb_put(skb, pkt_len); --------------010208040308010206050609-- From ralf@linux-mips.org Wed Sep 4 20:40:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 20:40:53 +0200 (CEST) Received: from p508B5F93.dip.t-dialin.net ([80.139.95.147]:31115 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 20:40:52 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g84Iec602714; Wed, 4 Sep 2002 20:40:38 +0200 Date: Wed, 4 Sep 2002 20:40:38 +0200 From: Ralf Baechle To: Jun Sun Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020904204038.D1121@linux-mips.org> References: <20020904155645.A31893@linux-mips.org> <20020904163101.C32519@linux-mips.org> <3D7643BA.6090807@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D7643BA.6090807@mvista.com>; from jsun@mvista.com on Wed, Sep 04, 2002 at 10:32:42AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 89 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 10:32:42AM -0700, Jun Sun wrote: > > The primary problem is the differnet calling sequence for o32 and N64. > > As it looks we'll be able to use either the o32 function or the native > > syscall to implement all of the necessary N32 syscalls. > > For 64bit kernel, do we intend to have one syscall table that support o32, > n32 and n64 altogether? Or we will have multiple tables for them? Several approach to solve that problem. Adding another 1000 entries - which will cost 8000 bytes of memory that will be mostly zeros. Having wrappers for each function that do the appropriate argument and result convertion is another. etc. > > The question is if we want to reserve another 1000 entries in our already > > huge syscall table for N32 or if we got a better solution ... > > It seems n32 can be naturally implemented through n64 syscalls, although I am > sure there are some nasty details to work out. Unfortunately there are ... > Where can I find n32/n64 spec? mipsabi.org which is no longer online. Anyway, I don't think there is a formal published N32 spec. And this whole thread is about the syscall interface. That isn't part of any ABI spec. Ralf From ralf@linux-mips.org Wed Sep 4 20:46:34 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 20:46:34 +0200 (CEST) Received: from p508B5F93.dip.t-dialin.net ([80.139.95.147]:35467 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 20:46:34 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g84IkMq02793; Wed, 4 Sep 2002 20:46:22 +0200 Date: Wed, 4 Sep 2002 20:46:22 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020904204622.D32519@linux-mips.org> References: <20020904163101.C32519@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Wed, Sep 04, 2002 at 05:19:51PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 90 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 05:19:51PM +0200, Maciej W. Rozycki wrote: > > The primary problem is the differnet calling sequence for o32 and N64. > > But we handle that already. Well, N32 is yet another case. Have to look into details again but some MIPS guy recently pointed out to me that there are a few syscalls which for N32 cannot be handled by the o32 or N64 syscall entry as they are right now. > > The question is if we want to reserve another 1000 entries in our already > > huge syscall table for N32 or if we got a better solution ... > > Aaarrgh, no more entries, please... Understandable reflex :) Btw, I did just chat with a Redhat guy. They say they're basically finished and are just waiting for us. Which means we need to deciede fast ... I'll be on the Linux Kongress for the next few days so I'll not be able to answer as quickly as I'd like to but I'll try to read me email as often as I can. Ralf From dom@mudchute.algor.co.uk Wed Sep 4 22:08:50 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 22:08:51 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:48625 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 22:08:50 +0200 Received: from mudchute.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g84K8Or29068; Wed, 4 Sep 2002 21:08:24 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id VAA25407; Wed, 4 Sep 2002 21:08:18 +0100 (BST) Date: Wed, 4 Sep 2002 21:08:18 +0100 (BST) Message-Id: <200209042008.VAA25407@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dharm Cc: "Maciej W. Rozycki" , Dominic Sweetman , Jun Sun , Linux-MIPS Subject: Re: Interrupt handling.... In-Reply-To: <20020904093627.A5241@momenco.com> References: <200209040953.KAA17466@mudchute.algor.co.uk> <20020904093627.A5241@momenco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 91 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Matthew Dharm (mdharm@momenco.com) writes: > > As I understand 0xfc00000c is the physical address. Thus you cannot > > reach it via KSEG0/1 (although you may use XKPHYS to get there in the > > 64-bit mode). Still ioremap() already handles the case mapping the area > > requested in the KSEG2 space, so it should work just fine. > > This is the case. The board itself has up to 1G of SDRAM. Most of the > boards we sell have a minimum of 512MB. So our I/O (PCI, external devices, > etc.) all have physical addresses in the high-end of the address space. Well, next time, get your board designers to think before they map... It's generally better to map some DRAM low (for boot ROMs and other stupid programs you don't want to make big-address aware), then remap the whole DRAM to some very high address for Linux. Much better than forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get at I/O. > 64-bit mode would be great... Bear in mind that there *isn't a 64-bit mode*. Privileged code (which is everything except Linux applications) can always run 64-bit instructions; all addresses are 64-bits really, it's just the sign-extension of the registers which makes you think you've got 32-bit pointers. Usually a 64-bit CPU can access XKPHYS any time it can access I/O registers. -- Dominic Sweetman, MIPS Technologies (UK) - formerly Algorithmics The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From mdharm@momenco.com Wed Sep 4 22:29:35 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 04 Sep 2002 22:29:36 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:7688 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 4 Sep 2002 22:29:35 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g84KTO606530; Wed, 4 Sep 2002 13:29:24 -0700 From: "Matthew Dharm" To: "Linux-MIPS" , "Ralf Baechle" Subject: PATCH: new probe addresses for M-Systems DiskOnChip for Ocelot-G Date: Wed, 4 Sep 2002 13:29:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C25417.15ABB230" 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 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 92 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C25417.15ABB230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The attached patch adds the probe addresses for the M-Systems DiskOnChip which is part of the Ocelot-G board. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_0008_01C25417.15ABB230 Content-Type: application/octet-stream; name="patch20020903" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch20020903" Index: drivers/mtd/devices/docprobe.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/drivers/mtd/devices/docprobe.c,v=0A= retrieving revision 1.3=0A= diff -u -u -r1.3 docprobe.c=0A= --- drivers/mtd/devices/docprobe.c 2001/11/05 20:15:52 1.3=0A= +++ drivers/mtd/devices/docprobe.c 2002/09/03 21:37:19=0A= @@ -88,6 +88,9 @@=0A= 0xe4000000,=0A= #elif defined(CONFIG_MOMENCO_OCELOT)=0A= 0x2f000000,=0A= + 0xff000000,=0A= +#elif defined(CONFIG_MOMENCO_OCELOT_G)=0A= + 0xff000000,=0A= #else=0A= #warning Unknown architecture for DiskOnChip. No default probe = locations defined=0A= #endif=0A= ------=_NextPart_000_0008_01C25417.15ABB230-- From alan@lxorguk.ukuu.org.uk Thu Sep 5 01:33:42 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 01:33:43 +0200 (CEST) Received: from pc1-cwma1-5-cust128.swa.cable.ntl.com ([80.5.120.128]:10998 "EHLO irongate.swansea.linux.org.uk") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 01:33:42 +0200 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id g84NYN30004596; Thu, 5 Sep 2002 00:34:24 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id g84NYLur004593; Thu, 5 Sep 2002 00:34:21 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: patch to kaweth.c to align IP header From: Alan Cox To: Quinn Jensen Cc: linux-mips@linux-mips.org In-Reply-To: <3D765072.60208@Lineo.COM> References: <3D765072.60208@Lineo.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-6) Date: 05 Sep 2002 00:34:21 +0100 Message-Id: <1031182461.3017.137.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 93 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips On Wed, 2002-09-04 at 19:26, Quinn Jensen wrote: > All, > > The Kawasaki LSI USB Ethernet driver was causing a crash > in ipt_do_table() on mips because the address fields in > the IP header were not word aligned. Many (all?) other You -must- handle alignment traps in the kernel for networking. The network code assumes and relies on this property and there are plenty of other ways to get misaligned datagrams through things like ip in ip. > ethernet drivers do an skb_reserve of 2 to word align > the address fields, and doing this in kaweth.c fixed > my crash. Its not the crash fix, its however right in the sense its a good performance optimisation for most platforms From carstenl@mips.com Thu Sep 5 08:41:33 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 08:41:34 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:34018 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 08:41:33 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g856emXb012593; Wed, 4 Sep 2002 23:40:49 -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 XAA00256; Wed, 4 Sep 2002 23:40:44 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g856eib08243; Thu, 5 Sep 2002 08:40:44 +0200 (MEST) Message-ID: <3D76FC6B.C9AA72F3@mips.com> Date: Thu, 05 Sep 2002 08:40:43 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 94 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips "Maciej W. Rozycki" wrote: > On Wed, 4 Sep 2002, Ralf Baechle wrote: > > > > It would be nice if we could keep a single set of syscalls for both (n)64 > > > and n32. The address crop for n32 may be handled the Alpha way. I will > > > investigate the topic soon. > > > > Can you describe how this is handled on the Alpha? > > I'm referring mostly to OSF/1 here as it was first to implement it. > Linux followed it in the sense it is able to execute OSF/1 binaries marked > as "32-bit", but native ELF binaries used to be fully 64-bit always. I > think by a popular demand GNU binutils are now able to create "cropped" > Alpha/Linux ELF binaries as well, but this is unverified for sure. The > implementation is two-fold. > > First, the static linker (if given the "-taso" option) maps an executable > into the low 31-bit address space (coincidentally, this will probably be > suitable for MIPS as well) and sets a special flag in the executable (it > does it in a weird place, but this is ECOFF and we have suitable flags in > the ELF header already). > > Second, seeing the "31-bit" flag set, the kernel returns any maps > requested within the low 31-bit address space. This way both shared > libraries (which thus need not be special, i.e. may be regular 64-bit > ones) and areas allocated by mmap() are addressable by the executable. > > To summarize, nothing much complicated. > > > The primary problem is the differnet calling sequence for o32 and N64. > > But we handle that already. > > > As it looks we'll be able to use either the o32 function or the native > > syscall to implement all of the necessary N32 syscalls. > > The (n)64 versions seem suitable and the o32 ones do not as n32 only > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position > pointers). > Please notice, that a 'long' is 32-bit for n32, so we need to do the same conversion for a lot of syscalls, as we already do for o32. > > > The question is if we want to reserve another 1000 entries in our already > > huge syscall table for N32 or if we got a better solution ... > > Aaarrgh, no more entries, please... > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + -- _ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527 | \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555 TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556 Denmark http://www.mips.com From carsten.lange@detewe.de Thu Sep 5 08:51:35 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 08:51:35 +0200 (CEST) Received: from dtwse201.detewe.de ([195.50.171.201]:22024 "EHLO dtwse201.detewe.de") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 08:51:35 +0200 Received: from zinse043.detewe.de (unverified) by dtwse201.detewe.de (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Sep 2002 08:52:10 +0200 Received: from detewe.de ([172.30.201.153]) by zinse043.detewe.de (Netscape Messaging Server 3.6) with ESMTP id AAA13F; Thu, 5 Sep 2002 08:50:30 +0200 Message-ID: <3D76FEE7.D1DA2D99@detewe.de> Date: Thu, 05 Sep 2002 08:51:19 +0200 From: Carsten Lange X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: gdbserver (gdb 5.2) with thread supprt Content-Type: multipart/mixed; boundary="------------41E73B4BC5F3208D24B4F27B" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 95 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Carsten.Lange@detewe.de Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------41E73B4BC5F3208D24B4F27B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, gdbserver from gdb 5.2 does not work for applications using threads, for others it works fine. I wonder whether gdbserver supports threads and what I have to do to set it up (e.g where to get the patch)? Any hints? Many thanks Carsten --------------41E73B4BC5F3208D24B4F27B Content-Type: text/x-vcard; charset=us-ascii; name="Carsten.Lange.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Carsten Lange Content-Disposition: attachment; filename="Carsten.Lange.vcf" begin:vcard n:Lange;Carsten tel;fax:+49 30 6104 4234 tel;work:+49 30 6104 4228 x-mozilla-html:FALSE url:http://www.detewe.de org:Cordless Technology A/S Berlin adr:;;Koepenicker Str. 180;10997 Berlin;;;Germany version:2.1 email;internet:Carsten.Lange@detewe.de x-mozilla-cpt:;2592 fn:Carsten Lange end:vcard --------------41E73B4BC5F3208D24B4F27B-- From kevink@mips.com Thu Sep 5 10:24:00 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 10:24:01 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:56038 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 10:24:00 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g858NoXb012988; Thu, 5 Sep 2002 01:23:50 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA04847; Thu, 5 Sep 2002 01:23:35 -0700 (PDT) Message-ID: <008d01c254b5$d7398500$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Alan Cox" , "Quinn Jensen" Cc: References: <3D765072.60208@Lineo.COM> <1031182461.3017.137.camel@irongate.swansea.linux.org.uk> Subject: Re: patch to kaweth.c to align IP header Date: Thu, 5 Sep 2002 10:23:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 96 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "Alan Cox" To: "Quinn Jensen" Cc: Sent: Thursday, September 05, 2002 1:34 AM Subject: Re: patch to kaweth.c to align IP header > On Wed, 2002-09-04 at 19:26, Quinn Jensen wrote: > > All, > > > > The Kawasaki LSI USB Ethernet driver was causing a crash > > in ipt_do_table() on mips because the address fields in > > the IP header were not word aligned. Many (all?) other > > You -must- handle alignment traps in the kernel for networking. The > network code assumes and relies on this property and there are plenty of > other ways to get misaligned datagrams through things like ip in ip. > > > ethernet drivers do an skb_reserve of 2 to word align > > the address fields, and doing this in kaweth.c fixed > > my crash. > > Its not the crash fix, its however right in the sense its a good > performance optimisation for most platforms It is true that, due to the unfortunate lack of foresight in the design of IP, no pre-alignment of buffers will *guarantee* that the address or other fields of IP headers will be aligned. But I note that a design which assumes, for non x86 CPUs, that unaligned references will be handled by a kernel trap handler had darn well better assure itself that the misaligned case is extemely infrequent. Otherwise, it would be a distinctly better design to extract all multi-byte IP header values using a macro which could map to a direct, possibly unaligned, load for CISC architectures, and to appropriate sequences of instructions for RISC architectures. I haven't measured the alignment fault path for MIPS/Linux (in any case, MIPS isn't the only architecture affected here), but if we assume for the sake of the argument that it's 50 instructions, and that an unaligned halfword costs 4 inline instructions (lbu,lbu,sll,or), then using the unaligned reference trap as a crutch is a win only if the fields are correctly aligned roughtly 94% of the time. If full 32-bit or 64-bit words are being extracted, a MIPS CPU can do the unaligned accesses in only 2 in-line instructions, which would push the breakeven point out even further. Does anyone have any actual statistical data on the cost and frequency of this use of the unaligned access fixup? Regards, Kevin K. From carstenl@mips.com Thu Sep 5 10:57:59 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 10:58:00 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:15592 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 10:57:59 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g858vnXb013136; Thu, 5 Sep 2002 01:57:49 -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 BAA06615; Thu, 5 Sep 2002 01:57:37 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g858vcb23913; Thu, 5 Sep 2002 10:57:38 +0200 (MEST) Message-ID: <3D771C7F.F6E7EBB5@mips.com> Date: Thu, 05 Sep 2002 10:57:35 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: "Kevin D. Kissell" CC: Alan Cox , Quinn Jensen , linux-mips@linux-mips.org Subject: Re: patch to kaweth.c to align IP header References: <3D765072.60208@Lineo.COM> <1031182461.3017.137.camel@irongate.swansea.linux.org.uk> <008d01c254b5$d7398500$10eca8c0@grendel> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 97 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips "Kevin D. Kissell" wrote: > ----- Original Message ----- > From: "Alan Cox" > To: "Quinn Jensen" > Cc: > Sent: Thursday, September 05, 2002 1:34 AM > Subject: Re: patch to kaweth.c to align IP header > > > On Wed, 2002-09-04 at 19:26, Quinn Jensen wrote: > > > All, > > > > > > The Kawasaki LSI USB Ethernet driver was causing a crash > > > in ipt_do_table() on mips because the address fields in > > > the IP header were not word aligned. Many (all?) other > > > > You -must- handle alignment traps in the kernel for networking. The > > network code assumes and relies on this property and there are plenty of > > other ways to get misaligned datagrams through things like ip in ip. > > > > > ethernet drivers do an skb_reserve of 2 to word align > > > the address fields, and doing this in kaweth.c fixed > > > my crash. > > > > Its not the crash fix, its however right in the sense its a good > > performance optimisation for most platforms > > It is true that, due to the unfortunate lack of foresight in the > design of IP, no pre-alignment of buffers will *guarantee* > that the address or other fields of IP headers will be aligned. > > But I note that a design which assumes, for non x86 CPUs, > that unaligned references will be handled by a kernel trap > handler had darn well better assure itself that the misaligned > case is extemely infrequent. Otherwise, it would be a distinctly > better design to extract all multi-byte IP header values using > a macro which could map to a direct, possibly unaligned, > load for CISC architectures, and to appropriate sequences > of instructions for RISC architectures. I haven't measured > the alignment fault path for MIPS/Linux (in any case, MIPS > isn't the only architecture affected here), but if we assume for > the sake of the argument that it's 50 instructions, and that an > unaligned halfword costs 4 inline instructions (lbu,lbu,sll,or), > then using the unaligned reference trap as a crutch is a win > only if the fields are correctly aligned roughtly 94% of the time. > > If full 32-bit or 64-bit words are being extracted, a MIPS CPU > can do the unaligned accesses in only 2 in-line instructions, > which would push the breakeven point out even further. > > Does anyone have any actual statistical data on the cost > and frequency of this use of the unaligned access fixup? > There is implemented a counter in the unaligned exception handler, you used to get hold of the value through /proc/cpuinfo, but this has apparently been removed from the latest kernels. > > Regards, > > Kevin K. -- _ _ ____ ___ 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 macro@ds2.pg.gda.pl Thu Sep 5 11:03:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 11:03:59 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:55477 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 11:03:58 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA02559; Thu, 5 Sep 2002 11:04:15 +0200 (MET DST) Date: Thu, 5 Sep 2002 11:04:14 +0200 (MET DST) From: "Maciej W. Rozycki" To: Matthew Dharm cc: Dominic Sweetman , Jun Sun , Linux-MIPS Subject: RE: Interrupt handling.... In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 98 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Matthew Dharm wrote: > Okay... What type of information do you need? Well, first check if a PTE is indeed installed by ioremap() in the table. If so, the what happens at the access time -- what exceptions, what are the contents of the related registers, what does exist in the TLB, etc. You don't need to go to the IRQ handler at first -- it might be easier to get such things if you deliberately access the location from elsewhere, e.g. from the setup code right after ioremap(). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Sep 5 11:17:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 11:17:16 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:20918 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 11:17:15 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA02844; Thu, 5 Sep 2002 11:17:33 +0200 (MET DST) Date: Thu, 5 Sep 2002 11:17:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Dominic Sweetman cc: Matthew Dharm , Jun Sun , Linux-MIPS Subject: Re: Interrupt handling.... In-Reply-To: <200209042008.VAA25407@mudchute.algor.co.uk> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 99 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Dominic Sweetman wrote: > Well, next time, get your board designers to think before they map... > > It's generally better to map some DRAM low (for boot ROMs and other > stupid programs you don't want to make big-address aware), then remap > the whole DRAM to some very high address for Linux. Much better than > forcing you to use the TLB (or XKPHYS, if you've a 64-bit CPU) to get > at I/O. Hmm, what's the deal? Other processors always use MMU to access iomem... > Bear in mind that there *isn't a 64-bit mode*. Privileged code (which > is everything except Linux applications) can always run 64-bit > instructions; all addresses are 64-bits really, it's just the > sign-extension of the registers which makes you think you've got > 32-bit pointers. Usually a 64-bit CPU can access XKPHYS any time > it can access I/O registers. Well, it's mostly a programming convention. Without going into details, arch/mips is the 32-bit mode and arch/mips64 is the 64-bit one. The usual approximation is the state of cp0.kx, even though 64-bit operations do indeed work when ~cp0.kx. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Sep 5 11:23:11 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 11:23:12 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:32182 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 11:23:11 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA02910; Thu, 5 Sep 2002 11:23:34 +0200 (MET DST) Date: Thu, 5 Sep 2002 11:23:33 +0200 (MET DST) From: "Maciej W. Rozycki" To: Carsten Langgaard cc: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <3D76FC6B.C9AA72F3@mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Carsten Langgaard wrote: > > The (n)64 versions seem suitable and the o32 ones do not as n32 only > > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position > > pointers). > > Please notice, that a 'long' is 32-bit for n32, so we need to do the same > conversion for a lot of syscalls, as we already do for o32. Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit. It doesn't make sense otherwise. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From tor@spacetec.no Thu Sep 5 11:30:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 11:30:58 +0200 (CEST) Received: from firewall.spacetec.no ([192.51.5.5]:46722 "EHLO pallas.spacetec.no") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 11:30:57 +0200 Received: (from tor@localhost) by pallas.spacetec.no (8.9.1a/8.9.1) id LAA30701; Thu, 5 Sep 2002 11:30:11 +0200 Message-Id: <200209050930.LAA30701@pallas.spacetec.no> From: tor@spacetec.no (Tor Arntsen) Date: Thu, 5 Sep 2002 11:30:11 +0200 In-Reply-To: "Maciej W. Rozycki" "Re: 64-bit and N32 kernel interfaces" (Sep 5, 10:23) X-Mailer: Mail User's Shell (7.2.6 beta(4) 03/19/98) To: "Maciej W. Rozycki" , Carsten Langgaard Subject: Re: 64-bit and N32 kernel interfaces Cc: Ralf Baechle , linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tor@spacetec.no Precedence: bulk X-list: linux-mips On Sep 5, 10:23, "Maciej W. Rozycki" wrote: >On Thu, 5 Sep 2002, Carsten Langgaard wrote: [...] >> Please notice, that a 'long' is 32-bit for n32, so we need to do the same >> conversion for a lot of syscalls, as we already do for o32. > > Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit. >It doesn't make sense otherwise. On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit. On SGI/Irix n64 long and void* are 64-bit too. -Tor From macro@ds2.pg.gda.pl Thu Sep 5 11:52:47 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 11:52:47 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:18871 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 11:52:47 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA03361; Thu, 5 Sep 2002 11:53:12 +0200 (MET DST) Date: Thu, 5 Sep 2002 11:53:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Ralf Baechle cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020904204622.D32519@linux-mips.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Ralf Baechle wrote: > Well, N32 is yet another case. Have to look into details again but some > MIPS guy recently pointed out to me that there are a few syscalls which > for N32 cannot be handled by the o32 or N64 syscall entry as they are right > now. Which ones? Maybe we might just add some padding to structures. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kjelde@mips.com Thu Sep 5 12:16:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 12:16:29 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:13546 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 12:16:28 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g85AFkXb013457; Thu, 5 Sep 2002 03:15:46 -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 DAA10680; Thu, 5 Sep 2002 03:15:41 -0700 (PDT) Received: from coplin19.mips.com (IDENT:root@coplin19 [192.168.205.89]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g85AFeb01541; Thu, 5 Sep 2002 12:15:40 +0200 (MEST) Received: from localhost (kjelde@localhost) by coplin19.mips.com (8.11.6/8.11.6) with ESMTP id g85AFeD04076; Thu, 5 Sep 2002 12:15:40 +0200 X-Authentication-Warning: coplin19.mips.com: kjelde owned process doing -bs Date: Thu, 5 Sep 2002 12:15:40 +0200 (MEST) From: Kjeld Borch Egevang To: Ralf Baechle cc: Jun Sun , "Maciej W. Rozycki" , Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020904204038.D1121@linux-mips.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kjelde@mips.com Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Ralf Baechle wrote: ... > Several approach to solve that problem. Adding another 1000 entries - which > will cost 8000 bytes of memory that will be mostly zeros. Having wrappers > for each function that do the appropriate argument and result convertion > is another. etc. Ralf, that's not true. In our current 64-bit kernel we have 234 entries for N64 which uses 8*234 = 1872 bytes. N32 has 241 entries using 1928 bytes. Even in an embedded environment that's not a lot of memory. /Kjeld -- _ _ ____ ___ Mailto:kjelde@mips.com |\ /|||___)(___ MIPS Denmark Direct: +45 44 86 55 85 | \/ ||| ____) Lautrupvang 4 B Switch: +45 44 86 55 55 TECHNOLOGIES DK-2750 Ballerup Fax...: +45 44 86 55 56 Denmark http://www.mips.com/ From alan@lxorguk.ukuu.org.uk Thu Sep 5 13:21:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 13:21:53 +0200 (CEST) Received: from pc1-cwma1-5-cust128.swa.cable.ntl.com ([80.5.120.128]:42235 "EHLO irongate.swansea.linux.org.uk") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 13:21:52 +0200 Received: from irongate.swansea.linux.org.uk (localhost [127.0.0.1]) by irongate.swansea.linux.org.uk (8.12.5/8.12.5) with ESMTP id g85BMi30006337; Thu, 5 Sep 2002 12:22:44 +0100 Received: (from alan@localhost) by irongate.swansea.linux.org.uk (8.12.5/8.12.5/Submit) id g85BMgCK006335; Thu, 5 Sep 2002 12:22:42 +0100 X-Authentication-Warning: irongate.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: patch to kaweth.c to align IP header From: Alan Cox To: "Kevin D. Kissell" Cc: Quinn Jensen , linux-mips@linux-mips.org In-Reply-To: <008d01c254b5$d7398500$10eca8c0@grendel> References: <3D765072.60208@Lineo.COM> <1031182461.3017.137.camel@irongate.swansea.linux.org.uk> <008d01c254b5$d7398500$10eca8c0@grendel> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-6) Date: 05 Sep 2002 12:22:42 +0100 Message-Id: <1031224962.6178.18.camel@irongate.swansea.linux.org.uk> Mime-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips On Thu, 2002-09-05 at 09:23, Kevin D. Kissell wrote: > It is true that, due to the unfortunate lack of foresight in the > design of IP, no pre-alignment of buffers will *guarantee* > that the address or other fields of IP headers will be aligned. It was not done for lack of foresight. It was carefully instrumented measured and assessed. > But I note that a design which assumes, for non x86 CPUs, > that unaligned references will be handled by a kernel trap > handler had darn well better assure itself that the misaligned > case is extemely infrequent. Otherwise, it would be a distinctly It does > then using the unaligned reference trap as a crutch is a win > only if the fields are correctly aligned roughtly 94% of the time. With properly set up network cards (and that can be a problem some can't DMA to half word start points) the benched numbers I got for normal use back when we decided to go this way were that no packet appeared unaligned unless deeply weird stuff like IPX over 802.2 without SNAP was being used. Nevertheless there are several way users can trigger such alignment so your code must handle them. Another case it can occur is PPP. Hitting 94% aligned is trivially the norm. From macro@ds2.pg.gda.pl Thu Sep 5 13:47:20 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 13:47:21 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:21946 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 13:47:20 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA05373; Thu, 5 Sep 2002 13:47:39 +0200 (MET DST) Date: Thu, 5 Sep 2002 13:47:39 +0200 (MET DST) From: "Maciej W. Rozycki" To: Tor Arntsen cc: Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <200209050930.LAA30701@pallas.spacetec.no> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Tor Arntsen wrote: > > Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit. > >It doesn't make sense otherwise. > > On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit. > On SGI/Irix n64 long and void* are 64-bit too. Hmm, it looks pretty much broken if that's true (especially given long long was non-standard untile very recently). I'll check the docs, yet. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Thu Sep 5 14:47:17 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 14:47:18 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:41453 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 14:47:17 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g85CkVXb013936; Thu, 5 Sep 2002 05:46:31 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA15243; Thu, 5 Sep 2002 05:46:24 -0700 (PDT) Message-ID: <010301c254da$892fcc50$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Tor Arntsen" Cc: "Carsten Langgaard" , "Ralf Baechle" , References: Subject: Re: 64-bit and N32 kernel interfaces Date: Thu, 5 Sep 2002 14:48:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Maciej W. Rozycki" > > On Thu, 5 Sep 2002, Tor Arntsen wrote: > > > > Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit. > > >It doesn't make sense otherwise. > > > > On SGI/Irix n32 long and void* are 32-bit, only long long is 64-bit. > > On SGI/Irix n64 long and void* are 64-bit too. > > Hmm, it looks pretty much broken if that's true (especially given long > long was non-standard untile very recently). I'll check the docs, yet. n32 has the same data types as o32, an "ILP32" C integer model. n64 is a pretty normal "LP64" C integer model. What do you consider to be broken, and how would you have preferred it to have been done? Regards, Kevin K. From drow@false.org Thu Sep 5 15:29:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 15:29:29 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:2066 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 15:29:28 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mxdP-00031W-00; Thu, 05 Sep 2002 09:29:27 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mwhB-0003eS-00; Thu, 05 Sep 2002 09:29:17 -0400 Date: Thu, 5 Sep 2002 09:29:17 -0400 From: Daniel Jacobowitz To: Carsten Lange Cc: linux-mips@linux-mips.org Subject: Re: gdbserver (gdb 5.2) with thread supprt Message-ID: <20020905132917.GA13975@nevyn.them.org> References: <3D76FEE7.D1DA2D99@detewe.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D76FEE7.D1DA2D99@detewe.de> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 08:51:19AM +0200, Carsten Lange wrote: > Hi, > > gdbserver from gdb 5.2 does not work for applications using threads, for others it > works fine. > > I wonder whether gdbserver supports threads and what I have to do to set it up > (e.g where to get the > patch)? > > Any hints? GDB CVS repository, of course. I added thread support in June. It will be in 5.3, and 5.3 snapshots should start showing up on sources.redhat.com/pub/gdb/ tomorrow. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From drow@false.org Thu Sep 5 15:41:37 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 15:41:37 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:4114 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 15:41:37 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mxpE-00032F-00 for ; Thu, 05 Sep 2002 09:41:40 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mwt1-0003l2-00 for ; Thu, 05 Sep 2002 09:41:31 -0400 Date: Thu, 5 Sep 2002 09:41:31 -0400 From: Daniel Jacobowitz To: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905134131.GB13975@nevyn.them.org> Mail-Followup-To: linux-mips@linux-mips.org References: <3D76FC6B.C9AA72F3@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 11:23:33AM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Carsten Langgaard wrote: > > > > The (n)64 versions seem suitable and the o32 ones do not as n32 only > > > crops addresses to 32-bit -- data may still be 64-bit (e.g. file position > > > pointers). > > > > Please notice, that a 'long' is 32-bit for n32, so we need to do the same > > conversion for a lot of syscalls, as we already do for o32. > > Any reference? AFAIK, long is 64-bit for n32 and only void * is 32-bit. > It doesn't make sense otherwise. Nope, it looks like long is 32-bit according to GCC. It means that 64-bit quantities (long long, structures) can go in integer registers. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From macro@ds2.pg.gda.pl Thu Sep 5 16:08:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 16:08:54 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:13246 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 16:08:53 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA07739; Thu, 5 Sep 2002 16:09:11 +0200 (MET DST) Date: Thu, 5 Sep 2002 16:09:11 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <010301c254da$892fcc50$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 109 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Kevin D. Kissell wrote: > n32 has the same data types as o32, an "ILP32" C integer > model. n64 is a pretty normal "LP64" C integer model. > > What do you consider to be broken, and how would you > have preferred it to have been done? For n32 it would be natural to have: - sizeof(int) = 32 - sizeof(long) = 64 - sizeof(void *) = 32 as the underlying hardware directly supports 64-bit operations (n32 requires at least MIPS III). Thus there is no penalty for 64-bit arithmetics and if one uses longs one normally wants the largest native integer type -- using long long typically (i.e. on most platforms) implies double-precision arithmetics with all the drawbacks, especially for the division and multiplication operations. With 32-bit long on 64-bit hardware software has no easy way to figure using 64-bit operations is still optimal performance-wise. I can't see any technical benefit from such a setup -- is there any? I doubt it. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From hartvige@mips.com Thu Sep 5 16:21:43 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 16:21:43 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:17653 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 16:21:43 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g85EL0Xb014502; Thu, 5 Sep 2002 07:21:00 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA18004; Thu, 5 Sep 2002 07:20:56 -0700 (PDT) Received: from copcs01.mips.com (copcs01 [192.168.205.111]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g85EKtb21019; Thu, 5 Sep 2002 16:20:55 +0200 (MEST) From: Hartvig Ekner Received: (from hartvige@localhost) by copcs01.mips.com (8.9.1/8.9.0) id QAA26367; Thu, 5 Sep 2002 16:20:55 +0200 (MET DST) Message-Id: <200209051420.QAA26367@copcs01.mips.com> Subject: Re: 64-bit and N32 kernel interfaces To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Thu, 5 Sep 2002 16:20:55 +0200 (MET DST) Cc: kevink@mips.com (Kevin D. Kissell), tor@spacetec.no (Tor Arntsen), carstenl@mips.com (Carsten Langgaard), ralf@linux-mips.org (Ralf Baechle), linux-mips@linux-mips.org In-Reply-To: from "Maciej W. Rozycki" at Sep 05, 2002 04:09:11 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 110 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hartvige@mips.com Precedence: bulk X-list: linux-mips I don't know the ultimate reasons why SGI choose ILP32 for n32, but one could certainly be portability. As defined, n32 provides all the benefits of 64-bit data (yes, you have to use long long to get to it), and 100% backward compatability with o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data file compatability with o32 as all structures are exactly identical between o32 and n32. /Hartvig Maciej W. Rozycki writes: > > On Thu, 5 Sep 2002, Kevin D. Kissell wrote: > > > n32 has the same data types as o32, an "ILP32" C integer > > model. n64 is a pretty normal "LP64" C integer model. > > > > What do you consider to be broken, and how would you > > have preferred it to have been done? > > For n32 it would be natural to have: > > - sizeof(int) = 32 > > - sizeof(long) = 64 > > - sizeof(void *) = 32 > > as the underlying hardware directly supports 64-bit operations (n32 > requires at least MIPS III). Thus there is no penalty for 64-bit > arithmetics and if one uses longs one normally wants the largest native > integer type -- using long long typically (i.e. on most platforms) implies > double-precision arithmetics with all the drawbacks, especially for the > division and multiplication operations. > > With 32-bit long on 64-bit hardware software has no easy way to figure > using 64-bit operations is still optimal performance-wise. I can't see > any technical benefit from such a setup -- is there any? I doubt it. > > -- > + Maciej W. Rozycki, Technical University of Gdansk, Poland + > +--------------------------------------------------------------+ > + e-mail: macro@ds2.pg.gda.pl, PGP key available + > > > -- _ _ _____ ____ Hartvig Ekner Mailto:hartvige@mips.com |\ /| | |____)(____ Direct: +45 4486 5503 | \/ | | | _____) MIPS Denmark Switch: +45 4486 5555 T E C H N O L O G I E S http://www.mips.com Fax...: +45 4486 5556 From drow@false.org Thu Sep 5 16:23:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 16:23:28 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:14098 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 16:23:28 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17myTB-00034f-00; Thu, 05 Sep 2002 10:22:58 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mxWz-0004AA-00; Thu, 05 Sep 2002 10:22:49 -0400 Date: Thu, 5 Sep 2002 10:22:49 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905142249.GA15843@nevyn.them.org> References: <010301c254da$892fcc50$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 04:09:11PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Kevin D. Kissell wrote: > > > n32 has the same data types as o32, an "ILP32" C integer > > model. n64 is a pretty normal "LP64" C integer model. > > > > What do you consider to be broken, and how would you > > have preferred it to have been done? > > For n32 it would be natural to have: > > - sizeof(int) = 32 > > - sizeof(long) = 64 > > - sizeof(void *) = 32 > > as the underlying hardware directly supports 64-bit operations (n32 > requires at least MIPS III). Thus there is no penalty for 64-bit > arithmetics and if one uses longs one normally wants the largest native > integer type -- using long long typically (i.e. on most platforms) implies > double-precision arithmetics with all the drawbacks, especially for the > division and multiplication operations. > > With 32-bit long on 64-bit hardware software has no easy way to figure > using 64-bit operations is still optimal performance-wise. I can't see > any technical benefit from such a setup -- is there any? I doubt it. Well, here's one - while we all know that C code which assumes a pointer and int are the same size is buggy, it makes everything substantially simpler if long and void* are the same size. That's true for both normal LP64 and ILP32 models. Since n32 was mostly a transitional tool (SGI was primarily interested in n64 as I understand it), I imagine they wanted path of least damage... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From macro@ds2.pg.gda.pl Thu Sep 5 16:53:49 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 16:53:49 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:37823 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 16:53:48 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA08381; Thu, 5 Sep 2002 16:54:09 +0200 (MET DST) Date: Thu, 5 Sep 2002 16:54:09 +0200 (MET DST) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <200209051420.QAA26367@copcs01.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Hartvig Ekner wrote: > I don't know the ultimate reasons why SGI choose ILP32 for n32, but one > could certainly be portability. It depends on how you define "portability". While it might help some broken software, it will hurt good one. > As defined, n32 provides all the benefits of 64-bit data (yes, you have > to use long long to get to it), and 100% backward compatability with So you can't use long to keep a file position pointer (off_t is quite a new invention) and have to go for long long, for example? Weird and definitely doesn't help portability. > o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data Thay should be fixed, instead. Using "void *" as a data container doesn't work in general and one who does so should be banished. And the other way round, there is no problem -- if one keeps 32-bit pointers in 64-bit longs, there is no bit loss. > file compatability with o32 as all structures are exactly identical between > o32 and n32. Why don't use o32 as is then, instead of creating a slightly different ABI? If some software needs binary data to be identical, then it has to select fixed-size types, e.g. int32_t, explicitly. While int32_t and friends are quite a new standard, other ways were used for years to set up such aspects, e.g. autoconf, imake, hand-written system-specific preprocessor macros, etc., etc. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@false.org Thu Sep 5 17:00:08 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 17:00:09 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:23314 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 17:00:08 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mz35-000376-00; Thu, 05 Sep 2002 11:00:03 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17my6s-0004Wx-00; Thu, 05 Sep 2002 10:59:54 -0400 Date: Thu, 5 Sep 2002 10:59:54 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905145954.GA17383@nevyn.them.org> References: <200209051420.QAA26367@copcs01.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 04:54:09PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Hartvig Ekner wrote: > > > I don't know the ultimate reasons why SGI choose ILP32 for n32, but one > > could certainly be portability. > > It depends on how you define "portability". While it might help some > broken software, it will hurt good one. > > > As defined, n32 provides all the benefits of 64-bit data (yes, you have > > to use long long to get to it), and 100% backward compatability with > > So you can't use long to keep a file position pointer (off_t is quite a > new invention) and have to go for long long, for example? Weird and > definitely doesn't help portability. > > > o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data > > Thay should be fixed, instead. Using "void *" as a data container > doesn't work in general and one who does so should be banished. And the > other way round, there is no problem -- if one keeps 32-bit pointers in > 64-bit longs, there is no bit loss. > > > file compatability with o32 as all structures are exactly identical between > > o32 and n32. > > Why don't use o32 as is then, instead of creating a slightly different > ABI? If some software needs binary data to be identical, then it has to > select fixed-size types, e.g. int32_t, explicitly. While int32_t and > friends are quite a new standard, other ways were used for years to set up > such aspects, e.g. autoconf, imake, hand-written system-specific > preprocessor macros, etc., etc. No - the point is that all data types have the same size in N32. It was created explicitly as a transitional sop for people who didn't want to fix their code, but wanted a performance increase from their 64-bit hardware. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From macro@ds2.pg.gda.pl Thu Sep 5 17:07:51 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 17:07:52 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:1216 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 17:07:51 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA08625; Thu, 5 Sep 2002 17:08:06 +0200 (MET DST) Date: Thu, 5 Sep 2002 17:08:06 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905142249.GA15843@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > Well, here's one - while we all know that C code which assumes a > pointer and int are the same size is buggy, it makes everything > substantially simpler if long and void* are the same size. That's true > for both normal LP64 and ILP32 models. Since n32 was mostly a > transitional tool (SGI was primarily interested in n64 as I understand > it), I imagine they wanted path of least damage... I see. But do we need the SGI's traditional n32 in Linux then? Having most experiences in the server world I'd vote for a pure 64-bit setup (with an optional ability to execute o32 stuff), but I understand there are people who consider it a waste of resources. Therefore, I believe we may choose another way and use an IP32 (if I encode it right) data model, where we have 32-bit ints and pointers for these who are short on memory, 64-bit longs for the maximum native precision (you don't choose long for the type for your favourite "i" loop counter unless you really need it) and an ability to have double-precision 128-bit long longs in the distant future (if needed). Any opinions? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Sep 5 17:10:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 17:10:36 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:5824 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 17:10:36 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA08673; Thu, 5 Sep 2002 17:10:52 +0200 (MET DST) Date: Thu, 5 Sep 2002 17:10:51 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905145954.GA17383@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 115 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > No - the point is that all data types have the same size in N32. It > was created explicitly as a transitional sop for people who didn't want > to fix their code, but wanted a performance increase from their 64-bit > hardware. Well, what's the performance increase of n32 over o32? The increased number of argument registers? I doubt it's noticeable in most cases. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@false.org Thu Sep 5 17:14:22 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 17:14:22 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:28690 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 17:14:22 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mzGs-00038L-00; Thu, 05 Sep 2002 11:14:18 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17myKf-0006Wi-00; Thu, 05 Sep 2002 11:14:09 -0400 Date: Thu, 5 Sep 2002 11:14:09 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905151409.GA25023@nevyn.them.org> References: <20020905145954.GA17383@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 05:10:51PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > No - the point is that all data types have the same size in N32. It > > was created explicitly as a transitional sop for people who didn't want > > to fix their code, but wanted a performance increase from their 64-bit > > hardware. > > Well, what's the performance increase of n32 over o32? The increased > number of argument registers? I doubt it's noticeable in most cases. N32 supports saving and restoring 64-bit registers, which O32 doesn't - according to some comments in GCC, O32 is in fact incompatible with using 64-bit operations. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From drow@false.org Thu Sep 5 17:15:03 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 17:15:04 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:30226 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 17:15:03 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17mzHV-00038O-00; Thu, 05 Sep 2002 11:14:58 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17myLJ-0006Wo-00; Thu, 05 Sep 2002 11:14:49 -0400 Date: Thu, 5 Sep 2002 11:14:49 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905151449.GB25023@nevyn.them.org> References: <20020905142249.GA15843@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 05:08:06PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > Well, here's one - while we all know that C code which assumes a > > pointer and int are the same size is buggy, it makes everything > > substantially simpler if long and void* are the same size. That's true > > for both normal LP64 and ILP32 models. Since n32 was mostly a > > transitional tool (SGI was primarily interested in n64 as I understand > > it), I imagine they wanted path of least damage... > > I see. But do we need the SGI's traditional n32 in Linux then? Having > most experiences in the server world I'd vote for a pure 64-bit setup > (with an optional ability to execute o32 stuff), but I understand there > are people who consider it a waste of resources. > > Therefore, I believe we may choose another way and use an IP32 (if I > encode it right) data model, where we have 32-bit ints and pointers for > these who are short on memory, 64-bit longs for the maximum native > precision (you don't choose long for the type for your favourite "i" loop > counter unless you really need it) and an ability to have double-precision > 128-bit long longs in the distant future (if needed). > > Any opinions? My opinion is that N32 is good enough for people who are short on space. We have too many MIPS ABIs already! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From macro@ds2.pg.gda.pl Thu Sep 5 18:16:33 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:16:33 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:962 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:16:33 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09637; Thu, 5 Sep 2002 18:16:49 +0200 (MET DST) Date: Thu, 5 Sep 2002 18:16:49 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905151409.GA25023@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > N32 supports saving and restoring 64-bit registers, which O32 doesn't - > according to some comments in GCC, O32 is in fact incompatible with > using 64-bit operations. But that old software wouldn't benefit as it didn't perform 64-bit operations unless manually coded in software using narrower data types. There is no 64-bit C data type for o32 and long long is quite a recent invention -- it didn't exist in the 80s or even early 90s. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@false.org Thu Sep 5 18:20:05 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:20:06 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:47634 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:20:05 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17n0IA-0003Cf-00; Thu, 05 Sep 2002 12:19:42 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mzLx-0001Jc-00; Thu, 05 Sep 2002 12:19:33 -0400 Date: Thu, 5 Sep 2002 12:19:33 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905161933.GA5023@nevyn.them.org> References: <20020905151409.GA25023@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 06:16:49PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > N32 supports saving and restoring 64-bit registers, which O32 doesn't - > > according to some comments in GCC, O32 is in fact incompatible with > > using 64-bit operations. > > But that old software wouldn't benefit as it didn't perform 64-bit > operations unless manually coded in software using narrower data types. > There is no 64-bit C data type for o32 and long long is quite a recent > invention -- it didn't exist in the 80s or even early 90s. Right. You don't recompile and get a magic bullet speed improvement (well, you do, but not a drastic one I think); but you don't recompile and get a magic bullet binary incompatibility either. Then you add 64-bit pieces by hand as necessary. That's my understanding anyway. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From Jon_Burgess@eur.3com.com Thu Sep 5 18:25:56 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:25:57 +0200 (CEST) Received: from ip-161-71-171-238.corp-eur.3com.com ([161.71.171.238]:27367 "EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:25:56 +0200 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g85GRDRG007964; Thu, 5 Sep 2002 17:27:23 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g85GQIR06446; Thu, 5 Sep 2002 17:26:18 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256C2B.005ABDF4 ; Thu, 5 Sep 2002 17:31:08 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: "Matthew Dharm" cc: "Linux-MIPS" Message-ID: <80256C2B.005ABC29.00@notesmta.eur.3com.com> Date: Thu, 5 Sep 2002 17:25:00 +0100 Subject: RE: Interrupt handling.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Jon_Burgess@eur.3com.com Precedence: bulk X-list: linux-mips > li t0, 0xfc000000 > lb t1, 0xc(t0) > >After all, >isn't that what ioremap is supposed to do? I think the problem is that you need to use the pointer which ioremap() returns to access the region you requested. It looks like you've assumed that ioremap() will map it 1:1 which I don't think is the case. i.e. struct hw_regs *foo; foo = (struct hw_regs *)ioremap(0xfc000000, ); foo->command = hw_reset; ... Jon From macro@ds2.pg.gda.pl Thu Sep 5 18:28:39 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:28:40 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:23746 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:28:39 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09797; Thu, 5 Sep 2002 18:28:57 +0200 (MET DST) Date: Thu, 5 Sep 2002 18:28:57 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905151449.GB25023@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > My opinion is that N32 is good enough for people who are short on > space. We have too many MIPS ABIs already! You meant "there are", I suppose, as we (i.e. Linux) only really have a single one right now -- o32. And my opinion is we should carefully choose additional ABIs for the 64-bit port based on technical superiority and flexibility and do not blindly follow what others do. To achieve this, we do not even need to fiddle with the toolchain -- ELF file formats are sufficient, binutils don't care and gcc may be set up as needed in a configuration header. All that matters is the kernel and libc. That said, I do not assert my address/data model propsal is optimal -- this is subject to a discussion, but please keep non-technical arguments away. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ica2_ts@csv.ica.uni-stuttgart.de Thu Sep 5 18:31:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:31:13 +0200 (CEST) Received: from iris1.csv.ica.uni-stuttgart.de ([129.69.118.2]:31516 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:31:12 +0200 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17mzS2-002RxB-00; Thu, 05 Sep 2002 18:25:50 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17mzWt-0006Gv-00; Thu, 05 Sep 2002 18:30:51 +0200 Date: Thu, 5 Sep 2002 18:30:51 +0200 To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905163051.GT4194@rembrandt.csv.ica.uni-stuttgart.de> References: <20020905142249.GA15843@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: [snip] > I see. But do we need the SGI's traditional n32 in Linux then? Having > most experiences in the server world I'd vote for a pure 64-bit setup > (with an optional ability to execute o32 stuff), but I understand there > are people who consider it a waste of resources. > > Therefore, I believe we may choose another way and use an IP32 (if I > encode it right) data model, where we have 32-bit ints and pointers for > these who are short on memory, 64-bit longs for the maximum native > precision (you don't choose long for the type for your favourite "i" loop > counter unless you really need it) Following this line of argumentation, there isn't much software which could benefit from 64 bit longs. :-) And 64 bit long long is available for such software anyway. > and an ability to have double-precision > 128-bit long longs in the distant future (if needed). So the linux n64 would be incompatible to SGI's, too? (It would be weird if the n64 long long was smaller than the n32 one). > Any opinions? It would mean to create two new ABIs, gaining little benefit but being incompatible from a (C-)programmers POV. And we already have too many MIPS ABIs. Thiemo From macro@ds2.pg.gda.pl Thu Sep 5 18:33:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:33:37 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:35522 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:33:36 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA09858; Thu, 5 Sep 2002 18:33:54 +0200 (MET DST) Date: Thu, 5 Sep 2002 18:33:53 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905161933.GA5023@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > Right. You don't recompile and get a magic bullet speed improvement > (well, you do, but not a drastic one I think); but you don't recompile > and get a magic bullet binary incompatibility either. Then you add > 64-bit pieces by hand as necessary. Huh? I can somewhat understand the "rebuild and forget" approach, especially in cases suitably experienced stuff was lost meanwhile. But if you start to fiddle with some old crap, you may equally well run 's/long/int/' within it, what's a deal. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@false.org Thu Sep 5 18:39:27 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:39:28 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:57362 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:39:27 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17n0bC-0003Eo-00; Thu, 05 Sep 2002 12:39:22 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17mzez-0001ay-00; Thu, 05 Sep 2002 12:39:13 -0400 Date: Thu, 5 Sep 2002 12:39:13 -0400 From: Daniel Jacobowitz To: "Maciej W. Rozycki" Cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905163913.GA6086@nevyn.them.org> References: <20020905161933.GA5023@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 06:33:53PM +0200, Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > Right. You don't recompile and get a magic bullet speed improvement > > (well, you do, but not a drastic one I think); but you don't recompile > > and get a magic bullet binary incompatibility either. Then you add > > 64-bit pieces by hand as necessary. > > Huh? I can somewhat understand the "rebuild and forget" approach, > especially in cases suitably experienced stuff was lost meanwhile. But if > you start to fiddle with some old crap, you may equally well run > 's/long/int/' within it, what's a deal. Eh? That's not even sort-of practical on an application of significant size. It would be a nightmare. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From macro@ds2.pg.gda.pl Thu Sep 5 18:53:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 18:53:52 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:10691 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 18:53:52 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA10131; Thu, 5 Sep 2002 18:54:05 +0200 (MET DST) Date: Thu, 5 Sep 2002 18:54:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905163051.GT4194@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Thiemo Seufer wrote: > > Therefore, I believe we may choose another way and use an IP32 (if I > > encode it right) data model, where we have 32-bit ints and pointers for > > these who are short on memory, 64-bit longs for the maximum native > > precision (you don't choose long for the type for your favourite "i" loop > > counter unless you really need it) > > Following this line of argumentation, there isn't much software which > could benefit from 64 bit longs. :-) And 64 bit long long is available > for such software anyway. It's up to a programmer to judge what kind of processing he needs. For computing, 64-bit integer arithmetics is indeed useful from time to time only and 32-bit one often suffices. > So the linux n64 would be incompatible to SGI's, too? (It would be > weird if the n64 long long was smaller than the n32 one). Why would anyone care? Do you want to run IRIX binaries on Linux? And at the source level, you have autoconf or as you can't arbitrarily assume any type sizes for any portable code. > It would mean to create two new ABIs, gaining little benefit but > being incompatible from a (C-)programmers POV. And we already have > too many MIPS ABIs. What programmer's POV? Does a programmer write a program for MIPS? No, unless he writes a kernel or a libc. A normal programmer just codes a program in C for a *nix-type system and if he wants any portability, he needs to follow universal guidelines. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Sep 5 19:16:06 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 19:16:07 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:54467 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 19:16:06 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA10420; Thu, 5 Sep 2002 19:16:23 +0200 (MET DST) Date: Thu, 5 Sep 2002 19:16:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: Daniel Jacobowitz cc: Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905163913.GA6086@nevyn.them.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > Huh? I can somewhat understand the "rebuild and forget" approach, > > especially in cases suitably experienced stuff was lost meanwhile. But if > > you start to fiddle with some old crap, you may equally well run > > 's/long/int/' within it, what's a deal. > > Eh? That's not even sort-of practical on an application of significant > size. It would be a nightmare. Oh yes, I tend to forget there are people who do not write clean software -- if the size of an object is critical e.g. for a system-independent binary data interface, there should be a data type for it defined in a single place somewhere. But who cares? "It's not me who'll have to fix it later, so why should I bother putting more effort into it." -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Thu Sep 5 19:28:34 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 19:28:35 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:41466 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 19:28:34 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g85HRKXb015575; Thu, 5 Sep 2002 10:27:20 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA02077; Thu, 5 Sep 2002 10:27:15 -0700 (PDT) Message-ID: <019601c25501$c5307250$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" , "Daniel Jacobowitz" Cc: "Hartvig Ekner" , "Tor Arntsen" , "Carsten Langgaard" , "Ralf Baechle" , References: Subject: Re: 64-bit and N32 kernel interfaces Date: Thu, 5 Sep 2002 19:29:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Maciej W. Rozycki" > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > N32 supports saving and restoring 64-bit registers, which O32 doesn't - > > according to some comments in GCC, O32 is in fact incompatible with > > using 64-bit operations. > > But that old software wouldn't benefit as it didn't perform 64-bit > operations unless manually coded in software using narrower data types. > There is no 64-bit C data type for o32 and long long is quite a recent > invention -- it didn't exist in the 80s or even early 90s. Well, actually,. as I recall from those days, "long long" *did* exist in the very late 1980's, though it wasn't part of any standard, and there were variant names proposed for it. Certainly it had been invented by the time the first 64-bit MIPS chips came out in 1991/1992. Maybe not in GCC, but in other complers of the period. The concensus was that "long" should be the largest element that could be loaded/stored/used in an integer register, which meant 32-bits for most of us in those days, yet there was a need to represent 64-bit integers for the clearest expression of some algorithms. MIPS was rather unique in having made a "binary compatible" transition from 32 to 64-bits. Does anyone know what's being done with C integer binding on the AMD "Hammer" architecture? They're looking at the same problem, 10 years further on. Kevin K. From ica2_ts@csv.ica.uni-stuttgart.de Thu Sep 5 19:44:40 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 19:44:41 +0200 (CEST) Received: from iris1.csv.ica.uni-stuttgart.de ([129.69.118.2]:47388 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 19:44:40 +0200 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17n0bF-002Q4d-00; Thu, 05 Sep 2002 19:39:25 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17n0g7-0006LS-00; Thu, 05 Sep 2002 19:44:27 +0200 Date: Thu, 5 Sep 2002 19:44:27 +0200 To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905174427.GU4194@rembrandt.csv.ica.uni-stuttgart.de> References: <20020905163051.GT4194@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.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: [snip] > > So the linux n64 would be incompatible to SGI's, too? (It would be > > weird if the n64 long long was smaller than the n32 one). > > Why would anyone care? Do you want to run IRIX binaries on Linux? And > at the source level, you have autoconf or as you can't > arbitrarily assume any type sizes for any portable code. Not everyone uses autoconf, and if you call "long long" a recent addition then the use of isn't safe, too. Using the same data types allows at least to choose the appropriate typedefs without caring about the underlying OS. > > It would mean to create two new ABIs, gaining little benefit but > > being incompatible from a (C-)programmers POV. And we already have > > too many MIPS ABIs. > > What programmer's POV? Does a programmer write a program for MIPS? No, > unless he writes a kernel or a libc. A normal programmer just codes a > program in C for a *nix-type system and if he wants any portability, he > needs to follow universal guidelines. World isn't as perfect as you claim. And for non-broken code it's nearly irrelevant if the 64 bit integer type is called "long" or "long long". About 128 bit integers: Most OS'es use "long long" already for 64 bit integers, which means there will be something like "quad long" for 128 bit integers (if these are needed). Thiemo From hartvige@mips.com Thu Sep 5 20:08:24 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 20:08:24 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:51195 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 20:08:24 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g85I78Xb015794; Thu, 5 Sep 2002 11:07:08 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA05080; Thu, 5 Sep 2002 11:07:04 -0700 (PDT) Received: from coplin09.mips.com (IDENT:root@coplin09 [192.168.205.79]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g85I73b11054; Thu, 5 Sep 2002 20:07:03 +0200 (MEST) Received: (from hartvige@localhost) by coplin09.mips.com (8.11.6/8.11.6) id g85I73W06904; Thu, 5 Sep 2002 20:07:03 +0200 From: Hartvig Ekner Message-Id: <200209051807.g85I73W06904@coplin09.mips.com> Subject: Re: 64-bit and N32 kernel interfaces To: macro@ds2.pg.gda.pl (Maciej W. Rozycki) Date: Thu, 5 Sep 2002 20:07:03 +0200 (CEST) Cc: dan@debian.org (Daniel Jacobowitz), hartvige@mips.com (Hartvig Ekner), kevink@mips.com (Kevin D. Kissell), tor@spacetec.no (Tor Arntsen), carstenl@mips.com (Carsten Langgaard), ralf@linux-mips.org (Ralf Baechle), linux-mips@linux-mips.org In-Reply-To: from "Maciej W. Rozycki" at Sep 05, 2002 05:10:51 X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hartvige@mips.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki writes: > > On Thu, 5 Sep 2002, Daniel Jacobowitz wrote: > > > No - the point is that all data types have the same size in N32. It > > was created explicitly as a transitional sop for people who didn't want > > to fix their code, but wanted a performance increase from their 64-bit > > hardware. > > Well, what's the performance increase of n32 over o32? The increased > number of argument registers? I doubt it's noticeable in most cases. The technical benefits of n32 over o32 are: * More argument registers => less memory traffic, less D-cache use, => faster code * 64-bit datapath of CPU can be utilized with big impact on certain applications * 32 floating point registers instead of 16 (and more efficient parameter passing as well) /Hartvig From macro@ds2.pg.gda.pl Thu Sep 5 20:54:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 20:54:13 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:41670 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 20:54:12 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA11861; Thu, 5 Sep 2002 20:54:28 +0200 (MET DST) Date: Thu, 5 Sep 2002 20:54:27 +0200 (MET DST) From: "Maciej W. Rozycki" To: Hartvig Ekner cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <200209051807.g85I73W06904@coplin09.mips.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Hartvig Ekner wrote: > The technical benefits of n32 over o32 are: > > * More argument registers => less memory traffic, less D-cache use, > => faster code Generally, since the stack is usually frequently accessed it tends to stick in the primary cache so the extra cost is null. But a set associative cache with an LFU or at least an LRU replacement algorithm is needed for this to be effective. Too bad such caches are rare for MIPS processors... So the win might actually be bigger than it should be. > * 64-bit datapath of CPU can be utilized with big impact on certain > applications But an old program doesn't make use of them, so it won't normally benefit. For new development it's true, but you don't absolutely need to cut long to 32 bits for new stuff. > * 32 floating point registers instead of 16 (and more efficient > parameter passing as well) Yes, that's true -- I missed it previously. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ica2_ts@csv.ica.uni-stuttgart.de Thu Sep 5 21:16:32 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 21:16:33 +0200 (CEST) Received: from iris1.csv.ica.uni-stuttgart.de ([129.69.118.2]:64284 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 21:16:32 +0200 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17n22B-002SVZ-00; Thu, 05 Sep 2002 21:11:19 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17n271-0001iG-00; Thu, 05 Sep 2002 21:16:19 +0200 Date: Thu, 5 Sep 2002 21:16:19 +0200 To: "Maciej W. Rozycki" Cc: Hartvig Ekner , Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905191619.GV4194@rembrandt.csv.ica.uni-stuttgart.de> References: <200209051807.g85I73W06904@coplin09.mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Thu, 5 Sep 2002, Hartvig Ekner wrote: > > > The technical benefits of n32 over o32 are: [snip] > > * 64-bit datapath of CPU can be utilized with big impact on certain > > applications > > But an old program doesn't make use of them, so it won't normally > benefit. An o32 program using compiler synthesized 64 bit integers will do so when recompiled for n32. Thiemo From macro@ds2.pg.gda.pl Thu Sep 5 21:34:11 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 21:34:12 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:49095 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 21:34:11 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA12385; Thu, 5 Sep 2002 21:34:28 +0200 (MET DST) Date: Thu, 5 Sep 2002 21:34:28 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Daniel Jacobowitz , Hartvig Ekner , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <019601c25501$c5307250$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Kevin D. Kissell wrote: > of some algorithms. MIPS was rather unique in having made > a "binary compatible" transition from 32 to 64-bits. Does anyone > know what's being done with C integer binding on the AMD > "Hammer" architecture? They're looking at the same problem, > 10 years further on. Well, SPARC is another mature example that works this way. And the PA-RISC, PPC, and S390 ports may have similar experiences, but I don't know the details. MIPS is quite unique with the n32 ABI as the ABI is 64-bit but with 32-bit addressing. I'll see if and how they handle such a case, but it's likely they have plain 32-bit and plain 64-bit ABIs only. BTW, I've found an interesting type size analyzis in the SUSv2 at: 'http://www.usenix.org/publications/login/standards/10.data.html' and they simply opt for LP64 for 64-bit systems. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Thu Sep 5 21:50:05 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 05 Sep 2002 21:50:05 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:14536 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Thu, 5 Sep 2002 21:50:05 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA12658; Thu, 5 Sep 2002 21:50:05 +0200 (MET DST) Date: Thu, 5 Sep 2002 21:50:05 +0200 (MET DST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905174427.GU4194@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 5 Sep 2002, Thiemo Seufer wrote: > > at the source level, you have autoconf or as you can't > > arbitrarily assume any type sizes for any portable code. > > Not everyone uses autoconf, and if you call "long long" a recent > addition then the use of isn't safe, too. That is not an excuse, sorry. You need not to use autoconf or if you don't want to -- you may use a different tool or simply group all tweakable settings in config.h and ask a user to edit it manually like autors of old programs did. > Using the same data types allows at least to choose the appropriate > typedefs without caring about the underlying OS. It doesn't. It is unsafe to assume it in general and it's even more unsafe for MIPS where we have at least three C models and you do not know in advance which one will a person doing a build choose. > > What programmer's POV? Does a programmer write a program for MIPS? No, > > unless he writes a kernel or a libc. A normal programmer just codes a > > program in C for a *nix-type system and if he wants any portability, he > > needs to follow universal guidelines. > > World isn't as perfect as you claim. And for non-broken code it's > nearly irrelevant if the 64 bit integer type is called "long" or > "long long". World isn't perfect, but it would be beneficial if at least we tried to keep it as good as we can. > About 128 bit integers: Most OS'es use "long long" already for > 64 bit integers, which means there will be something like > "quad long" for 128 bit integers (if these are needed). We'll see, but I wouldn't bet on it. Personally, I'd rather see "long long" to be a double-precision (not necessarily 128-bit) type universally. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ica2_ts@csv.ica.uni-stuttgart.de Fri Sep 6 00:12:40 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 00:12:41 +0200 (CEST) Received: from iris1.csv.ica.uni-stuttgart.de ([129.69.118.2]:24093 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 00:12:40 +0200 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17n4mV-002Si8-00; Fri, 06 Sep 2002 00:07:19 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17n4rN-0002nd-00; Fri, 06 Sep 2002 00:12:21 +0200 Date: Fri, 6 Sep 2002 00:12:21 +0200 To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020905221221.GX4194@rembrandt.csv.ica.uni-stuttgart.de> References: <20020905174427.GU4194@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.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: [snip] > > Using the same data types allows at least to choose the appropriate > > typedefs without caring about the underlying OS. > > It doesn't. It is unsafe to assume it in general and it's even more > unsafe for MIPS where we have at least three C models and you do not know > in advance which one will a person doing a build choose. It's knowing the ABI vs. ABI + OS (or OS-specific ABI-variant, if you want to call it different). > > > What programmer's POV? Does a programmer write a program for MIPS? No, > > > unless he writes a kernel or a libc. A normal programmer just codes a > > > program in C for a *nix-type system and if he wants any portability, he > > > needs to follow universal guidelines. > > > > World isn't as perfect as you claim. And for non-broken code it's > > nearly irrelevant if the 64 bit integer type is called "long" or > > "long long". > > World isn't perfect, but it would be beneficial if at least we tried to > keep it as good as we can. I agree. And I believe in the "least surprise" principle, which means we shouldn't deviate from widely known conventions without good reason. I still don't see the advantage of a 64 bit long in n32. Thiemo From mdharm@momenco.com Fri Sep 6 05:26:29 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 05:26:30 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:45577 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 05:26:29 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g863QE613782 for ; Thu, 5 Sep 2002 20:26:14 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: /dev/rtc lookalike for NEW_TIME_C? Date: Thu, 5 Sep 2002 20:26:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Has anyone written a driver module provide something like /dev/rtc for those platforms that use the CONFIG_NEW_TIME_C? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From jsun@orion.mvista.com Fri Sep 6 20:29:56 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 20:29:56 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:49394 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 20:29:56 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g86IIFO01331; Fri, 6 Sep 2002 11:18:15 -0700 Date: Fri, 6 Sep 2002 11:18:15 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [jsun@mvista.com: Re: /dev/rtc lookalike for NEW_TIME_C?] Message-ID: <20020906111815.B1282@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 136 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Try again .... ----- Forwarded message from Jun Sun ----- On Thu, Sep 05, 2002 at 08:26:14PM -0700, Matthew Dharm wrote: > Has anyone written a driver module provide something like /dev/rtc for > those platforms that use the CONFIG_NEW_TIME_C? > Yes. I submitted this patch November last year. There was some discussions, but no real opposition. Ralf, can you apply this patch? Tom Rini is supposedly to come up with a unified solution in 2.5+. But until then this is such a useful thing for MIPS folks. http://linux.junsun.net/patches/oss.sgi.com/submitted. Jun ----- End forwarded message ----- From mdharm@momenco.com Fri Sep 6 22:04:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 22:04:37 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:12810 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 22:04:36 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g86K4S617264 for ; Fri, 6 Sep 2002 13:04:28 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: LOADADDR and low physical addresses? Date: Fri, 6 Sep 2002 13:04:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 137 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips So, I've got an interesting problem... which has forced me to look at the use of the LOADADDR variable in the Makefile, and try (quickly) to brush up on my linker scripting... Basically I've got a processor with on-chip registers that need to be located in the first 512MByte of _physical_ address. To make things difficult, they cannot be re-located once placed (configuration is done by a hardware config stream at reset). It's only 16KBytes of address, but since I recall that linux on mips can't (well, probably can't) handle discontiguous memory maps (we discussed this about a year ago, I think), I was looking for a good place to put them. Now, I think my problems are solved if the LOADADDR variable works the way I think it does -- that the kernel loads at that address, and only uses memory from that point upwards. So, if my LOADADDR is 0x80100000, then the first 0x100000 won't get used. Of course, the exception vectors are there, but that doesn't take up that much space. So there should be a chunk of address space I can use for other things, like this register bank. Yes? No? Is my understanding even close? Matt P.S. Of course, if this is right, then I need to figure out the proper/best way to use the add_memory_region() function.... -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From jsun@orion.mvista.com Fri Sep 6 23:05:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 23:05:08 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:31225 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 23:05:07 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g86KrO601586; Fri, 6 Sep 2002 13:53:24 -0700 Date: Fri, 6 Sep 2002 13:53:24 -0700 From: Jun Sun To: Matthew Dharm Cc: Linux-MIPS , jsun@mvista.com Subject: Re: LOADADDR and low physical addresses? Message-ID: <20020906135324.D1382@mvista.com> 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 mdharm@momenco.com on Fri, Sep 06, 2002 at 01:04:28PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Fri, Sep 06, 2002 at 01:04:28PM -0700, Matthew Dharm wrote: > So, I've got an interesting problem... which has forced me to look at > the use of the LOADADDR variable in the Makefile, and try (quickly) to > brush up on my linker scripting... > > Basically I've got a processor with on-chip registers that need to be > located in the first 512MByte of _physical_ address. To make things > difficult, they cannot be re-located once placed (configuration is > done by a hardware config stream at reset). It's only 16KBytes of > address, but since I recall that linux on mips can't (well, probably > can't) handle discontiguous memory maps (we discussed this about a > year ago, I think), I was looking for a good place to put them. > > Now, I think my problems are solved if the LOADADDR variable works the > way I think it does -- that the kernel loads at that address, and only > uses memory from that point upwards. So, if my LOADADDR is > 0x80100000, then the first 0x100000 won't get used. Of course, the > exception vectors are there, but that doesn't take up that much space. > So there should be a chunk of address space I can use for other > things, like this register bank. > > Yes? No? Is my understanding even close? > That is right. The only catch is that if you make LOADADDR very high (as in the case system ram starts at a high address), the kernel page table will be very high too. It starts from phys address 0. Also if you map your control registers at near-zero phy address, don't you also have system RAM there too? Normally it is not ok to have two devices decoded at the same phys address. > P.S. Of course, if this is right, then I need to figure out the > proper/best way to use the add_memory_region() function.... Unless I misunderstand something here, I don't think you need to mess with add_memory_region(). Jun From mdharm@momenco.com Fri Sep 6 23:13:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 23:13:16 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:17930 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 23:13:15 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g86LD8617579; Fri, 6 Sep 2002 14:13:08 -0700 From: "Matthew Dharm" To: "Jun Sun" Cc: "Linux-MIPS" Subject: RE: LOADADDR and low physical addresses? Date: Fri, 6 Sep 2002 14:13:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <20020906135324.D1382@mvista.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Yes, the having two devices at the same physical address might be a problem, but one I _might_ be able to work around. Not only do I have a large bank of SDRAM, but I also have a small bank of on-chip SRAM. So I'm thinking that the map will go (starting from 0) like this: on-chip SRAM, control registers, main memory And this is where I think the add_memory_region() magic might need to happen. Do I need to add the on-chip SRAM and control registers using add_memory_region()? Is it going to be okay to have a large and mis-aligned bank of SDRAM? Questions abound. Needless to say, I'm going to have some choice words with the chip designers over this... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: Jun Sun [mailto:jsun@mvista.com] > Sent: Friday, September 06, 2002 1:53 PM > To: Matthew Dharm > Cc: Linux-MIPS; jsun@mvista.com > Subject: Re: LOADADDR and low physical addresses? > > > On Fri, Sep 06, 2002 at 01:04:28PM -0700, Matthew Dharm wrote: > > So, I've got an interesting problem... which has forced > me to look at > > the use of the LOADADDR variable in the Makefile, and try > (quickly) to > > brush up on my linker scripting... > > > > Basically I've got a processor with on-chip registers > that need to be > > located in the first 512MByte of _physical_ address. To > make things > > difficult, they cannot be re-located once placed (configuration is > > done by a hardware config stream at reset). It's only 16KBytes of > > address, but since I recall that linux on mips can't > (well, probably > > can't) handle discontiguous memory maps (we discussed this about a > > year ago, I think), I was looking for a good place to put them. > > > > Now, I think my problems are solved if the LOADADDR > variable works the > > way I think it does -- that the kernel loads at that > address, and only > > uses memory from that point upwards. So, if my LOADADDR is > > 0x80100000, then the first 0x100000 won't get used. Of > course, the > > exception vectors are there, but that doesn't take up > that much space. > > So there should be a chunk of address space I can use for other > > things, like this register bank. > > > > Yes? No? Is my understanding even close? > > > > That is right. > > The only catch is that if you make LOADADDR very high (as > in the case > system ram starts at a high address), the kernel page > table will be very high too. It starts from phys address 0. > > Also if you map your control registers at near-zero phy > address, don't you > also have system RAM there too? Normally it is not ok to have two > devices decoded at the same phys address. > > > P.S. Of course, if this is right, then I need to figure out the > > proper/best way to use the add_memory_region() function.... > > Unless I misunderstand something here, I don't think you need > to mess with add_memory_region(). > > Jun > From jsun@orion.mvista.com Fri Sep 6 23:54:13 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 06 Sep 2002 23:54:14 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:4604 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Fri, 6 Sep 2002 23:54:13 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g86LgWs01753; Fri, 6 Sep 2002 14:42:32 -0700 Date: Fri, 6 Sep 2002 14:42:32 -0700 From: Jun Sun To: Matthew Dharm Cc: Linux-MIPS , jsun@mvista.com Subject: Re: LOADADDR and low physical addresses? Message-ID: <20020906144232.E1382@mvista.com> References: <20020906135324.D1382@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 mdharm@momenco.com on Fri, Sep 06, 2002 at 02:13:08PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 140 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Fri, Sep 06, 2002 at 02:13:08PM -0700, Matthew Dharm wrote: > Yes, the having two devices at the same physical address might be a > problem, but one I _might_ be able to work around. Not only do I have > a large bank of SDRAM, but I also have a small bank of on-chip SRAM. > > So I'm thinking that the map will go (starting from 0) like this: > on-chip SRAM, control registers, main memory > > And this is where I think the add_memory_region() magic might need to > happen. Do I need to add the on-chip SRAM and control registers using > add_memory_region()? I don't think you have to. I *think* it works if you don't. Not sure know if you actuall do add. > Is it going to be okay to have a large and > mis-aligned bank of SDRAM? That should be ok. Jun From Manoj_Ekbote@pmc-sierra.com Sat Sep 7 00:36:03 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Sep 2002 00:36:04 +0200 (CEST) Received: from father.pmc-sierra.bc.ca ([216.241.224.13]:35062 "HELO father.pmc-sierra.bc.ca") by linux-mips.org with SMTP id ; Sat, 7 Sep 2002 00:36:03 +0200 Received: (qmail 4883 invoked by uid 104); 6 Sep 2002 22:35:53 -0000 Received: from Manoj_Ekbote@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4218. . Clean. Processed in 0.51649 secs); 06 Sep 2002 22:35:53 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 6 Sep 2002 22:35:52 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g86MZqw13439; Fri, 6 Sep 2002 15:35:52 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Sep 2002 15:37:40 -0700 Message-ID: <71690137A786F7428FF9670D47CB95ED18AD48@SJE4EXM01> From: Manoj Ekbote To: "'Matthew Dharm'" Cc: Linux-MIPS Subject: RE: LOADADDR and low physical addresses? Date: Fri, 6 Sep 2002 15:35:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Manoj_Ekbote@pmc-sierra.com Precedence: bulk X-list: linux-mips -----Original Message----- From: Matthew Dharm [mailto:mdharm@momenco.com] Sent: Friday, September 06, 2002 2:13 PM To: Jun Sun Cc: Linux-MIPS Subject: RE: LOADADDR and low physical addresses? Yes, the having two devices at the same physical address might be a problem, but one I _might_ be able to work around. Not only do I have a large bank of SDRAM, but I also have a small bank of on-chip SRAM. So I'm thinking that the map will go (starting from 0) like this: on-chip SRAM, control registers, main memory And this is where I think the add_memory_region() magic might need to happen. Do I need to add the on-chip SRAM and control registers using add_memory_region()? --I am pretty sure you don't have to do that.You just need to tell Linux --where the main memory starts at. Manoj From mdharm@momenco.com Sat Sep 7 02:13:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 07 Sep 2002 02:13:15 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:32522 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Sat, 7 Sep 2002 02:13:14 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g870D2618341; Fri, 6 Sep 2002 17:13:02 -0700 From: "Matthew Dharm" To: "Jun Sun" , Subject: RE: [jsun@mvista.com: Re: /dev/rtc lookalike for NEW_TIME_C?] Date: Fri, 6 Sep 2002 17:13:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <20020906111815.B1282@mvista.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips In case anyone is interesed, I just tried this. The patch still applies, tho with some fuzz. It appears to work as advertised, which is to say that it does everything I'm interested in. I _definately_ think this should go in on the 2.4 branch, as well as the 2.5 branch. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Jun Sun > Sent: Friday, September 06, 2002 11:18 AM > To: linux-mips@linux-mips.org > Cc: jsun@mvista.com > Subject: [jsun@mvista.com: Re: /dev/rtc lookalike for NEW_TIME_C?] > > > > Try again .... > > ----- Forwarded message from Jun Sun ----- > > On Thu, Sep 05, 2002 at 08:26:14PM -0700, Matthew Dharm wrote: > > Has anyone written a driver module provide something like > /dev/rtc for > > those platforms that use the CONFIG_NEW_TIME_C? > > > > Yes. I submitted this patch November last year. There was > some discussions, > but no real opposition. Ralf, can you apply this patch? Tom Rini > is supposedly to come up with a unified solution in 2.5+. But until > then this is such a useful thing for MIPS folks. > > http://linux.junsun.net/patches/oss.sgi.com/submitted. > > Jun > > ----- End forwarded message ----- > From ralf@linux-mips.org Sun Sep 8 18:12:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Sep 2002 18:12:15 +0200 (CEST) Received: from p508B4F9D.dip.t-dialin.net ([80.139.79.157]:27008 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 8 Sep 2002 18:12:14 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g86AEOs05039; Fri, 6 Sep 2002 12:14:24 +0200 Date: Fri, 6 Sep 2002 12:14:24 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020906121424.E2993@linux-mips.org> References: <20020905142249.GA15843@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Sep 05, 2002 at 05:08:06PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 05:08:06PM +0200, Maciej W. Rozycki wrote: > I see. But do we need the SGI's traditional n32 in Linux then? Having > most experiences in the server world I'd vote for a pure 64-bit setup > (with an optional ability to execute o32 stuff), but I understand there > are people who consider it a waste of resources. In the SGI world o32 basically has been killed - there no more 32-bit processors shipped since many years. So most SGI MIPS systems are running N32 code by standard and N64 is available as an option which only is used for the small number of applications that actually are going to gain from it. O32 is deprecated; at this time it's just historical garbage. Ralf From ralf@linux-mips.org Sun Sep 8 18:12:49 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Sep 2002 18:12:50 +0200 (CEST) Received: from p508B4F9D.dip.t-dialin.net ([80.139.79.157]:29568 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 8 Sep 2002 18:12:49 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g869UnT04205; Fri, 6 Sep 2002 11:30:49 +0200 Date: Fri, 6 Sep 2002 11:30:49 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020906113049.A2993@linux-mips.org> References: <20020905145954.GA17383@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Sep 05, 2002 at 05:10:51PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 05:10:51PM +0200, Maciej W. Rozycki wrote: > > No - the point is that all data types have the same size in N32. It > > was created explicitly as a transitional sop for people who didn't want > > to fix their code, but wanted a performance increase from their 64-bit > > hardware. > > Well, what's the performance increase of n32 over o32? The increased > number of argument registers? I doubt it's noticeable in most cases. That's a minor optimization. More important is the availability of MIPS III/IV and MIPS64 instruction sets which means 64-bit integer registers and 32 64-bit double precission fp registers. Ralf From ralf@linux-mips.org Sun Sep 8 18:13:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 08 Sep 2002 18:13:29 +0200 (CEST) Received: from p508B4F9D.dip.t-dialin.net ([80.139.79.157]:30848 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 8 Sep 2002 18:13:28 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g869gdG04428; Fri, 6 Sep 2002 11:42:39 +0200 Date: Fri, 6 Sep 2002 11:42:39 +0200 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Daniel Jacobowitz , Hartvig Ekner , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020906114239.B2993@linux-mips.org> References: <20020905151409.GA25023@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from macro@ds2.pg.gda.pl on Thu, Sep 05, 2002 at 06:16:49PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 05, 2002 at 06:16:49PM +0200, Maciej W. Rozycki wrote: > > N32 supports saving and restoring 64-bit registers, which O32 doesn't - > > according to some comments in GCC, O32 is in fact incompatible with > > using 64-bit operations. > > But that old software wouldn't benefit as it didn't perform 64-bit > operations unless manually coded in software using narrower data types. > There is no 64-bit C data type for o32 and long long is quite a recent > invention -- it didn't exist in the 80s or even early 90s. Not in any standard but de facto in existence since a long time. Anyway, the changes in floating point in the N32 are so substancial that there are projects that say without N32 or N64 they don't even need to start working on their projects. Ralf From jeff@keyresearch.com Mon Sep 9 02:33:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 02:33:17 +0200 (CEST) Received: from [66.120.210.133] ([66.120.210.133]:43014 "EHLO kabul.ad.skymv.com") by linux-mips.org with ESMTP id convert rfc822-to-8bit; Mon, 9 Sep 2002 02:33:16 +0200 Received: from kabul.ad.skymv.com ([192.168.1.70]) by kabul.ad.skymv.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 8 Sep 2002 17:33:00 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: 64-bit and N32 kernel interfaces - a bit of history X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Date: Sun, 8 Sep 2002 17:33:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 64-bit and N32 kernel interfaces thread-index: AcJVDbqwfYPJa+/sR2+IM9Ia9NnvcgCipNDA From: "Jeff Broughton" To: X-OriginalArrivalTime: 09 Sep 2002 00:33:00.0542 (UTC) FILETIME=[739279E0:01C25798] X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jeff@keyresearch.com Precedence: bulk X-list: linux-mips After the discussion on this list about data type sizes, I asked Jim Dehnert, who was the person at SGI charged with creating N32, what drove them to development N32 in addition to O32 and N64. Here is his reply: Performance was almost all of the reason. I don't think we ever quantified it well, but that was partially because we were speculating about future usage as much as worrying about the present. I'll try to dredge up some of the reasons from memory... Relative to the original 32-bit ABI and what could be done compatibly, N32 passed FP parameters much more efficiently (because it could do so in single registers instead of pairs, which I vaguely recall sometimes even required copies to memory and back), allowed the same for 64-bit integers, and passed 8 instead of 4 in registers. We felt that the FP parameter issues were particularly important in our markets. A less obvious issue had to do with 64-bit integers and floats in temporaries across calls. The old 32-bit ABI defined adequate sets of callee-saved registers, but of course the standard for save/restore was just that 32 bits be saved and restored. That meant fundamentally that there were _no_ 64-bit callee-saved registers. Again, this was not a big problem in most existing code, but we expected it to become more important, and thought we had just one chance to fix it. This may have been more the deciding issue than the parameter-passing ones, but of course once you decide on anything incompatible, everything more or less becomes fair game. The secondary motivation, after performance, was simplicity, on two levels. All of the situations I described above can be handled in the old 32-bit ABI (and in fact they were, though we didn't release all the capabilities), but it makes parameter passing and temporary management much more complex. As a wild guess, I would say that in the first compiler for the R8000 (our first supported 64-bit processor, though the R4000 had 64-bit capabilities we didn't support), which supported the 64-bit ABI and both 32-bit ABIs, at least 3/4 of the complexity for parameter passing was present just for the 32-bit ABI, and we didn't even support everything we might have. The second level was that we needed to be supporting the 64-bit ABI, and there was never much question in our minds that it needed to be different. All of the reasons above apply, with the additional observation that now 64-bit addresses/pointers are everywhere, so the issues regarding 64-bit parameters and temporaries are immediately important. (Again, an extension of the old 32-bit ABI was defined, but it was _ugly_.) Given this, and looking some years into the future, supporting a 32-bit ABI that was essentially the same except for data type sizes was a much more attractive prospect than having two completely incompatible ones. Now at this point you're thinking, "but I wanted to know why you had a 32-bit ABI at all instead of just the 64-bit ABI." So I'll take a shot at that too. Again performance was an issue. Most data is small. 32-bit ints are adequate almost always, and most programs are small enough that 32-bit pointers are too. A program compiled with a 32-bit ABI is generally significantly smaller than one compiled for a 64-bit ABI, and the difference shows up in cache behavior. This we did quantify to some extent, because we had easily comparable ABIs. Though I don't recall the real data, I think we found that the average benefit was a few percent. Often it was zero, but occasionally it was much larger, corresponding to programs poised at the cache-size cliff. So there was a performance benefit to programs that didn't need the address space afforded to 64-bit programs, a shrinking but still large percentage. But for this case, the more important issue was porting effort. The vast majority of existing applications were written for 32-bit ABIs. Many, even most, are written cleanly enough to be easily ported to a 64-bit ABI. But there are usually a few issues (e.g. someone saves a pointer value in an int), and sometimes they are a big deal. And it's something customers dread even if it eventually turns out not to be so bad. So we believed that we needed to continue to support a 32-bit ABI even on 64-bit systems, and that its use would continue to be widespread enough that its performance was still important. (You probably recall that DEC, which preceded MIPS/SGI by a bit in the 64-bit world, initially attempted to support only 64-bit software, but ended up backing off. So there's evidence besides SGI's biases.) The downside to each distinct supported ABI was that they fragmented the available library base (from 3rd-party vendors), since many of them resisted supporting more than one (or two) ABIs on a platform. That turns out to be a significant issue for a company like SGI, and it's not clear to me in retrospect that the new 32-bit ABI was the right thing to do overall, though it was clearly technically superior. There were enough other issues during that period that we'll probably never be sure. Anyway, that's the view of the person responsible. Hopefully, a bit of history can aid the discussion. -Jeff Broughton From carstenl@mips.com Mon Sep 9 14:16:25 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 14:16:26 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:30117 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 14:16:25 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g89CGGUD004226; Mon, 9 Sep 2002 05:16:17 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id FAA03562; Mon, 9 Sep 2002 05:16:17 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g89CGDb24282; Mon, 9 Sep 2002 14:16:13 +0200 (MEST) Message-ID: <3D7C910A.6D217586@mips.com> Date: Mon, 09 Sep 2002 14:16:10 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@linux-mips.org Subject: 64-bit kernel patch Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips I have send this patch before, although it's a little bit different from the previous one. The patch fixes the ipc syscalls in the o32 wrapper/conversion routines, which is needed when running a 64-bit kernel on an o32 userland. Ralf, could you please apply. /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 carstenl@mips.com Mon Sep 9 15:04:00 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 15:04:01 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:10406 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 15:04:00 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g89D3pUD004393; Mon, 9 Sep 2002 06:03:51 -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 GAA04365; Mon, 9 Sep 2002 06:03:52 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g89D3nb28551; Mon, 9 Sep 2002 15:03:49 +0200 (MEST) Message-ID: <3D7C9C34.AC04A4B@mips.com> Date: Mon, 09 Sep 2002 15:03:48 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit kernel patch References: <3D7C910A.6D217586@mips.com> Content-Type: multipart/mixed; boundary="------------3A830A5615E2F5B16D6844EB" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------3A830A5615E2F5B16D6844EB Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit OK, I try again. This time with the patch attached. /Carsten Carsten Langgaard wrote: > I have send this patch before, although it's a little bit different from > the previous one. > The patch fixes the ipc syscalls in the o32 wrapper/conversion routines, > which is needed when running a 64-bit kernel on an o32 userland. > Ralf, could you please apply. > > /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 -- _ _ ____ ___ 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 --------------3A830A5615E2F5B16D6844EB Content-Type: text/plain; charset=iso-8859-15; name="ipc.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipc.patch" Index: arch/mips64/kernel/linux32.c =================================================================== RCS file: /cvs/linux/arch/mips64/kernel/linux32.c,v retrieving revision 1.42.2.9 diff -u -r1.42.2.9 linux32.c --- arch/mips64/kernel/linux32.c 2002/07/23 12:26:09 1.42.2.9 +++ arch/mips64/kernel/linux32.c 2002/09/09 12:06:04 @@ -35,8 +35,16 @@ #include #include - +/* Use this to get at 32-bit user passed pointers. */ +/* A() macro should be used for places where you e.g. + have some internal variable u32 and just want to get + rid of a compiler warning. AA() has to be used in + places where you want to convert a function argument + to 32bit pointer or when you e.g. access pt_regs + structure and want to consider 32bit registers only. + */ #define A(__x) ((unsigned long)(__x)) +#define AA(__x) ((unsigned long)((int)__x)) #ifdef __MIPSEB__ #define merge_64(r1,r2) ((((r1) & 0xffffffffUL) << 32) + ((r2) & 0xffffffffUL)) @@ -1494,6 +1502,19 @@ unsigned short seq; }; +struct ipc64_perm32 { + key_t key; + __kernel_uid_t32 uid; + __kernel_gid_t32 gid; + __kernel_uid_t32 cuid; + __kernel_gid_t32 cgid; + __kernel_mode_t32 mode; + unsigned short seq; + unsigned short __pad1; + unsigned int __unused1; + unsigned int __unused2; +}; + struct semid_ds32 { struct ipc_perm32 sem_perm; /* permissions .. see ipc.h */ __kernel_time_t32 sem_otime; /* last semop time */ @@ -1522,6 +1543,23 @@ __kernel_ipc_pid_t32 msg_lrpid; }; +struct msqid64_ds32 { + struct ipc64_perm32 msg_perm; + __kernel_time_t32 msg_stime; + unsigned int __unused1; + __kernel_time_t32 msg_rtime; + unsigned int __unused2; + __kernel_time_t32 msg_ctime; + unsigned int __unused3; + unsigned int msg_cbytes; + unsigned int msg_qnum; + unsigned int msg_qbytes; + __kernel_pid_t32 msg_lspid; + __kernel_pid_t32 msg_lrpid; + unsigned int __unused4; + unsigned int __unused5; +}; + struct shmid_ds32 { struct ipc_perm32 shm_perm; int shm_segsz; @@ -1533,7 +1571,10 @@ unsigned short shm_nattch; }; -#define IPCOP_MASK(__x) (1UL << (__x)) +struct ipc_kludge32 { + u32 msgp; + s32 msgtyp; +}; static int do_sys32_semctl(int first, int second, int third, void *uptr) @@ -1600,21 +1641,23 @@ return err; } -static int do_sys32_msgsnd (int first, int second, int third, void *uptr) { - struct msgbuf *p = kmalloc (second + sizeof (struct msgbuf) - + 4, GFP_USER); struct msgbuf32 *up = (struct msgbuf32 *)uptr; + struct msgbuf *p; mm_segment_t old_fs; int err; + if (second < 0) + return -EINVAL; + p = kmalloc (second + sizeof (struct msgbuf) + + 4, GFP_USER); if (!p) return -ENOMEM; err = get_user (p->mtype, &up->mtype); if (err) goto out; - err = __copy_from_user (p->mtext, &up->mtext, second); + err |= __copy_from_user (p->mtext, &up->mtext, second); if (err) goto out; old_fs = get_fs (); @@ -1623,6 +1666,7 @@ set_fs (old_fs); out: kfree (p); + return err; } @@ -1636,18 +1680,21 @@ int err; if (!version) { - struct ipc_kludge *uipck = (struct ipc_kludge *)uptr; - struct ipc_kludge ipck; + struct ipc_kludge32 *uipck = (struct ipc_kludge32 *)uptr; + struct ipc_kludge32 ipck; err = -EINVAL; if (!uptr) goto out; err = -EFAULT; - if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge))) + if (copy_from_user (&ipck, uipck, sizeof (struct ipc_kludge32))) goto out; - uptr = (void *)A(ipck.msgp); + uptr = (void *)AA(ipck.msgp); msgtyp = ipck.msgtyp; } + + if (second < 0) + return -EINVAL; err = -ENOMEM; p = kmalloc (second + sizeof (struct msgbuf) + 4, GFP_USER); if (!p) @@ -1672,13 +1719,12 @@ do_sys32_msgctl (int first, int second, void *uptr) { int err = -EINVAL, err2; - struct msqid_ds m; - struct msqid64_ds m64; - struct msqid_ds32 *up = (struct msqid_ds32 *)uptr; + struct msqid64_ds m; + struct msqid_ds32 *up32 = (struct msqid_ds32 *)uptr; + struct msqid64_ds32 *up64 = (struct msqid64_ds32 *)uptr; mm_segment_t old_fs; - switch (second) { - + switch (second & ~IPC_64) { case IPC_INFO: case IPC_RMID: case MSG_INFO: @@ -1686,15 +1732,30 @@ break; case IPC_SET: - err = get_user (m.msg_perm.uid, &up->msg_perm.uid); - err |= __get_user (m.msg_perm.gid, &up->msg_perm.gid); - err |= __get_user (m.msg_perm.mode, &up->msg_perm.mode); - err |= __get_user (m.msg_qbytes, &up->msg_qbytes); + if (second & IPC_64) { + if (!access_ok(VERIFY_READ, up64, sizeof(*up64))) { + err = -EFAULT; + break; + } + err = __get_user(m.msg_perm.uid, &up64->msg_perm.uid); + err |= __get_user(m.msg_perm.gid, &up64->msg_perm.gid); + err |= __get_user(m.msg_perm.mode, &up64->msg_perm.mode); + err |= __get_user(m.msg_qbytes, &up64->msg_qbytes); + } else { + if (!access_ok(VERIFY_READ, up32, sizeof(*up32))) { + err = -EFAULT; + break; + } + err = __get_user(m.msg_perm.uid, &up32->msg_perm.uid); + err |= __get_user(m.msg_perm.gid, &up32->msg_perm.gid); + err |= __get_user(m.msg_perm.mode, &up32->msg_perm.mode); + err |= __get_user(m.msg_qbytes, &up32->msg_qbytes); + } if (err) break; old_fs = get_fs (); set_fs (KERNEL_DS); - err = sys_msgctl (first, second, &m); + err = sys_msgctl (first, second, (struct msqid_ds *)&m); set_fs (old_fs); break; @@ -1702,27 +1763,54 @@ case MSG_STAT: old_fs = get_fs (); set_fs (KERNEL_DS); - err = sys_msgctl (first, second, (void *) &m64); + err = sys_msgctl (first, second, (struct msqid_ds *)&m); set_fs (old_fs); - err2 = put_user (m64.msg_perm.key, &up->msg_perm.key); - err2 |= __put_user(m64.msg_perm.uid, &up->msg_perm.uid); - err2 |= __put_user(m64.msg_perm.gid, &up->msg_perm.gid); - err2 |= __put_user(m64.msg_perm.cuid, &up->msg_perm.cuid); - err2 |= __put_user(m64.msg_perm.cgid, &up->msg_perm.cgid); - err2 |= __put_user(m64.msg_perm.mode, &up->msg_perm.mode); - err2 |= __put_user(m64.msg_perm.seq, &up->msg_perm.seq); - err2 |= __put_user(m64.msg_stime, &up->msg_stime); - err2 |= __put_user(m64.msg_rtime, &up->msg_rtime); - err2 |= __put_user(m64.msg_ctime, &up->msg_ctime); - err2 |= __put_user(m64.msg_cbytes, &up->msg_cbytes); - err2 |= __put_user(m64.msg_qnum, &up->msg_qnum); - err2 |= __put_user(m64.msg_qbytes, &up->msg_qbytes); - err2 |= __put_user(m64.msg_lspid, &up->msg_lspid); - err2 |= __put_user(m64.msg_lrpid, &up->msg_lrpid); - if (err2) - err = -EFAULT; + if (second & IPC_64) { + if (!access_ok(VERIFY_WRITE, up64, sizeof(*up64))) { + err = -EFAULT; + break; + } + err2 = __put_user(m.msg_perm.key, &up64->msg_perm.key); + err2 |= __put_user(m.msg_perm.uid, &up64->msg_perm.uid); + err2 |= __put_user(m.msg_perm.gid, &up64->msg_perm.gid); + err2 |= __put_user(m.msg_perm.cuid, &up64->msg_perm.cuid); + err2 |= __put_user(m.msg_perm.cgid, &up64->msg_perm.cgid); + err2 |= __put_user(m.msg_perm.mode, &up64->msg_perm.mode); + err2 |= __put_user(m.msg_perm.seq, &up64->msg_perm.seq); + err2 |= __put_user(m.msg_stime, &up64->msg_stime); + err2 |= __put_user(m.msg_rtime, &up64->msg_rtime); + err2 |= __put_user(m.msg_ctime, &up64->msg_ctime); + err2 |= __put_user(m.msg_cbytes, &up64->msg_cbytes); + err2 |= __put_user(m.msg_qnum, &up64->msg_qnum); + err2 |= __put_user(m.msg_qbytes, &up64->msg_qbytes); + err2 |= __put_user(m.msg_lspid, &up64->msg_lspid); + err2 |= __put_user(m.msg_lrpid, &up64->msg_lrpid); + if (err2) + err = -EFAULT; + } else { + if (!access_ok(VERIFY_WRITE, up32, sizeof(*up32))) { + err = -EFAULT; + break; + } + err2 = __put_user(m.msg_perm.key, &up32->msg_perm.key); + err2 |= __put_user(m.msg_perm.uid, &up32->msg_perm.uid); + err2 |= __put_user(m.msg_perm.gid, &up32->msg_perm.gid); + err2 |= __put_user(m.msg_perm.cuid, &up32->msg_perm.cuid); + err2 |= __put_user(m.msg_perm.cgid, &up32->msg_perm.cgid); + err2 |= __put_user(m.msg_perm.mode, &up32->msg_perm.mode); + err2 |= __put_user(m.msg_perm.seq, &up32->msg_perm.seq); + err2 |= __put_user(m.msg_stime, &up32->msg_stime); + err2 |= __put_user(m.msg_rtime, &up32->msg_rtime); + err2 |= __put_user(m.msg_ctime, &up32->msg_ctime); + err2 |= __put_user(m.msg_cbytes, &up32->msg_cbytes); + err2 |= __put_user(m.msg_qnum, &up32->msg_qnum); + err2 |= __put_user(m.msg_qbytes, &up32->msg_qbytes); + err2 |= __put_user(m.msg_lspid, &up32->msg_lspid); + err2 |= __put_user(m.msg_lrpid, &up32->msg_lrpid); + if (err2) + err = -EFAULT; + } break; - } return err; @@ -1845,7 +1933,7 @@ case SEMOP: /* struct sembuf is the same on 32 and 64bit :)) */ - err = sys_semop (first, (struct sembuf *)A(ptr), + err = sys_semop (first, (struct sembuf *)AA(ptr), second); break; case SEMGET: @@ -1853,27 +1941,27 @@ break; case SEMCTL: err = do_sys32_semctl (first, second, third, - (void *)A(ptr)); + (void *)AA(ptr)); break; case MSGSND: err = do_sys32_msgsnd (first, second, third, - (void *)A(ptr)); + (void *)AA(ptr)); break; case MSGRCV: err = do_sys32_msgrcv (first, second, fifth, third, - version, (void *)A(ptr)); + version, (void *)AA(ptr)); break; case MSGGET: err = sys_msgget ((key_t) first, second); break; case MSGCTL: - err = do_sys32_msgctl (first, second, (void *)A(ptr)); + err = do_sys32_msgctl (first, second, (void *)AA(ptr)); break; case SHMAT: err = do_sys32_shmat (first, second, third, - version, (void *)A(ptr)); + version, (void *)AA(ptr)); break; case SHMDT: err = sys_shmdt ((char *)A(ptr)); @@ -1882,7 +1970,7 @@ err = sys_shmget (first, second, third); break; case SHMCTL: - err = do_sys32_shmctl (first, second, (void *)A(ptr)); + err = do_sys32_shmctl (first, second, (void *)AA(ptr)); break; default: err = -EINVAL; --------------3A830A5615E2F5B16D6844EB-- From dom@algor.co.uk Mon Sep 9 16:02:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 16:02:07 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:46786 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 16:02:07 +0200 Received: from gladsmuir.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g89E1ir21266; Mon, 9 Sep 2002 15:01:49 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15740.43464.282405.987558@gladsmuir.algor.co.uk> Date: Mon, 9 Sep 2002 15:01:44 +0100 To: Ralf Baechle Cc: "Maciej W. Rozycki" , Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020906121424.E2993@linux-mips.org> References: <20020905142249.GA15843@nevyn.them.org> <20020906121424.E2993@linux-mips.org> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Ralf Baechle (ralf@linux-mips.org) writes: > In the SGI world o32 basically has been killed - there no more 32-bit > processors shipped since many years. So most SGI MIPS systems are > running N32 code by standard and N64 is available as an option which only > is used for the small number of applications that actually are going to > gain from it. O32 is deprecated; at this time it's just historical garbage. True: but just to emphasise that's SGI. There are still lots of 32-bit MIPS CPUs about (which can't run n32/n64, of course) which may want to run Linux, and for now o32 is all that is available to them. Dominic From macro@ds2.pg.gda.pl Mon Sep 9 19:39:02 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 19:39:02 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:18361 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 19:39:02 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA03069; Mon, 9 Sep 2002 19:39:12 +0200 (MET DST) Date: Mon, 9 Sep 2002 19:39:12 +0200 (MET DST) From: "Maciej W. Rozycki" To: Thiemo Seufer cc: Daniel Jacobowitz , "Kevin D. Kissell" , Tor Arntsen , Carsten Langgaard , Ralf Baechle , linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020905221221.GX4194@rembrandt.csv.ica.uni-stuttgart.de> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 6 Sep 2002, Thiemo Seufer wrote: > I agree. And I believe in the "least surprise" principle, which means > we shouldn't deviate from widely known conventions without good reason. > I still don't see the advantage of a 64 bit long in n32. Well, for me it's more surprising to see long not sufficient to contain data of the register width than to see the width of long being different from the width of a pointer. The latter I've already seen (both ways). The former is new to me. Others may have different experiences, though. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From macro@ds2.pg.gda.pl Mon Sep 9 20:17:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 20:17:39 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:5050 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 20:17:38 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA03572; Mon, 9 Sep 2002 20:17:54 +0200 (MET DST) Date: Mon, 9 Sep 2002 20:17:53 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jun Sun cc: Matthew Dharm , Linux-MIPS Subject: Re: LOADADDR and low physical addresses? In-Reply-To: <20020906144232.E1382@mvista.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 6 Sep 2002, Jun Sun wrote: > > And this is where I think the add_memory_region() magic might need to > > happen. Do I need to add the on-chip SRAM and control registers using > > add_memory_region()? > > I don't think you have to. I *think* it works if you don't. Not sure > know if you actuall do add. Well, you have to register usable RAM areas with add_memory_region(), if you want to make them available to Linux. Adding other ranges is optional but you have to consider a part of the kernel may want to know if the range is usable or occupied (consider e.g. the PCI setup code modifying BARs). It's also nice and sometimes useful to a user to let him see what space is occupied. What you register with add_memory_region() is printed upon boot and available from /proc/iomem. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From nop@nop.com Mon Sep 9 22:20:45 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 22:20:45 +0200 (CEST) Received: from place.org ([65.163.18.18]:65492 "EHLO zachs.place.org") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 22:20:45 +0200 Received: by zachs.place.org (Postfix, from userid 1002) id D9A6A182F9; Mon, 9 Sep 2002 15:20:36 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zachs.place.org (Postfix) with ESMTP id 5BD3518187; Mon, 9 Sep 2002 15:20:36 -0500 (CDT) Date: Mon, 9 Sep 2002 15:20:36 -0500 (CDT) From: Jay Carlson X-X-Sender: nop@zachs.place.org To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces In-Reply-To: <20020904155645.A31893@linux-mips.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 152 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nop@nop.com Precedence: bulk X-list: linux-mips On Wed, 4 Sep 2002, Ralf Baechle wrote: > #define __NR_uselib (__NR_Linux + 86) > > a.out support. Do we really want that. Well, it's support for Linux-a.out-style shared libraries, which are actually binary-format independent. Quick summary of how they work in ELF: The file argument to uselib must have 1 or 2 program headers. Exactly one of them must be PT_LOAD. That segment is loaded at the fixed virtual address specified in in the header. It's marked readable, writable, executable, and any BSS region is zeroed. I contemplated using uselib(2) in snow and decided that I wanted multiple segments to support text and rodata being read-only. I figured that attempting to communicate the read-only nature of the maps to the VM could elicit more efficient behavior. Anyway, now that we have ELF interpreters you can get one library loaded into core for you by the kernel. That library can define a more reasonable version of uselib in userspace... I guess my point is that even the tiny set of people doing statically linked shared libraries will probably avoid this syscall. Jay From cjmitch@rsc.co.uk Mon Sep 9 22:31:31 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 22:31:32 +0200 (CEST) Received: from colossus.systems.pipex.net ([62.241.160.73]:41707 "EHLO colossus.systems.pipex.net") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 22:31:31 +0200 Received: from bigyin (userds45.uk.uudial.com [62.188.6.151]) by colossus.systems.pipex.net (Postfix) with SMTP id C838916000624 for ; Mon, 9 Sep 2002 21:31:23 +0100 (BST) Message-ID: <004601c2583f$d6e8f350$9706bc3e@bigyin> From: "Render Dynamics Ltd." To: Subject: Date: Mon, 9 Sep 2002 21:31:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C25848.37FA8610" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 153 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: cjmitch@rsc.co.uk Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C25848.37FA8610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe linux-mips ------=_NextPart_000_0043_01C25848.37FA8610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe linux-mips
------=_NextPart_000_0043_01C25848.37FA8610-- From chris@render-dynamics.com Mon Sep 9 22:32:50 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Sep 2002 22:32:50 +0200 (CEST) Received: from colossus.systems.pipex.net ([62.241.160.73]:63467 "EHLO colossus.systems.pipex.net") by linux-mips.org with ESMTP id ; Mon, 9 Sep 2002 22:32:50 +0200 Received: from bigyin (userds45.uk.uudial.com [62.188.6.151]) by colossus.systems.pipex.net (Postfix) with SMTP id 8BA9816000567 for ; Mon, 9 Sep 2002 21:32:43 +0100 (BST) Message-ID: <004f01c25840$06711260$9706bc3e@bigyin> Reply-To: "Render Dynamics Ltd." From: "Render Dynamics Ltd." To: Subject: Date: Mon, 9 Sep 2002 21:32:31 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C25848.679060C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: chris@render-dynamics.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C25848.679060C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsubscribe linux-mips ------=_NextPart_000_004C_01C25848.679060C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe linux-mips
------=_NextPart_000_004C_01C25848.679060C0-- From carstenl@mips.com Tue Sep 10 13:55:45 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Sep 2002 13:55:45 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:1977 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Tue, 10 Sep 2002 13:55:45 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8ABtMUD008902; Tue, 10 Sep 2002 04:55: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 EAA18146; Tue, 10 Sep 2002 04:55:23 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g8ABtKb03509; Tue, 10 Sep 2002 13:55:20 +0200 (MEST) Message-ID: <3D7DDDA6.7327CA34@mips.com> Date: Tue, 10 Sep 2002 13:55:18 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , linux-mips@linux-mips.org Subject: FP emulator patch Content-Type: multipart/mixed; boundary="------------21F78C6EBA981D15B3EF21F1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 155 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------21F78C6EBA981D15B3EF21F1 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit This patch fix a bug in the FP emulator, when used in the 64-bit kernel. Ralf, could you please apply. /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 --------------21F78C6EBA981D15B3EF21F1 Content-Type: text/plain; charset=iso-8859-15; name="fpe.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fpe.patch" Index: arch/mips/math-emu/cp1emu.c =================================================================== RCS file: /cvs/linux/arch/mips/math-emu/cp1emu.c,v retrieving revision 1.13.2.9 diff -u -r1.13.2.9 cp1emu.c --- arch/mips/math-emu/cp1emu.c 2002/08/05 23:53:34 1.13.2.9 +++ arch/mips/math-emu/cp1emu.c 2002/09/10 11:47:22 @@ -168,8 +168,8 @@ #define SIFROMREG(si,x) ((si) = \ (xcp->cp0_status & FR_BIT) || !(x & 1) ? \ - ctx->regs[x] : \ - ctx->regs[x & ~1] >> 32 ) + (int)ctx->regs[x] : \ + (int)(ctx->regs[x & ~1] >> 32 )) #define SITOREG(si,x) (ctx->regs[x & ~((xcp->cp0_status & FR_BIT) == 0)] = \ (xcp->cp0_status & FR_BIT) || !(x & 1) ? \ ctx->regs[x & ~1] >> 32 << 32 | (u32)(si) : \ --------------21F78C6EBA981D15B3EF21F1-- From merker@linuxtag.org Tue Sep 10 23:01:54 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 10 Sep 2002 23:01:55 +0200 (CEST) Received: from cassidy.nuernberg.linuxtag.net ([212.204.83.80]:8973 "EHLO cassidy.nuernberg.linuxtag.net") by linux-mips.org with ESMTP id ; Tue, 10 Sep 2002 23:01:54 +0200 Received: by cassidy.nuernberg.linuxtag.net (Postfix, from userid 1006) id 9790EEC280; Tue, 10 Sep 2002 23:05:17 +0200 (CEST) Received: from hydra.linuxtag.uni-kl.de (VPN-Hydra [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id A9816EC0F6 for ; Tue, 10 Sep 2002 23:05:14 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id 35D691DD5; Tue, 10 Sep 2002 23:01:40 +0200 (CEST) Delivered-To: merker@linuxtag.org Received: from cassidy.nuernberg.linuxtag.net (unknown [192.168.200.1]) by hydra.linuxtag.uni-kl.de (Postfix) with ESMTP id 8A4A51D37 for ; Tue, 10 Sep 2002 21:00:49 +0000 (UTC) Received: by cassidy.nuernberg.linuxtag.net (Postfix, from userid 1006) id AEF93EC280; Tue, 10 Sep 2002 23:04:23 +0200 (CEST) Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id AEAC4EC0F6 for ; Tue, 10 Sep 2002 23:04:20 +0200 (CEST) Received: from excalibur.cologne.de (p508510F9.dip.t-dialin.net [80.133.16.249]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id XAA04022 for ; Tue, 10 Sep 2002 23:00:47 +0200 (MET DST) Resent-From: karsten@excalibur.cologne.de Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian)) id 17osCd-0001jp-00 for ; Tue, 10 Sep 2002 23:05:43 +0200 Date: Tue, 10 Sep 2002 22:48:41 +0200 From: Karsten Merker To: linux-mips@linux-mips.org Cc: p2@mind.be Subject: Cobalt NASRaq patches Message-ID: <20020910204841.GA6525@excalibur.cologne.de> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org, p2@mind.be Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-No-Archive: yes Resent-Date: Tue, 10 Sep 2002 23:05:42 +0200 Resent-To: merker@linuxtag.org Resent-Message-Id: Resent-From: merker@linuxtag.org Resent-Date: Tue, 10 Sep 2002 23:01:40 +0200 Resent-To: linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hallo everybody, Peter de Schrijver and I have been working on the support for the Cobalt NASRaq. The results are several patches, of which the first three are IMHO ready for inclusion into oss cvs (patches are short and self-explaining and should not have any side effects). These are: - cobalt-2.4-20020908-2-galileo.diff Small change in the code fragment distinguishing between "old" and "new" galileo chipsets). The old code did not take into account that there are systems with newer chip revisions than 0x10. - cobalt-2.4-20020908-2-rootdev.diff Allow setting the root device through a config option. The firmware of the MIPS-based Cobalt systems does not allow to pass commandline parameters to the kernel, so the root device has to be compiled in. - cobalt-2.4-20020908-2-serial.diff The NASRaq has an ST16C650 serial controller, which has some differences in the register set in comparison to the standard 16C550 which need to be handled. Besides these, the tulip driver needs some patches, too. These are not yet ready for inclusion into cvs and will be submitted later. Ralf, Maciej, could you please apply the appended patches? Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cobalt-2.4-20020908-2-galileo.diff" diff -Nur linux-mips-cvs/arch/mips/cobalt/pci.c linux-cobalt/arch/mips/cobalt/pci.c --- linux-mips-cvs/arch/mips/cobalt/pci.c Thu Aug 15 09:56:41 2002 +++ linux-cobalt/arch/mips/cobalt/pci.c Sun Sep 8 22:25:16 2002 @@ -8,6 +8,9 @@ * Copyright (C) 1995, 1996, 1997 by Ralf Baechle * Copyright (C) 2001 by Liam Davies (ldavies@agile.tv) * + * 2002/09/08 changed qube_raq_galileo_fixup to handle newer Galileo revisions + * Peter de Schrijver , + * Karsten Merker */ #include @@ -20,6 +23,8 @@ #include #include +#undef DEBUG + #ifdef CONFIG_PCI int cobalt_board_id; @@ -204,6 +209,10 @@ { unsigned short galileo_id; +#ifdef DEBUG + printk("pci.c: qube_raq_galileo_fixup: pci vendor id: %04x, pci device id: %04x\n",dev->vendor,dev->device); +#endif + /* Fix PCI latency-timer and cache-line-size values in Galileo * host bridge. */ @@ -219,7 +228,17 @@ */ pci_read_config_word(dev, PCI_REVISION_ID, &galileo_id); galileo_id &= 0xff; /* mask off class info */ - if (galileo_id == 0x10) { + + /* Originally the code checked only for existence of revision + * 0x10 (new Galileo) or 0x01/0x02 (old Galileo). At least in + * the NASRAQ there is a revision 0x11, which should probably + * be handled as new Galileo too, so we now check for + * galileo_id >= 0x10 instead of galileo_id == 0x10. + * Peter de Schrijver , + * Karsten Merker , 2002/09/08 + */ + + if (galileo_id >= 0x10) { /* New Galileo, assumes PCI stop line to VIA is connected. */ *((volatile unsigned int *)0xb4000c04) = 0x00004020; } else if (galileo_id == 0x1 || galileo_id == 0x2) { --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cobalt-2.4-20020908-2-rootdev.diff" diff -Nur linux-mips-cvs/Documentation/Configure.help linux-cobalt/Documentation/Configure.help --- linux-mips-cvs/Documentation/Configure.help Thu Jun 27 00:34:59 2002 +++ linux-cobalt/Documentation/Configure.help Sun Sep 8 22:55:06 2002 @@ -2336,6 +2336,15 @@ behaviour is platform-dependent, but normally the flash frequency is a hyperbolic function of the 5-minute load average. +Root device for the MIPS-based Cobalt systems +CONFIG_COBALT_MIPS_ROOTDEVICE + The firmware of the MIPS-based Cobalt systems does not allow to + specify a kernel command line, so it has to be compiled into the + kernel. This includes the root device to use, so you have to change + this option and recompile the kernel to use another root partition. + Please note that this option is overridden by CONFIG_ROOT_NFS, + which implies a "root=/dev/nfs rw". + Networking support CONFIG_NET Unless you really know what you are doing, you should say Y here. diff -Nur linux-mips-cvs/arch/mips/cobalt/setup.c linux-cobalt/arch/mips/cobalt/setup.c --- linux-mips-cvs/arch/mips/cobalt/setup.c Thu Aug 15 10:03:21 2002 +++ linux-cobalt/arch/mips/cobalt/setup.c Sun Sep 8 22:40:44 2002 @@ -8,6 +8,14 @@ * Copyright (C) 1996, 1997 by Ralf Baechle * Copyright (C) 2001 by Liam Davies (ldavies@agile.tv) * + * 2002/09/08 added CONFIG_COBALT_MIPS_ROOTDEVICE option + * The Cobalt firmware does not allow to specify a kernel command + * line, so it has to be compiled into the kernel. Made the + * root device a config option so one does not always have to + * modify the sources to boot from another partition. + * Peter de Schrijver , + * Karsten Merker + * */ #include @@ -34,6 +42,9 @@ extern struct rtc_ops std_rtc_ops; extern struct ide_ops std_ide_ops; +#ifndef CONFIG_COBALT_MIPS_ROOTDEVICE +#define CONFIG_COBALT_MIPS_ROOTDEVICE "/dev/hda1" +#endif char arcs_cmdline[CL_SIZE] = { "console=ttyS0,115200 " @@ -41,9 +52,9 @@ "ip=on " #endif #ifdef CONFIG_ROOT_NFS - "root=/dev/nfs " + "root=/dev/nfs rw " #else - "root=/dev/hda1 " + "root=" CONFIG_COBALT_MIPS_ROOTDEVICE #endif }; diff -Nur linux-mips-cvs/arch/mips/config-shared.in linux-cobalt/arch/mips/config-shared.in --- linux-mips-cvs/arch/mips/config-shared.in Tue Sep 3 01:34:10 2002 +++ linux-cobalt/arch/mips/config-shared.in Sun Sep 8 22:42:57 2002 @@ -584,6 +584,10 @@ bool ' ISA bus support' CONFIG_ISA fi +if [ "$CONFIG_MIPS_COBALT" = "y" ]; then + string 'Cobalt systems root device' CONFIG_COBALT_MIPS_ROOTDEVICE "/dev/hda1" +fi + bool 'Networking support' CONFIG_NET if [ "$CONFIG_PCI" != "y" ]; then --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cobalt-2.4-20020908-2-serial.diff" diff -Nur linux-mips-cvs/drivers/char/serial.c linux-cobalt/drivers/char/serial.c --- linux-mips-cvs/drivers/char/serial.c Wed Jul 24 15:51:48 2002 +++ linux-cobalt/drivers/char/serial.c Sun Sep 8 23:35:08 2002 @@ -68,6 +68,14 @@ * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, * carstenl@mips.com * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + * + * 2002/09/08 fixed handling of the ST16C650 UART + * The ST16C650, which is used in the Cobalt NASRAQ, differs + * from the "normal" 16C550 regarding the FIFO handling and needs + * special treatment (e.g. FIFO trigger level bits are defined + * differently than for the 16C550). + * Peter de Schrijver , Karsten Merker + * */ static char *serial_version = "5.05c"; @@ -307,8 +315,15 @@ { "16550A", 16, UART_CLEAR_FIFO | UART_USE_FIFO }, { "cirrus", 1, 0 }, /* usurped by cyclades.c */ { "ST16650", 1, UART_CLEAR_FIFO | UART_STARTECH }, - { "ST16650V2", 32, UART_CLEAR_FIFO | UART_USE_FIFO | - UART_STARTECH }, + { "ST16650V2", 16, UART_CLEAR_FIFO | UART_USE_FIFO | + UART_STARTECH }, /* Although the datasheet indicates a 32byte + Tx FIFO size, the lowest possible trigger + level is 8 bytes, which effectively should + give us a 24 byte guaranteed FIFO. But + testing has indicated this doesn't work, + although it's unclear why. + Limiting the Tx FIFO size to 16bytes does + work. */ { "TI16750", 64, UART_CLEAR_FIFO | UART_USE_FIFO}, { "Startech", 1, 0}, /* usurped by cyclades.c */ { "16C950/954", 128, UART_CLEAR_FIFO | UART_USE_FIFO}, @@ -1753,6 +1768,10 @@ else if (info->state->type == PORT_RSA) fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_14; #endif + else if (info->state->type == PORT_16650V2) { + fcr = UART_FCR_ENABLE_FIFO | UART_FCR6_R_TRIGGER_8 + | UART_FCR6_T_TRIGGER_8; + } else fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_8; } --vtzGhvizbBRQ85DL-- From rmurray@cyberhqz.com Wed Sep 11 05:28:41 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Sep 2002 05:28:41 +0200 (CEST) Received: from h24-83-208-253.sbm.shawcable.net ([24.83.208.253]:31632 "EHLO straylight.cyberhqz.com") by linux-mips.org with ESMTP id ; Wed, 11 Sep 2002 05:28:41 +0200 Received: from cyberhq.internal.cyberhqz.com (cyberhq.internal.cyberhqz.com [192.168.0.2]) by straylight.cyberhqz.com (Postfix) with ESMTP id BCBAA5400B; Tue, 10 Sep 2002 20:28:33 -0700 (PDT) Received: by cyberhq.internal.cyberhqz.com (Postfix, from userid 1000) id 326C41B96A9; Tue, 10 Sep 2002 20:28:32 -0700 (PDT) Date: Tue, 10 Sep 2002 20:28:32 -0700 From: Ryan Murray To: linux-mips@linux-mips.org Cc: libc-alpha@sources.redhat.com Subject: [patch] userspace mcontext_t doesn't match what kernel returns Message-ID: <20020911032832.GA1500@cyberhqz.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 157 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rmurray@debian.org Precedence: bulk X-list: linux-mips --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, The definition of mcontext_t in sysdeps/unix/sysv/linux/mips/sys/ucontext.h does not match what the kernel copies to userspace (struct sigcontext). alpha, ia64, and hppa have fixed this by typedefing one to the other in sys/ucontext.h The following patch accomplishes the same thing for mips. --=20 Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own. --- sysdeps/unix/sysv/linux/mips/sys/ucontext.h 2002-09-10 20:16:52.0000000= 00 -0700 +++ sysdeps/unix/sysv/linux/mips/sys/ucontext.h 2002-09-10 20:17:24.0000000= 00 -0700 @@ -61,11 +61,7 @@ =20 =20 /* Context to describe whole processor state. */ -typedef struct - { - gregset_t gregs; - fpregset_t fpregs; - } mcontext_t; +typedef struct sigcontext mcontext_t; =20 /* Userlevel context. */ typedef struct ucontext --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9frhfN2Dbz/1mRasRAlH7AKDGz4kHoyBsQOyOSdXeuUFhcbBEaQCeI5yX LLrN33jUyyS4Yny5Pl/kwWE= =mPJS -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From sjhill@realitydiluted.com Wed Sep 11 21:06:08 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Sep 2002 21:06:09 +0200 (CEST) Received: from real.realitydiluted.com ([208.242.241.164]:60124 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Wed, 11 Sep 2002 21:06:08 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17p87y-0007kV-00; Wed, 11 Sep 2002 09:05:58 -0500 Message-ID: <3D7F9414.2020305@realitydiluted.com> Date: Wed, 11 Sep 2002 14:05:56 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 X-Accept-Language: en MIME-Version: 1.0 To: uclibc.@uclibc.org, linux-mips@linux-mips.org Subject: New uClibc-0.9.15 cross toolchains for MIPS... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Greetings. I am pleased to announce new cross toolchains for uClibc based MIPS big and little endian compilers. These RPMS are for installation on a x86 host to produce uClibc binaries for MIPS targets. They can be downloaded from the following URL: ftp://ftp.realitydiluted.com/Linux/uclibc/ The RPMS are based off of the uClibc toolchain builder found at: http://www.us.kernel.org/pub/linux/libs/uclibc/toolchain/ This toolchain uses the following tool versions: binutils-2.13 gcc-3.2 uClibc-0.9.15 w/patches to uClibc CVS as of yesterday These toolchains can also be used to compile Linux MIPS kernels which I have been doing with no problems at all. Thanks and enjoy! -Steve From brian@murphy.dk Wed Sep 11 22:45:05 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 11 Sep 2002 22:45:06 +0200 (CEST) Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:51253 "EHLO ubik.localnet") by linux-mips.org with ESMTP id ; Wed, 11 Sep 2002 22:45:05 +0200 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g8BKiw6m014253 for ; Wed, 11 Sep 2002 22:44:58 +0200 Message-ID: <3D7FAB4A.4010802@murphy.dk> Date: Wed, 11 Sep 2002 22:44:58 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: linux-mips Subject: ide-dma bug Content-Type: multipart/mixed; boundary="------------060003010506000001030300" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------060003010506000001030300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit If I use the ide-dma.c from the current cvs (2.4 branch) then I get an error from ext2 when it tries to mount the root filesystem along the lines of ext2_check_page: bad entry in directory #2 By applying the attached patch I can continue (it reverses part of the change from the yesterday to today), i.e. I can boot the system. I may have time at some point to look at this problem, but it should not be isolated to mips(el) as far as I can see, so some experts are probably working at it as I write. /Brian --------------060003010506000001030300 Content-Type: application/x-java-vm; name="patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patch" SW5kZXg6IGlkZS1kbWEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL2xpbnV4LW1p cHMvZHJpdmVycy9pZGUvaWRlLWRtYS5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4y CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQpkaWZmIC11IC1yMS4xLjEuMiAtcjEuMS4x LjEKLS0tIGlkZS1kbWEuYwkxMSBTZXAgMjAwMiAxNzo1NzoxNCAtMDAwMAkxLjEuMS4yCisr KyBpZGUtZG1hLmMJMTggSnVsIDIwMDIgMTc6MzQ6NDggLTAwMDAJMS4xLjEuMQpAQCAtMjUy LDUzICsyNTIsMzMgQEAKIHsKIAlzdHJ1Y3QgYnVmZmVyX2hlYWQgKmJoOwogCXN0cnVjdCBz Y2F0dGVybGlzdCAqc2cgPSBod2lmLT5zZ190YWJsZTsKLQl1bnNpZ25lZCBsb25nIGxhc3Rk YXRhZW5kID0gfjBVTDsKIAlpbnQgbmVudHMgPSAwOwogCiAJaWYgKGh3aWYtPnNnX2RtYV9h Y3RpdmUpCiAJCUJVRygpOwotCisJCQogCWlmIChycS0+Y21kID09IFJFQUQpCiAJCWh3aWYt PnNnX2RtYV9kaXJlY3Rpb24gPSBQQ0lfRE1BX0ZST01ERVZJQ0U7CiAJZWxzZQogCQlod2lm LT5zZ19kbWFfZGlyZWN0aW9uID0gUENJX0RNQV9UT0RFVklDRTsKLQogCWJoID0gcnEtPmJo OwogCWRvIHsKLQkJc3RydWN0IHNjYXR0ZXJsaXN0ICpzZ2U7Ci0KLQkJLyoKLQkJICogY29u dGludWUgc2VnbWVudCBmcm9tIGJlZm9yZT8KLQkJICovCi0JCWlmIChiaF9waHlzKGJoKSA9 PSBsYXN0ZGF0YWVuZCkgewotCQkJc2dbbmVudHMgLSAxXS5sZW5ndGggKz0gYmgtPmJfc2l6 ZTsKLQkJCWxhc3RkYXRhZW5kICs9IGJoLT5iX3NpemU7Ci0JCQljb250aW51ZTsKLQkJfQor CQl1bnNpZ25lZCBjaGFyICp2aXJ0X2FkZHIgPSBiaC0+Yl9kYXRhOworCQl1bnNpZ25lZCBp bnQgc2l6ZSA9IGJoLT5iX3NpemU7CiAKLQkJLyoKLQkJICogc3RhcnQgbmV3IHNlZ21lbnQK LQkJICovCiAJCWlmIChuZW50cyA+PSBQUkRfRU5UUklFUykKIAkJCXJldHVybiAwOwogCi0J CXNnZSA9ICZzZ1tuZW50c107Ci0JCW1lbXNldChzZ2UsIDAsIHNpemVvZigqc2dlKSk7Ci0K LQkJaWYgKGJoLT5iX3BhZ2UpIHsKLQkJCXNnZS0+cGFnZSA9IGJoLT5iX3BhZ2U7Ci0JCQlz Z2UtPm9mZnNldCA9IGJoX29mZnNldChiaCk7Ci0JCX0gZWxzZSB7Ci0JCQlpZiAoKCh1bnNp Z25lZCBsb25nKSBiaC0+Yl9kYXRhKSA8IFBBR0VfU0laRSkKLQkJCQlCVUcoKTsKLQotCQkJ c2dlLT5hZGRyZXNzID0gYmgtPmJfZGF0YTsKKwkJd2hpbGUgKChiaCA9IGJoLT5iX3JlcW5l eHQpICE9IE5VTEwpIHsKKwkJCWlmICgodmlydF9hZGRyICsgc2l6ZSkgIT0gKHVuc2lnbmVk IGNoYXIgKikgYmgtPmJfZGF0YSkKKwkJCQlicmVhazsKKwkJCXNpemUgKz0gYmgtPmJfc2l6 ZTsKIAkJfQotCi0JCXNnZS0+bGVuZ3RoID0gYmgtPmJfc2l6ZTsKLQkJbGFzdGRhdGFlbmQg PSBiaF9waHlzKGJoKSArIGJoLT5iX3NpemU7CisJCW1lbXNldCgmc2dbbmVudHNdLCAwLCBz aXplb2YoKnNnKSk7CisJCXNnW25lbnRzXS5hZGRyZXNzID0gdmlydF9hZGRyOworCQlzZ1tu ZW50c10ubGVuZ3RoID0gc2l6ZTsKIAkJbmVudHMrKzsKLQl9IHdoaWxlICgoYmggPSBiaC0+ Yl9yZXFuZXh0KSAhPSBOVUxMKTsKKwl9IHdoaWxlIChiaCAhPSBOVUxMKTsKIAogCXJldHVy biBwY2lfbWFwX3NnKGh3aWYtPnBjaV9kZXYsIHNnLCBuZW50cywgaHdpZi0+c2dfZG1hX2Rp cmVjdGlvbik7CiB9Cg== --------------060003010506000001030300-- From carstenl@mips.com Thu Sep 12 10:33:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Sep 2002 10:33:17 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:7394 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Thu, 12 Sep 2002 10:33:16 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8C8WWUD017396; Thu, 12 Sep 2002 01:32:32 -0700 (PDT) Received: from copfs01.mips.com (copfs01 [192.168.205.101]) by newman.mips.com (8.9.3/8.9.0) with ESMTP id BAA00030; Thu, 12 Sep 2002 01:32:30 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g8C8WQb19613; Thu, 12 Sep 2002 10:32:27 +0200 (MEST) Message-ID: <3D805119.5A9E3C42@mips.com> Date: Thu, 12 Sep 2002 10:32:25 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle , "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: memcpy Content-Type: multipart/mixed; boundary="------------B6F61DC383BBFBDE077BE76C" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 160 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------B6F61DC383BBFBDE077BE76C Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit I have found another bug in the 64-bit memcpy function, so I figured it was time to use the 32-bit version (as it's more or less are prepared for 64-bit). With a few fixes the memcpy.S file can now be shared between the 32-bit and 64-bit kernel (the only difference is the definition of USE_DOUBLE). I have attached the patch for arch/mips/lib/memcpy.S and the full file for the arch/mips64/lib/memcpy.S /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 --------------B6F61DC383BBFBDE077BE76C Content-Type: text/plain; charset=iso-8859-15; name="memcpy.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="memcpy.patch" Index: arch/mips/lib/memcpy.S =================================================================== RCS file: /cvs/linux/arch/mips/lib/memcpy.S,v retrieving revision 1.6.2.3 diff -u -r1.6.2.3 memcpy.S --- arch/mips/lib/memcpy.S 2002/06/30 23:10:57 1.6.2.3 +++ arch/mips/lib/memcpy.S 2002/09/12 08:12:21 @@ -99,6 +99,24 @@ #define NBYTES 8 #define LOG_NBYTES 3 +/* + * As we are sharing code base with the mips32 tree (which use the o32 ABI + * register definitions). We need to redefine the register definitions from + * the n64 ABI register naming to the o32 ABI register naming. + */ +#undef t0 +#undef t1 +#undef t2 +#undef t3 +#define t0 $8 +#define t1 $9 +#define t2 $10 +#define t3 $11 +#define t4 $12 +#define t5 $13 +#define t6 $14 +#define t7 $15 + #else #define LOAD lw @@ -385,7 +403,7 @@ * * Assumes src < THREAD_BUADDR($28) */ - lw t0, THREAD_BUADDR($28) + LOAD t0, THREAD_BUADDR($28) 1: EXC( lb t1, 0(src), l_exc) ADD src, src, 1 @@ -393,16 +411,16 @@ bne src, t0, 1b ADD dst, dst, 1 l_exc: - lw t0, THREAD_BUADDR($28) # t0 is just past last good address + LOAD t0, THREAD_BUADDR($28) # t0 is just past last good address nop - subu len, AT, t0 # len number of uncopied bytes + SUB len, AT, t0 # len number of uncopied bytes /* * Here's where we rely on src and dst being incremented in tandem, * See (3) above. * dst += (fault addr - src) to put dst at first byte to clear */ - addu dst, t0 # compute start address in a1 - subu dst, src + ADD dst, t0 # compute start address in a1 + SUB dst, src /* * Clear len bytes starting at dst. Can't call __bzero because it * might modify len. An inefficient loop for these rare times... @@ -440,8 +458,8 @@ .align 5 LEAF(memmove) - addu t0, a0, a2 - addu t1, a1, a2 + ADD t0, a0, a2 + ADD t1, a1, a2 sltu t0, a1, t0 # dst + len <= src -> memcpy sltu t1, a0, t1 # dst >= src + len -> memcpy and t0, t1 @@ -455,16 +473,16 @@ sltu t0, a1, a0 beqz t0, r_end_bytes_up # src >= dst nop - addu a0, a2 # dst = dst + len - addu a1, a2 # src = src + len + ADD a0, a2 # dst = dst + len + ADD a1, a2 # src = src + len r_end_bytes: lb t0, -1(a1) - subu a2, a2, 0x1 + SUB a2, a2, 0x1 sb t0, -1(a0) - subu a1, a1, 0x1 + SUB a1, a1, 0x1 bnez a2, r_end_bytes - subu a0, a0, 0x1 + SUB a0, a0, 0x1 r_out: jr ra @@ -472,11 +490,11 @@ r_end_bytes_up: lb t0, (a1) - subu a2, a2, 0x1 + SUB a2, a2, 0x1 sb t0, (a0) - addu a1, a1, 0x1 + ADD a1, a1, 0x1 bnez a2, r_end_bytes_up - addu a0, a0, 0x1 + ADD a0, a0, 0x1 jr ra move a2, zero --------------B6F61DC383BBFBDE077BE76C Content-Type: text/plain; charset=iso-8859-15; name="memcpy.S" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="memcpy.S" /* * 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. * * Unified implementation of memcpy, memmove and the __copy_user backend. * * Copyright (C) 1998, 99, 2000, 01, 2002 Ralf Baechle (ralf@gnu.org) * Copyright (C) 1999, 2000, 01, 2002 Silicon Graphics, Inc. * Copyright (C) 2002 Broadcom, Inc. * memcpy/copy_user author: Mark Vandevoorde * * Mnemonic names for arguments to memcpy/__copy_user */ #include #include #include #include #define dst a0 #define src a1 #define len a2 /* * Spec * * memcpy copies len bytes from src to dst and sets v0 to dst. * It assumes that * - src and dst don't overlap * - src is readable * - dst is writable * memcpy uses the standard calling convention * * __copy_user copies up to len bytes from src to dst and sets a2 (len) to * the number of uncopied bytes due to an exception caused by a read or write. * __copy_user assumes that src and dst don't overlap, and that the call is * implementing one of the following: * copy_to_user * - src is readable (no exceptions when reading src) * copy_from_user * - dst is writable (no exceptions when writing dst) * __copy_user uses a non-standard calling convention; see * include/asm-mips/uaccess.h * * When an exception happens on a load, the handler must # ensure that all of the destination buffer is overwritten to prevent * leaking information to user mode programs. */ /* * Implementation */ /* * The exception handler for loads requires that: * 1- AT contain the address of the byte just past the end of the source * of the copy, * 2- src_entry <= src < AT, and * 3- (dst - src) == (dst_entry - src_entry), * The _entry suffix denotes values when __copy_user was called. * * (1) is set up up by uaccess.h and maintained by not writing AT in copy_user * (2) is met by incrementing src by the number of bytes copied * (3) is met by not doing loads between a pair of increments of dst and src * * The exception handlers for stores adjust len (if necessary) and return. * These handlers do not need to overwrite any data. * * For __rmemcpy and memmove an exception is always a kernel bug, therefore * they're not protected. */ #define EXC(inst_reg,addr,handler) \ 9: inst_reg, addr; \ .section __ex_table,"a"; \ PTR 9b, handler; \ .previous /* * In the mips64 (not mips32) tree, so we use doubles */ #define USE_DOUBLE #if defined(USE_DOUBLE) #define LOAD ld #define LOADL ldl #define LOADR ldr #define STOREL sdl #define STORER sdr #define STORE sd #define ADD daddu #define SUB dsubu #define SRL dsrl #define SRA dsra #define SLL dsll #define SLLV dsllv #define SRLV dsrlv #define NBYTES 8 #define LOG_NBYTES 3 /* * As we are sharing code base with the mips32 tree (which use the o32 ABI * register definitions). We need to redefine the register definitions from * the n64 ABI register naming to the o32 ABI register naming. */ #undef t0 #undef t1 #undef t2 #undef t3 #define t0 $8 #define t1 $9 #define t2 $10 #define t3 $11 #define t4 $12 #define t5 $13 #define t6 $14 #define t7 $15 #else #define LOAD lw #define LOADL lwl #define LOADR lwr #define STOREL swl #define STORER swr #define STORE sw #define ADD addu #define SUB subu #define SRL srl #define SLL sll #define SRA sra #define SLLV sllv #define SRLV srlv #define NBYTES 4 #define LOG_NBYTES 2 #endif /* USE_DOUBLE */ #ifdef CONFIG_CPU_LITTLE_ENDIAN #define LDFIRST LOADR #define LDREST LOADL #define STFIRST STORER #define STREST STOREL #define SHIFT_DISCARD SLLV #else #define LDFIRST LOADL #define LDREST LOADR #define STFIRST STOREL #define STREST STORER #define SHIFT_DISCARD SRLV #endif #define FIRST(unit) ((unit)*NBYTES) #define REST(unit) (FIRST(unit)+NBYTES-1) #define UNIT(unit) FIRST(unit) #define ADDRMASK (NBYTES-1) .text .set noreorder .set noat /* * A combined memcpy/__copy_user * __copy_user sets len to 0 for success; else to an upper bound of * the number of uncopied bytes. * memcpy sets v0 to dst. */ .align 5 LEAF(memcpy) /* a0=dst a1=src a2=len */ move v0, dst /* return value */ __memcpy: FEXPORT(__copy_user) /* * Note: dst & src may be unaligned, len may be 0 * Temps */ #define rem t8 /* * The "issue break"s below are very approximate. * Issue delays for dcache fills will perturb the schedule, as will * load queue full replay traps, etc. * * If len < NBYTES use byte operations. */ PREF( 0, 0(src) ) PREF( 1, 0(dst) ) sltu t2, len, NBYTES and t1, dst, ADDRMASK PREF( 0, 1*32(src) ) PREF( 1, 1*32(dst) ) bnez t2, copy_bytes_checklen and t0, src, ADDRMASK PREF( 0, 2*32(src) ) PREF( 1, 2*32(dst) ) bnez t1, dst_unaligned nop bnez t0, src_unaligned_dst_aligned /* * use delay slot for fall-through * src and dst are aligned; need to compute rem */ both_aligned: SRL t0, len, LOG_NBYTES+3 # +3 for 8 units/iter beqz t0, cleanup_both_aligned # len < 8*NBYTES and rem, len, (8*NBYTES-1) # rem = len % (8*NBYTES) PREF( 0, 3*32(src) ) PREF( 1, 3*32(dst) ) .align 4 1: EXC( LOAD t0, UNIT(0)(src), l_exc) EXC( LOAD t1, UNIT(1)(src), l_exc_copy) EXC( LOAD t2, UNIT(2)(src), l_exc_copy) EXC( LOAD t3, UNIT(3)(src), l_exc_copy) SUB len, len, 8*NBYTES EXC( LOAD t4, UNIT(4)(src), l_exc_copy) EXC( LOAD t7, UNIT(5)(src), l_exc_copy) EXC( STORE t0, UNIT(0)(dst), s_exc_p8u) EXC( STORE t1, UNIT(1)(dst), s_exc_p7u) EXC( LOAD t0, UNIT(6)(src), l_exc_copy) EXC( LOAD t1, UNIT(7)(src), l_exc_copy) ADD src, src, 8*NBYTES ADD dst, dst, 8*NBYTES EXC( STORE t2, UNIT(-6)(dst), s_exc_p6u) EXC( STORE t3, UNIT(-5)(dst), s_exc_p5u) EXC( STORE t4, UNIT(-4)(dst), s_exc_p4u) EXC( STORE t7, UNIT(-3)(dst), s_exc_p3u) EXC( STORE t0, UNIT(-2)(dst), s_exc_p2u) EXC( STORE t1, UNIT(-1)(dst), s_exc_p1u) PREF( 0, 8*32(src) ) PREF( 1, 8*32(dst) ) bne len, rem, 1b nop /* * len == rem == the number of bytes left to copy < 8*NBYTES */ cleanup_both_aligned: beqz len, done sltu t0, len, 4*NBYTES bnez t0, less_than_4units and rem, len, (NBYTES-1) # rem = len % NBYTES /* * len >= 4*NBYTES */ EXC( LOAD t0, UNIT(0)(src), l_exc) EXC( LOAD t1, UNIT(1)(src), l_exc_copy) EXC( LOAD t2, UNIT(2)(src), l_exc_copy) EXC( LOAD t3, UNIT(3)(src), l_exc_copy) SUB len, len, 4*NBYTES ADD src, src, 4*NBYTES EXC( STORE t0, UNIT(0)(dst), s_exc_p4u) EXC( STORE t1, UNIT(1)(dst), s_exc_p3u) EXC( STORE t2, UNIT(2)(dst), s_exc_p2u) EXC( STORE t3, UNIT(3)(dst), s_exc_p1u) beqz len, done ADD dst, dst, 4*NBYTES less_than_4units: /* * rem = len % NBYTES */ beq rem, len, copy_bytes nop 1: EXC( LOAD t0, 0(src), l_exc) ADD src, src, NBYTES SUB len, len, NBYTES EXC( STORE t0, 0(dst), s_exc_p1u) bne rem, len, 1b ADD dst, dst, NBYTES /* * src and dst are aligned, need to copy rem bytes (rem < NBYTES) * A loop would do only a byte at a time with possible branch * mispredicts. Can't do an explicit LOAD dst,mask,or,STORE * because can't assume read-access to dst. Instead, use * STREST dst, which doesn't require read access to dst. * * This code should perform better than a simple loop on modern, * wide-issue mips processors because the code has fewer branches and * more instruction-level parallelism. */ #define bits t2 beqz len, done ADD t1, dst, len # t1 is just past last byte of dst li bits, 8*NBYTES SLL rem, len, 3 # rem = number of bits to keep EXC( LOAD t0, 0(src), l_exc) SUB bits, bits, rem # bits = number of bits to discard SHIFT_DISCARD t0, t0, bits EXC( STREST t0, -1(t1), s_exc) jr ra move len, zero dst_unaligned: /* * dst is unaligned * t0 = src & ADDRMASK * t1 = dst & ADDRMASK; T1 > 0 * len >= NBYTES * * Copy enough bytes to align dst * Set match = (src and dst have same alignment) */ #define match rem EXC( LDFIRST t3, FIRST(0)(src), l_exc) ADD t2, zero, NBYTES EXC( LDREST t3, REST(0)(src), l_exc_copy) SUB t2, t2, t1 # t2 = number of bytes copied xor match, t0, t1 EXC( STFIRST t3, FIRST(0)(dst), s_exc) beq len, t2, done SUB len, len, t2 ADD dst, dst, t2 beqz match, both_aligned ADD src, src, t2 src_unaligned_dst_aligned: SRL t0, len, LOG_NBYTES+2 # +2 for 4 units/iter PREF( 0, 3*32(src) ) beqz t0, cleanup_src_unaligned and rem, len, (4*NBYTES-1) # rem = len % 4*NBYTES PREF( 1, 3*32(dst) ) 1: /* * Avoid consecutive LD*'s to the same register since some mips * implementations can't issue them in the same cycle. * It's OK to load FIRST(N+1) before REST(N) because the two addresses * are to the same unit (unless src is aligned, but it's not). */ EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDFIRST t1, FIRST(1)(src), l_exc_copy) SUB len, len, 4*NBYTES EXC( LDREST t0, REST(0)(src), l_exc_copy) EXC( LDREST t1, REST(1)(src), l_exc_copy) EXC( LDFIRST t2, FIRST(2)(src), l_exc_copy) EXC( LDFIRST t3, FIRST(3)(src), l_exc_copy) EXC( LDREST t2, REST(2)(src), l_exc_copy) EXC( LDREST t3, REST(3)(src), l_exc_copy) PREF( 0, 9*32(src) ) # 0 is PREF_LOAD (not streamed) ADD src, src, 4*NBYTES #ifdef CONFIG_CPU_SB1 nop # improves slotting #endif EXC( STORE t0, UNIT(0)(dst), s_exc_p4u) EXC( STORE t1, UNIT(1)(dst), s_exc_p3u) EXC( STORE t2, UNIT(2)(dst), s_exc_p2u) EXC( STORE t3, UNIT(3)(dst), s_exc_p1u) PREF( 1, 9*32(dst) ) # 1 is PREF_STORE (not streamed) bne len, rem, 1b ADD dst, dst, 4*NBYTES cleanup_src_unaligned: beqz len, done and rem, len, NBYTES-1 # rem = len % NBYTES beq rem, len, copy_bytes 1: EXC( LDFIRST t0, FIRST(0)(src), l_exc) EXC( LDREST t0, REST(0)(src), l_exc_copy) ADD src, src, NBYTES SUB len, len, NBYTES EXC( STORE t0, 0(dst), s_exc_p1u) bne len, rem, 1b ADD dst, dst, NBYTES copy_bytes_checklen: beqz len, done nop copy_bytes: /* 0 < len < NBYTES */ #define COPY_BYTE(N) \ EXC( lb t0, N(src), l_exc); \ SUB len, len, 1; \ beqz len, done; \ EXC( sb t0, N(dst), s_exc_p1) COPY_BYTE(0) COPY_BYTE(1) #ifdef USE_DOUBLE COPY_BYTE(2) COPY_BYTE(3) COPY_BYTE(4) COPY_BYTE(5) #endif EXC( lb t0, NBYTES-2(src), l_exc) SUB len, len, 1 jr ra EXC( sb t0, NBYTES-2(dst), s_exc_p1) done: jr ra nop END(memcpy) l_exc_copy: /* * Copy bytes from src until faulting load address (or until a * lb faults) * * When reached by a faulting LDFIRST/LDREST, THREAD_BUADDR($28) * may be more than a byte beyond the last address. * Hence, the lb below may get an exception. * * Assumes src < THREAD_BUADDR($28) */ LOAD t0, THREAD_BUADDR($28) 1: EXC( lb t1, 0(src), l_exc) ADD src, src, 1 sb t1, 0(dst) # can't fault -- we're copy_from_user bne src, t0, 1b ADD dst, dst, 1 l_exc: LOAD t0, THREAD_BUADDR($28) # t0 is just past last good address nop SUB len, AT, t0 # len number of uncopied bytes /* * Here's where we rely on src and dst being incremented in tandem, * See (3) above. * dst += (fault addr - src) to put dst at first byte to clear */ ADD dst, t0 # compute start address in a1 SUB dst, src /* * Clear len bytes starting at dst. Can't call __bzero because it * might modify len. An inefficient loop for these rare times... */ beqz len, done SUB src, len, 1 1: sb zero, 0(dst) ADD dst, dst, 1 bnez src, 1b SUB src, src, 1 jr ra nop #define SEXC(n) \ s_exc_p ## n ## u: \ jr ra; \ ADD len, len, n*NBYTES SEXC(8) SEXC(7) SEXC(6) SEXC(5) SEXC(4) SEXC(3) SEXC(2) SEXC(1) s_exc_p1: jr ra ADD len, len, 1 s_exc: jr ra nop .align 5 LEAF(memmove) ADD t0, a0, a2 ADD t1, a1, a2 sltu t0, a1, t0 # dst + len <= src -> memcpy sltu t1, a0, t1 # dst >= src + len -> memcpy and t0, t1 beqz t0, __memcpy move v0, a0 /* return value */ beqz a2, r_out END(memmove) /* fall through to __rmemcpy */ LEAF(__rmemcpy) /* a0=dst a1=src a2=len */ sltu t0, a1, a0 beqz t0, r_end_bytes_up # src >= dst nop ADD a0, a2 # dst = dst + len ADD a1, a2 # src = src + len r_end_bytes: lb t0, -1(a1) SUB a2, a2, 0x1 sb t0, -1(a0) SUB a1, a1, 0x1 bnez a2, r_end_bytes SUB a0, a0, 0x1 r_out: jr ra move a2, zero r_end_bytes_up: lb t0, (a1) SUB a2, a2, 0x1 sb t0, (a0) ADD a1, a1, 0x1 bnez a2, r_end_bytes_up ADD a0, a0, 0x1 jr ra move a2, zero END(__rmemcpy) --------------B6F61DC383BBFBDE077BE76C-- From yoichi_yuasa@montavista.co.jp Thu Sep 12 11:58:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Sep 2002 11:58:17 +0200 (CEST) Received: from r-bu.iij4u.or.jp ([210.130.0.89]:39900 "EHLO r-bu.iij4u.or.jp") by linux-mips.org with ESMTP id ; Thu, 12 Sep 2002 11:58:16 +0200 Received: from pudding ([202.216.29.50]) by r-bu.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g8C9w3G20090; Thu, 12 Sep 2002 18:58:04 +0900 (JST) Date: Thu, 12 Sep 2002 18:56:12 +0900 From: Yoichi Yuasa To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: patch for pci.c Message-Id: <20020912185612.56743fd7.yoichi_yuasa@montavista.co.jp> Organization: MontaVista Software Japan, Inc. X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@montavista.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, The argument of pcibios_enable_device is changed. In include/linux/pci.h: int pcibios_enable_device(struct pci_dev *, int mask); The following patch is required for the cvs tree of linux_2_4 tag. --- ./arch/mips/kernel/pci.c.orig Wed May 29 12:03:16 2002 +++ ./arch/mips/kernel/pci.c Thu Sep 12 18:22:14 2002 @@ -100,7 +100,7 @@ pcibios_fixup_irqs(); } -int pcibios_enable_device(struct pci_dev *dev) +int pcibios_enable_device(struct pci_dev *dev, int mask) { /* pciauto_assign_resources() will enable all devices found */ return 0; -- Yoichi Yuasa Montavista Software Japan, Inc. From brian@murphy.dk Thu Sep 12 22:15:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 12 Sep 2002 22:15:31 +0200 (CEST) Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:10807 "EHLO ubik.localnet") by linux-mips.org with ESMTP id ; Thu, 12 Sep 2002 22:15:30 +0200 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g8CKFB6m032403; Thu, 12 Sep 2002 22:15:11 +0200 Message-ID: <3D80F5CF.1040905@murphy.dk> Date: Thu, 12 Sep 2002 22:15:11 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Brian Murphy CC: linux-mips Subject: [PATCH 2.4] Re: ide-dma bug (cache flushing) References: <3D7FAB4A.4010802@murphy.dk> Content-Type: multipart/mixed; boundary="------------070501060604050701070702" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 162 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------070501060604050701070702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It seems like this problem is (yet again) caused by lack of cache flushing. The attached patch adds a dma_cache_wback_inv to pci_map_sg in pci.h to the if fork in which sg->address is not set. This fixes my problem. Can someone with commit access please apply this patch? /Brian --------------070501060604050701070702 Content-Type: text/plain; name="flush.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="flush.patch" Index: include/asm-mips/pci.h =================================================================== RCS file: /cvs/linux-mips/include/asm-mips/pci.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 pci.h --- include/asm-mips/pci.h 19 Aug 2002 18:00:29 -0000 1.1.1.2 +++ include/asm-mips/pci.h 12 Sep 2002 20:06:31 -0000 @@ -200,9 +200,13 @@ dma_cache_wback_inv((unsigned long)sg->address, sg->length); sg->dma_address = bus_to_baddr(hwdev, __pa(sg->address)); - } else + } else { sg->dma_address = page_to_bus(sg->page) + sg->offset; + dma_cache_wback_inv( + (unsigned long)(page_address(sg->page)+ + sg->offset), sg->length); + } } return nents; --------------070501060604050701070702-- From gerald.champagne@esstech.com Fri Sep 13 00:40:04 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 00:40:04 +0200 (CEST) Received: from mail.esstech.com ([64.152.86.3]:17325 "HELO [64.152.86.3]") by linux-mips.org with SMTP id ; Fri, 13 Sep 2002 00:40:04 +0200 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; Thu, 12 Sep 2002 15:40:03 -0700 Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.12.2/8.12.2) with SMTP id g8CMer0A007049 for ; Thu, 12 Sep 2002 15:40:53 -0700 (PDT) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id PAA24880; Thu, 12 Sep 2002 15:39:04 -0700 Received: from [193.5.206.150] by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id RAA17206; Thu, 12 Sep 2002 17:31:08 -0500 Subject: tools for modifying dwarf symbols From: Gerald Champagne To: Linux Mips Mailing List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 12 Sep 2002 17:30:59 -0500 Message-Id: <1031869864.7173.84.camel@localhost.localdomain> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 163 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gerald.champagne@esstech.com Precedence: bulk X-list: linux-mips Is there a tool that will allow me to modify the path of filenames in dwarf symbols in an elf file? I've looked at everything in binutils, but these tools only manipulate the binary portion of elf files. I don't see any similar tools for modifying dwarf debug symbols in an elf file. My problem is that my debugger can't read the source files when absolute paths are used in filenames. In my environment, I have to compile on one system using one path to the files, then later I have to access the same data from the debugger using a different path. This works when the filenames are embedded using relative paths. Larger systems like the linux kernel or the pmon boot loader use absolute path names everywhere in the makefiles. These absolute paths are embedded in the elf file and my debugger gets confused. Is there a tool or library that will simplify manipulating the dwarf data in the elf files? Thanks, Gerald From mdharm@momenco.com Fri Sep 13 03:59:08 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 03:59:08 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:54286 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 03:59:08 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8D1wv628745 for ; Thu, 12 Sep 2002 18:58:58 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: When to #ifdef on CPUs? Date: Thu, 12 Sep 2002 18:58:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips I'm basically done with my task of porting linux to our SR71000-based board. I'm getting ready to start feeding patches to Ralf, and something occured to me.... Sometimes, in some places, we use CONFIG_ options to select the apropriate CPU. Other places, we probe for the CPU based on the PRID register. In some places, the reason for the choice is clear -- it's just much easier to select the cache library based on a CONFIG_ option in a Makefile than trying to do run-time assignment of many function pointers. However, is some places, the choice is not clear. In cpu-probe.c, for example, several of the CPU identification routines are wrapped in #ifdef's -- odd, since the wrong 'case' of the switch statements should never get executed, even if compiled in.... So, what's the rule here? When do I used #ifdef and when do I just let the PRID stuff work it's magic? I mean, heck... it might be nice to put a check to see if the detected CPU matches what the kernel was compiled for... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From FlashFyre_2000@yahoo.com Fri Sep 13 06:19:37 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 06:19:38 +0200 (CEST) Received: from mail.ccis.com ([205.139.55.3]:16914 "EHLO mail.ccis.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 06:19:37 +0200 Received: from yahoo.com ([205.253.44.16]) by mail.ccis.com ; Thu, 12 Sep 2002 21:19:19 -0700 Message-ID: <3D8167C2.4070502@yahoo.com> Date: Thu, 12 Sep 2002 21:21:22 -0700 From: FlashFyre_2000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: seeking vme mips sbc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 165 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: FlashFyre_2000@yahoo.com Precedence: bulk X-list: linux-mips Are there any companies making MIPS and vme bus based single board computers? -- John From macro@ds2.pg.gda.pl Fri Sep 13 09:21:46 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 09:21:46 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:41643 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 09:21:46 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA21652; Fri, 13 Sep 2002 09:22:07 +0200 (MET DST) Date: Fri, 13 Sep 2002 09:22:06 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Matthew Dharm cc: Linux-MIPS Subject: Re: When to #ifdef on CPUs? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Thu, 12 Sep 2002, Matthew Dharm wrote: > So, what's the rule here? When do I used #ifdef and when do I just > let the PRID stuff work it's magic? > > I mean, heck... it might be nice to put a check to see if the detected > CPU matches what the kernel was compiled for... Well, we might be able to build generic kernels one day. So you need to judge whether some bits of code are needed/useful if run on your processor in a generic configuration (use PRId then) or are specific to a configuration dedicated to your processor (use a config option then). There are places in the existing code that violate the rule but the reasons are mostly historical and they will hopefully get cleaned up sooner or later (I have a few of them on my to-do list, too). Thus please don't be much too influenced by old code. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Fri Sep 13 11:06:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 11:06:36 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:23542 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 11:06:36 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8D96QUD022059; Fri, 13 Sep 2002 02:06:26 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA09509; Fri, 13 Sep 2002 02:06:29 -0700 (PDT) Message-ID: <00a801c25b05$251ae980$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Matthew Dharm" , "Linux-MIPS" References: Subject: Re: When to #ifdef on CPUs? Date: Fri, 13 Sep 2002 11:08:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Matthew Dharm" > I'm basically done with my task of porting linux to our SR71000-based > board. I'm getting ready to start feeding patches to Ralf, and > something occured to me.... > > Sometimes, in some places, we use CONFIG_ options to select the > apropriate CPU. Other places, we probe for the CPU based on the PRID > register. > > In some places, the reason for the choice is clear -- it's just much > easier to select the cache library based on a CONFIG_ option in a > Makefile than trying to do run-time assignment of many function > pointers. > > However, is some places, the choice is not clear. In cpu-probe.c, for > example, several of the CPU identification routines are wrapped in > #ifdef's -- odd, since the wrong 'case' of the switch statements > should never get executed, even if compiled in.... There is a big discontinuity between the R3000 privileged resource model and that of the R4000 and later CPUs. So it would not surprise me if the MIPS/Linux kernel retained some R3000/non-R3000 conditional code for a while longer. Much of rest of what you're seeing, particularly in cpu-probe.c, is just slop - expedient hacks that somehow became permanent. But the ambivalence between run-time and build-time binding to CPUs probably also reflects the two poles of use of MIPS/Linux. The folks who use it on old SGI and DEC workstations have platforms like the SGI Indy where the same relatively RAM-rich platform configuration can support a number of different CPUs . That tends to lead to run-time binding of the CPU-specific routines and parameters. The folks who use it for embedded apps tend to have system and peripheral setups that are anyway pretty application-specific, and since memory isn't entirely free, there's no advantage, and some slight disadvantage, in including code to support other CPUs in the OS image. And there are, alas, cases where the designers screwed up and failed to provide a correctly unique PrID register value, such as is apparently the case with the NEC Vr4111 and VR4181. I'd be willing to bet that there is *some* way to distinguish those two parts at run-time if one really wanted to, though. > So, what's the rule here? When do I used #ifdef and when do I just > let the PRID stuff work it's magic? I don't know that there's a rule as such, but I would strongly recommend using the PrID and Config registers to generate a kernel CPU ID and a set of mips_cpu.options bits, and that information abstracted into the mips_cpu structure should be used in preference to comparing against CPU ID's. It may require a little more thought up-front, but it leaves the rest of the code a lot easier to maintain. You should have seen what the kernel looked like before we introduced the mips_cpu structure! > I mean, heck... it might be nice to put a check to see if the detected > CPU matches what the kernel was compiled for... If it doesn't, that's a bug. Kevin K. From atulsrivastava9@rediffmail.com Fri Sep 13 11:56:01 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 11:56:02 +0200 (CEST) Received: from webmail23.rediffmail.com ([203.199.83.145]:11415 "HELO webmail23.rediffmail.com") by linux-mips.org with SMTP id ; Fri, 13 Sep 2002 11:56:01 +0200 Received: (qmail 24814 invoked by uid 510); 13 Sep 2002 09:54:49 -0000 Date: 13 Sep 2002 09:54:49 -0000 Message-ID: <20020913095449.24813.qmail@webmail23.rediffmail.com> Received: from unknown (202.54.89.92) by rediffmail.com via HTTP; 13 Sep 2002 09:54:49 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: usable memory map.. Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello , on MIPS IDT 79S334A i am getting following usable memory regions by print_memory_map in arch/mips/kernel/setup.c . memory: 8000fc00 @ 80000400 (usable) memory: 00e01d2b @ 001fe2db (usable) note that first column is SIZE and second one is START address. my question is.. 1> what is the significance of usable memory , in terms of availibility for linux..? 2> where it is initialised ..i guess must be passed from firmware or from tags.. 3>on my board ram (16 MB)at 0x8000000 ,initial 0x400 is a room for exception table and hence effectively it would start from 0x80000400 . does this map relates to any way to LOAD ADRRESS ? i would like to add that i have problem of starting any user space process it is reporting always a bad memory acess on address 0x0fc01788. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From atulsrivastava9@rediffmail.com Fri Sep 13 12:02:06 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 12:02:07 +0200 (CEST) Received: from webmail23.rediffmail.com ([203.199.83.145]:63895 "HELO webmail23.rediffmail.com") by linux-mips.org with SMTP id ; Fri, 13 Sep 2002 12:02:06 +0200 Received: (qmail 30905 invoked by uid 510); 13 Sep 2002 10:00:58 -0000 Date: 13 Sep 2002 10:00:58 -0000 Message-ID: <20020913100058.30904.qmail@webmail23.rediffmail.com> Received: from unknown (202.54.89.92) by rediffmail.com via HTTP; 13 Sep 2002 10:00:58 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: addition in usable memory map.. Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello , during booting on MIPS IDT 79S334A i am getting following usable memory regions by print_memory_map in arch/mips/kernel/setup.c . memory: 8000fc00 @ 80000400 (usable) memory: 00e01d2b @ 001fe2db (usable) Initial ramdisk at: 0x8014c000 (604512 bytes) . . . above line i missed to mention in my previous post. note that first column is SIZE and second one is START address. my question is.. 1> what is the significance of usable memory , in terms of availibility for linux..? 2> where it is initialised ..i guess must be passed from firmware or from tags.. 3>on my board ram (16 MB)at 0x8000000 ,initial 0x400 is a room for exception table and hence effectively it would start from 0x80000400 . does this map relates to any way to LOAD ADRRESS ? i would like to add that i have problem of starting any user space process it is reporting always a bad memory acess on address 0x0fc01788. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From seh@zee2.com Fri Sep 13 12:07:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 12:07:36 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:8432 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 12:07:36 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8DA7GC10963 for ; Fri, 13 Sep 2002 11:07:23 +0100 Message-ID: <3D81B8D3.1609CD69@zee2.com> Date: Fri, 13 Sep 2002 11:07:15 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS Subject: cannot debug multi-threaded programs with gdb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 170 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips Hi, I've been trying to debug a simple multi-threaded test program using gdb, and it always fails as follows: [New Thread 1024 (LWP 39)] Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 1024 (LWP 39)] warning: Warning: GDB can't find the start of the function at 0xffffffff. I've tried various different compilers, gdb, glibc version but the problem is the same. Note that I can debug non-threaded c/c++ programs without any problem. My environment is as follows: CPU: NEC VR5432 kernel: linux-2.4.10 + patches glibc: 2.2.3 + patches gdb: 5.2/3 from CVS gcc: 3.1 (also tried 3.0.1) binutils: Version 2.11.90.0.25 Does anyone have any idea what is wrong and how to fix it. Regards, Stuart From macro@ds2.pg.gda.pl Fri Sep 13 12:34:04 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 12:34:05 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:2993 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 12:34:04 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA25192; Fri, 13 Sep 2002 12:34:22 +0200 (MET DST) Date: Fri, 13 Sep 2002 12:34:22 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: Matthew Dharm , Linux-MIPS Subject: Re: When to #ifdef on CPUs? In-Reply-To: <00a801c25b05$251ae980$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 13 Sep 2002, Kevin D. Kissell wrote: > There is a big discontinuity between the R3000 privileged resource > model and that of the R4000 and later CPUs. So it would not surprise > me if the MIPS/Linux kernel retained some R3000/non-R3000 > conditional code for a while longer. Much of rest of what you're Well, code paths may be selected via indirect calls and variable references. That may be tedious and require much care when implementing, but it is doable. > seeing, particularly in cpu-probe.c, is just slop - expedient hacks > that somehow became permanent. A few fixes here is pending on my short-term to-do list. I'd like to get rid of #ifdefs here as they are unnecessary. > But the ambivalence between run-time and build-time binding > to CPUs probably also reflects the two poles of use of > MIPS/Linux. The folks who use it on old SGI and DEC > workstations have platforms like the SGI Indy where the > same relatively RAM-rich platform configuration can support > a number of different CPUs . That tends to lead to run-time > binding of the CPU-specific routines and parameters. > The folks who use it for embedded apps tend to have > system and peripheral setups that are anyway pretty > application-specific, and since memory isn't entirely free, > there's no advantage, and some slight disadvantage, > in including code to support other CPUs in the OS image. I have the Alpha approach in mind. The idea is to select between a generic and a system-specific kernel. With the former there is a vector of available configurations one of which is selected early in the boot process. Items from the vector element chosen are accessed indirectly. With the latter only a single element of the vector is build and its contents are accessed directly with the help of some preprocessor magic. > And there are, alas, cases where the designers screwed up > and failed to provide a correctly unique PrID register value, > such as is apparently the case with the NEC Vr4111 and > VR4181. I'd be willing to bet that there is *some* way to > distinguish those two parts at run-time if one really wanted > to, though. Well, if the chips differ, which is the case as I infer from what you wrote, then the difference between them may be used to determine which one of them a system is being executed on. > > I mean, heck... it might be nice to put a check to see if the detected > > CPU matches what the kernel was compiled for... > > If it doesn't, that's a bug. No, it's a user fault. And it's nice to the user to print an appropriate message and panic() explicitly instead of crashing in an interesting way. This is currently being done for the R3k vs R4k in the DECstation-specific code, but it might be beneficial to expand it move it somewhere to the generic code. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Fri Sep 13 12:49:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 12:49:53 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:42999 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 12:49:52 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8DAnhUD022386; Fri, 13 Sep 2002 03:49:43 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA14637; Fri, 13 Sep 2002 03:49:48 -0700 (PDT) Message-ID: <00ca01c25b13$92c7f780$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Matthew Dharm" , "Linux-MIPS" References: Subject: Re: When to #ifdef on CPUs? Date: Fri, 13 Sep 2002 12:51:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Matthew Dharm" > I'm basically done with my task of porting linux to our SR71000-based > board. I'm getting ready to start feeding patches to Ralf, and > something occured to me.... > > Sometimes, in some places, we use CONFIG_ options to select the > apropriate CPU. Other places, we probe for the CPU based on the PRID > register. > > In some places, the reason for the choice is clear -- it's just much > easier to select the cache library based on a CONFIG_ option in a > Makefile than trying to do run-time assignment of many function > pointers. > > However, is some places, the choice is not clear. In cpu-probe.c, for > example, several of the CPU identification routines are wrapped in > #ifdef's -- odd, since the wrong 'case' of the switch statements > should never get executed, even if compiled in.... There is a big discontinuity between the R3000 privileged resource model and that of the R4000 and later CPUs. So it would not surprise me if the MIPS/Linux kernel retained some R3000/non-R3000 conditional code for a while longer. Much of rest of what you're seeing, particularly in cpu-probe.c, is just slop - expedient hacks that somehow became permanent. But the ambivalence between run-time and build-time binding to CPUs probably also reflects the two poles of use of MIPS/Linux. The folks who use it on old SGI and DEC workstations have platforms like the SGI Indy where the same relatively RAM-rich platform configuration can support a number of different CPUs . That tends to lead to run-time binding of the CPU-specific routines and parameters. The folks who use it for embedded apps tend to have system and peripheral setups that are anyway pretty application-specific, and since memory isn't entirely free, there's no advantage, and some slight disadvantage, in including code to support other CPUs in the OS image. So we have an environment where boot-time CPU binding works OK across the set of CPUs used in Indys, and not necessarily for others. And there are, alas, cases where the designers failed to provide a correctly unique PrID register value, such as is apparently the case with the NEC Vr4111 and VR4181. I'd be willing to bet that there is *some* way to distinguish those two parts at run-time if one really wanted to, though. > So, what's the rule here? When do I used #ifdef and when do I just > let the PRID stuff work it's magic? I don't know that there's a rule as such, but I would strongly recommend using the PrID and Config registers to generate a kernel CPU ID and a set of mips_cpu.options bits, and that information abstracted into the mips_cpu structure should be used in preference to comparing against CPU ID's. It may require a little more thought up-front, but it leaves the rest of the code a lot easier to maintain. You should have seen what the kernel looked like before we introduced the mips_cpu structure! Fortunately, the standardization of the privileged resource architecture in the MIPS32 and MIPS64 specs means that the problem shouldn't get much worse - newer parts should just work with a MIPS32 kernel. > I mean, heck... it might be nice to put a check to see if the detected > CPU matches what the kernel was compiled for... If it doesn't, that's a bug. Kevin K. From drow@false.org Fri Sep 13 15:51:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 15:51:16 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:16902 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 15:51:16 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17prmd-0001ra-00; Fri, 13 Sep 2002 09:50:59 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17pqqn-0002or-00; Fri, 13 Sep 2002 09:51:13 -0400 Date: Fri, 13 Sep 2002 09:51:13 -0400 From: Daniel Jacobowitz To: Stuart Hughes Cc: Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb Message-ID: <20020913135113.GA10721@nevyn.them.org> References: <3D81B8D3.1609CD69@zee2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D81B8D3.1609CD69@zee2.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Fri, Sep 13, 2002 at 11:07:15AM +0100, Stuart Hughes wrote: > Hi, > > I've been trying to debug a simple multi-threaded test program using > gdb, and it always fails as follows: > > [New Thread 1024 (LWP > 39)] > > Program received signal SIGTRAP, Trace/breakpoint > trap. > [Switching to Thread 1024 (LWP > 39)] > warning: Warning: GDB can't find the start of the function at > 0xffffffff. > > I've tried various different compilers, gdb, glibc version but the > problem is the same. Note that I can debug non-threaded c/c++ programs > without any problem. My environment is as follows: > > CPU: NEC VR5432 > kernel: linux-2.4.10 + patches > glibc: 2.2.3 + patches Not enough patches I'd bet. Glibc 2.2.3 had an incorrect size listed for elf_gregset_t, and it was fixed in 2.2.5. That would cause this problem. > gdb: 5.2/3 from CVS > gcc: 3.1 (also tried 3.0.1) > binutils: Version 2.11.90.0.25 > > Does anyone have any idea what is wrong and how to fix it. > > Regards, Stuart > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From seh@zee2.com Fri Sep 13 16:11:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 16:11:30 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:23540 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 16:11:30 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8DEBAC00535; Fri, 13 Sep 2002 15:11:12 +0100 Message-ID: <3D81F1D8.5E92F8EB@zee2.com> Date: Fri, 13 Sep 2002 15:10:32 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb References: <3D81B8D3.1609CD69@zee2.com> <20020913135113.GA10721@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------04880802BDFFA3222F4BF6F2" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------04880802BDFFA3222F4BF6F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Daniel, Thanks for your help. I also just found a posting by you from January explaining this. I tried it out, and it works like a dream. FWIW I've attached a patch I applied to glibc. Regards, Stuart Daniel Jacobowitz wrote: > > On Fri, Sep 13, 2002 at 11:07:15AM +0100, Stuart Hughes wrote: > > Hi, > > > > I've been trying to debug a simple multi-threaded test program using > > gdb, and it always fails as follows: > > > > [New Thread 1024 (LWP > > 39)] > > > > Program received signal SIGTRAP, Trace/breakpoint > > trap. > > [Switching to Thread 1024 (LWP > > 39)] > > warning: Warning: GDB can't find the start of the function at > > 0xffffffff. > > > > I've tried various different compilers, gdb, glibc version but the > > problem is the same. Note that I can debug non-threaded c/c++ programs > > without any problem. My environment is as follows: > > > > CPU: NEC VR5432 > > kernel: linux-2.4.10 + patches > > glibc: 2.2.3 + patches > > Not enough patches I'd bet. Glibc 2.2.3 had an incorrect size listed > for elf_gregset_t, and it was fixed in 2.2.5. That would cause this > problem. > > > gdb: 5.2/3 from CVS > > gcc: 3.1 (also tried 3.0.1) > > binutils: Version 2.11.90.0.25 > > > > Does anyone have any idea what is wrong and how to fix it. > > > > Regards, Stuart > > > > > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer --------------04880802BDFFA3222F4BF6F2 Content-Type: text/plain; charset=us-ascii; name="glibc-2.2.3-gdb-pthread-diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="glibc-2.2.3-gdb-pthread-diff" --- glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/procfs.h.orig Fri Sep 13 14:26:42 2002 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/procfs.h Fri Sep 13 14:26:54 2002 @@ -101,8 +101,8 @@ typedef void *psaddr_t; /* Register sets. Linux has different names. */ -typedef gregset_t prgregset_t; -typedef fpregset_t prfpregset_t; +typedef elf_gregset_t prgregset_t; +typedef elf_fpregset_t prfpregset_t; /* We don't have any differences between processes and threads, therefore habe only ine PID type. */ --------------04880802BDFFA3222F4BF6F2-- From g.c.bransby-99@student.lboro.ac.uk Fri Sep 13 16:13:29 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 16:13:30 +0200 (CEST) Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:57783 "EHLO fw-cam.cambridge.arm.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 16:13:29 +0200 Received: by fw-cam.cambridge.arm.com; id PAA05832; Fri, 13 Sep 2002 15:13:07 +0100 (BST) Received: from unknown(172.16.9.107) by fw-cam.cambridge.arm.com via smap (V5.5) id xma005380; Fri, 13 Sep 02 15:12:28 +0100 Date: Fri, 13 Sep 2002 15:12:36 +0100 From: Gareth To: linux-mips@linux-mips.org Subject: Instruction tracing Message-Id: <20020913151236.45429b74.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: g.c.bransby-99@student.lboro.ac.uk Precedence: bulk X-list: linux-mips Hello, I am trying to debug a program running on a mips malta dev board (no operating system). I am using gdb running on a linux pc connected to the board via serial and the board is running YAMON gdb. I can step through the code, set break points, examine memory and variables etc, but what I would really like to do is get an instruction trace of the program. Any help greatly appreciated. Gareth From drow@false.org Fri Sep 13 16:18:51 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 16:18:51 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:26886 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 16:18:51 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17psDB-0001te-00; Fri, 13 Sep 2002 10:18:25 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17prHM-0003AY-00; Fri, 13 Sep 2002 10:18:40 -0400 Date: Fri, 13 Sep 2002 10:18:40 -0400 From: Daniel Jacobowitz To: Gareth Cc: linux-mips@linux-mips.org Subject: Re: Instruction tracing Message-ID: <20020913141840.GA12165@nevyn.them.org> References: <20020913151236.45429b74.g.c.bransby-99@student.lboro.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020913151236.45429b74.g.c.bransby-99@student.lboro.ac.uk> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Fri, Sep 13, 2002 at 03:12:36PM +0100, Gareth wrote: > Hello, > > I am trying to debug a program running on a mips malta dev board (no operating > system). I am using gdb running on a linux pc connected to the board via > serial and the board is running YAMON gdb. I can step through the code, set > break points, examine memory and variables etc, but what I would really like > to do is get an instruction trace of the program. > > Any help greatly appreciated. Sorry, but I don't believe GDB supports this. Some simulators or probes may support it directly but core GDB really can't do anything about it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From g.c.bransby-99@student.lboro.ac.uk Fri Sep 13 18:28:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 18:28:52 +0200 (CEST) Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:44679 "EHLO fw-cam.cambridge.arm.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 18:28:52 +0200 Received: by fw-cam.cambridge.arm.com; id RAA12072; Fri, 13 Sep 2002 17:28:38 +0100 (BST) Received: from unknown(172.16.9.107) by fw-cam.cambridge.arm.com via smap (V5.5) id xma011784; Fri, 13 Sep 02 17:28:17 +0100 Date: Fri, 13 Sep 2002 17:28:24 +0100 From: Gareth To: linux-mips@linux-mips.org Subject: Cycle counter Message-Id: <20020913172824.5c7ed0a4.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: g.c.bransby-99@student.lboro.ac.uk Precedence: bulk X-list: linux-mips Hi, Another question reagarding the mips malta board. I am wanting to be able to find out how many cycles a certain loop takes to execute. I understand there is a cycle counter built into the processor that I want to use for this. I have a bit of inline assembly to do the job but the results I am getting are not consistent so i think there is probably something wrong with my attempt at the inline assembly. Here is the code : void al_signal_start(void); size_t al_signal_finished(void); unsigned int GetcpuCycles(void); char str[8]; int main (void) { double x; al_signal_start(); x = al_signal_finished(); printf("GetcpuCycles says : %f \n",x); return 0; } size_t al_signal_finished(void) { return GetcpuCycles(); } void al_signal_start(void) { int zero,temp; __asm__("move $2, $zero"); __asm__("nop"); __asm__("mtc0 $2, $9" : : "r" (temp)); __asm__("nop"); __asm__("nop"); __asm__("nop"); } unsigned int GetcpuCycles(void) { int temp; __asm__(".set reorder"); __asm__("mfc0 $2, $9" : : "r" (temp)); __asm__("nop"); __asm__("nop"); __asm__("nop"); /*__asm__("jr $31" );*/ } As you can see, main just starts and stops the counter with no instructions in between. I expexcted the cycle count to be zero or close to it because of the instructions required to get the count but this is not the case. I am getting numbers like 8499. Is there just something wrong with my assembly or is there something else I am missing? Thanks for any help Gareth From nmckee@telogy.com Fri Sep 13 18:41:27 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 18:41:28 +0200 (CEST) Received: from [209.116.120.7] ([209.116.120.7]:31500 "EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 18:41:27 +0200 Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Sep 2002 12:40:48 -0400 Message-ID: <37A3C2F21006D611995100B0D0F9B73CBFE282@tnint11.telogy.design.ti.com> From: "Zajerko-McKee, Nick" To: 'Gareth' , linux-mips@linux-mips.org Subject: RE: Cycle counter Date: Fri, 13 Sep 2002 12:40:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nmckee@telogy.com Precedence: bulk X-list: linux-mips Is this under a OS or a single execution? Are there interrupts enabled? If so, disable them for measurements. (Clock interrupt, serial port, etc.). BTW, most MIPS implementations for OS's and monitors use the count/compare for their main tick. If you set it to zero you may be stepping on someone's tick. A better method might be to read the count register and read it again at the end and do a difference - that way you preserve other's values. Other reasons for a delay: to fetch code (external mem ->cache -> cpu) and push items onto/off the stack... Theres probably more that I can't think of right now... -----Original Message----- From: Gareth [mailto:g.c.bransby-99@student.lboro.ac.uk] Sent: Friday, September 13, 2002 12:28 PM To: linux-mips@linux-mips.org Subject: Cycle counter Hi, Another question reagarding the mips malta board. I am wanting to be able to find out how many cycles a certain loop takes to execute. I understand there is a cycle counter built into the processor that I want to use for this. I have a bit of inline assembly to do the job but the results I am getting are not consistent so i think there is probably something wrong with my attempt at the inline assembly. Here is the code : void al_signal_start(void); size_t al_signal_finished(void); unsigned int GetcpuCycles(void); char str[8]; int main (void) { double x; al_signal_start(); x = al_signal_finished(); printf("GetcpuCycles says : %f \n",x); return 0; } size_t al_signal_finished(void) { return GetcpuCycles(); } void al_signal_start(void) { int zero,temp; __asm__("move $2, $zero"); __asm__("nop"); __asm__("mtc0 $2, $9" : : "r" (temp)); __asm__("nop"); __asm__("nop"); __asm__("nop"); } unsigned int GetcpuCycles(void) { int temp; __asm__(".set reorder"); __asm__("mfc0 $2, $9" : : "r" (temp)); __asm__("nop"); __asm__("nop"); __asm__("nop"); /*__asm__("jr $31" );*/ } As you can see, main just starts and stops the counter with no instructions in between. I expexcted the cycle count to be zero or close to it because of the instructions required to get the count but this is not the case. I am getting numbers like 8499. Is there just something wrong with my assembly or is there something else I am missing? Thanks for any help Gareth From mdharm@momenco.com Fri Sep 13 18:51:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 18:51:39 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:18191 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 18:51:38 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8DGpR600936; Fri, 13 Sep 2002 09:51:27 -0700 From: "Matthew Dharm" To: "Zajerko-McKee, Nick" , "'Gareth'" , Subject: RE: Cycle counter Date: Fri, 13 Sep 2002 09:51:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <37A3C2F21006D611995100B0D0F9B73CBFE282@tnint11.telogy.design.ti.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Does this even run in userspace? When I try something like this (using mfc0) in userspace, I get an illegal instruction exception. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Zajerko-McKee, > Nick > Sent: Friday, September 13, 2002 9:41 AM > To: 'Gareth'; linux-mips@linux-mips.org > Subject: RE: Cycle counter > > > Is this under a OS or a single execution? Are there > interrupts enabled? If > so, disable them for measurements. (Clock interrupt, serial > port, etc.). > > BTW, most MIPS implementations for OS's and monitors use > the count/compare > for their main tick. If you set it to zero you may be > stepping on someone's > tick. A better method might be to read the count register > and read it again > at the end and do a difference - that way you preserve > other's values. > > Other reasons for a delay: to fetch code (external mem > ->cache -> cpu) and > push items onto/off the stack... Theres probably more that > I can't think of > right now... > > -----Original Message----- > From: Gareth [mailto:g.c.bransby-99@student.lboro.ac.uk] > Sent: Friday, September 13, 2002 12:28 PM > To: linux-mips@linux-mips.org > Subject: Cycle counter > > > Hi, > > Another question reagarding the mips malta board. I am > wanting to be able to > find out how many cycles a certain loop takes to execute. I > understand there > is > a cycle counter built into the processor that I want to use > for this. I have > a > bit of inline assembly to do the job but the results I am > getting are not > consistent so i think there is probably something wrong > with my attempt at > the > inline assembly. Here is the code : > > void al_signal_start(void); > size_t al_signal_finished(void); > unsigned int GetcpuCycles(void); > > char str[8]; > > int main (void) > { > double x; > al_signal_start(); > > x = al_signal_finished(); > printf("GetcpuCycles says : %f \n",x); > > return 0; > } > > size_t al_signal_finished(void) > { > return GetcpuCycles(); > } > > void al_signal_start(void) > { > int zero,temp; > __asm__("move $2, $zero"); > __asm__("nop"); > __asm__("mtc0 $2, $9" : : "r" (temp)); > __asm__("nop"); > __asm__("nop"); > __asm__("nop"); > } > > unsigned int GetcpuCycles(void) > { > int temp; > __asm__(".set reorder"); > __asm__("mfc0 $2, $9" : : "r" (temp)); > __asm__("nop"); > __asm__("nop"); > __asm__("nop"); > /*__asm__("jr $31" );*/ > } > > > As you can see, main just starts and stops the counter with > no instructions > in > between. I expexcted the cycle count to be zero or close to > it because of > the > instructions required to get the count but this is not the > case. I am > getting > numbers like 8499. Is there just something wrong with my > assembly or is > there > something else I am missing? > > Thanks for any help > Gareth > > From kevink@mips.com Fri Sep 13 19:08:47 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 Sep 2002 19:08:48 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:15101 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Fri, 13 Sep 2002 19:08:47 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8DH8WUD023841; Fri, 13 Sep 2002 10:08:32 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA04242; Fri, 13 Sep 2002 10:08:33 -0700 (PDT) Message-ID: <009201c25b48$7da2cf30$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Gareth" , References: <20020913172824.5c7ed0a4.g.c.bransby-99@student.lboro.ac.uk> Subject: Re: Cycle counter Date: Fri, 13 Sep 2002 19:10:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips A few comments, a couple of which are in common with Nick's response. 1) With anything except the absolutely latest MIPS CPU design (the M4K), you cannot access the Count register unless you have full system coprocessor access, which is to say, unless you are in the kernel. If you're doing this in user mode, I would expect you to get a SIGILL on your mtc0/mfc0. If you're embedding your code in the kernel and triggering it via a system call, and if you disable interrupts during the sample interval, you should get a more-or-less accurate result. 2) As Nick points out, you should absolutely never *write* to the count register. Sample it and compute deltas, but do not change it, as system timing depends on it in many (most?) kernels. 3) Make sure you check the users manual for your CPU to determine whether the count register is incremented every cycle or every two cycles. 4) Personally, when I want to know how long a loop takes to execute under Linux, I generally use the good old-fashioned gettomeofday() system call to time a very large number of iterations of the loop, enough to run for 10 seconds or so, and divide by the number of iterations. That won't give you the worst-case, caches-cold execution time, but it will give you a very close approximation of the Nth iteration time, without having to embed the code in the kernel. Regards, Kevin K. ----- Original Message ----- From: "Gareth" To: Sent: Friday, September 13, 2002 6:28 PM Subject: Cycle counter > Hi, > > Another question reagarding the mips malta board. I am wanting to be able to > find out how many cycles a certain loop takes to execute. I understand there is > a cycle counter built into the processor that I want to use for this. I have a > bit of inline assembly to do the job but the results I am getting are not > consistent so i think there is probably something wrong with my attempt at the > inline assembly. Here is the code : > > void al_signal_start(void); > size_t al_signal_finished(void); > unsigned int GetcpuCycles(void); > > char str[8]; > > int main (void) > { > double x; > al_signal_start(); > > x = al_signal_finished(); > printf("GetcpuCycles says : %f \n",x); > > return 0; > } > > size_t al_signal_finished(void) > { > return GetcpuCycles(); > } > > void al_signal_start(void) > { > int zero,temp; > __asm__("move $2, $zero"); > __asm__("nop"); > __asm__("mtc0 $2, $9" : : "r" (temp)); > __asm__("nop"); > __asm__("nop"); > __asm__("nop"); > } > > unsigned int GetcpuCycles(void) > { > int temp; > __asm__(".set reorder"); > __asm__("mfc0 $2, $9" : : "r" (temp)); > __asm__("nop"); > __asm__("nop"); > __asm__("nop"); > /*__asm__("jr $31" );*/ > } > > > As you can see, main just starts and stops the counter with no instructions in > between. I expexcted the cycle count to be zero or close to it because of the > instructions required to get the count but this is not the case. I am getting > numbers like 8499. Is there just something wrong with my assembly or is there > something else I am missing? > > Thanks for any help > Gareth > > > From ralf@linux-mips.org Sun Sep 15 21:06:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Sep 2002 21:06:17 +0200 (CEST) Received: from p508B6B85.dip.t-dialin.net ([80.139.107.133]:46976 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Sun, 15 Sep 2002 21:06:16 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8FJ62b24844; Sun, 15 Sep 2002 21:06:02 +0200 Date: Sun, 15 Sep 2002 21:06:01 +0200 From: Ralf Baechle To: Ryan Murray Cc: linux-mips@linux-mips.org, libc-alpha@sources.redhat.com Subject: Re: [patch] userspace mcontext_t doesn't match what kernel returns Message-ID: <20020915210601.A24588@linux-mips.org> References: <20020911032832.GA1500@cyberhqz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020911032832.GA1500@cyberhqz.com>; from rmurray@debian.org on Tue, Sep 10, 2002 at 08:28:32PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Sep 10, 2002 at 08:28:32PM -0700, Ryan Murray wrote: > The definition of mcontext_t in sysdeps/unix/sysv/linux/mips/sys/ucontext.h > does not match what the kernel copies to userspace (struct sigcontext). > alpha, ia64, and hppa have fixed this by typedefing one to the other in > sys/ucontext.h The following patch accomplishes the same thing for mips. I choose to fix the kernel instead which will keep as closer to the MIPS ABI and also prevent having to recompile zillions of user apps. Below my working version of . Ralf /* * 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. * * Low level exception handling * * Copyright (C) 1998, 1999 by Ralf Baechle */ #ifndef _ASM_UCONTEXT_H #define _ASM_UCONTEXT_H typedef struct { gregset_t gregs; fpregset_t fpregs; } mcontext_t; struct ucontext { unsigned long uc_flags; struct ucontext *uc_link; stack_t uc_stack; mcontext_t uc_mcontext; sigset_t uc_sigmask; /* mask last for extensibility */ }; #endif /* _ASM_UCONTEXT_H */ From drow@false.org Sun Sep 15 21:15:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 15 Sep 2002 21:15:59 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:13326 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Sun, 15 Sep 2002 21:15:58 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17qfo7-0000ps-00; Sun, 15 Sep 2002 15:15:51 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17qesP-0005kN-00; Sun, 15 Sep 2002 15:16:13 -0400 Date: Sun, 15 Sep 2002 15:16:13 -0400 From: Daniel Jacobowitz To: Ralf Baechle Cc: Ryan Murray , linux-mips@linux-mips.org, libc-alpha@sources.redhat.com Subject: Re: [patch] userspace mcontext_t doesn't match what kernel returns Message-ID: <20020915191613.GA21794@nevyn.them.org> Mail-Followup-To: Ralf Baechle , Ryan Murray , linux-mips@linux-mips.org, libc-alpha@sources.redhat.com References: <20020911032832.GA1500@cyberhqz.com> <20020915210601.A24588@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020915210601.A24588@linux-mips.org> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Sun, Sep 15, 2002 at 09:06:01PM +0200, Ralf Baechle wrote: > On Tue, Sep 10, 2002 at 08:28:32PM -0700, Ryan Murray wrote: > > > The definition of mcontext_t in sysdeps/unix/sysv/linux/mips/sys/ucontext.h > > does not match what the kernel copies to userspace (struct sigcontext). > > alpha, ia64, and hppa have fixed this by typedefing one to the other in > > sys/ucontext.h The following patch accomplishes the same thing for mips. > > I choose to fix the kernel instead which will keep as closer to the MIPS > ABI and also prevent having to recompile zillions of user apps. Below my > working version of . What are the gregset_t/fpregset_t types in your working tree? There aren't any definitions of them in the only copy of the MIPS code that I have here, and they've had various bad definitions in glibc until recently. They also recently changed... [Although I think your kernel change is the right way to go, here. Just being cautious.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From ralf@linux-mips.org Mon Sep 16 01:09:11 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 01:09:12 +0200 (CEST) Received: from p508B6B85.dip.t-dialin.net ([80.139.107.133]:61059 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 01:09:11 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8FN8vh27166; Mon, 16 Sep 2002 01:08:57 +0200 Date: Mon, 16 Sep 2002 01:08:57 +0200 From: Ralf Baechle To: Ryan Murray , linux-mips@linux-mips.org, libc-alpha@sources.redhat.com Subject: Re: [patch] userspace mcontext_t doesn't match what kernel returns Message-ID: <20020916010857.B24588@linux-mips.org> References: <20020911032832.GA1500@cyberhqz.com> <20020915210601.A24588@linux-mips.org> <20020915191613.GA21794@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020915191613.GA21794@nevyn.them.org>; from dan@debian.org on Sun, Sep 15, 2002 at 03:16:13PM -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Sep 15, 2002 at 03:16:13PM -0400, Daniel Jacobowitz wrote: > > I choose to fix the kernel instead which will keep as closer to the MIPS > > ABI and also prevent having to recompile zillions of user apps. Below my > > working version of . > > What are the gregset_t/fpregset_t types in your working tree? There > aren't any definitions of them in the only copy of the MIPS code that I > have here, and they've had various bad definitions in glibc until > recently. They also recently changed... By the time I sent my previous mail I didn't yet have any. Below the changes I've made to libc but the kernel changes are identical. > [Although I think your kernel change is the right way to go, here. > Just being cautious.] I'm not yet finished. The libc definitions for gregset_t and fpregset_t are not what they're expected to be (coincidentally I got a related bug report just a few days ago, so that issue is also itching a bit ...) and I'd like to change them to as below. This is a binary incompatible change but since so far just one person has complained about the non-matching definitions of struct ucontext, it seems there are very few users of the affected data type? /* Type for general register. */ typedef unsigned long int greg_t; /* Number of general registers. */ #define NGREG 36 typedef greg_t gregset_t[NGREG]; /* Container for all FPU registers. */ typedef struct fpregset { union { double fp_dregs[16]; float fp_fregs[32]; unsigned int fp_regs[32]; } fp_r; unsigned int fp_csr; unsigned int fp_pad; } fpregset_t; /* Context to describe whole processor state. */ typedef struct { gregset_t gregs; fpregset_t fpregs; } mcontext_t; /* Userlevel context. */ typedef struct ucontext { unsigned long int uc_flags; struct ucontext *uc_link; stack_t uc_stack; mcontext_t uc_mcontext; __sigset_t uc_sigmask; } ucontext_t; From g.c.bransby-99@student.lboro.ac.uk Mon Sep 16 11:02:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 11:02:54 +0200 (CEST) Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:411 "EHLO fw-cam.cambridge.arm.com") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 11:02:53 +0200 Received: by fw-cam.cambridge.arm.com; id KAA07872; Mon, 16 Sep 2002 10:02:41 +0100 (BST) Received: from unknown(172.16.9.107) by fw-cam.cambridge.arm.com via smap (V5.5) id xma007623; Mon, 16 Sep 02 10:02:22 +0100 Date: Mon, 16 Sep 2002 10:02:25 +0100 From: Gareth To: Richard Hodges Cc: linux-mips@linux-mips.org Subject: Re: Cycle counter Message-Id: <20020916100225.01903423.g.c.bransby-99@student.lboro.ac.uk> In-Reply-To: References: <20020913172824.5c7ed0a4.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: g.c.bransby-99@student.lboro.ac.uk Precedence: bulk X-list: linux-mips Thanks for the help. This program is not running in linux, it is running as a single application on the core. The processor is a 4kc. I tried your code and it works fine. I just deleted your do_something() so the timer starts and stops immediatly. I get 21 ticks now rather than the 8000 or so I was getting with my code which is much more realistic. On Fri, 13 Sep 2002 09:41:27 -0700 (PDT) Richard Hodges wrote: > On Fri, 13 Sep 2002, Gareth wrote: > > > Another question reagarding the mips malta board. I am wanting to be > > able to find out how many cycles a certain loop takes to execute. I > > understand there is a cycle counter built into the processor that I > > want to use for this. I have a bit of inline assembly to do the job > > but the results I am getting are not consistent so i think there is > > probably something wrong with my attempt at the inline assembly. Here > > is the code : > > > void al_signal_start(void) > > { > > int zero,temp; > > __asm__("move $2, $zero"); > > __asm__("nop"); > > __asm__("mtc0 $2, $9" : : "r" (temp)); > > Is this from user space? If so, this may fail from user space. (I sure > hope it does!) > > > As you can see, main just starts and stops the counter with no > > instructions in between. I expexcted the cycle count to be zero or > > close to it because of the instructions required to get the count but > > this is not the case. I am getting numbers like 8499. Is there just > > something wrong with my assembly or is there something else I am > > missing? > > Try something like this: > > #define GET_CLOCK(var){__asm__ volatile("mfc0 %0,$9":"=r"(var));} > { > unsigned int clock1, clock2; > > GET_CLOCK(clock1); > do_something(); > GET_CLOCK(clock2); > > printf("ticks = %d\n", clock2 - clock1); > } > > -Richard > > > From ralf@linux-mips.org Mon Sep 16 15:02:00 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 15:02:01 +0200 (CEST) Received: from p508B798C.dip.t-dialin.net ([80.139.121.140]:25993 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 15:02:00 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8GD1rT01737 for linux-mips@linux-mips.org; Mon, 16 Sep 2002 15:01:53 +0200 Date: Mon, 16 Sep 2002 15:01:52 +0200 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020916150152.A1677@linux-mips.org> References: <20020904155645.A31893@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020904155645.A31893@linux-mips.org>; from ralf@linux-mips.org on Wed, Sep 04, 2002 at 03:56:45PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Sep 04, 2002 at 03:56:45PM +0200, Ralf Baechle wrote: Additional changes I've done to my working version: > As first think I want to get rid of all the historic crap we have in > our syscall tables for the 64-bit syscalls. Let's start here: > > #define __NR_syscall (__NR_Linux + 0) > > Deprecated because can be implemented in userspace. > > #define __NR_ioperm (__NR_Linux + 101) > #define __NR_iopl (__NR_Linux + 110) > #define __NR_vm86 (__NR_Linux + 113) > > i386 braindamage we're never going to support. So why have it in our > syscall table? > > #define __NR_unused59 (__NR_Linux + 59) > #define __NR_reserved82 (__NR_Linux + 82) > #define __NR_unused109 (__NR_Linux + 109) > #define __NR_unused150 (__NR_Linux + 150) > > Unused entries. Why keep them ... > > #define __NR_break (__NR_Linux + 17) > #define __NR_stty (__NR_Linux + 31) > #define __NR_gtty (__NR_Linux + 32) > #define __NR_ftime (__NR_Linux + 35) > #define __NR_prof (__NR_Linux + 44) > #define __NR_signal (__NR_Linux + 48) > #define __NR_mpx (__NR_Linux + 56) > #define __NR_ulimit (__NR_Linux + 58) > #define __NR_readdir (__NR_Linux + 89) > #define __NR_profil (__NR_Linux + 98) > #define __NR_modify_ldt (__NR_Linux + 123) One more for the same cathegory: #define __NR_lock (__NR_Linux + 53) > Slots that data back to day one of UNIX way before Linux was born. > > #define __NR_socketcall (__NR_Linux + 102) > > Wrapper syscall, obsoleted since quite a while in the 32-bit kernel. > > #define __NR_idle (__NR_Linux + 112) > > Internal syscall, no longer used. > > #define __NR_ipc (__NR_Linux + 117) This implies eleven new entries for: __NR_semget __NR_semop __NR_semctl __NR_msgget __NR_msgsnd __NR_msgrcv __NR_msgctl __NR_shmget __NR_shmat __NR_shmdt __NR_shmctl > Yet another multiplexor syscall and imho another candidate for getting > rid of. > > #define __NR_oldstat (__NR_Linux + 18) > #define __NR_umount (__NR_Linux + 22) > #define __NR_oldfstat (__NR_Linux + 28) > #define __NR_oldlstat (__NR_Linux + 84) > > Superseeded by newer versions. > > #define __NR_uselib (__NR_Linux + 86) > > a.out support. Do we really want that. > > I probably missed a few. The primary purpose of this posting is to get a > discussion about the 64-bit syscall interface started. It's still not > cast into stone so we can modify it as we see fit. The entire syscall > interface is still open for changes, this includes all structures etc. > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI. > > Suggestions, comments etc? Ralf From atulsrivastava9@rediffmail.com Mon Sep 16 15:16:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 15:16:53 +0200 (CEST) Received: from webmail25.rediffmail.com ([203.199.83.147]:30951 "HELO webmail25.rediffmail.com") by linux-mips.org with SMTP id ; Mon, 16 Sep 2002 15:16:53 +0200 Received: (qmail 3465 invoked by uid 510); 16 Sep 2002 13:14:54 -0000 Date: 16 Sep 2002 13:14:54 -0000 Message-ID: <20020916131454.3464.qmail@webmail25.rediffmail.com> Received: from unknown (202.54.89.86) by rediffmail.com via HTTP; 16 Sep 2002 13:14:54 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: reserved instruction exception on MIPS IDT 79S334A Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello, till now everything was alright... now enabled the support for NFS mounting of root filesystem instead of Ramdisk , but running the image gave "Reserved Instruction Exception". anybody has experienced this before ..? do I need any flag in complier..? on net i do find this type of exception description under topic "difference between IDT RC4640/RC64474/RC64574" ..but how i take care of that.. Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From yuasa@hh.iij4u.or.jp Mon Sep 16 15:39:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 15:39:12 +0200 (CEST) Received: from r-hh.iij4u.or.jp ([210.130.0.72]:21495 "EHLO r-hh.iij4u.or.jp") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 15:39:12 +0200 Received: from stratos.montavista.co.jp (h157.p989.iij4u.or.jp [210.138.221.157]) by r-hh.iij4u.or.jp (8.11.6+IIJ/8.11.6) with SMTP id g8GDd0f01804; Mon, 16 Sep 2002 22:39:00 +0900 (JST) Date: Mon, 16 Sep 2002 22:38:51 +0900 From: Yoichi Yuasa To: ralf@oss.sgi.com Cc: linux-mips@linux-mips.org Subject: Re: patch for pci.c Message-Id: <20020916223851.540a112a.yuasa@hh.iij4u.or.jp> In-Reply-To: <20020912185612.56743fd7.yoichi_yuasa@montavista.co.jp> References: <20020912185612.56743fd7.yoichi_yuasa@montavista.co.jp> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yuasa@hh.iij4u.or.jp Precedence: bulk X-list: linux-mips Hi Ralf If this patch is not applied, the following errors will occur. Please apply this patch to linux_2_4 tag. make[1]: Entering directory `/home/yuasa/src/mips/linux/arch/mips/kernel' mipsel-linux-gcc -D__KERNEL__ -I/home/yuasa/src/mips/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I /home/yuasa/src/mips/linux/include/asm/gcc -G 0 -mno-abicalls -fno-pic -pipe -mcpu=r4600 -mips2 -Wa,--trap -nostdinc -iwithprefix include -DKBUILD_BASENAME=pci -c -o pci.o pci.c pci.c:104: conflicting types for `pcibios_enable_device' /home/yuasa/src/mips/linux/include/linux/pci.h:496: previous declaration of `pcibios_enable_device' make[1]: *** [pci.o] Error 1 make[1]: Leaving directory `/home/yuasa/src/mips/linux/arch/mips/kernel' make: *** [_dir_arch/mips/kernel] Error 2 On Thu, 12 Sep 2002 18:56:12 +0900 Yoichi Yuasa wrote: > Hi Ralf, > > The argument of pcibios_enable_device is changed. > > In include/linux/pci.h: > int pcibios_enable_device(struct pci_dev *, int mask); > > The following patch is required for the cvs tree of linux_2_4 tag. > > --- ./arch/mips/kernel/pci.c.orig Wed May 29 12:03:16 2002 > +++ ./arch/mips/kernel/pci.c Thu Sep 12 18:22:14 2002 > @@ -100,7 +100,7 @@ > pcibios_fixup_irqs(); > } > > -int pcibios_enable_device(struct pci_dev *dev) > +int pcibios_enable_device(struct pci_dev *dev, int mask) > { > /* pciauto_assign_resources() will enable all devices found */ > return 0; Thanks, Yoichi From js@convergence.de Mon Sep 16 16:16:13 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 16:16:14 +0200 (CEST) Received: from buserror-extern.convergence.de ([212.84.236.66]:33284 "EHLO hell") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 16:16:13 +0200 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17qwfV-0002CF-00 for ; Mon, 16 Sep 2002 16:16:05 +0200 Date: Mon, 16 Sep 2002 16:16:05 +0200 From: Johannes Stezenbach To: linux-mips@linux-mips.org Subject: Compressed kernel image Message-ID: <20020916141605.GA8409@convergence.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, for the embedded Linux project I'm working on I needed the ability to boot a compressed kernel image from ROM, i.e. uncompress it to RAM and jump to the kernel entry. So I took some parts from arch/i386/boot/compressed, and some from linux-mips.sf.net/arch/mips/zboot/ and hacked up something which works for me. The appended patch is incomplete as I removed anything specific to my platform. To use it for a different platform you would need: - A head.S which works for your board. Depending on what your bootloader does, you probably don't need the cache flushing stuff. - For debug output, you need a putc() implementation; maybe the included uart16550.c works for you. If you think you don't need to debug anything ;-), you could use a dummy putc(). - Set some configuration variables in the Makefile. I tested both booting from ROM and loading the zImage to RAM, then uncompressing to some different area in RAM. Note: For my platform I allocate a 2MB frame buffer at 0x80002000 in unified memory, so reuse this space for uncompressing the zImage. I hope the patch is of use to someone. Comments are welcome. Regards, Johannes --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-oss-zimage.patch" diff -urN linux-oss.orig/arch/mips/Makefile linux-oss/arch/mips/Makefile --- linux-oss.orig/arch/mips/Makefile 2002-09-09 21:30:11.000000000 +0200 +++ linux-oss/arch/mips/Makefile 2002-09-16 14:55:40.000000000 +0200 @@ -475,6 +475,11 @@ endif MAKEBOOT = $(MAKE) -C arch/$(ARCH)/boot +MAKEZBOOT = $(MAKE) -C arch/$(ARCH)/boot/compressed + +BOOT_TARGETS = zImage +$(BOOT_TARGETS): vmlinux + @$(MAKEZBOOT) $@ vmlinux.ecoff: vmlinux @$(MAKEBOOT) $@ @@ -484,6 +489,7 @@ rm -f arch/$(ARCH)/ld.script $(MAKE) -C arch/$(ARCH)/tools clean $(MAKE) -C arch/mips/baget clean + $(MAKE) -C arch/$(ARCH)/boot/compressed clean archmrproper: @$(MAKEBOOT) mrproper diff -urN linux-oss.orig/arch/mips/boot/compressed/Makefile linux-oss/arch/mips/boot/compressed/Makefile --- linux-oss.orig/arch/mips/boot/compressed/Makefile 1970-01-01 01:00:00.000000000 +0100 +++ linux-oss/arch/mips/boot/compressed/Makefile 2002-09-16 15:01:13.000000000 +0200 @@ -0,0 +1,74 @@ +# +# linux/arch/mips/boot/compressed/Makefile +# +# create a compressed zImage from the original vmlinux +# + +HEAD = head.o +SYSTEM = $(TOPDIR)/vmlinux + +ZLDFLAGS = -e zstartup -T $(TOPDIR)/arch/mips/ld.script + +all: $(TOPDIR)/zImage + +################################################################## +# board configuration +################################################################## + +ifdef CONFIG_FOOBAR // board specific + +# ZIMAGE_OFFSET is the load offset of the compression loader +ifdef BOOT_FROM_ROM +# zImage in ROM after boot code +ZIMAGE_OFFSET := 0x9fc20000 +ZBSS := -Tbss 0x80002000 +else +# for loading in RAM +ZIMAGE_OFFSET := 0x81000000 +endif + +# *MUST* match LOADADDR from arch/mips/Makefile +LOADADDR := 0x80202000 +KERNEL_ENTRY = $(shell $(OBJDUMP) -f $(SYSTEM) | sed -n -e 's/^start address //p') +# working space for gunzip: +FREE_RAM := 0x80080000 +END_RAM := 0x80200000 +# putc config +PUTC_IMPL := uart16550.o +uart16550.o: uart16550.c Makefile + $(CC) $(CFLAGS) -DBASE=0xb2001000 -DMAX_BAUD=1152000 -DREG_OFFSET=0x10 -c uart16550.c +endif + +################################################################## + +OBJECTS = $(HEAD) misc.o $(PUTC_IMPL) + +ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZBSS) $(ZLDFLAGS) + +.PHONY: zImage +zImage: $(TOPDIR)/zImage + +$(TOPDIR)/zImage: piggy.o $(OBJECTS) + $(LD) $(ZLINKFLAGS) -o $(TOPDIR)/zImage $(OBJECTS) piggy.o + +head.o: head.S Makefile $(SYSTEM) + $(CC) $(AFLAGS) -DKERNEL_ENTRY=$(KERNEL_ENTRY) -c head.S + +comma := , + +misc.o: misc.c Makefile + $(CC) $(CFLAGS) -DLOADADDR=$(LOADADDR) \ + -DFREE_RAM=$(FREE_RAM) -DEND_RAM=$(END_RAM) \ + -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) -c misc.c + +piggy.o: $(SYSTEM) + tmppiggy=_tmp_$$$$piggy; \ + rm -f $$tmppiggy $$tmppiggy.gz $$tmppiggy.lnk; \ + $(OBJCOPY) -S -O binary -R .note -R .comment $(SYSTEM) $$tmppiggy; \ + gzip -f -9 < $$tmppiggy > $$tmppiggy.gz; \ + echo "SECTIONS { .data : { input_len = .; LONG(input_data_end - input_data) input_data = .; *(.data) input_data_end = .; }}" > $$tmppiggy.lnk; \ + $(LD) -r -o piggy.o -b binary $$tmppiggy.gz -b elf32-tradbigmips -T $$tmppiggy.lnk; \ + rm -f $$tmppiggy $$tmppiggy.gz $$tmppiggy.lnk + +clean: + rm -f $(TOPDIR)/zImage _tmp_* *.o diff -urN linux-oss.orig/arch/mips/boot/compressed/head.S linux-oss/arch/mips/boot/compressed/head.S --- linux-oss.orig/arch/mips/boot/compressed/head.S 1970-01-01 01:00:00.000000000 +0100 +++ linux-oss/arch/mips/boot/compressed/head.S 2002-09-16 15:11:48.000000000 +0200 @@ -0,0 +1,100 @@ +/* + * arch/mips/boot/compressed/head.S + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1994, 1995 Waldorf Electronics + * Written by Ralf Baechle and Andreas Busse + * Copyright (C) 1995 - 1999 Ralf Baechle + * Copyright (C) 1996 Paul M. Antoine + * Modified for DECStation and hence R3000 support by Paul M. Antoine + * Further modifications by David S. Miller and Harald Koerfgen + * Copyright (C) 1999 Silicon Graphics, Inc. + * + * Head.S contains the MIPS exception handler and startup code. + * + ************************************************************************** + * 9 Nov, 2000. + * Added Cache Error exception handler and SBDDP EJTAG debug exception. + * + * Kevin Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com + * Copyright (C) 2000 MIPS Technologies, Inc. All rights reserved. + ************************************************************************** + * 08/2002 modified for zImage boot from ROM + * Johannes Stezenbach + */ + + +#include +#include + +#include +#include +#include +#include +#include +#include + +#define IndexInvalidate_I 0x00 + + .set noreorder + .cprestore + LEAF(zstartup) +zstartup: + + la sp, .stack + move s0, a0 + move s1, a1 + move s2, a2 + move s3, a3 + + /* Clear BSS */ + /* Note: when zImage is in ROM, _edata and _bss point to + * ROM space even when using -Tbss on the linker command line; + * maybe ld.script needs to be corrected. + */ + la a0, .stack + la a2, _end +1: sw zero, 0(a0) + bne a2, a0, 1b + addu a0, 4 + + /* flush the I-Cache */ + li k0, 0x80000000 # start address + li k1, 0x80004000 # end address (16KB I-Cache) + subu k1, 128 + +2: + .set mips3 + cache IndexInvalidate_I, 0(k0) + cache IndexInvalidate_I, 32(k0) + cache IndexInvalidate_I, 64(k0) + cache IndexInvalidate_I, 96(k0) + .set mips0 + + bne k0, k1, 2b + addu k0, k0, 128 + /* done */ + + la ra, 3f + la k0, decompress_kernel + jr k0 + nop +3: + + move a0, s0 + move a1, s1 + move a2, s2 + move a3, s3 + li k0, KERNEL_ENTRY + jr k0 + nop +4: + b 4b + END(zstartup) + + .bss + .fill 0x2000 + EXPORT(.stack) diff -urN linux-oss.orig/arch/mips/boot/compressed/misc.c linux-oss/arch/mips/boot/compressed/misc.c --- linux-oss.orig/arch/mips/boot/compressed/misc.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-oss/arch/mips/boot/compressed/misc.c 2002-08-06 19:19:11.000000000 +0200 @@ -0,0 +1,311 @@ +/* + * arch/mips/boot/misc.c + * + * This is a collection of several routines from gzip-1.0.3 + * adapted for Linux. + * + * malloc by Hannu Savolainen 1993 and Matthias Urlichs 1994 + * puts by Nick Holloway 1993, better puts by Martin Mares 1995 + * High loaded stuff by Hans Lermen & Werner Almesberger, Feb. 1996 + * + * Modified by RidgeRun Inc. + * + * 08/2002 modified for booting zImage from ROM + * Johannes Stezenbach + * (All statically initialized data is read only, all data which needs to be + * in RAM must not be statically initialized.) + */ + +#define ZDEBUG 1 + +#include + +/* + * gzip declarations + */ +#define OF(args) args +#define STATIC static +#define memzero(s, n) memset ((s), 0, (n)) +typedef unsigned char uch; +typedef unsigned short ush; +typedef unsigned long ulg; +#define WSIZE 0x8000 /* Window size must be at least 32k, */ + /* and a power of two */ +static uch *inbuf; /* input buffer */ +static uch window[WSIZE]; /* Sliding window buffer */ + +/* gzip flag byte */ +#define ASCII_FLAG 0x01 /* bit 0 set: file probably ASCII text */ +#define CONTINUATION 0x02 /* bit 1 set: continuation of multi-part gzip file */ +#define EXTRA_FIELD 0x04 /* bit 2 set: extra field present */ +#define ORIG_NAME 0x08 /* bit 3 set: original file name present */ +#define COMMENT 0x10 /* bit 4 set: file comment present */ +#define ENCRYPTED 0x20 /* bit 5 set: file is encrypted */ +#define RESERVED 0xC0 /* bit 6,7: reserved */ + + +static unsigned insize; /* valid bytes in inbuf */ +static unsigned inptr; /* index of next byte to be processed in inbuf */ +static unsigned outcnt; /* bytes in output buffer */ + +void variable_init(void); +static void puts(const char *); +extern void putc_init(void); +extern void putc(unsigned char c); +static int fill_inbuf(void); +static void flush_window(void); +static void error(char *m); +static void gzip_mark(void **); +static void gzip_release(void **); + +extern char input_data[]; +extern int input_len; + + +void int2hex(unsigned long val) +{ + unsigned char buf[10]; + int i; + for (i = 7; i >= 0; i--) + { + buf[i] = "0123456789ABCDEF"[val & 0x0F]; + val >>= 4; + } + buf[8] = '\0'; + puts(buf); +} + +static unsigned long byte_count; + +int get_byte(void) +{ +#if ZDEBUG > 1 + static int printCnt; +#endif + unsigned char c = (inptr < insize ? inbuf[inptr++] : fill_inbuf()); + byte_count++; + +#if ZDEBUG > 1 + if (printCnt++ < 32) + { + puts("byte count = "); + int2hex(byte_count); + puts(" byte val = "); + int2hex(c); + puts("\n"); + } +#endif + return c; +} + +/* Diagnostic functions */ +#ifdef DEBUG +# define Assert(cond,msg) {if(!(cond)) error(msg);} +# define Trace(x) fprintf x +# define Tracev(x) {if (verbose) fprintf x ;} +# define Tracevv(x) {if (verbose>1) fprintf x ;} +# define Tracec(c,x) {if (verbose && (c)) fprintf x ;} +# define Tracecv(c,x) {if (verbose>1 && (c)) fprintf x ;} +#else +# define Assert(cond,msg) +# define Trace(x) +# define Tracev(x) +# define Tracevv(x) +# define Tracec(c,x) +# define Tracecv(c,x) +#endif + +/* + * This is set up by the setup-routine at boot-time + */ + +static long bytes_out; +static uch *output_data; +static unsigned long output_ptr; + + +static void *malloc(int size); +static void free(void *where); +static void error(char *m); +static void gzip_mark(void **); +static void gzip_release(void **); + +static unsigned long free_mem_ptr; +static unsigned long free_mem_end_ptr; + +#include "../../../../lib/inflate.c" + +static void *malloc(int size) +{ + void *p; + + if (size < 0) + error("Malloc error\n"); + if (free_mem_ptr <= 0) error("Memory error\n"); + + free_mem_ptr = (free_mem_ptr + 3) & ~3; /* Align */ + + p = (void *) free_mem_ptr; + free_mem_ptr += size; + + if (free_mem_ptr >= free_mem_end_ptr) + error("\nOut of memory\n"); + + return p; +} + +static void free(void *where) +{ /* Don't care */ +} + +static void gzip_mark(void **ptr) +{ + *ptr = (void *) free_mem_ptr; +} + +static void gzip_release(void **ptr) +{ + free_mem_ptr = (long) *ptr; +} + +static void puts(const char *s) +{ + while (*s) { + if (*s == 10) + putc(13); + putc(*s++); + } +} + +void *memset(void *s, int c, size_t n) +{ + int i; + char *ss = (char *) s; + + for (i = 0; i < n; i++) + ss[i] = c; + return s; +} + +void *memcpy(void *__dest, __const void *__src, size_t __n) +{ + int i; + char *d = (char *) __dest, *s = (char *) __src; + + for (i = 0; i < __n; i++) + d[i] = s[i]; + return __dest; +} + +/* =========================================================================== + * Fill the input buffer. This is called only when the buffer is empty + * and at least one byte is really needed. + */ +static int fill_inbuf(void) +{ + if (insize != 0) { + error("ran out of input data\n"); + } + + inbuf = input_data; + insize = input_len; + inptr = 1; + return inbuf[0]; +} + +/* =========================================================================== + * Write the output window window[0..outcnt-1] and update crc and bytes_out. + * (Used for the decompressed data only.) + */ +static void flush_window(void) +{ + ulg c = crc; /* temporary variable */ + unsigned n; + uch *in, *out, ch; + + in = window; + out = &output_data[output_ptr]; + for (n = 0; n < outcnt; n++) { + ch = *out++ = *in++; + c = crc_32_tab[((int) c ^ ch) & 0xff] ^ (c >> 8); + } + crc = c; + bytes_out += (ulg) outcnt; + output_ptr += (ulg) outcnt; + outcnt = 0; +} + +void check_mem(void) +{ + int i; + + puts("\ncplens = "); + for (i = 0; i < 10; i++) { + int2hex(cplens[i]); + puts(" "); + } + puts("\ncplext = "); + for (i = 0; i < 10; i++) { + int2hex(cplext[i]); + puts(" "); + } + puts("\nborder = "); + for (i = 0; i < 10; i++) { + int2hex(border[i]); + puts(" "); + } + puts("\n"); +} + +static void error(char *x) +{ + check_mem(); + puts("\n\n"); + puts(x); + puts("byte_count = "); + int2hex(byte_count); + puts("\n"); + puts("\n\n -- System halted"); + while (1); /* Halt */ +} + +void variable_init(void) +{ + byte_count = 0; + output_data = (char *) LOADADDR; + free_mem_ptr = FREE_RAM; + free_mem_end_ptr = END_RAM; +#if ZDEBUG + puts("variable_init:\n"); + int2hex((unsigned long)output_data); puts("\n"); + int2hex(free_mem_ptr); puts("\n"); + int2hex(free_mem_end_ptr); puts("\n"); + int2hex((unsigned long)input_data); puts("\n"); + int2hex(input_len); puts("\n"); +#endif +} + +int decompress_kernel(void) +{ +#if ZDEBUG + //check_mem(); + unsigned long *p = (unsigned long *)LOADADDR; +#endif + + putc_init(); + variable_init(); + + makecrc(); + puts("Uncompressing Linux... \n"); + gunzip(); // ...see inflate.c + puts("Ok, booting the kernel.\n"); + +#if ZDEBUG + int2hex(p[0]); puts("\n"); + int2hex(p[1]); puts("\n"); + int2hex(p[2]); puts("\n"); + int2hex(p[3]); puts("\n"); +#endif + + return 0; +} diff -urN linux-oss.orig/arch/mips/boot/compressed/uart16550.c linux-oss/arch/mips/boot/compressed/uart16550.c --- linux-oss.orig/arch/mips/boot/compressed/uart16550.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-oss/arch/mips/boot/compressed/uart16550.c 2002-09-16 15:16:38.000000000 +0200 @@ -0,0 +1,141 @@ +/* + * 16550 uart routines. + * based on something similar to arch/mips/vr4181/osprey/dbg_io.c + * Copyright (C) 2001 MontaVista Software Inc. + * Author: jsun@mvista.com or jsun@junsun.net + */ +#include +#include + +/* === CONFIG === */ + +/* + * #define BASE 0xb2001000 + * #define MAX_BAUD 1152000 + * #define REG_OFFSET 0x10 + */ +#if (!defined(BASE) || !defined(MAX_BAUD) || !defined(REG_OFFSET)) +#error You must define BASE, MAX_BAUD and REG_OFFSET in the Makefile. +#endif + +#ifndef INIT_SERIAL_PORT +#define INIT_SERIAL_PORT 1 +#endif + +#ifndef DEFAULT_BAUD +#define DEFAULT_BAUD UART16550_BAUD_115200 +#endif +#ifndef DEFAULT_PARITY +#define DEFAULT_PARITY UART16550_PARITY_NONE +#endif +#ifndef DEFAULT_DATA +#define DEFAULT_DATA UART16550_DATA_8BIT +#endif +#ifndef DEFAULT_STOP +#define DEFAULT_STOP UART16550_STOP_1BIT +#endif + +/* === END OF CONFIG === */ + +typedef unsigned char uint8; +typedef unsigned int uint32; + +#define UART16550_BAUD_2400 2400 +#define UART16550_BAUD_4800 4800 +#define UART16550_BAUD_9600 9600 +#define UART16550_BAUD_19200 19200 +#define UART16550_BAUD_38400 38400 +#define UART16550_BAUD_57600 57600 +#define UART16550_BAUD_115200 115200 + +#define UART16550_PARITY_NONE 0 +#define UART16550_PARITY_ODD 0x08 +#define UART16550_PARITY_EVEN 0x18 +#define UART16550_PARITY_MARK 0x28 +#define UART16550_PARITY_SPACE 0x38 + +#define UART16550_DATA_5BIT 0x0 +#define UART16550_DATA_6BIT 0x1 +#define UART16550_DATA_7BIT 0x2 +#define UART16550_DATA_8BIT 0x3 + +#define UART16550_STOP_1BIT 0x0 +#define UART16550_STOP_2BIT 0x4 + +/* register offset */ +#define OFS_RCV_BUFFER (0*REG_OFFSET) +#define OFS_TRANS_HOLD (0*REG_OFFSET) +#define OFS_SEND_BUFFER (0*REG_OFFSET) +#define OFS_INTR_ENABLE (1*REG_OFFSET) +#define OFS_INTR_ID (2*REG_OFFSET) +#define OFS_DATA_FORMAT (3*REG_OFFSET) +#define OFS_LINE_CONTROL (3*REG_OFFSET) +#define OFS_MODEM_CONTROL (4*REG_OFFSET) +#define OFS_RS232_OUTPUT (4*REG_OFFSET) +#define OFS_LINE_STATUS (5*REG_OFFSET) +#define OFS_MODEM_STATUS (6*REG_OFFSET) +#define OFS_RS232_INPUT (6*REG_OFFSET) +#define OFS_SCRATCH_PAD (7*REG_OFFSET) + +#define OFS_DIVISOR_LSB (0*REG_OFFSET) +#define OFS_DIVISOR_MSB (1*REG_OFFSET) + +#define UART16550_READ(y) (*((volatile uint8*)(BASE + y))) +#define UART16550_WRITE(y, z) ((*((volatile uint8*)(BASE + y))) = z) + +static void Uart16550Init(uint32 baud, uint8 data, uint8 parity, uint8 stop) +{ + /* disable interrupts */ + UART16550_WRITE(OFS_LINE_CONTROL, 0x0); + UART16550_WRITE(OFS_INTR_ENABLE, 0); + + /* set up baud rate */ + { + uint32 divisor; + + /* set DIAB bit */ + UART16550_WRITE(OFS_LINE_CONTROL, 0x80); + + /* set divisor */ + divisor = MAX_BAUD / baud; + UART16550_WRITE(OFS_DIVISOR_LSB, divisor & 0xff); + UART16550_WRITE(OFS_DIVISOR_MSB, (divisor & 0xff00)>>8); + + /* clear DIAB bit */ + UART16550_WRITE(OFS_LINE_CONTROL, 0x0); + } + + /* set data format */ + UART16550_WRITE(OFS_DATA_FORMAT, data | parity | stop); +} + + +void +putc_init(void) +{ +#if INIT_SERIAL_PORT + Uart16550Init(DEFAULT_BAUD, DEFAULT_DATA, DEFAULT_PARITY, DEFAULT_STOP); +#endif +} + +void +putc(unsigned char c) +{ + while ((UART16550_READ(OFS_LINE_STATUS) &0x20) == 0); + UART16550_WRITE(OFS_SEND_BUFFER, c); +} + +#if 0 +unsigned char +getc(void) +{ + while((UART16550_READ(OFS_LINE_STATUS) & 0x1) == 0); + return UART16550_READ(OFS_RCV_BUFFER); +} + +int +tstc(void) +{ + return((UART16550_READ(OFS_LINE_STATUS) & 0x01) != 0); +} +#endif --envbJBWh7q8WU6mo-- From ralf@linux-mips.org Mon Sep 16 16:41:51 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 16:41:52 +0200 (CEST) Received: from p508B798C.dip.t-dialin.net ([80.139.121.140]:10634 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 16:41:51 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8GEfbx02587; Mon, 16 Sep 2002 16:41:37 +0200 Date: Mon, 16 Sep 2002 16:41:37 +0200 From: Ralf Baechle To: atul srivastava Cc: linux-mips@linux-mips.org Subject: Re: reserved instruction exception on MIPS IDT 79S334A Message-ID: <20020916164137.A2579@linux-mips.org> References: <20020916131454.3464.qmail@webmail25.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020916131454.3464.qmail@webmail25.rediffmail.com>; from atulsrivastava9@rediffmail.com on Mon, Sep 16, 2002 at 01:14:54PM -0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 16, 2002 at 01:14:54PM -0000, atul srivastava wrote: > till now everything was alright... > now enabled the support for NFS mounting of root filesystem > instead of Ramdisk , but running the > image gave "Reserved Instruction Exception". > > anybody has experienced this before ..? > > do I need any flag in complier..? > > on net i do find this type of exception description > under topic "difference between IDT RC4640/RC64474/RC64574" ..but > how i take care of that.. I bet you're not properly flushing the caches before executing the unpacked code. Ralf From correo@cpmsa.com Mon Sep 16 16:48:32 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 16:48:32 +0200 (CEST) Received: from m30exfe4.codetel.net.do ([196.3.81.59]:17648 "EHLO mail4.codetel.net.do") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 16:48:32 +0200 Received: from notebook ([200.88.2.223]) by mail4.codetel.net.do with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 10:48:20 -0400 Reply-To: From: =?iso-8859-1?Q?CP&M_Concepci=F3n=2C_Poueri=E9_&_Mu=F1oz=2C_S.A.?= To: Subject: How to unsuscribe? Date: Mon, 16 Sep 2002 10:48:20 -0400 Organization: CP&M Message-ID: <001201c25d90$19ba9fd0$0200a8c0@notebook> 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, Build 10.0.2616 In-Reply-To: <20020916164137.A2579@linux-mips.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 16 Sep 2002 14:48:20.0966 (UTC) FILETIME=[19D1F860:01C25D90] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: correo@cpmsa.com Precedence: bulk X-list: linux-mips Anybody knows how to unsuscribe from this list? From ralf@linux-mips.org Mon Sep 16 17:41:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 17:41:08 +0200 (CEST) Received: from p508B798C.dip.t-dialin.net ([80.139.121.140]:53130 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 17:41:07 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8GFeq203342 for linux-mips@linux-mips.org; Mon, 16 Sep 2002 17:40:52 +0200 Date: Mon, 16 Sep 2002 17:40:52 +0200 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: Re: 64-bit and N32 kernel interfaces Message-ID: <20020916174052.B2579@linux-mips.org> References: <20020904155645.A31893@linux-mips.org> <20020916150152.A1677@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020916150152.A1677@linux-mips.org>; from ralf@linux-mips.org on Mon, Sep 16, 2002 at 03:01:52PM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 16, 2002 at 03:01:52PM +0200, Ralf Baechle wrote: More chainswing ... > > As first think I want to get rid of all the historic crap we have in > > our syscall tables for the 64-bit syscalls. Let's start here: > > > > #define __NR_syscall (__NR_Linux + 0) > > > > Deprecated because can be implemented in userspace. > > > > #define __NR_ioperm (__NR_Linux + 101) > > #define __NR_iopl (__NR_Linux + 110) > > #define __NR_vm86 (__NR_Linux + 113) > > > > i386 braindamage we're never going to support. So why have it in our > > syscall table? > > > > #define __NR_unused59 (__NR_Linux + 59) > > #define __NR_reserved82 (__NR_Linux + 82) > > #define __NR_unused109 (__NR_Linux + 109) > > #define __NR_unused150 (__NR_Linux + 150) > > > > Unused entries. Why keep them ... > > > > #define __NR_break (__NR_Linux + 17) > > #define __NR_stty (__NR_Linux + 31) > > #define __NR_gtty (__NR_Linux + 32) > > #define __NR_ftime (__NR_Linux + 35) > > #define __NR_prof (__NR_Linux + 44) > > #define __NR_signal (__NR_Linux + 48) > > #define __NR_mpx (__NR_Linux + 56) > > #define __NR_ulimit (__NR_Linux + 58) > > #define __NR_readdir (__NR_Linux + 89) > > #define __NR_profil (__NR_Linux + 98) > > #define __NR_modify_ldt (__NR_Linux + 123) > > One more for the same cathegory: > > #define __NR_lock (__NR_Linux + 53) > > > Slots that data back to day one of UNIX way before Linux was born. > > > > #define __NR_socketcall (__NR_Linux + 102) > > > > Wrapper syscall, obsoleted since quite a while in the 32-bit kernel. > > > > #define __NR_idle (__NR_Linux + 112) > > > > Internal syscall, no longer used. > > > > #define __NR_ipc (__NR_Linux + 117) > > This implies eleven new entries for: > > __NR_semget > __NR_semop > __NR_semctl > __NR_msgget > __NR_msgsnd > __NR_msgrcv > __NR_msgctl > __NR_shmget > __NR_shmat > __NR_shmdt > __NR_shmctl > > > Yet another multiplexor syscall and imho another candidate for getting > > rid of. > > > > #define __NR_oldstat (__NR_Linux + 18) > > #define __NR_umount (__NR_Linux + 22) > > #define __NR_oldfstat (__NR_Linux + 28) > > #define __NR_oldlstat (__NR_Linux + 84) > > > > Superseeded by newer versions. > > > > #define __NR_uselib (__NR_Linux + 86) > > > > a.out support. Do we really want that. > > > > I probably missed a few. The primary purpose of this posting is to get a > > discussion about the 64-bit syscall interface started. It's still not > > cast into stone so we can modify it as we see fit. The entire syscall > > interface is still open for changes, this includes all structures etc. > > Along with a 64-bit ABI we'll also have to deciede about a N32 ABI. llseek, pread64/pwrite64, getdent64 are no longer needed as their standard counterparts are already 64 bit. Modern libc doesn't use the old style signal calls __NR_sigaction, __NR_sigsuspend, __NR_sigpending, __NR_sigprocmask. That means __NR_sigreturn can also go. __NR_sgetmask and __NR_ssetmask are only capable of dealing with signal masks of at most bitsof(long) and thus have become useless and replaced by sigprocmask(2). __NR_waitpid can be implemented on top of wait(2). __NR_stime can be implemented on top of settimeofday(2). __NR_nice can be implemented on top of getpriority / setpriority and was a stupid interface anyway. __NR_recv can be implemented on recvfrom(2) and __NR_send using sendfrom(2). Ralf From js@convergence.de Mon Sep 16 18:40:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 18:40:39 +0200 (CEST) Received: from buserror-extern.convergence.de ([212.84.236.66]:4613 "EHLO hell") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 18:40:38 +0200 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17qyvK-0003HG-00 for ; Mon, 16 Sep 2002 18:40:34 +0200 Date: Mon, 16 Sep 2002 18:40:34 +0200 From: Johannes Stezenbach To: linux-mips@linux-mips.org Subject: Once again: test_and_set for CPUs w/o LL/SC Message-ID: <20020916164034.GA12489@convergence.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, the thread with subject "LL/SC benchmarking" in mid July died away, since I was busy doing more pressing things. To refresh your memory: The NEC VR41xx CPU has no LL/SC instructions, so they must be emulated by the kernel, which slows down the test-and-set and compare-and-swap operations (used by linux-threads) considerably. For the VR41xx (and other CPUs which have branch-likely instructions), there exisits a workaround which enables userspace-only atomic operations, with minor help from the kernel: The kernel must guarantee that register k1 is not equal to some magic value after every transition to userspace. Two things were left open in July: - find out the minimal amount of changes to the kernel to guarantee k1 != MAGIC after eret - determine how to tell glibc to use the branch-likely workaround instead of emulated LL/SC I looked through the kernel code, and I think that arch/mips/mm/tlbex-r4k.S always leaves the last value from CP0_ENTRYLO in k1, thus bit 31 of k1 is guarateed to be zero. The other interrupt and exception handlers seem to be too complex to make any guarantees about the value left in k1, so I added a 'move k1,$0' to RESTORE_SP_AND_RET in include/asm-mips/stackframe.h, and conditionalized it via CONFIG_MIPS_USERSPACE_ATOMIC_OPS. To tell glibc about the support for the branch-likely workaround I added a sysctl. A few things: - I couldn't come up with a better name for the config option and sysctl. - If glibc were to use sysctl(2) to query for mips_userspace_atomic_ops, glibc would depend on linux/sysctl.h from the very newest kernel, which is bad; maybe glibc should just query for exisitence of the file /proc/sys/kernel/mips_userspace_atomic_ops? Or maybe we should just add a /proc/foobar instead of a sysctl? - Maybe I should add some comments to tlbex-r4k.S so no-one accidentally breaks the k1 < 0x80000000 assertion? Please comment on the appended patch. If we could agree the kernel support for this, I would prepare a matching glibc patch. Regards, Johannes --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-oss-nollsc.patch" Index: Documentation/Configure.help =================================================================== RCS file: /cvs/linux/Documentation/Attic/Configure.help,v retrieving revision 1.109.2.8 diff -a -u -r1.109.2.8 Configure.help --- Documentation/Configure.help 2002/09/11 12:44:23 1.109.2.8 +++ Documentation/Configure.help 2002/09/16 14:39:29 @@ -2337,6 +2337,20 @@ for better performance, N if you don't know. You must say Y here for multiprocessor machines. +Support userspace atomic ops for MIPS2 CPUs +CONFIG_MIPS_USERSPACE_ATOMIC_OPS + Say Y here if your CPU supports the MIPS2 ISA (i.e. it has + support for the "branch likely" instructions), but does not + have the LL and SC instructions which normally are required for + userspace atomic operations, e.g. for the NEC VR41xx CPUs. + Selecting this option guarantees that the value of the k1 register, + which is normally reserved for the kernel, is lower than + 0x80000000 after any transition from kernel to userspace. It + also sets the read-only sysctl kernel.mips_userspace_atomic_ops to + the value "1", so that libc/libpthread can detect kernel support for + a fast test-and-set implementation for this kind of CPU (instead + of LL/SC emulation). If in doubt, say N. + lld and scd instructions available CONFIG_CPU_HAS_LLDSCD Say Y here if your CPU has the lld and scd instructions, the 64-bit Index: arch/mips/config-shared.in =================================================================== RCS file: /cvs/linux/arch/mips/config-shared.in,v retrieving revision 1.1.2.18 diff -a -u -r1.1.2.18 config-shared.in --- arch/mips/config-shared.in 2002/09/11 12:44:28 1.1.2.18 +++ arch/mips/config-shared.in 2002/09/16 14:39:31 @@ -513,6 +513,9 @@ dep_bool 'Override CPU Options' CONFIG_CPU_ADVANCED $CONFIG_MIPS32 if [ "$CONFIG_CPU_ADVANCED" = "y" ]; then bool ' ll/sc Instructions available' CONFIG_CPU_HAS_LLSC + if [ "$CONFIG_CPU_HAS_LLSC" = "n" ]; then + bool ' Support userspace atomic ops for MIPS2 CPUs' CONFIG_MIPS_USERSPACE_ATOMIC_OPS + fi bool ' lld/scd Instructions available' CONFIG_CPU_HAS_LLDSCD bool ' Writeback Buffer available' CONFIG_CPU_HAS_WB else @@ -528,6 +531,11 @@ define_bool CONFIG_CPU_HAS_LLDSCD n define_bool CONFIG_CPU_HAS_WB n fi + if [ "$CONFIG_CPU_VR41XX" = "y" ]; then + define_bool CONFIG_MIPS_USERSPACE_ATOMIC_OPS y + else + define_bool CONFIG_MIPS_USERSPACE_ATOMIC_OPS n + fi else if [ "$CONFIG_CPU_MIPS32" = "y" ]; then define_bool CONFIG_CPU_HAS_LLSC y @@ -538,6 +546,7 @@ define_bool CONFIG_CPU_HAS_LLDSCD y define_bool CONFIG_CPU_HAS_WB n fi + define_bool CONFIG_MIPS_USERSPACE_ATOMIC_OPS n fi fi if [ "$CONFIG_CPU_R3000" = "y" ]; then Index: include/asm-mips/stackframe.h =================================================================== RCS file: /cvs/linux/include/asm-mips/stackframe.h,v retrieving revision 1.18.2.2 diff -a -u -r1.18.2.2 stackframe.h --- include/asm-mips/stackframe.h 2002/08/05 23:53:37 1.18.2.2 +++ include/asm-mips/stackframe.h 2002/09/16 14:39:35 @@ -201,8 +201,15 @@ lw $3, PT_R3(sp); \ lw $2, PT_R2(sp) +#ifdef CONFIG_MIPS_USERSPACE_ATOMIC_OPS +#define CLEAR_K1 move k1,$0; +#else +#define CLEAR_K1 +#endif + #define RESTORE_SP_AND_RET \ lw sp, PT_R29(sp); \ + CLEAR_K1 \ .set mips3; \ eret; \ .set mips0 Index: include/linux/sysctl.h =================================================================== RCS file: /cvs/linux/include/linux/sysctl.h,v retrieving revision 1.44.2.3 diff -a -u -r1.44.2.3 sysctl.h --- include/linux/sysctl.h 2002/09/11 12:45:40 1.44.2.3 +++ include/linux/sysctl.h 2002/09/16 14:39:35 @@ -124,6 +124,7 @@ KERN_CORE_USES_PID=52, /* int: use core or core.%pid */ KERN_TAINTED=53, /* int: various kernel tainted flags */ KERN_CADPID=54, /* int: PID of the process to notify on CAD */ + KERN_MIPS_USERSPACE_ATOMIC_OPS=55, /* int: kernel supports atomicity w/o LL/SC */ }; Index: kernel/sysctl.c =================================================================== RCS file: /cvs/linux/kernel/sysctl.c,v retrieving revision 1.46.2.4 diff -a -u -r1.46.2.4 sysctl.c --- kernel/sysctl.c 2002/09/10 15:32:56 1.46.2.4 +++ kernel/sysctl.c 2002/09/16 14:39:36 @@ -96,6 +96,10 @@ extern int acct_parm[]; #endif +#ifdef CONFIG_MIPS_USERSPACE_ATOMIC_OPS +static int mips_userspace_atomic_ops = 1; +#endif + extern int pgt_cache_water[]; static int parse_table(int *, int, void *, size_t *, void *, size_t, @@ -255,6 +259,10 @@ #endif {KERN_S390_USER_DEBUG_LOGGING,"userprocess_debug", &sysctl_userprocess_debug,sizeof(int),0644,NULL,&proc_dointvec}, +#endif +#ifdef CONFIG_MIPS_USERSPACE_ATOMIC_OPS + {KERN_MIPS_USERSPACE_ATOMIC_OPS, "mips_userspace_atomic_ops", + &mips_userspace_atomic_ops, sizeof(int), 0444, NULL, &proc_dointvec}, #endif {0} }; --FCuugMFkClbJLl1L-- From mdharm@momenco.com Mon Sep 16 23:15:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 23:15:09 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:4881 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 23:15:09 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8GLF0627314 for ; Mon, 16 Sep 2002 14:15:01 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: fs problem between 2.4.19-rc1 and tip? Date: Mon, 16 Sep 2002 14:15:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Is anyone else seeing a problem using SCSI disks (ext2 format) that was introduced between 2.4.19-rc1 and the tip revision? Upon booting the 2.4.20-pre6 (tip of CVS), the root filesystem throws an error about an "unaligned directory entry" and then cannot find init. 2.4.19-rc1 with the _same_ hardware configuration works just fine. Is it just me, or this this something general? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From mdharm@momenco.com Mon Sep 16 23:35:46 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 23:35:46 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:7697 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 23:35:46 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8GLZd627435 for ; Mon, 16 Sep 2002 14:35:39 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: bug with 512MB of RAM? Date: Mon, 16 Sep 2002 14:35:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips A long time ago, there was a bug somewhere that only affected boards with 512MB of memory with RM7000 processors. Apparently, there were problems in the cache-managment code causing a problem working with memory near the end of kseg0. I don't recall all the details -- by the time I got to looking at it the first time, someone already had a fix. I was told this was fixed... but I'm seeing some symptoms that this was not fixed. Does anyone actually recall if this was fixed or not? If it was, I need to look elsewhere. But, if it wasn't actually fixed.... Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From jsun@orion.mvista.com Mon Sep 16 23:40:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 16 Sep 2002 23:40:15 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:5630 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Mon, 16 Sep 2002 23:40:15 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8GLRjM17778; Mon, 16 Sep 2002 14:27:45 -0700 Date: Mon, 16 Sep 2002 14:27:45 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [PATCH] fpu enabling/disabling in ptrace.c Message-ID: <20020916142745.A17321@mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I think the original intention is to enable FPU, read the FPU id register and restore original FPU state. Unfortnately restore_flags() does not achieve it. Following patch fixes that. Applies to both 2.4 and 2.5 branch. Jun P.S., I am still waiting for comments or check-in of the following patches: 020417.kgdb-compile-warning.patch 020722.malta-kgdb 020826.swarm-rtc-m41t81.patch --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="020916.ptrace.c-restore-fpu-state.patch" diff -Nru link/arch/mips/kernel/ptrace.c.orig link/arch/mips/kernel/ptrace.c --- link/arch/mips/kernel/ptrace.c.orig Fri Aug 9 09:38:10 2002 +++ link/arch/mips/kernel/ptrace.c Mon Sep 16 14:22:27 2002 @@ -168,10 +168,10 @@ break; } - __save_flags(flags); + flags = read_32bit_cp0_register(CP0_STATUS); __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0": "=r" (tmp)); - __restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); break; } default: diff -Nru link/arch/mips64/kernel/ptrace.c.orig link/arch/mips64/kernel/ptrace.c --- link/arch/mips64/kernel/ptrace.c.orig Fri Aug 9 09:38:19 2002 +++ link/arch/mips64/kernel/ptrace.c Mon Sep 16 14:24:02 2002 @@ -165,10 +165,10 @@ break; case FPC_EIR: { /* implementation / version register */ unsigned int flags; - __save_flags(flags); + flags = read_32bit_cp0_register(CP0_STATUS); __enable_fpu(); __asm__ __volatile__("cfc1\t%0,$0": "=r" (tmp)); - __restore_flags(flags); + write_32bit_cp0_register(CP0_STATUS, flags); break; } default: --NzB8fVQJ5HfG6fxh-- From jsun@orion.mvista.com Tue Sep 17 01:07:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 01:07:08 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:33519 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 01:07:07 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8GMsdf20722; Mon, 16 Sep 2002 15:54:39 -0700 Date: Mon, 16 Sep 2002 15:54:39 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [PATCH] make xconfig work again Message-ID: <20020916155439.B17321@mvista.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Kind of guess the fix for au1000 and decstation.... Jun --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="020916.a.make-xconfig-work-again.patch" diff -Nru link/arch/mips/config-shared.in.orig link/arch/mips/config-shared.in --- link/arch/mips/config-shared.in.orig Mon Sep 16 14:19:06 2002 +++ link/arch/mips/config-shared.in Mon Sep 16 15:30:31 2002 @@ -479,7 +479,7 @@ if [ "$CONFIG_CPU_SB1" = "y" ]; then choice 'SB1 Pass' \ "Pass1 CONFIG_CPU_SB1_PASS_1 \ - Pass2 CONFIG_CPU_SB1_PASS_2 + Pass2 CONFIG_CPU_SB1_PASS_2 \ Pass2.2 CONFIG_CPU_SB1_PASS_2_2" Pass1 if [ "$CONFIG_CPU_SB1_PASS_1" = "y" ]; then define_bool CONFIG_SB1_PASS_1_WORKAROUNDS y diff -Nru link/drivers/pcmcia/Config.in.orig link/drivers/pcmcia/Config.in --- link/drivers/pcmcia/Config.in.orig Wed Aug 21 15:45:59 2002 +++ link/drivers/pcmcia/Config.in Mon Sep 16 15:49:30 2002 @@ -30,9 +30,9 @@ dep_tristate ' M8xx support' CONFIG_PCMCIA_M8XX $CONFIG_PCMCIA fi if [ "$CONFIG_MIPS_AU1000" = "y" ]; then - dep_tristate ' Au1x00 pcmcia support' CONFIG_PCMCIA_AU1000 $CONFIG_PCMCIA + dep_tristate ' Au1x00 pcmcia support' CONFIG_PCMCIA_AU1000 $CONFIG_PCMCIA if [ "$CONFIG_PCMCIA_AU1000" != "n" ]; then - dep_tristate ' Pb1x00 board support' CONFIG_PCMCIA_PB1X00 + bool ' Pb1x00 board support' CONFIG_PCMCIA_PB1X00 fi fi fi diff -Nru link/drivers/video/Config.in.orig link/drivers/video/Config.in --- link/drivers/video/Config.in.orig Mon Sep 16 14:20:33 2002 +++ link/drivers/video/Config.in Mon Sep 16 15:34:42 2002 @@ -213,7 +213,7 @@ if [ "$CONFIG_DECSTATION" = "y" ]; then dep_bool ' PMAG-BA TURBOchannel framebuffer support' CONFIG_FB_PMAG_BA $CONFIG_TC dep_bool ' PMAGB-B TURBOchannel framebuffer support' CONFIG_FB_PMAGB_B $CONFIG_TC - dep_bool ' Maxine (Personal DECstation) onboard framebuffer support' CONFIG_FB_MAXINE + dep_bool ' Maxine (Personal DECstation) onboard framebuffer support' CONFIG_FB_MAXINE $CONFIG_TC fi if [ "$CONFIG_NINO" = "y" ]; then bool ' TMPTX3912/PR31700 frame buffer support' CONFIG_FB_TX3912 --i0/AhcQY5QxfSsSZ-- From wjhun@Oswego.EDU Tue Sep 17 11:12:22 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 11:12:23 +0200 (CEST) Received: from [129.3.11.16] ([129.3.11.16]:27611 "EHLO rocky.oswego.edu") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 11:12:22 +0200 Received: from localhost (wjhun@localhost) by rocky.oswego.edu (8.11.6+Sun/8.12.3) with ESMTP id g8H9BL424259 for ; Tue, 17 Sep 2002 05:11:22 -0400 (EDT) X-Authentication-Warning: rocky.oswego.edu: wjhun owned process doing -bs Date: Tue, 17 Sep 2002 05:11:21 -0400 (EDT) From: William Jhun To: Subject: [PATCH] ip22 console selection fixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wjhun@Oswego.EDU Precedence: bulk X-list: linux-mips This patch fixes some problems in selecting which console to use on the ip22s. - Replace unobvious ttyS with arc for the arc console device name - If ARC var console=d*, use serial. If 'g', use Newport only. If neither or not set, default to ARC. Old code was disabling ARC console and using serial console if CONFIG_ARC_CONSOLE was set. (why?!) - ArcGetEnvironmentVariable() can conceivably return NULL, so don't blindly dereference. Thanks, Will Index: arch/mips/arc/arc_con.c =================================================================== RCS file: /cvs/linux/arch/mips/arc/arc_con.c,v retrieving revision 1.1.4.3 diff -u -r1.1.4.3 arc_con.c --- arch/mips/arc/arc_con.c 2002/08/05 23:53:30 1.1.4.3 +++ arch/mips/arc/arc_con.c 2002/09/17 08:57:12 @@ -39,7 +39,7 @@ } static struct console arc_cons = { - name: "ttyS", + name: "arc", write: prom_console_write, device: prom_console_device, setup: prom_console_setup, Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.1.2.13 diff -u -r1.1.2.13 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 2002/07/23 16:39:10 1.1.2.13 +++ arch/mips/sgi-ip22/ip22-setup.c 2002/09/17 08:57:12 @@ -162,19 +162,22 @@ * line and "d2" for the second serial line. */ ctype = ArcGetEnvironmentVariable("console"); - if (*ctype == 'd') { + if (ctype && *ctype == 'd') { #ifdef CONFIG_SERIAL_CONSOLE if(*(ctype + 1) == '2') console_setup("ttyS1"); else console_setup("ttyS0"); #endif - } else { + } #ifdef CONFIG_ARC_CONSOLE - prom_flags &= PROM_FLAG_USE_AS_CONSOLE; - console_setup("ttyS0"); -#endif + else if (!ctype || *ctype != 'g') { + /* Use ARC if we don't want serial ('d') or + * Newport ('g'). */ + prom_flags |= PROM_FLAG_USE_AS_CONSOLE; + console_setup("arc"); } +#endif #ifdef CONFIG_REMOTE_DEBUG kgdb_ttyd = prom_getcmdline(); @@ -201,7 +204,7 @@ #ifdef CONFIG_VT #ifdef CONFIG_SGI_NEWPORT_CONSOLE - { + if (ctype && *ctype == 'g'){ unsigned long *gfxinfo; long (*__vec)(void) = (void *) *(long *)((PROMBLOCK)->pvector + 0x20); @@ -209,29 +212,29 @@ sgi_gfxaddr = ((gfxinfo[1] >= 0xa0000000 && gfxinfo[1] <= 0xc0000000) ? gfxinfo[1] - 0xa0000000 : 0); + + /* newport addresses? */ + if (sgi_gfxaddr == 0x1f0f0000 || sgi_gfxaddr == 0x1f4f0000) { + conswitchp = &newport_con; + + screen_info = (struct screen_info) { + 0, 0, /* orig-x, orig-y */ + 0, /* unused */ + 0, /* orig_video_page */ + 0, /* orig_video_mode */ + 160, /* orig_video_cols */ + 0, 0, 0, /* unused, ega_bx, unused */ + 64, /* orig_video_lines */ + 0, /* orig_video_isVGA */ + 16 /* orig_video_points */ + }; + } } - /* newport addresses? */ - if (sgi_gfxaddr == 0x1f0f0000 || sgi_gfxaddr == 0x1f4f0000) { - conswitchp = &newport_con; - - screen_info = (struct screen_info) { - 0, 0, /* orig-x, orig-y */ - 0, /* unused */ - 0, /* orig_video_page */ - 0, /* orig_video_mode */ - 160, /* orig_video_cols */ - 0, 0, 0, /* unused, ega_bx, unused */ - 64, /* orig_video_lines */ - 0, /* orig_video_isVGA */ - 16 /* orig_video_points */ - }; - } else { - conswitchp = &dummy_con; - } -#else -#ifdef CONFIG_DUMMY_CONSOLE - conswitchp = &dummy_con; #endif +#ifdef CONFIG_DUMMY_CONSOLE + /* Either if newport console wasn't used or failed to initialize. */ + if(conswitchp != &newport_con) + conswitchp = &dummy_con; #endif #endif --- |William Y. Jhun - wjhun@oswego.edu From mikehill@hgeng.com Tue Sep 17 16:00:35 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 16:00:36 +0200 (CEST) Received: from [198.163.180.7] ([198.163.180.7]:35282 "HELO snog.front.onramp.ca") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 16:00:35 +0200 Received: (qmail 16186 invoked from network); 17 Sep 2002 14:00:08 -0000 Received: from gateway.hgeng.com (HELO shadowfax.hgeng.com) (199.246.74.82) by 0 with SMTP; 17 Sep 2002 14:00:08 -0000 Received: from [192.168.1.6] (dilbert.hgeng.com [192.168.1.6]) by shadowfax.hgeng.com (8.12.5/8.12.5/Debian-1) with ESMTP id g8HDxnOK003562 for ; Tue, 17 Sep 2002 09:59:49 -0400 Subject: Re: [PATCH] ip22 console selection fixes From: Michael Hill To: linux-mips@linux-mips.org In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1032271189.29089.63.camel@dilbert.hgeng.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 17 Sep 2002 09:59:49 -0400 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mikehill@hgeng.com Precedence: bulk X-list: linux-mips On Tue, 2002-09-17 at 05:11, William Jhun wrote: > This patch fixes some problems in selecting which console to use on the > ip22s. Will's patch restores the missing kernel boot messages in place of the stationary (friendly but not very descriptive) Tux graphic. Mike From g.c.bransby-99@student.lboro.ac.uk Tue Sep 17 17:20:59 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 17:20:59 +0200 (CEST) Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:56492 "EHLO fw-cam.cambridge.arm.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 17:20:59 +0200 Received: by fw-cam.cambridge.arm.com; id QAA11807; Tue, 17 Sep 2002 16:20:48 +0100 (BST) Received: from unknown(172.16.9.107) by fw-cam.cambridge.arm.com via smap (V5.5) id xma010644; Tue, 17 Sep 02 16:19:59 +0100 Date: Tue, 17 Sep 2002 16:19:59 +0100 From: Gareth To: linux-mips@linux-mips.org Subject: Delayed jumps and branches Message-Id: <20020917161959.33787757.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: g.c.bransby-99@student.lboro.ac.uk Precedence: bulk X-list: linux-mips Hi, I have been going through my mips architecture book learning about the delay slots used in loads, jumps and branches and I am in need of some clarification. The instruction just after the jump instruction is always executed wether the jump is taken or not, right? So the compiler can re-aarange the assembly to take advantage of this, but if no instruction (that can be executed wether the jump is taken or not) can be placed after the jump, a nop is used intstead. So take this code for example : jal li $s2, 3 li $v0, 2 If the jump is not taken, it requires 3 cycles to execute these 3 instructions. If the jump is taken, it requires 3 cycles to execute the first instruction of my_function, and li $s2, 3 is executed. Is my reasoning correct? Thanks Gareth From js@convergence.de Tue Sep 17 17:31:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 17:31:10 +0200 (CEST) Received: from buserror-extern.convergence.de ([212.84.236.66]:28422 "EHLO hell") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 17:31:09 +0200 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17rKJb-0004Em-00 for ; Tue, 17 Sep 2002 17:31:03 +0200 Date: Tue, 17 Sep 2002 17:31:02 +0200 From: Johannes Stezenbach To: linux-mips@linux-mips.org Subject: consistent_alloc() for MIPS Message-ID: <20020917153102.GA16159@convergence.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, a co-worker ported consistent_alloc() from ARM to MIPS. We use it to allocate DMA buffers in unified memory in a non-PCI system-on-a-chip embedded thingy. Maybe we could have just used pci_alloc_consistent(), but consistent_alloc() has the advantage of freeing unused pages allocated due to __get_free_pages() power-of-two- number-of-pages semantics. BTW, it seems that at least for CONFIG_SGI_IP27 pci_alloc_consistent() does not work for non-PCI DMA buffers (hwdev == NULL). Anyway, the code for pci_alloc_consistent() looks confusing because it seems to dereference a NULL pointer. The attached patch works for us, but maybe someone could comment if a) it was a good idea to port it from ARM to MIPS b) we made no gross mistakes (e.g. do we need to flush the dcache? Currently it works without. Should we ioremap()?) c) if it is of use to other linux/MIPS users One other thing: The comments for dma_cache_wback_inv() in io.h seem to lack a "memory" in "...makes caches and coherent...". Also, dma_cache_wback() and dma_cache_wback_inv() seem to be identical. Is this intentional? Regards, Johannes --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="linux-oss-consistent-alloc.patch" diff -ruaN linux-oss.orig/arch/mips/mm/Makefile linux-oss/arch/mips/mm/Makefile --- linux-oss.orig/arch/mips/mm/Makefile 2002-09-09 21:30:12.000000000 +0200 +++ linux-oss/arch/mips/mm/Makefile 2002-09-13 12:53:17.000000000 +0200 @@ -10,8 +10,8 @@ O_TARGET := mm.o -export-objs += ioremap.o loadmmu.o umap.o -obj-y += extable.o init.o ioremap.o fault.o loadmmu.o +export-objs += ioremap.o loadmmu.o umap.o consistent.o +obj-y += extable.o init.o ioremap.o fault.o loadmmu.o consistent.o obj-$(CONFIG_CPU_R3000) += pg-r3k.o c-r3k.o c-tx39.o tlb-r3k.o \ tlbex-r3k.o diff -ruaN linux-oss.orig/arch/mips/mm/consistent.c linux-oss/arch/mips/mm/consistent.c --- linux-oss.orig/arch/mips/mm/consistent.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-oss/arch/mips/mm/consistent.c 2002-05-24 18:55:30.000000000 +0200 @@ -0,0 +1,108 @@ +/* + * linux/arch/mips/mm/consistent.c + * + * Copyright (C) 2002 Denis Oliver Kropp + * + * + * Based on linux/arch/arm/mm/consistent.c + * + * Copyright (C) 2000 Russell King + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Dynamic DMA mapping support. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* + * This allocates one page of cache-coherent memory space and returns + * both the virtual and a "dma" address to that space. It is not clear + * whether this could be called from an interrupt context or not. For + * now, we expressly forbid it, especially as some of the stuff we do + * here is not interrupt context safe. + * + * Note that this does *not* zero the allocated area! + */ +void *consistent_alloc(int gfp, size_t size, dma_addr_t *dma_handle) +{ + struct page *page, *free, *end; + unsigned long order; + void *virt; + + if (in_interrupt()) + BUG(); + + size = PAGE_ALIGN(size); + order = get_order(size); + + page = alloc_pages(gfp, order); + if (!page) + return NULL; + + virt = page_address(page); + *dma_handle = virt_to_bus(virt); + + /* + * free wasted pages. We skip the first page since we know + * that it will have count = 1 and won't require freeing. + * We also mark the pages in use as reserved so that + * remap_page_range works. + */ + page = virt_to_page(virt); + free = page + (size >> PAGE_SHIFT); + end = page + (1 << order); + + for (; page < end; page++) { + set_page_count(page, 1); + if (page >= free) + __free_page(page); + else + SetPageReserved(page); + } + + return (void*) KSEG1ADDR(virt); +} + +/* + * free a page as defined by the above mapping. We expressly forbid + * calling this from interrupt context. + */ +void consistent_free(void *vaddr, size_t size, dma_addr_t handle) +{ + struct page *page, *end; + void *virt; + + if (in_interrupt()) + BUG(); + + virt = bus_to_virt(handle); + + /* + * More messing around with the MM internals. This is + * sick, but then so is remap_page_range(). + */ + size = PAGE_ALIGN(size); + page = virt_to_page(virt); + end = page + (size >> PAGE_SHIFT); + + for (; page < end; page++) + ClearPageReserved(page); +} + +EXPORT_SYMBOL(consistent_alloc); +EXPORT_SYMBOL(consistent_free); + diff -ruaN linux-oss.orig/include/asm-mips/io.h linux-oss/include/asm-mips/io.h --- linux-oss.orig/include/asm-mips/io.h 2002-08-16 20:36:17.000000000 +0200 +++ linux-oss/include/asm-mips/io.h 2002-09-13 12:53:18.000000000 +0200 @@ -222,6 +222,15 @@ extern void iounmap(void *addr); /* + * DMA-consistent mapping functions. These allocate/free a region of + * uncached, unwrite-buffered mapped memory space for use with DMA + * devices. This is the "generic" version. The PCI specific version + * is in pci.h + */ +extern void *consistent_alloc(int gfp, size_t size, dma_addr_t *handle); +extern void consistent_free(void *vaddr, size_t size, dma_addr_t handle); + +/* * XXX We need system specific versions of these to handle EISA address bits * 24-31 on SNI. * XXX more SNI hacks. --XsQoSWH+UP9D9v3l-- From ica2_ts@csv.ica.uni-stuttgart.de Tue Sep 17 17:42:08 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 17:42:09 +0200 (CEST) Received: from iris1.csv.ica.uni-stuttgart.de ([129.69.118.2]:19773 "EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 17:42:08 +0200 Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42]) by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2) id 17rKOt-002h7i-00 for linux-mips@linux-mips.org; Tue, 17 Sep 2002 17:36:31 +0200 Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian)) id 17rKUD-0003OT-00 for ; Tue, 17 Sep 2002 17:42:01 +0200 Date: Tue, 17 Sep 2002 17:42:01 +0200 To: linux-mips@linux-mips.org Subject: Re: Delayed jumps and branches Message-ID: <20020917154201.GA18697@rembrandt.csv.ica.uni-stuttgart.de> References: <20020917161959.33787757.g.c.bransby-99@student.lboro.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020917161959.33787757.g.c.bransby-99@student.lboro.ac.uk> User-Agent: Mutt/1.4i From: Thiemo Seufer Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de Precedence: bulk X-list: linux-mips Gareth wrote: > Hi, > > I have been going through my mips architecture book learning about the delay > slots used in loads, jumps and branches and I am in need of some clarification. > The instruction just after the jump instruction is always executed wether the > jump is taken or not, right? There are no conditional jumps, so you are right. :-) > So the compiler can re-aarange the assembly to > take advantage of this, but if no instruction (that can be executed wether the > jump is taken or not) can be placed after the jump, a nop is used intstead. So > take this code for example : > > jal > li $s2, 3 > li $v0, 2 The register name is either "$2" or "v0". > If the jump is not taken, it requires 3 cycles to execute these 3 instructions. > If the jump is taken, it requires 3 cycles to execute the first instruction of > my_function, and li $s2, 3 is executed. > > Is my reasoning correct? Yes, if it was e.g. beq t0, zero, instead of jal. Note that the "branch likely" variants don't execute the delay slot if not taken. Thiemo From seh@zee2.com Tue Sep 17 19:03:35 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 19:03:36 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:29680 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 19:03:35 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8HH3HM10370 for ; Tue, 17 Sep 2002 18:03:20 +0100 Message-ID: <3D876053.C2CD1D8C@zee2.com> Date: Tue, 17 Sep 2002 18:03:15 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS Subject: cannot debug multi-threaded programs with gdb/gdbserver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips Hi, I managed to get gdb to do multi-threaded debug using a gdb on the target, after Daniel J helped with a patch to sys/procfs.h I am now trying to do host target with gdb/gdbserver. The program on the target uses pthreads. I can connect, but as soon as you try to continue (to a breakpoint) I get: Program received signal SIG32, Real-time event 32. warning: Warning: GDB can't find the start of the function at 0x2abee684. .... I know that SIG32 is used for the thread control on the target, but I'm not sure if the host gdb is supposed to receive this. I tried "set handle SIG32 pass noprint nostop" and variations, but this didn't help. Does anyone know whether there is some special setup needed on gdb/gdbserver to use the multi-threaded gdbserver ?? My environment is as follows: CPU: NEC VR5432 kernel: linux-2.4.18 + patches glibc: 2.2.3 + patches gdb: 5.2/3 from CVS gcc: 3.1 binutils: Version 2.11.90.0.25 cross-gdb configured using: configure --prefix=/usr --target=mipsel-linux --disable-sim --disable-tcl --enable-threads --enable-shared gdbserver configured using: configure --prefix=/usr --host=mipsel-linux --target=mipsel-linux --enable-threads --enable-shared Regards, Stuart From sjhill@realitydiluted.com Tue Sep 17 19:24:32 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 19:24:33 +0200 (CEST) Received: from real.realitydiluted.com ([208.242.241.164]:45546 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 19:24:32 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17rHOp-00040I-00; Tue, 17 Sep 2002 07:24:15 -0500 Message-ID: <3D87653E.9030702@realitydiluted.com> Date: Tue, 17 Sep 2002 12:24:14 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 X-Accept-Language: en MIME-Version: 1.0 To: Stuart Hughes CC: Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver References: <3D876053.C2CD1D8C@zee2.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Stuart Hughes wrote: > > Does anyone know whether there is some special setup needed on > gdb/gdbserver to use the multi-threaded gdbserver ?? > Wow, there are so many things to tell you...where to start... > My environment is as follows: > > CPU: NEC VR5432 > kernel: linux-2.4.18 + patches > glibc: 2.2.3 + patches > gdb: 5.2/3 from CVS > Has to be the gdb-5.3 branch...go look at http://sources.redhat.com/gdb > gcc: 3.1 > binutils: Version 2.11.90.0.25 > Don't use H.J. Lu's binutils, use the released one. Use gcc-3.2 and binutils-2.13 as they have fixes for the MIPS debugging symbols with regards to DWARF. > cross-gdb configured using: > > configure --prefix=/usr --target=mipsel-linux --disable-sim > --disable-tcl --enable-threads --enable-shared > Use '--target=mips-linux' and you'll be better off. Don't worry, it will support both endians. > gdbserver configured using: > > configure --prefix=/usr --host=mipsel-linux --target=mipsel-linux > --enable-threads --enable-shared > I would also try 'CC=mipsel-linux-gcc configure <...>'. -Steve From jsun@orion.mvista.com Tue Sep 17 20:16:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:16:58 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:53231 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 20:16:57 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HI4Nf05292; Tue, 17 Sep 2002 11:04:23 -0700 Date: Tue, 17 Sep 2002 11:04:23 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [RFC] FPU context switch Message-ID: <20020917110423.E17321@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips I am rewriting the FPU management code with the following objectives in my mind: 1) to make it work for SMP. Right now, processes can migrate to different CPUs leaving their FPU context on another CPU. And the global variable last_task_used_math is shared by multiple CPUs. :-) 2) to provide a layer to generic kernel code that hides the differences between fpu emul case and hard FPU case, so that we don't see many "if (mips_cpu.options & MIPS_CPU_FPU)" around. 3) to simplify some existing code (such as those in signal.c) so that we don't see many "if (last_task_used_math == ...)" around. I am now facing a couple of choices in the implementation and like to hear back from you. Those choices mainly differ at when we should save fpu context and when we should restore it. 1) always blindly save and restore during context switch (switch_to()) Not interesting. Just list it here for completeness. 2) save PFU context when process is switched off *only if* FPU is used in the last run. restore FPU context on next use of FPU. Need to use an additional flag to remember whether it is used in the current run. Perhaps overridding used_math? In that case, used_math == 2 indicates it used in the current run. used_math is set back to 1 when process is switched off. Very simply to implement. 3) save FPU context when process is switched off *only if* FPU is used in the last run. restore FPU context on the next use of FPU and *only* if other processes have tampered FPU context since the last use of FPU by the current process. This requires each CPU to remember the last owner of FPU. In order to support possible process migration cases in a SMP system, each process also needs to remember the processor on which it used FPU last. A process has a valid live FPU context on a CPU if those two variables match to each other. Therefore we can avoid unnecessary restoring FPU context. Fairly complex in implementation. 4) don't save or restore any FPU context during context switches. Instead, we implement a full SMP-safe version of lazy fpu switch. This introduces three states in terms of FPU context status: a) live FPU context in current CPU b) saved FPU context in memory c) live FPU context in another CPU Before we only have a) and b) states. c) is new in this approach. To deal with c), we need to provide an inter-processor call so that we can ask another CPU to save FPU context in case we need to access it on this CPU. Additionally we need similar variables required in 3) to keep track who owns FPU at any time. Very complex to implement. Has the best performance, though. Currently I am leaning towards 2) or 3). What is your opinion? Jun From drow@false.org Tue Sep 17 20:26:16 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:26:17 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:1544 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 20:26:16 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rNya-0004Em-00; Tue, 17 Sep 2002 14:25:36 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rN2W-0006XY-00; Tue, 17 Sep 2002 14:25:36 -0400 Date: Tue, 17 Sep 2002 14:25:36 -0400 From: Daniel Jacobowitz To: "Steven J. Hill" Cc: Stuart Hughes , Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver Message-ID: <20020917182536.GA25012@nevyn.them.org> References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D87653E.9030702@realitydiluted.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 12:24:14PM -0500, Steven J. Hill wrote: > Stuart Hughes wrote: > > > >Does anyone know whether there is some special setup needed on > >gdb/gdbserver to use the multi-threaded gdbserver ?? > > > Wow, there are so many things to tell you...where to start... Steve, have you started memorizing my responses again? :) > >My environment is as follows: > > > >CPU: NEC VR5432 > >kernel: linux-2.4.18 + patches > >glibc: 2.2.3 + patches > >gdb: 5.2/3 from CVS > > > Has to be the gdb-5.3 branch...go look at http://sources.redhat.com/gdb > > >gcc: 3.1 > >binutils: Version 2.11.90.0.25 > > > Don't use H.J. Lu's binutils, use the released one. Use gcc-3.2 and > binutils-2.13 as they have fixes for the MIPS debugging symbols with > regards to DWARF. > > >cross-gdb configured using: > > > >configure --prefix=/usr --target=mipsel-linux --disable-sim > >--disable-tcl --enable-threads --enable-shared > > > Use '--target=mips-linux' and you'll be better off. Don't worry, it > will support both endians. Except for this one - where'd that come from? It should make no functional difference either way, at least assuming you always give GDB a binary. > >gdbserver configured using: > > > >configure --prefix=/usr --host=mipsel-linux --target=mipsel-linux > >--enable-threads --enable-shared > > > I would also try 'CC=mipsel-linux-gcc configure <...>'. Definitely. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From justinca@cs.cmu.edu Tue Sep 17 20:27:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:27:09 +0200 (CEST) Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]:61899 "HELO gs256.sp.cs.cmu.edu") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 20:27:09 +0200 Subject: Re: Delayed jumps and branches From: justinca@cs.cmu.edu To: Gareth Cc: linux-mips@linux-mips.org In-Reply-To: <20020917161959.33787757.g.c.bransby-99@student.lboro.ac.uk> References: <20020917161959.33787757.g.c.bransby-99@student.lboro.ac.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q+nb2dc7wgIh4ey09bkw" X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:26:18 -0400 Message-Id: <1032287178.27966.133.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Source-Info: Sender is really justinca+@gs256.sp.cs.cmu.edu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: justinca@cs.cmu.edu Precedence: bulk X-list: linux-mips --=-Q+nb2dc7wgIh4ey09bkw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-09-17 at 11:19, Gareth wrote: > Hi, > jal > li $s2, 3 > li $v0, 2 >=20 > If the jump is not taken, it requires 3 cycles to execute these 3 instruc= tions. > If the jump is taken, it requires 3 cycles to execute the first instructi= on of > my_function, and li $s2, 3 is executed. >=20 > Is my reasoning correct? >=20 Aside from the corrections Thiemo sent, you should probably also disabuse yourself of the notion that one instruction =3D=3D one cycle.=20 For most processors, there's no simple answer to the question "how many cycles will this code segment take to run". Even in the embedded world, most newer processors are superscalar. In addition, if you want to be precise, you have to take into account cache behaviour, branch prediction, issue restrictions, etc. -Justin --=-Q+nb2dc7wgIh4ey09bkw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9h3PK47Lg4cGgb74RAvt0AKCxxyeynMj9TK6FL6gzGQS2L3ZwcACcCHIy AZBYb7ePF4BizakKKHCp0jg= =mAoT -----END PGP SIGNATURE----- --=-Q+nb2dc7wgIh4ey09bkw-- From lindahl@keyresearch.com Tue Sep 17 20:33:54 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:33:55 +0200 (CEST) Received: from nixon.xkey.com ([209.245.148.124]:22740 "HELO nixon.xkey.com") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 20:33:54 +0200 Received: (qmail 6665 invoked from network); 17 Sep 2002 18:33:45 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 17 Sep 2002 18:33:45 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g8HIVbx02025 for linux-mips@linux-mips.org; Tue, 17 Sep 2002 11:31:37 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 17 Sep 2002 11:31:36 -0700 From: Greg Lindahl To: linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch Message-ID: <20020917113136.A1890@wumpus.internal.keyresearch.com> References: <20020917110423.E17321@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917110423.E17321@mvista.com>; from jsun@mvista.com on Tue, Sep 17, 2002 at 11:04:23AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 11:04:23AM -0700, Jun Sun wrote: > Currently I am leaning towards 2) or 3). What is your opinion? (1) and (2) are how other archs like Alpha and Itanium deal with this. I think (3) is likely to be painful to debug and maintain and won't win much. So I'd suggest (2). g From justinca@cs.cmu.edu Tue Sep 17 20:43:02 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:43:03 +0200 (CEST) Received: from GS256.SP.CS.CMU.EDU ([128.2.199.27]:64715 "HELO gs256.sp.cs.cmu.edu") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 20:43:02 +0200 Subject: Re: [RFC] FPU context switch From: justinca@cs.cmu.edu To: Jun Sun Cc: linux-mips@linux-mips.org In-Reply-To: <20020917110423.E17321@mvista.com> References: <20020917110423.E17321@mvista.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-r3p6y52323ylrM5yXPYF" X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:42:20 -0400 Message-Id: <1032288140.28433.165.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Source-Info: Sender is really justinca+@gs256.sp.cs.cmu.edu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: justinca@cs.cmu.edu Precedence: bulk X-list: linux-mips --=-r3p6y52323ylrM5yXPYF Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-09-17 at 14:04, Jun Sun wrote: >=20 > I am rewriting the FPU management code with the following > objectives in my mind: >=20 > 1) to make it work for SMP. Right now, processes can migrate > to different CPUs leaving their FPU context on another CPU. > And the global variable last_task_used_math is shared by > multiple CPUs. :-) >=20 I took a stab at this for a couple hours a while back, and didn't come up with anything I liked. But I may have some insights for you. > 2) save PFU context when process is switched off *only if*=20 > FPU is used in the last run. =20 > restore FPU context on next use of FPU. >=20 > Need to use an additional flag to remember whether it is used > in the current run. Perhaps overridding used_math? In that > case, used_math =3D=3D 2 indicates it used in the current run. > used_math is set back to 1 when process is switched off. >=20 > Very simply to implement. >=20 > 3) save FPU context when process is switched off *only if*=20 > FPU is used in the last run. =20 > restore FPU context on the next use of FPU and *only* if other=20 > processes have tampered FPU context since the last use of FPU by=20 > the current process. >=20 > This requires each CPU to remember the last owner of FPU. > In order to support possible process migration cases in a SMP > system, each process also needs to remember the processor > on which it used FPU last. A process has a valid live FPU > context on a CPU if those two variables match to each other. > Therefore we can avoid unnecessary restoring FPU context. >=20 > Fairly complex in implementation.=20 >=20 I'd argue for something between 2 & 3. Always save FPU state, and if you know the state has been preserved for the next run, skip the restore. I'm a bit leery of the whole "don't restore FPU state on context switch until you use the FPU again" idea as it's added complexity and I'm not at all sure you're going to see any measurable performance gain out of it. Certainly on an FPU-intensive process this is going to be a loss. >=20 > 4) don't save or restore any FPU context during context switches. > Instead, we implement a full SMP-safe version of lazy fpu=20 > switch. >=20 > This introduces three states in terms of FPU context status: > a) live FPU context in current CPU > b) saved FPU context in memory > c) live FPU context in another CPU > Before we only have a) and b) states. c) is new in this approach. >=20 > To deal with c), we need to provide an inter-processor call so that > we can ask another CPU to save FPU context in case we need to access > it on this CPU. >=20 > Additionally we need similar variables required in 3) to keep track > who owns FPU at any time. >=20 > Very complex to implement. Has the best performance, though. >=20 Just say no. I doubt this will have the best performance on SMP, just because the process of getting the state off of the other CPU is going to be extremely costly. I'd rather see #1 just for simplicity's sake before #4... > Currently I am leaning towards 2) or 3). What is your opinion? >=20 Something quick and dirty that I ended up doing recently was to bind fpu users to the CPU they we're using at the time of the first FPU fault.=20 The last_task_used_math expansion is straightforward and it seemed to work pretty well. -Justin --=-r3p6y52323ylrM5yXPYF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9h3eM47Lg4cGgb74RAgQMAJ9JIw3BUErlr+0PTD4LFUKff5Gk8ACeO/OO v8UH6Y4Slqme0tl4S3B0RjQ= =xBHQ -----END PGP SIGNATURE----- --=-r3p6y52323ylrM5yXPYF-- From jsun@orion.mvista.com Tue Sep 17 20:47:49 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 20:47:49 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:2044 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 20:47:49 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HIZGO05422; Tue, 17 Sep 2002 11:35:16 -0700 Date: Tue, 17 Sep 2002 11:35:16 -0700 From: Jun Sun To: Greg Lindahl Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [RFC] FPU context switch Message-ID: <20020917113516.F17321@mvista.com> References: <20020917110423.E17321@mvista.com> <20020917113136.A1890@wumpus.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020917113136.A1890@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Tue, Sep 17, 2002 at 11:31:36AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 11:31:36AM -0700, Greg Lindahl wrote: > On Tue, Sep 17, 2002 at 11:04:23AM -0700, Jun Sun wrote: > > > Currently I am leaning towards 2) or 3). What is your opinion? > > (1) and (2) are how other archs like Alpha and Itanium deal with > this. I think (3) is likely to be painful to debug The good news is that I have already got it implemented and it survived fairly stressful FPU tests. :-) > and maintain and > won't win much. So I'd suggest (2). > Yes, 3) is a little harder to maitain. I don't have much clue as how much it will improve the performance in reality. Presumably if there is only one FPU intensive process in the system, it can improve a little bit. Thanks for the feedback. Jun From jsun@orion.mvista.com Tue Sep 17 21:01:06 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 21:01:07 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:18927 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 21:01:06 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HImVR05439; Tue, 17 Sep 2002 11:48:31 -0700 Date: Tue, 17 Sep 2002 11:48:31 -0700 From: Jun Sun To: justinca@cs.cmu.edu Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [RFC] FPU context switch Message-ID: <20020917114831.G17321@mvista.com> References: <20020917110423.E17321@mvista.com> <1032288140.28433.165.camel@gs256.sp.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1032288140.28433.165.camel@gs256.sp.cs.cmu.edu>; from justinca@cs.cmu.edu on Tue, Sep 17, 2002 at 02:42:20PM -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 02:42:20PM -0400, justinca@cs.cmu.edu wrote: > > > > This requires each CPU to remember the last owner of FPU. > > In order to support possible process migration cases in a SMP > > system, each process also needs to remember the processor > > on which it used FPU last. A process has a valid live FPU > > context on a CPU if those two variables match to each other. > > Therefore we can avoid unnecessary restoring FPU context. > > > > Fairly complex in implementation. > > > > I'd argue for something between 2 & 3. Always save FPU state, and if > you know the state has been preserved for the next run, skip the > restore. > Determining whether the current FPU context is valid for the new process is not easy. It requires last_task_used_math like variable for each CPU. > I'm a bit leery of the whole "don't restore FPU state on context switch > until you use the FPU again" idea as it's added complexity Quite easy to implement. Just turn off ST0_CU1 bit in the status register saved in the kernel stack when a process is switched off. Therefore next use of FPU will cause a trap and do_cpu() does the normal thing. > and I'm not > at all sure you're going to see any measurable performance gain out of > it. I think this gives a big performance improvement because most processes don't use FPU during their runs but they all have used_math flag set! Jun From lindahl@keyresearch.com Tue Sep 17 21:05:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 21:05:27 +0200 (CEST) Received: from nixon.xkey.com ([209.245.148.124]:51671 "HELO nixon.xkey.com") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 21:05:26 +0200 Received: (qmail 13178 invoked from network); 17 Sep 2002 19:05:19 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 17 Sep 2002 19:05:19 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g8HJ3AM02250; Tue, 17 Sep 2002 12:03:10 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 17 Sep 2002 12:03:10 -0700 From: Greg Lindahl To: Jun Sun Cc: linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch Message-ID: <20020917120310.A2043@wumpus.internal.keyresearch.com> References: <20020917110423.E17321@mvista.com> <1032288140.28433.165.camel@gs256.sp.cs.cmu.edu> <20020917114831.G17321@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020917114831.G17321@mvista.com>; from jsun@mvista.com on Tue, Sep 17, 2002 at 11:48:31AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 11:48:31AM -0700, Jun Sun wrote: > I think this gives a big performance improvement because most processes > don't use FPU during their runs but they all have used_math flag set! Jun, You really ought to prove that first. Many people spend a lot of time optimizing things that aren't important. If it isn't important, than the simplest scheme is the best choice. greg From flo@rfc822.org Tue Sep 17 21:34:34 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 21:34:34 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:34576 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Tue, 17 Sep 2002 21:34:34 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 26ED783F; Tue, 17 Sep 2002 21:34:26 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5363E3717F; Tue, 17 Sep 2002 21:28:33 +0200 (CEST) Date: Tue, 17 Sep 2002 21:28:33 +0200 From: Florian Lohoff To: William Jhun Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] ip22 console selection fixes Message-ID: <20020917192833.GA11379@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 05:11:21AM -0400, William Jhun wrote: > This patch fixes some problems in selecting which console to use on the > ip22s. >=20 > - Replace unobvious ttyS with arc for the arc console device name > - If ARC var console=3Dd*, use serial. If 'g', use Newport only. If > neither or not set, default to ARC. Old code was disabling ARC > console and using serial console if CONFIG_ARC_CONSOLE was set. (why?!) > - ArcGetEnvironmentVariable() can conceivably return NULL, so don't > blindly dereference. I would rather like to see the whole ARC console stuff die - There will never be any REAL ARC console usable in userspace - You can only redirect kernel output there but has always seem to be unstable. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9h4JhUaz2rXW+gJcRAqitAJ9tW7gzhEb+CFv3FqIu7Uwojab5SACcDTjF wbTzLI8HTC+G/htJb/QIuy4= =aE2M -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From drow@false.org Tue Sep 17 21:38:33 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 21:38:33 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:28424 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 21:38:33 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rP6y-0004Lw-00; Tue, 17 Sep 2002 15:38:20 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rOAu-0007M8-00; Tue, 17 Sep 2002 15:38:20 -0400 Date: Tue, 17 Sep 2002 15:38:20 -0400 From: Daniel Jacobowitz To: Greg Lindahl Cc: Jun Sun , linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch Message-ID: <20020917193820.GA28255@nevyn.them.org> References: <20020917110423.E17321@mvista.com> <1032288140.28433.165.camel@gs256.sp.cs.cmu.edu> <20020917114831.G17321@mvista.com> <20020917120310.A2043@wumpus.internal.keyresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020917120310.A2043@wumpus.internal.keyresearch.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 12:03:10PM -0700, Greg Lindahl wrote: > On Tue, Sep 17, 2002 at 11:48:31AM -0700, Jun Sun wrote: > > > I think this gives a big performance improvement because most processes > > don't use FPU during their runs but they all have used_math flag set! > > Jun, > > You really ought to prove that first. Many people spend a lot of time > optimizing things that aren't important. If it isn't important, than > the simplest scheme is the best choice. Oh, he's quite correct. There's a setjmp() early in the execution path, and it saves FP registers on machines with FP support configured on. So tasks are marked as FPU users. I've never thought of a terribly good way around this. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From sjhill@realitydiluted.com Tue Sep 17 21:47:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 21:47:15 +0200 (CEST) Received: from real.realitydiluted.com ([208.242.241.164]:37355 "EHLO real.realitydiluted.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 21:47:14 +0200 Received: from localhost.localdomain ([127.0.0.1] helo=realitydiluted.com) by real.realitydiluted.com with esmtp (Exim 3.22 #1 (Red Hat Linux)) id 17rJcU-00045r-00; Tue, 17 Sep 2002 09:46:30 -0500 Message-ID: <3D878695.3040101@realitydiluted.com> Date: Tue, 17 Sep 2002 14:46:29 -0500 From: "Steven J. Hill" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1 X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Stuart Hughes , Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> <20020917182536.GA25012@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sjhill@realitydiluted.com Precedence: bulk X-list: linux-mips Daniel Jacobowitz wrote: > On Tue, Sep 17, 2002 at 12:24:14PM -0500, Steven J. Hill wrote: > > Steve, have you started memorizing my responses again? :) > *gurgle* Yeah, I have. I apologize if it seemed I was taking credit for anything. >>>cross-gdb configured using: >>> >>>configure --prefix=/usr --target=mipsel-linux --disable-sim >>>--disable-tcl --enable-threads --enable-shared >>> >> >>Use '--target=mips-linux' and you'll be better off. Don't worry, it >>will support both endians. > > > Except for this one - where'd that come from? It should make no > functional difference either way, at least assuming you always give GDB > a binary. > I got some weird errors (unfortunately I can't remember) if I tried using 'mipsel-linux' as the target. So you're saying that a gdb configured for 'mipsel-linux' or 'mips-linux' should work the same? Thanks Daniel. -Steve From drow@false.org Tue Sep 17 22:47:40 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 22:47:41 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:60680 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 22:47:40 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rQBs-0004TP-00; Tue, 17 Sep 2002 16:47:28 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rPFp-0008Bi-00; Tue, 17 Sep 2002 16:47:29 -0400 Date: Tue, 17 Sep 2002 16:47:29 -0400 From: Daniel Jacobowitz To: "Steven J. Hill" Cc: Stuart Hughes , Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver Message-ID: <20020917204729.GA31458@nevyn.them.org> References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> <20020917182536.GA25012@nevyn.them.org> <3D878695.3040101@realitydiluted.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D878695.3040101@realitydiluted.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 02:46:29PM -0500, Steven J. Hill wrote: > Daniel Jacobowitz wrote: > >On Tue, Sep 17, 2002 at 12:24:14PM -0500, Steven J. Hill wrote: > > > >Steve, have you started memorizing my responses again? :) > > > *gurgle* Yeah, I have. I apologize if it seemed I was taking > credit for anything. > > >>>cross-gdb configured using: > >>> > >>>configure --prefix=/usr --target=mipsel-linux --disable-sim > >>>--disable-tcl --enable-threads --enable-shared > >>> > >> > >>Use '--target=mips-linux' and you'll be better off. Don't worry, it > >>will support both endians. > > > > > >Except for this one - where'd that come from? It should make no > >functional difference either way, at least assuming you always give GDB > >a binary. > > > I got some weird errors (unfortunately I can't remember) if I tried > using 'mipsel-linux' as the target. So you're saying that a gdb > configured for 'mipsel-linux' or 'mips-linux' should work the same? > Thanks Daniel. Hmm, if you can reproduce these let me know what they are. I use a mipsel GDB regularly. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From dom@algor.co.uk Tue Sep 17 23:44:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 23:44:27 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:31460 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 23:44:26 +0200 Received: from gladsmuir.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g8HLiCr26331; Tue, 17 Sep 2002 22:44:17 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15751.41516.224075.295052@gladsmuir.algor.co.uk> Date: Tue, 17 Sep 2002 22:44:12 +0100 To: Jun Sun Cc: linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch In-Reply-To: <20020917110423.E17321@mvista.com> References: <20020917110423.E17321@mvista.com> X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Jun Sun (jsun@mvista.com) writes: > 1) always blindly save and restore during context switch (switch_to()) Just a suggestion... > Not interesting. Just list it here for completeness. Agreed, it's not interesting. But it would work, every time; while the current scheme has been a fertile source of interesting bugs. How much useful optimisation might have been done with the effort required to fix them? Saving all the FPU registers on a 400MHz CPU takes about a tenth of a microsecond. Does anyone reading this list have evidence that this is ever any kind of problem? Dominic Sweetman MIPS Technologies. From mdharm@momenco.com Tue Sep 17 23:58:11 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 17 Sep 2002 23:58:12 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:17938 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Tue, 17 Sep 2002 23:58:11 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8HLw0603428; Tue, 17 Sep 2002 14:58:00 -0700 From: "Matthew Dharm" To: "Dominic Sweetman" , "Jun Sun" Cc: Subject: RE: [RFC] FPU context switch Date: Tue, 17 Sep 2002 14:58:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15751.41516.224075.295052@gladsmuir.algor.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips I've got some evidence. We use both OpenBSD and Linux on our hardware. Using apps that use the FPU, we see a _significant_ performance difference. The problem appears to be that OpenBSD always save/restores, where Linux doesn't. The difference is _very_ noticable. On the order of 10-20% for FPU-heavy applications. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of > Dominic Sweetman > Sent: Tuesday, September 17, 2002 2:44 PM > To: Jun Sun > Cc: linux-mips@linux-mips.org > Subject: Re: [RFC] FPU context switch > > > > Jun Sun (jsun@mvista.com) writes: > > > 1) always blindly save and restore during context switch > (switch_to()) > > Just a suggestion... > > > Not interesting. Just list it here for completeness. > > Agreed, it's not interesting. > > But it would work, every time; while the current scheme has been a > fertile source of interesting bugs. How much useful optimisation > might have been done with the effort required to fix them? > > Saving all the FPU registers on a 400MHz CPU takes about a > tenth of a > microsecond. Does anyone reading this list have evidence > that this is > ever any kind of problem? > > Dominic Sweetman > MIPS Technologies. > > From kevink@mips.com Wed Sep 18 00:28:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 00:28:39 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:23763 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 00:28:38 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8HMSKUD007734; Tue, 17 Sep 2002 15:28:20 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA06724; Tue, 17 Sep 2002 15:28:31 -0700 (PDT) Message-ID: <019d01c25e99$d9786af0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Matthew Dharm" , "Dominic Sweetman" , "Jun Sun" Cc: References: Subject: Re: [RFC] FPU context switch Date: Wed, 18 Sep 2002 00:30:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips I'm extremely skeptical about this "evidence". Saving/restoring the context of the CPU is going to less than double the context switch overhead between processes. For an overall application to degrade by 20% due solely to that, it seems to me that it must therefore be spending something more than 40% of its time doing context switches (20% for the FPU, 20+% for the GPRs, TLB, etc). Poorly written multithreaded applications will do that sometimes, but not a serious "FPU-heavy" application. There's got to be another factor at play between OpenBSD and Linux, e.g. the VM subsystem. Lazy FPU context switch was one of those 1980's ideas that seemed clever at the time but which was always a bit overrated. We implemented it from scratch in SVR3 for the Fairchild Clipper CPU, in such a way as we could turn it on and off, and measured the context switch time with a logic analyser. I don't recall the exact number, but in the end we had saved far less than 10% of the *context switch* time, which was barely measureable in terms of overall application performance. It would be easy enough to do the same for MIPS/Linux and do an apples-to-apples comparison. Indeed, I could have sworn that someone had already done that the last time the topic got thrashed around on this list. Regards, Kevin K. ----- Original Message ----- From: "Matthew Dharm" To: "Dominic Sweetman" ; "Jun Sun" Cc: Sent: Tuesday, September 17, 2002 11:58 PM Subject: RE: [RFC] FPU context switch > I've got some evidence. > > We use both OpenBSD and Linux on our hardware. Using apps that use > the FPU, we see a _significant_ performance difference. The problem > appears to be that OpenBSD always save/restores, where Linux doesn't. > > The difference is _very_ noticable. On the order of 10-20% for > FPU-heavy applications. > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > > -----Original Message----- > > From: linux-mips-bounce@linux-mips.org > > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of > > Dominic Sweetman > > Sent: Tuesday, September 17, 2002 2:44 PM > > To: Jun Sun > > Cc: linux-mips@linux-mips.org > > Subject: Re: [RFC] FPU context switch > > > > > > > > Jun Sun (jsun@mvista.com) writes: > > > > > 1) always blindly save and restore during context switch > > (switch_to()) > > > > Just a suggestion... > > > > > Not interesting. Just list it here for completeness. > > > > Agreed, it's not interesting. > > > > But it would work, every time; while the current scheme has been a > > fertile source of interesting bugs. How much useful optimisation > > might have been done with the effort required to fix them? > > > > Saving all the FPU registers on a 400MHz CPU takes about a > > tenth of a > > microsecond. Does anyone reading this list have evidence > > that this is > > ever any kind of problem? > > > > Dominic Sweetman > > MIPS Technologies. > > > > > > > From lindahl@keyresearch.com Wed Sep 18 01:01:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:01:16 +0200 (CEST) Received: from nixon.xkey.com ([209.245.148.124]:59267 "HELO nixon.xkey.com") by linux-mips.org with SMTP id ; Wed, 18 Sep 2002 01:01:15 +0200 Received: (qmail 24204 invoked from network); 17 Sep 2002 23:01:03 -0000 Received: from localhost (HELO localhost.conservativecomputer.com) (127.0.0.1) by localhost with SMTP; 17 Sep 2002 23:01:03 -0000 Received: (from lindahl@localhost) by localhost.conservativecomputer.com (8.11.6/8.11.0) id g8HMws801974 for linux-mips@linux-mips.org; Tue, 17 Sep 2002 15:58:54 -0700 X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f Date: Tue, 17 Sep 2002 15:58:54 -0700 From: Greg Lindahl To: linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch Message-ID: <20020917155854.B1883@wumpus.attbi.com> References: <019d01c25e99$d9786af0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <019d01c25e99$d9786af0$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 12:30:23AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lindahl@keyresearch.com Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 12:30:23AM +0200, Kevin D. Kissell wrote: > I'm extremely skeptical about this "evidence". The only good test is Linux with and without lazy saves. Throwing in a new OS complicates matters. It sounds like Jun already has working code for (1) and (3), so he can do a good test. > Indeed, I could have sworn that someone had already done that the > last time the topic got thrashed around on this list. Yes, I remember that too, which is why I'm surprised the issue came up again. g From jsun@orion.mvista.com Wed Sep 18 01:16:23 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:16:24 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:40179 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 01:16:23 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HN3mE23387; Tue, 17 Sep 2002 16:03:48 -0700 Date: Tue, 17 Sep 2002 16:03:48 -0700 From: Jun Sun To: Greg Lindahl Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [RFC] FPU context switch Message-ID: <20020917160348.N17321@mvista.com> References: <019d01c25e99$d9786af0$10eca8c0@grendel> <20020917155854.B1883@wumpus.attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020917155854.B1883@wumpus.attbi.com>; from lindahl@keyresearch.com on Tue, Sep 17, 2002 at 03:58:54PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Tue, Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote: > > Yes, I remember that too, which is why I'm surprised the issue came up > again. > ... because nobody has fixed it yet. What a surprise. :-) Jun From jsun@orion.mvista.com Wed Sep 18 01:17:03 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:17:04 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:48371 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 01:17:03 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HN4Pj23401; Tue, 17 Sep 2002 16:04:25 -0700 Date: Tue, 17 Sep 2002 16:04:25 -0700 From: Jun Sun To: linux-mips@linux-mips.org Cc: jsun@mvista.com Subject: [jsun@mvista.com: Re: [RFC] FPU context switch] Message-ID: <20020917160425.O17321@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips Meant to send to the list .... ----- Forwarded message from Jun Sun ----- X-Sieve: cmu-sieve 2.0 Date: Tue, 17 Sep 2002 16:02:26 -0700 From: Jun Sun To: Greg Lindahl Cc: jsun@mvista.com Subject: Re: [RFC] FPU context switch User-Agent: Mutt/1.2.5i In-Reply-To: <20020917155854.B1883@wumpus.attbi.com>; from lindahl@keyresearch.com on Tue, Sep 17, 2002 at 03:58:54PM -0700 On Tue, Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote: > On Wed, Sep 18, 2002 at 12:30:23AM +0200, Kevin D. Kissell wrote: > > > I'm extremely skeptical about this "evidence". > > The only good test is Linux with and without lazy saves. Throwing in a > new OS complicates matters. It sounds like Jun already has working > code for (1) and (3), so he can do a good test. > I actually have 2) and 3). 1) is easy to do, though. Anyone can recommand some test programs to try? A while back, I tried lmbench which is not very telling. I think the reason is that most of the tests are not using FPU at all. However I might try it again anyway. It might tell the difference between 1) and 2)&3) easily. Jun ----- End forwarded message ----- From kevink@mips.com Wed Sep 18 01:43:04 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:43:05 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:47572 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 01:43:04 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8HNgsUD008089; Tue, 17 Sep 2002 16:42:54 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA09925; Tue, 17 Sep 2002 16:43:04 -0700 (PDT) Message-ID: <01ad01c25ea4$435ab220$10eca8c0@grendel> From: "Kevin D. Kissell" To: , "Jun Sun" References: <20020917110423.E17321@mvista.com> Subject: Re: [RFC] FPU context switch Date: Wed, 18 Sep 2002 01:44:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > I am now facing a couple of choices in the implementation and > like to hear back from you. Those choices mainly differ at when we > should save fpu context and when we should restore it. > > 1) always blindly save and restore during context switch (switch_to()) > > Not interesting. Just list it here for completeness. Not everything that is interesting is worth doing. And not everything worth doing is interesting. > 2) save PFU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on next use of FPU. > > Need to use an additional flag to remember whether it is used > in the current run. > > Perhaps overridding used_math? In that > case, used_math == 2 indicates it used in the current run. > used_math is set back to 1 when process is switched off. > > Very simply to implement. It's still somewhat less simple than the current hack, and *that* was gotten wrong repeatedly. > 3) save FPU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on the next use of FPU and *only* if other > processes have tampered FPU context since the last use of FPU by > the current process. > > This requires each CPU to remember the last owner of FPU. > In order to support possible process migration cases in a SMP > system, each process also needs to remember the processor > on which it used FPU last. A process has a valid live FPU > context on a CPU if those two variables match to each other. > Therefore we can avoid unnecessary restoring FPU context. > > Fairly complex in implementation. > > 4) don't save or restore any FPU context during context switches. > Instead, we implement a full SMP-safe version of lazy fpu > switch. > > This introduces three states in terms of FPU context status: > a) live FPU context in current CPU > b) saved FPU context in memory > c) live FPU context in another CPU > Before we only have a) and b) states. c) is new in this approach. > > To deal with c), we need to provide an inter-processor call so that > we can ask another CPU to save FPU context in case we need to access > it on this CPU. > > Additionally we need similar variables required in 3) to keep track > who owns FPU at any time. > > Very complex to implement. Has the best performance, though. > > Currently I am leaning towards 2) or 3). What is your opinion? My opinion is that an FP context restore costs something on the order of 40 in-line instructions which touch contiguous data. You don't need to load and evaluate very many control variables to burn through those 40-odd cycles, particularly if you are manipulating volatile coherent shared cache lines on a cache-coherent SMP (let's not even talk about what happens if you haven't got cache coherence). "FPU Shootdowns", which is essentially what you're calling for in 4c, would, in my opinion, be a Bad Thing. I'd much prefer something that is simple and processor-local, even if it may be less optimal in some corner cases. For example, Why not simply use CP0.Status.CU1 as a "dirty" bit? If it's set when a process switches out, the FPU state gets saved, and CU1 cleared. If it's not set when a process hits an FP instruction, CU1 gets set and the context gets loaded. This involves no access whatever to shared control variables, indeed, it doesn't even go to memory to make the decision. It will, of course, save some FP contexts that don't need saving, but it is well behaved in the cases I care most about - it avoids saving/restoring FPRs of code that is doing no FP whatsoever, and it ensures that whenever a thread starts up, whatever CPU its on, its full context is available to that CPU, no (coherent) questions asked. Regards, Kevin K. From mdharm@momenco.com Wed Sep 18 01:47:44 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:47:45 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:27154 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 01:47:44 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8HNlT604122; Tue, 17 Sep 2002 16:47:31 -0700 From: "Matthew Dharm" To: "Ralf Baechle" , "Linux-MIPS" Subject: PATCH: new MTD probe addresses for Ocelot and Ocelot-G Date: Tue, 17 Sep 2002 16:47:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C25E69.E9307800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C25E69.E9307800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The attached patch updates the probe addresses for the Ocelot and Ocelot-G boards for the MTD driver. This is actually a resend. This patch was skipped the first time. Ralf, please apply to both 2.4 and 2.5 branches. Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com ------=_NextPart_000_0014_01C25E69.E9307800 Content-Type: application/octet-stream; name="patch20020903" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch20020903" Index: drivers/mtd/devices/docprobe.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /cvs/linux/drivers/mtd/devices/docprobe.c,v=0A= retrieving revision 1.3=0A= diff -u -u -r1.3 docprobe.c=0A= --- drivers/mtd/devices/docprobe.c 2001/11/05 20:15:52 1.3=0A= +++ drivers/mtd/devices/docprobe.c 2002/09/03 21:37:19=0A= @@ -88,6 +88,9 @@=0A= 0xe4000000,=0A= #elif defined(CONFIG_MOMENCO_OCELOT)=0A= 0x2f000000,=0A= + 0xff000000,=0A= +#elif defined(CONFIG_MOMENCO_OCELOT_G)=0A= + 0xff000000,=0A= #else=0A= #warning Unknown architecture for DiskOnChip. No default probe = locations defined=0A= #endif=0A= ------=_NextPart_000_0014_01C25E69.E9307800-- From jsun@orion.mvista.com Wed Sep 18 01:57:54 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 01:57:54 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:48882 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 01:57:54 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8HNjKx27046; Tue, 17 Sep 2002 16:45:20 -0700 Date: Tue, 17 Sep 2002 16:45:20 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [RFC] FPU context switch Message-ID: <20020917164520.P17321@mvista.com> References: <20020917110423.E17321@mvista.com> <01ad01c25ea4$435ab220$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01ad01c25ea4$435ab220$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 01:44:57AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 01:44:57AM +0200, Kevin D. Kissell wrote: > > I am now facing a couple of choices in the implementation and > > like to hear back from you. Those choices mainly differ at when we > > should save fpu context and when we should restore it. > > > > 1) always blindly save and restore during context switch (switch_to()) > > > > Not interesting. Just list it here for completeness. > > Not everything that is interesting is worth doing. > And not everything worth doing is interesting. > > > 2) save PFU context when process is switched off *only if* > > FPU is used in the last run. > > restore FPU context on next use of FPU. > > > > Need to use an additional flag to remember whether it is used > > in the current run. > > > > Perhaps overridding used_math? In that > > case, used_math == 2 indicates it used in the current run. > > used_math is set back to 1 when process is switched off. > > > > Very simply to implement. > > It's still somewhat less simple than the current hack, > and *that* was gotten wrong repeatedly. > It is much simpler than the current hack, because it does not maintain last_task_used_math or any "lazy switch" concepts. > > I'd much prefer something that is simple and processor-local, > even if it may be less optimal in some corner cases. For example, > Why not simply use CP0.Status.CU1 as a "dirty" bit? If it's set > when a process switches out, the FPU state gets saved, and CU1 > cleared. If it's not set when a process hits an FP instruction, > CU1 gets set and the context gets loaded. This involves no > access whatever to shared control variables, indeed, it doesn't > even go to memory to make the decision. It will, of course, save > some FP contexts that don't need saving, but it is well behaved > in the cases I care most about - it avoids saving/restoring FPRs > of code that is doing no FP whatsoever, and it ensures that > whenever a thread starts up, whatever CPU its on, its full > context is available to that CPU, no (coherent) questions asked. > This is basically 2) except for dirty bit difference. My current implementaion uses bit:1 in task->used_math flag for "dirty" bit purpose. I was thinking to use CU1, but it turns out to be a non- reliable indicator. Several places inside the kernel turning on/off FPUs. Perhaps after further cleanups, these offending places may become obsolete. I will keep this option in my mind. Jun From kevink@mips.com Wed Sep 18 02:08:25 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 02:08:26 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:6869 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 02:08:25 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8I08EUD008189; Tue, 17 Sep 2002 17:08:14 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id RAA11080; Tue, 17 Sep 2002 17:08:25 -0700 (PDT) Message-ID: <01b801c25ea7$ce074ed0$10eca8c0@grendel> From: "Kevin D. Kissell" To: , "Jun Sun" References: <20020917160425.O17321@mvista.com> Subject: Re: [jsun@mvista.com: Re: [RFC] FPU context switch] Date: Wed, 18 Sep 2002 02:10:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > ----- Forwarded message from Jun Sun ----- Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote: > > > > The only good test is Linux with and without lazy saves. Throwing in a > > new OS complicates matters. It sounds like Jun already has working > > code for (1) and (3), so he can do a good test. > > > > I actually have 2) and 3). 1) is easy to do, though. > > Anyone can recommand some test programs to try? > > A while back, I tried lmbench which is not very telling. > I think the reason is that most of the tests are not using > FPU at all. "Not very telling?" Sounds to me as if it confirms the hypothesis that the benefits of these optimizations are maginal. ;-) > However I might try it again anyway. It might tell the > difference between 1) and 2)&3) easily. If I wanted to see the effect at its strongest, I'd whip up an FP-intensive, low-I/O program along the lines of the old fashioned Whetstone benchmark that runs for at least a few seconds, then time a script that forks off N of them in parallel with M instances of a program that does no FP. You can then play with M and N to see where a hack becomes advantageous. If all runnable programs are using the FPU, there's clearly no benefit from the optimization. Are you able to test this stuff on a proper SMP system, by the way? The efficiency of the code that manipulates interprocessor control variables can reasonably be expected to drop off a bit in a system with MP cache invalidations blasting left and right. Regards, Kevin K. From jsun@orion.mvista.com Wed Sep 18 02:27:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 02:27:08 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:15613 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 02:27:07 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8I0EYj27445; Tue, 17 Sep 2002 17:14:34 -0700 Date: Tue, 17 Sep 2002 17:14:34 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [jsun@mvista.com: Re: [RFC] FPU context switch] Message-ID: <20020917171434.Q17321@mvista.com> References: <20020917160425.O17321@mvista.com> <01b801c25ea7$ce074ed0$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01b801c25ea7$ce074ed0$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 02:10:17AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 02:10:17AM +0200, Kevin D. Kissell wrote: > Are you able to test this stuff on a proper SMP > system, by the way? The efficiency of the code > that manipulates interprocessor control variables > can reasonably be expected to drop off a bit > in a system with MP cache invalidations blasting > left and right. > Yes. I understand this effect. Solution 1), 2) and 3) don't really suffer from this problem because variables tested & manipulated are local - unless the process migrates which is a different problem. Jun From mdharm@momenco.com Wed Sep 18 03:59:47 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 03:59:48 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:35858 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 03:59:47 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8I1xd604821; Tue, 17 Sep 2002 18:59:39 -0700 From: "Matthew Dharm" To: "Matthew Dharm" , "Linux-MIPS" Subject: RE: bug with 512MB of RAM? Date: Tue, 17 Sep 2002 18:59:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips So, I went digging into this.... It seems that the RM7k cache routines for DMA managment don't like it if the addr+size runs up to the end of kseg0 (addr 0xa0000000). A quick if() to test the 'end' variable in c-rm7k.c and make sure we never call {flush|invalidate}_{s|d}cache_line() with an address in kseg1 makes boards with 512MByte of memory work. Of course, this has me wondering how CONFIG_HIGHMEM works... from a quick scan of mm/init.c, it looks like DMA-able memory is only allocated out of kseg0... but I'm not a memory-management expert. Actually, I'm something of a rookie here... I'm trying to wrap my brain around the concept of 'zones', and it looks like everything should 'just work'.... But I'm wondering if: (a) Someone will confirm my analysis that DMA-able memory is allocated with kseg0 addresses, thus no 'highmem' will be used (b) Someone has a primer on the memory-managment system? If I'm right, I'll be submitting a patch to fix c-rm7k.c for 2.4 and 2.5 Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Matthew Dharm > Sent: Monday, September 16, 2002 2:36 PM > To: Linux-MIPS > Subject: bug with 512MB of RAM? > > > A long time ago, there was a bug somewhere that only affected boards > with 512MB of memory with RM7000 processors. Apparently, there were > problems in the cache-managment code causing a problem working with > memory near the end of kseg0. I don't recall all the details -- by > the time I got to looking at it the first time, someone > already had a > fix. > > I was told this was fixed... but I'm seeing some symptoms that this > was not fixed. Does anyone actually recall if this was > fixed or not? > If it was, I need to look elsewhere. But, if it wasn't actually > fixed.... > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. > Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > From seh@zee2.com Wed Sep 18 09:49:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 09:49:26 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:56305 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 09:49:26 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8I7mqM13757 for ; Wed, 18 Sep 2002 08:48:55 +0100 Message-ID: <3D882FE4.54787C25@zee2.com> Date: Wed, 18 Sep 2002 08:48:52 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> <20020917182536.GA25012@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips Hi Steve/Daniel, Thanks very much for your help ! I've now got a few days "homework" to try out :-) Regards, Stuart Daniel Jacobowitz wrote: > > On Tue, Sep 17, 2002 at 12:24:14PM -0500, Steven J. Hill wrote: > > Stuart Hughes wrote: > > > > > >Does anyone know whether there is some special setup needed on > > >gdb/gdbserver to use the multi-threaded gdbserver ?? > > > > > Wow, there are so many things to tell you...where to start... > > Steve, have you started memorizing my responses again? :) > > > >My environment is as follows: > > > > > >CPU: NEC VR5432 > > >kernel: linux-2.4.18 + patches > > >glibc: 2.2.3 + patches > > >gdb: 5.2/3 from CVS > > > > > Has to be the gdb-5.3 branch...go look at http://sources.redhat.com/gdb > > > > >gcc: 3.1 > > >binutils: Version 2.11.90.0.25 > > > > > Don't use H.J. Lu's binutils, use the released one. Use gcc-3.2 and > > binutils-2.13 as they have fixes for the MIPS debugging symbols with > > regards to DWARF. > > > > >cross-gdb configured using: > > > > > >configure --prefix=/usr --target=mipsel-linux --disable-sim > > >--disable-tcl --enable-threads --enable-shared > > > > > Use '--target=mips-linux' and you'll be better off. Don't worry, it > > will support both endians. > > Except for this one - where'd that come from? It should make no > functional difference either way, at least assuming you always give GDB > a binary. > > > >gdbserver configured using: > > > > > >configure --prefix=/usr --host=mipsel-linux --target=mipsel-linux > > >--enable-threads --enable-shared > > > > > I would also try 'CC=mipsel-linux-gcc configure <...>'. > > Definitely. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer From carstenl@mips.com Wed Sep 18 10:30:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 10:30:10 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:14299 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 10:30:09 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8I8TqUD009629; Wed, 18 Sep 2002 01:29:52 -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 BAA24820; Wed, 18 Sep 2002 01:30:00 -0700 (PDT) Received: from mips.com (IDENT:carstenl@coplin20 [192.168.205.90]) by copfs01.mips.com (8.11.4/8.9.0) with ESMTP id g8I8Tpb28455; Wed, 18 Sep 2002 10:29:51 +0200 (MEST) Message-ID: <3D88397E.8EFB8B13@mips.com> Date: Wed, 18 Sep 2002 10:29:50 +0200 From: Carsten Langgaard X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.9-31-P3-UP-WS-jg i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: linux-mips@linux-mips.org Subject: Re: [RFC] FPU context switch References: <20020917110423.E17321@mvista.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: carstenl@mips.com Precedence: bulk X-list: linux-mips Jun Sun wrote: > I am rewriting the FPU management code with the following > objectives in my mind: > > 1) to make it work for SMP. Right now, processes can migrate > to different CPUs leaving their FPU context on another CPU. > And the global variable last_task_used_math is shared by > multiple CPUs. :-) > > 2) to provide a layer to generic kernel code that hides > the differences between fpu emul case and hard FPU case, > so that we don't see many "if (mips_cpu.options & MIPS_CPU_FPU)" > around. > > 3) to simplify some existing code (such as those in signal.c) > so that we don't see many "if (last_task_used_math == ...)" around. > > I am now facing a couple of choices in the implementation and > like to hear back from you. Those choices mainly differ at when we > should save fpu context and when we should restore it. > > 1) always blindly save and restore during context switch (switch_to()) > > Not interesting. Just list it here for completeness. > > 2) save PFU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on next use of FPU. > > Need to use an additional flag to remember whether it is used > in the current run. Perhaps overridding used_math? In that > case, used_math == 2 indicates it used in the current run. > used_math is set back to 1 when process is switched off. > Let's go for solution 2. Try to look in 64-bit kernel (when CONFIG_SMP is enabled), here solution 2 is already implemented (the plan is to implement this in the 32-bit kernel as well, but please go a head and do it). The extra flag you are looking for, is the PF_USEDFPU flag, which also is used by other architecture. Locally we have got rid of the '#ifdef CONFIG_SMP', and always do it the SMP way. The "last_task_used_math / lazy fpu switch" method has just cost to much pain. > > Very simply to implement. > > 3) save FPU context when process is switched off *only if* > FPU is used in the last run. > restore FPU context on the next use of FPU and *only* if other > processes have tampered FPU context since the last use of FPU by > the current process. > > This requires each CPU to remember the last owner of FPU. > In order to support possible process migration cases in a SMP > system, each process also needs to remember the processor > on which it used FPU last. A process has a valid live FPU > context on a CPU if those two variables match to each other. > Therefore we can avoid unnecessary restoring FPU context. > > Fairly complex in implementation. > > 4) don't save or restore any FPU context during context switches. > Instead, we implement a full SMP-safe version of lazy fpu > switch. > > This introduces three states in terms of FPU context status: > a) live FPU context in current CPU > b) saved FPU context in memory > c) live FPU context in another CPU > Before we only have a) and b) states. c) is new in this approach. > > To deal with c), we need to provide an inter-processor call so that > we can ask another CPU to save FPU context in case we need to access > it on this CPU. > > Additionally we need similar variables required in 3) to keep track > who owns FPU at any time. > > Very complex to implement. Has the best performance, though. > > Currently I am leaning towards 2) or 3). What is your opinion? > > Jun -- _ _ ____ ___ 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 kevink@mips.com Wed Sep 18 10:36:39 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 10:36:40 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:21467 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 10:36:39 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8I8aVUD009648; Wed, 18 Sep 2002 01:36:31 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA25025; Wed, 18 Sep 2002 01:36:39 -0700 (PDT) Message-ID: <003c01c25eee$cfb41c30$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" Cc: , References: <20020917110423.E17321@mvista.com> <01ad01c25ea4$435ab220$10eca8c0@grendel> <20020917164520.P17321@mvista.com> Subject: Re: [RFC] FPU context switch Date: Wed, 18 Sep 2002 10:38:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Jun Sun" > On Wed, Sep 18, 2002 at 01:44:57AM +0200, Kevin D. Kissell wrote: > > > > I'd much prefer something that is simple and processor-local, > > even if it may be less optimal in some corner cases. For example, > > Why not simply use CP0.Status.CU1 as a "dirty" bit? If it's set > > when a process switches out, the FPU state gets saved, and CU1 > > cleared. If it's not set when a process hits an FP instruction, > > CU1 gets set and the context gets loaded. This involves no > > access whatever to shared control variables, indeed, it doesn't > > even go to memory to make the decision. It will, of course, save > > some FP contexts that don't need saving, but it is well behaved > > in the cases I care most about - it avoids saving/restoring FPRs > > of code that is doing no FP whatsoever, and it ensures that > > whenever a thread starts up, whatever CPU its on, its full > > context is available to that CPU, no (coherent) questions asked. > > > > This is basically 2) except for dirty bit difference. > > My current implementaion uses bit:1 in task->used_math flag for > "dirty" bit purpose. Which is not a property of the CPU, but of the thread, meaning that it will be written by one CPU and read by another, i.e. there will be MP memory traffic and cache interventions/invalidations/misses around the operation. Kevin K. From kevink@mips.com Wed Sep 18 10:43:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 10:43:13 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:25307 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 10:43:12 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8I8h5UD009676; Wed, 18 Sep 2002 01:43:05 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA25145; Wed, 18 Sep 2002 01:43:12 -0700 (PDT) Message-ID: <004101c25eef$ba035350$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <20020917160425.O17321@mvista.com> <01b801c25ea7$ce074ed0$10eca8c0@grendel> <20020917171434.Q17321@mvista.com> Subject: Re: [jsun@mvista.com: Re: [RFC] FPU context switch] Date: Wed, 18 Sep 2002 10: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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Jun Sun" > On Wed, Sep 18, 2002 at 02:10:17AM +0200, Kevin D. Kissell wrote: > > Are you able to test this stuff on a proper SMP > > system, by the way? The efficiency of the code > > that manipulates interprocessor control variables > > can reasonably be expected to drop off a bit > > in a system with MP cache invalidations blasting > > left and right. > > Yes. I understand this effect. Solution 1), 2) > and 3) don't really suffer from this problem because > variables tested & manipulated are local - unless the > process migrates which is a different problem. It's not a "different problem", it's the heart of the problem. If we weren't worried about SMP behavior, we wouldn't be revisiting this stuff. While (1) can obviously be done without any global knowledge, as could something (2)-like based on CPU-local state such as Status.CU1, (2), (3) and (4), as you describe them, all depend to some degree on shared multiprocessor variables to determine whether to save or restore FP state. Regards, Kevin K. From js@convergence.de Wed Sep 18 14:10:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 14:10:58 +0200 (CEST) Received: from buserror-extern.convergence.de ([212.84.236.66]:49670 "EHLO hell") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 14:10:57 +0200 Received: from js by hell with local (Exim 3.35 #1 (Debian)) id 17rdfL-00059j-00; Wed, 18 Sep 2002 14:10:47 +0200 Date: Wed, 18 Sep 2002 14:10:47 +0200 From: Johannes Stezenbach To: "Steven J. Hill" Cc: Stuart Hughes , Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver Message-ID: <20020918121047.GA17744@convergence.de> References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D87653E.9030702@realitydiluted.com> User-Agent: Mutt/1.4i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: js@convergence.de Precedence: bulk X-list: linux-mips Steven J. Hill wrote: > Stuart Hughes wrote: > > > >Does anyone know whether there is some special setup needed on > >gdb/gdbserver to use the multi-threaded gdbserver ?? ... > >binutils: Version 2.11.90.0.25 > > > Don't use H.J. Lu's binutils, use the released one. Use gcc-3.2 and > binutils-2.13 as they have fixes for the MIPS debugging symbols with > regards to DWARF. Is this a general recommendation to avoid H.J. Lu's binutils, or do you just favor the newer binutils version? What about binutils 2.13.90.0.4? I'm currently using gcc-2.95.4 with the Debian patches, and binutils binutils-2.12.90.0.14, which seem to work well. I planned to switch to gcc-3.2 but postponed it because I read about the DWARF debugging problems. Are they solved with gcc-3.2 / binutils-2.13 / gdb-5.3-CVS ? Regards, Johannes From atulsrivastava9@rediffmail.com Wed Sep 18 14:34:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 14:34:15 +0200 (CEST) Received: from webmail22.rediffmail.com ([203.199.83.144]:64464 "HELO webmail22.rediffmail.com") by linux-mips.org with SMTP id ; Wed, 18 Sep 2002 14:34:14 +0200 Received: (qmail 28352 invoked by uid 510); 18 Sep 2002 12:31:48 -0000 Date: 18 Sep 2002 12:31:48 -0000 Message-ID: <20020918123148.28350.qmail@webmail22.rediffmail.com> Received: from unknown (202.54.89.92) by rediffmail.com via HTTP; 18 Sep 2002 12:31:48 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: vm_growsdown in mips.. Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello, after kernel has booted , when shell is being execve'ed it repeatedly loops in do_page_fault() with address 0x0fc01788. address 0x0fc01788 is well within user address space. In do_page_fault() code 1.vma = find_vma(mm,address) goes succefully ..means address pertains to the current task. 2.but fails in if(!(vma->vm_flags & VM_GROWSDOWN) { goto bad_area; } VM_GROWSDOWN flag indicates the stack area. is this indicates problem with mmu initialisation..? Best Regards, __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From caravel_uk@transtools.com Wed Sep 18 15:05:46 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 15:05:47 +0200 (CEST) Received: from [213.9.157.198] ([213.9.157.198]:22282 "EHLO transtools.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 15:05:46 +0200 Received: from smtp.transtools.com ([172.16.22.62]) by transtools.com (8.12.3/8.12.3) with SMTP id g8IE3Dx4020565 for linux-mips@linux-mips.org; Wed, 18 Sep 2002 14:03:13 GMT Date: Wed, 18 Sep 2002 14:03:13 GMT From: Caravel UK Message-Id: <200209181403.g8IE3Dx4020565@transtools.com> X-Mailer: CODE Windows Cosmo Mail Version 1.0.0 To: linux-mips@linux-mips.org Subject: Go to Java. Go Now! MIME-Version: 1.0 Content-Type: multipart/related;boundary="mc0p4Jq0M:2Yt08jU534c0p===========" X-RAVMilter-Version: 8.3.1(snapshot 20020108) (correott) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: caravel_uk@transtools.com Precedence: bulk X-list: linux-mips This is the preamble area of a multipart message Mail readers that understand multipart format should ignore this preamble If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --mc0p4Jq0M:2Yt08jU534c0p=========== Content-Type:text/html;charset=ISO-8859-1 Caravel

Now you and your customers can benefit from a fast and sure conversion of your legacy RPG based systems to Java™!

Let us introduce Caravel™, the latest conversion technology from TransTOOLs.

 

Caravel™ of TransTOOLs, translates 100% of the RPG systems running on OS/400® to Java™, with the advantages of this standard: graphic interfaces, object-oriented programming, multi-platform, Web applications, e-business components. All this using the most advanced technology.

Systems are translated while keeping 100% the same functionality. For RPG-based systems, Caravel™ means an immediate and sure solution, with an open technological outlook.

Learn more about our conversion technology, explore the possibilities! Let us produce a demo on a system of your choice (no strings attached!)

 

For more information, please visit:
http://www.transtools.com

or send us an e-mail at:
caravel_uk@transtools.com

3 Bethesda Metro Center, Suite 700, Bethesda, Maryland 20814
Phone: 301.941.1823 / 1824

   


HOW TO UNSUBSCRIBE: You received this e-mail because you are registered at one of our Web sites, or on one of our partner's sites. If you do not want to receive e-mail marketing from us, please email us at caravel@transtools.com, subject: "UNSUBSCRIBE".
--mc0p4Jq0M:2Yt08jU534c0p=========== Content-Type: APLICATION/OCTET-STREAM;name="salto.jpg" Content-Transfer-Encoding: Base64 Content-ID: <320333313@17092002-0801> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAGQAA/+IMWElDQ19QUk9GSUxFAAEBAAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQA AAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAAAsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVjaAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0IgSUVDNjE5 NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFlaIAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABjaWFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAABZJRUMg aHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRp dGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABMCVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMA KAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHRAdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34D igOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQtBDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsKEQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gL sAvIC+EL+QwSDCoMQwxcDHUMjgynDMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YPsw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMDEyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaPFrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ 3RoEGioaURp3Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+HukfEx8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPwJB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgpaymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu 7i8kL1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NL mkviTCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZUQlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzWXSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedmPWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/RcCtw hnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITjhUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQbpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKe QJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvV TtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf///+4AIUFkb2JlAGTAAAAAAQMAEAMCAwYAABdkAAAgcwAANJ//2wCEABENDQ0ODRIODhIaEQ8RGh8XEhIXHyIXFxcXFyIjGx4dHR4b IyMpKi0qKSM2Njs7NjZBQUFBQUFBQUFBQUFBQUEBEhERFBYUGBUVGBcTFxMXHRcZGRcdKx0dIB0dKzgoIyMjIyg4MjUtLS01Mjw8ODg8PEFBQUFBQUFBQUFBQUFBQf/CABEIAXgBGAMBIgACEQEDEQH/xADUAAEAAgMBAQAAAAAAAAAAAAAAAQMCBAUGBwEBAAMBAQEAAAAAAAAAAAAAAAECAwQFBhAAAgIDAAEDBAICAQQDAQAAAQIDBAARBRIhEwYQIEAUMCIxFVBgMiMkcEEzNBEAAgECBAIGCAQEAwgDAAAAAQIDABEh MRIEQVEQYXEiMhMgQIGRQiMUBTCxwVKh0WIzUJJDYIDhcoKisiTCRBUSAAEDAgMGBAYBAwUBAAAAAAEAEQIhMUFREhAwYXEiAyCBMlJAkaHRQhNiYLHB8OFywtIz/9oADAMBAAIRAxEAAADkD1OEEpEAAgJkAmEJiQiQiQAAAAAADF1ezlp5F0sLRopvtXXdnUrOiyxvU7OhS2q36Ja7YtmNKbO/WfOPX8es8eTWh63Xy080uz0prHraz5J6HgzGDcqlQ2LDTdxSdnlUegppq7XH69Z1uVlq65+g2Ofu46UcLbo2z7FfR4+d /R8qzixPXt5HRmMuPtci9e3z9Raq7qcaY9HfQ59rMufbMcH1PluprT1nDq08dOzqZ8yY9TwbePLotRevOJ0pExKRCJEkSAQJICRJARZgglEgAAAAAGIixMEhASABAAACYkgJkhEgiQABAJBGIi6YEhUJkAASiAAkEATEwSAAAiQEAYiLiUAgTKAAAJgAkCYmEJQSEIkkAAEAYpiLp6E5ac5Ma4hKYAEggmAEyERMCYkCCQAAAgCLqbefp3u75B5fod/z/U0u7joTHdxgEwCUwmEAkCQgEAAkEAAARMItmwu4u3D1XmLvP7I1 Pcaffw+Tmyvu5AmDXY32E68r0TrQEIkkAEAAAAAQEpC+Kc+Tpz6XIr8/u974+7tXr5Wr0nmO3h1Nbt7fF29nm69uWvG288PY8kNaAgAAAAAJgImJEjNWLc7oczXvx8r1L8Lurz9HV876fwnNXZwww7Iy3eX1Nc6YPW8sEggAAAAAJgEGOFNLbs9qk62/u8nye/mtu3Loo62xXw76/nu/5bt5r40t3qy2s88PU86EtM0CQiQmAAAABKAPVx5ru/Pe/wBzUwoxczX18qM8m1ZbE9HopyPO+gw5tPM9vPfvTW1PQ8D2fMqhHbyA sAAASREoJACANzS6Wv4P0uWWPGjG7e8t6qMr89DPevQ2NbRvXv8ALtp5OjG7DRytnfqb3oc3OS9byYSITACSSESQACCJmIB1fX+S914f0Xzrxn3fwevH4e7XiI9TTwN3LTPo8rY1p3J4VcT6Pc3tvO/By79uW3j9P6J5j1PN4Q7eMCJEiESgiUTKEyjGfV7HN1eMHTy7/r/mdPh/QfZHn+9fm8p8++3cG1fm+NOqb888dCnVH1mfF7vH2dPHja8vWdnxUI9VytLf0pzNL3eHVy+Gj1vH7eXlTOO3NJYmu7r+j4uvxfptXc5t ul5LY486a6HreM4/XnHo4Hv/ABvM8/0Pt93zr3dL6ny/7LrWp8Qemp0z8/n6zcvTh7+fTw6eTjuaHbw5V5Z4705WuHuyypit+t3/ABBX6Hp+c7kxjbzeLL2uvpObXW1fQ6bn4FdlHrceCXpeXCEWmAp6mnllr7jq/O/R8Hpd7y3qckeEd3i9nLz8N7mcvV0udZh2+fA255nEZTgi2c1q2sypml+l1vL2cnZ6fr+Mnk7fYeRw1tcMMctv1fJ1ndZ7edjKNuaAMgstpvrr2PSeJ2eH0Pa8i3pYbfOtf33g/Q82uJb8yJEJIhIR kTCZRCcjKyrLLeF3RW1u7t7nL1VL2O3zeIy9XxsJyxEzcmnPO2t7c8Jz3x73GjLb2/msNrk7PP6/s/PdfDysbsd+atnlpjVNkxarPYurfTz3r668u7sbuenI6PXs599W6yc9IiMIZKkvCzjl6fl15CEWkrst3PajLoW5b8nHp1I59mzgdDnVYcvToMujfXmupPZ5Whd2d/Lbz2fpMc9OJsdTOtqNqJztLHCJzimqzYp1qrV2GotHlEvQ8ebqc4vs31bWXVfmvx6KsrMqzzsOnXeuvZt7FLcuvtY1nxvrPIe+5fS0b9id/Pxs wiJtVomyKsJX169MxfRVjeueGMWTjjjMZK0x5/I7PJZkX2dsx693ZMOi2wpecSE2hngVnwH0M5/Rms6POqwLIEpgRGAVVl644EoxJiBMf//aAAgBAgABBQD8JpNHyGiQAHUrnl/YMpwsoxm0FlDNgl2fIbdwgDgkMpzyGe5/RgwYq2kUiMKQEDLH/c4qN4lW8I1/oEUFT5Lp9FD5SL5ARuF8CREjBvE+1/0T+xF5fgWWIj8RlNz+AQDlit6EnILoIBBGPOilZ42/lmqBy8RU152iY2o2jL6H9lEG/b/jJ1kr+bM6rlUeTgZH GXYDQ/hLoDJPFGk3RWYtOgEk5kNUf+MAZFGqL/EwcZMA+e2QI4y+NVTUUhjeewGFGf3Iv4gTpV8jOviUPplhBtYCzVGCzfxRD01hAIEXhhB1HGoM1yRsEp3Bb8j97WVBxVICtv7XT+yoMIbEsTx4nQxLMbZ6YToTXlSNLkkyxkNJr0eBGWSIqQ30WJ2ArtlhUU14IvbmpkYwZT6ZrWe7Io9yUiVi2V5kylESfoVBxq8TCWFosjkKlXDCeJi8EXtx/QqDhijOGvCcnp6C+K5Xh919hR7o39Tklcgo5BhlDj73ijfNpGsku82f qSMJ+ksSPmmRo7ORyK43m8L4ZMabWNMxwsT9NZ6565vGbWF8D42mEkTLlJ9L7gxps97DJhO81gXAueP0OMThObGBhovhk9IG0S301msC4FGazWa+hxsP09cP0i/7hg1np9Bg+z//2gAIAQMAAQUA/CVNjxO9bJQg54+mjmicCglkIGGPWaOlXyJUgEHNHPH+6kEbGMwL7G3IL/1GFhsMPJ2/sWJDDR2uww0h0S678ht2BG//ACf8D6/8R7EmiNfZv+SuAZPXLSDX13/ICQYLIzQyatpiCDiRswaJ1/litlAsgcSwrIorsHEW 2PixlAEn8ROAE5EniArHGOb9JHCqTs/whWOCGRmgqmPBGcRAuSH+xbJZC7Zr+FfbOBM8hjOFxZTjr5rHEQbkJRwPv39N5YCB3bxEZ2CM/wAZG3oZABZUmHyzf37zfpdY+RJOA6wybAI3I7kQ1UUeGsmqgA+mbzf03m8Gzi1SRr1syK0rIV+2P/tZjmkOPXifHpDHrOMIIxQWK1D5LAiF/wCqeR2J3DRTAgqCMeVEJnGV2kZbM83uw3lOL4sPXCAc9pTnhHgjUKyEG7KoX/73gYjEsSqY5UmDoGxkKmGVQliX3JM2cDsM9+UY Lc4yvdDFgxyxMIUAZz+udfVTvI7IYOmWIWT7/U5HNKg8XkaOILmvqATirg1kUrx4viyy1QDNDJE2s8cWI4IcWDFiUZofUeGf13r1RN4EGFMXalZFfOvH5SeycWAYItYEwDN5vN5v6KfVAMAz1zxOwuBPW+Nrr7N5v7B/ldYmsH09Prc//L7D9v8A/9oACAEBAAEFAP8AgT+Mfwh/wHB5qdG4O1xFn7denXu1+N07ETo8b0ar27Xf5v6U9bkdK1FJG8UmfGYopejYgeXoWeP0qsX6Nr9WOlalr1OV0LiWK09WWrfH+o/RguVP kSwi9gBJZeb8frdFuR0ebWqWbclvnXaX043Pr3OJ8eqqLMMMtiS1yuhTT9K1+rJRtRV/0rFeX5RHFFe+IkHOYvLSTq8qlW6Xc7F2l0flkKJe5k0kN/5BLLN1u91rlC58siQWIYZbEnxuGSDsc8XT3IfIU/jzC1S6X/ocCkvQ/wBX8tA9yK6I+dB3zDHfuC4+VWVLPylNdD/XcKxz+dK1D45Xsy9P4/nPtPT+PR14jP8AG/GGpwr1nqLxd2+Tdpx2aHyax5dH5PIH6fOvy8+1/uPjzydXrv0LQ7vHtL1Oi/RtwSGGbt9LnXgv d5FuPrdJulapWmp2n+RcmPON1Vo3U7PErJyrooXu10l6VtOvyp+f2+pX6Q+vyBKytlXu0p6t3v0kqcfsQVIej2KX6WL0oBxOR34qdLjdX/WzWO3zK1bi9FOdcrfIYYupPaE9/rWqVqz+JNNLO/8A8hn/AKlq8W3ZRuNbIIKn8+IpGKvX8mWM363USGdR+eoDKV82ks2JTR7twVbcM8Fj84MVwaJK7ytekhk/9Xq1r1CWjJ+ejg5JCDnPvSVZa71LkVz43UmSevPWk+tu2tZYLkVqGSv0IsS5WYgg/jxy+joDkVqxWHN+QSRy 2Iq16G/SanNliUxR3+VbghoM6z83ooR3Pj1Ow1B9x/jh2XJCvjEynKXVmrFmodeGT44rRTo46t+nKq83kc1Us9R65pW57BniRbf4yqSWTYtr/wCKghUkjXuSRnjTyyUemfGxBKkeM7NJZDTvLz7POrkaP4qjEUnI4vckvOGmgXwirQLOa/K5wNiWDn8u1M8swYeLSBcjMjvK8nj+MnoIxJLJZj/1tb2xpgBlSCeUqqRw9md24S+JUt/ZNSmKLwU+v4jOq578Rx6NqOGhyprSRV6VFLgkvP8ApsBDXqxtHBFLGP11PQ8ZuQsr BZZXc0yVkdGV9fiUI+ZXwcznySzVfOKa6tKOza/alJ9DohfHVOC2wv8AuixGRu5Aadh5Ag5dA1VvwNG+HX4da6zS1rxGC/55cdZIFdJQk+iyx+MNGGvDxLHUspNWjtxkyB5o4Z46vHorPOGlYNBbrzKYnJ3+HWhhV4JJmvh5BgvMic2xHMCVlWo9KGpUpWbTS3Zb8fHnm/Uu1xOjtJ7dWZXa7Z/XipTvVk6ZV5vw2Dwc+I23q6LDqW0RYZmiaGWPp12SK6sV6SzTjgE81+7H2BD1IbM0swEsQSMzyt7oK5LXEnP/AA74PhWp xHnfJuB0aKnZyNlGVbc1OVOhS6SdSs0ka2lnIj/ZrCKZyVEIp1bF7H+N2JUb41bTK3P6MItcy5WH4Hiw+lGMXb+EBh8m+HEYwKnIhMGiuXYTGwWUTkZ79nUtl0Tl1li5IklUCcYpEmCuoXs8Zoj6j+VVZ25fxyIJ24VWsdbq3q/Pej0kmX6fJviUV5I0SvIbaYbSZ+ymCeLGlXJJFI59mpLy5Ja6ix1Y4mTvSplP5D70otKVsVOZbyX42Tljj9CvjI6H74Ktiyf9VeEnN5EFITWQkfVsW1tO3m3dkzkdqfmycntQTxKyuufI PjVXsRX6FnnWft4d0tTk3IGA0WkBguJBAnUnxbO8qdYxOl5JFeTnWjY+MVphZ4HRgxkdT9ICqSVTx+jPTpDn1vkdu/Xiu3/ZrQdLzwOFbWWEjmy5zjEtG/ZoTcD5IlsQWI51ztcKn2Yezw7nHsfWOKWQ8vmXq81KWS9ensJbdmRx4HToGVB6abcdqzHklyxIaXdngyt3K0+PFSsCXj8vcvO5kGVrHIfPfqxZL1SFu9LnXoKtpbvFlZoomJMP0B0bnNJIMkT8L5SWerdjnGXqVa/W6PxGehNFx6QMfK5yhfCJbVqSEQdTl9at d58tAbxSVO0YmJs8GwqRh2PoGZTS7EkIgspbTrVeosVVj7w9yNEqWZg6JPFQ4tLgrbd57LsWOvrs46RyA0KLZz7n6QodVJUySOOVOlxf0W0GAUnOikiwcjq1aEtvpTXvsBIz3Hz3HwSvnutnu4JBiyqpg7PTr5X+R0miheK3eW0gy/er0oLN2e6XdnIHqkJc/Zv08vSrNNAed1wMiljlQgEdDhkEE5L/AHRKciZtQCd/xjeKI5JCrgC3ahezYluzyuXIUkwVS5r885reEEfYDrA5OKrbodGSJqtuOymdXjraE/uxSFt4T9+v vjlkjLzRuPL+qxsxrU2Jq0lAjgVR/jPU4fT6emf4xNYsyjBJsV7s0L0uokozp8yC/DNDJC2s19ms1ms1ms1mtZrAuBTsRk4leRhRoOTXoqoVFUDC2Hf0GbzeDeJE7GKFsYKuLYkibm9kajkSVLFZHexz5YM9oadCPtA3gU7CHFiOe1vPZxKrNkHMd8g5AGJRgUJCiZrCcJzWAHCNZrFXeCJTgQKVPjnuscWMuTABntlTS6MleSw6yz8r25B360HIkil93CBvxIwAa8d4qYIfSOHYFfI4EGJTWQQc9VyOJUH02MLYWwvgh9PA AFdlY1x1C4jEYF3ixbKwZ+vIMaNgBG+NHvIp5oc5lhEs/Nv+6IL7ntkkxkYFxYCcWq+JVl0sbApE5xKvka8QQADN4WwthbC4GNLjS5HN4j9hcLgnyOwd5oZBESsUfqkaDPEadU1tRjeBwqpB/oegGv06v9rP65XFrhsFAlq9EDEqIMEEYBqxbEKjBGowADP8YThcDGlGPYGNPvGkOF/prAMTRxVXI4AxjjCjWBznu+Ky2HJUSPiwsMERONX3ktYiCi2rDVQClcApCMVQuD67zYwuBjTgY9nGsMcMhOFjhOFsLfQ4MiPqhUZG d4gLYIxhg3i1t49dc9kjI4jixLnsjJYgK9c6fwBHgowgDNjPPWCQZ7mF8aTGcnGLY3+d5vC2FsJwn6BScAIxBiL6RK24/IBV3ij0GeG8MWLHrFGAHLH/APNCSFjO4S2M+NIcMme5nuZ5k5vDvGxjhbCcP0P0/9oACAECAgY/APgmETJg5ZCRLPnROhJwAc9hjkHdUIyuqkUQIGp6XzWls9g6TpJbUmcPknObKQ9rV5pwRkrha2wdlIgSIm3puCFAyiZsCCL1KETdlAmBIiCDHjmgPyAU5aamIDFToQaGL0qEKOTLVKjkOoiQ t904FU9nUYgSBibg9LIjTUz1CfBRDP1B+SmL+luICmRHTWJiOMV1WAfzldaWPpZsf6K06w/wJbkeWyUDhUP8AxqtfbFrx+yEokiUUB3KSzTiuxrngrtz3plA6ZfQoiUWkE0j0FSPbk5jTinKJBbFRfLePkpS9xpyVSu5MUjOVOWwQFseSAGG6YyAKPcnOIiMVp7ZbtYyasj9lQ6uSZiADYXRHtkVUtxQAq9Sc925cjNAB2yTAen8Uwo1yukdQxRBsaELRA0PqNvJCJpLtgDywO7ljgmQlg9/b/shQDlsEgA4wOK/YYEdsWfE 5IPTUNO7J2MagroNB+JsqLV3B+yWHt+SMGiI4ADJAhnBcLT3BpJsRbcMA/FOgRfLBZEXHhLr7rpsqSpkU0gOYortz2OjOIJMcCokgRjIGyEeSZMzEBgUxoRYppX/AL7HAoqkBaQHIvLJYT1XK1dov/EpjEjmFZULcMFQkcitRmeRWirS9QjipREZwMfxlbyX7DTaxD80xgKr3wzxHNOLFOFQGWvLNCPz21AVYR+S9EVq7WF4/ZGjFapDpj/plkPDRGXb84fZOKEXCa0stw8og8U0WAHioqpx0y9w/wAppdMsCLHkmnRsU8S7 eO+4smkHCcPOOeI5qY4hV2W3lBsIUhy+CO6//9oACAEDAgY/APgnJ05Ii7ZJkQ2wHMsqgoMCiDRk+z1BwHZO1EwyQPuwVirLS/BCoGl78VIA6ahkSM1JpM7VT4Ooh8XdRrmCjWgDBEjFMSmyRk8TqwN3QL/i2niibdJUTzfgSognVcE81S5LeQsncXf+itWksm+AD8xz2CY82+AcYLR3De0vuiJVdExTGmxxQYKo+W9EZjVHPEIGJeJVPULKIkKYpo24oAh2opAYHeNcmijH2ivNOAnNSKbJTPIcSic91QEoRES/FapDVPDg rNzTvqI+iJahqqB0SaNQDLd9LO1l1MdjlOUMCLJ5YWC1/j3C/I7uEQNDVoKHzTpvpmnvzTlM9DktGoa+GSIAfT1fLdxh7a/NVThdQ81Vae2f1jE3khMEmWJJzVbEEFP26t+J8dFUsU3FlIEPEUBxDJ7g2PhBCr9EHvmFZyqOPqvdyVQUAmkacEWRPAp8UZO+ouY808eqJuCtUajEYjY0jXkqAlOS0ZWiPurmGiwWnujT/IW808ZAjMFXXUH44qp+YTN5hOwfAyWbr9dydrgseCBEzRBujue3A/8AFNIW+iqhqkI/rzyRkLWH LZQqkpDzVO5P5r/6S81p7zB7St80KuEw9crJ7k3dcfBUoR7prh3P/SaVQbHA8lqHVH+3PcNCRAyTzLk+GiqqJiNcDeJ/6nBEx64m4NxwITwD/wAUBOJiSHAKy2tst4MlmnHg1ROk8FVoTywPJduWcFTdN4Knb2T/AB3VUPH2OX+N1//aAAgBAQEGPwD/AGp0y/2IhqkAw1cAt+uvoxtV+nvo83QujlfSeHXRGydXhcatKMGCNexW4vQmh27NGcQxKrcdQYgmjHIpV1NmUixBqLboCdbDVa1wnxHHkKVoYtG10qite93tc343 rzoNuWjOTEqt+zURemjkUo6mzKwsQegrKiyL5THSwDC9151NDAhZzK4RFHJjkKM08BWMZsCrW7dJNq+s8s/TA2MlxbPTle+dPukjJgjNnkuAAR2nroybaAugw1XVR7CxF6MO4QxyDNTU25O02xk2zRxpeO+oGwu2OdfbikSLIGiln0qBeN9Wq/8AlqMwIqRvCjAKAo718cOgAYk4AVEs0I3G8lF2JAJ68TkOHXTbyAJttyhwQ6UdyM1sPFhka8vbRmR8yBwHWTgKH1URjDZHBlPtUkdDRyIuty4EthqU8DfPCt7DuYlZ4ksQ wDaWBIwvSxQoZJG8KjE15m4gKJ+4EMB26SbV9Z5Z+nvbzLi1727aTdSRlYJLBHwsbi4/Kts+4j0RzMpTVbvLccL9dRJFGsa+SGIUBcSzDh2VvYwe+yoV9msfrUyfdQw02CAarhgTqvprY7eFCkc7KJLktm4Xiajg2xCQxqp0WFnvfDLK2FRSqLNLH3+sqbX91bd4m0sZFUn+ljpI91RbGR//AFiYzpwwLYE39tQ7fasI4kjVtOkENiRbLKwrbzgWeVDr/wCm1vzpYYVLyN4VGZsL1JFKumRI2DKeButbj6IIZNcuppASiprx OGNfcI5d6N7II2LqANMWpW7oxOdq3v2tji6l478yNJ9x01tdj4Zdwdcg428ZB7CQKgabdx/b9ouMbKPmuMc8QMc62jA3JRseYuLfnU+y0XM7q4e+WjqoIkRw2w299XxrfS+XXlUTBNHlRJFYm99HHohd/CsiluwEXrbSSX8lkCk/8rkt/BhW63WyRiYUchiXFnVNQwapt5t7ee74ta9u8EHuFbz6w62guUkIt4FDjLj0DcpnHMCRzXWAw9oqX7jAQY91AL9ZGTe0Vv8AeKoaaJO6OpVL29pFbva75vNjK5kAW1XBGAFfcPt+ bAeZGvNiMP8AuUV/+ZHjJtxBe3AX03/yg0kKeHbIoA4aj3vytWBuFjQD23b9aXcRd63ddDkynMV9XJtT9TmQUBOrnnp9tJOieUIcIhe7Z3uain3+3J3UIwsuoE/045dRyozsNKgaY0/aoqOW1/LZXtz0m9Rz7VHXdggs7C1lUHDxHG9RSfctuW3MIwIXUCerEe40ZtOiNRpjQ5hevrNRblBcxte3MZEe0U+628DHeSLY3UKT1M18qeecF0mBDlfECTqvW42+2glWKcHW4sSWYEZM2QvUe5YEotw6rmVYW6qEsYZYkUKitYHm TgTxNbeDfwu8m1ChFXJtA0jG4zGdbdoUeN4wQ4YC3et4SDw9DaGCEQa4tTIFEbYnAsB0Jtfu0Jk8uwWQDVe2ROIIPZUmy+27fQkilWYgKLOLEgDEntqTZ7yPzdrKb4ANYnA3B4YUft/2yIxwufmMRbDqxJN7Yk9DfbtL+cz6g1hotqDZ3v8AwptruVdwL+UyAGwbMG5HGn8xTJt5gBIozwyIv21LF9qhKSzg6ntpC39pOF8BkK86QM0TIUcLYtjiMyOIrdbuRJDBuFUKqgagY7BbgtbK/Gn3TglHk1lTj3L+H3Usmyh8iIIF ZNKx3a7G9kJGRHqpkmcyOcCzG5w/3KRLhGhxBOdqLQWljXNydOXbRUixGBH+Aa2Gp/gFOv3F9KR20RKLeYeGIpW3ltrEbFIri7AZXIp02u21mMDVMMAtvz/wHSwyxvVppC6xf2xcgChtwnmOTaJ7Z3wxpl3C6HbHqx9fwq4wNEOLrypURdMSnKgkoBwwYeJTVm78Z8EgyP8AgABz51qAxFC/hOYorIA6P4ozRbYt5TjER5qT20Yp0KOOeXv9AfFI2S/qa8uM6N2xsq2uDRLQFgouSK0s+hxhpNYY+r6W9hrka+U1iMq07vGN zYkcKKOBIuYHEe2tIN428B6LoNUjYRrzNLu5nDl8XF8VvQ0+08qhil7y2sVIppPt3cdcWTtxponBEsRswPrFjiORotey8aK5nhQDXZBmaCOwDr4WGYpm2s2uVfgIsD7ag28oKNGSG6iakimbxWsQdWFK8c3myW7wOGPKnjEQiVMCc/bWonW6/wBuXK4OYIqaVRZpSCwGWHrIj/diakLNqAy6BJE2llxwNQbiXxyg39htU25YjzJz3PZRZhrbhetanSTwFaSblrC3OoPMI1z3+UD4B2irA3tx9Wv0CJc8z1AU5jxUYD2Vbic6 IdtK18xTJzxsK1gBY410oB11qbncDlQru4twoIx0tfA86VZGLPbjjYesLDENUjYCnXVfdOO8eV6tzxq1fL7sY8UhwtQVchmT8RpGOARu9+leYcyMquMBR0486DPifhFXPqmP8BesD1UJ3jIjOIPbXnOTHAMjxbsFNNouw8LE4k9VedLLpkGS24V3pbddBm+aw40Gia5tiowpjuTZh4VrcQrN5xYgoLabWoWF+Huq2NuNJHHi0ma0UfMeqnyolF/ET3iffTeTAqhiD7atJYi2XClQRXjGFhhai57oHgTlRvn0XJtahIDogvge LVql8J8Bq5HdIII7aaJh8tzeNuBvWWJwFfW7nCZ7eUn7RUcxHclGBrEeqBInLyHJMq0tZXXxC9aS1PfGwvWqM3NzevLly4NV79lNv/uknlbZReOL4nPCnl3a6dp/9ckWJFeVJgRijcjTJKLSLhbqryp01rwPEUszN5qrisZ50TbE5DkBQ2lw3lCx6iaaI/CcPVCUQD9vVUyeWYUTxg43q4NPrPdAP5U8Q7sxJMf9WNNGyaNwvw1/7MujfyX8m4voIyp979/fXHtsYgTZLZ3tlT7mST6D7PECqG3fnIyAXOl+qbR5pP0wbAso 7a1JhOmR5itca3cZrWpRp5pyNdzGeTBf6a8wG9z3+u9CZcBIL+qO6AGWUXjB5ik3u6gMSSXGsfFbCu7ajt42ux8ZHCgwyBvSsrWnQYMM6bbzjyt9H/bb99N9n3TaJkI8kn4rHI0Nz90kEku2X5e1FlSMAceBvURgUxGFu9PewUA5AU0ULnVEACSLaudFou8D4xTTabE88L0WlGpmyPACrDjUc6m7LfUOr1RQn+gw/wC41HtZkDIUAZT140+42btJscyg8Ufb1Vjnxohhga8yBrcxwNKZPk7lMmFLu4jqkj8TDM27KLtqMxwd bnv2pIdHlIDcAHGhdQrWAsLDLro2Gp+ZyFFkfujC/CkvOEK9V6+XOJG5HCn224j0q3he9xWuRLp+4Y/l6jiCO0dCxH/UIJ7Fx6CrAFTgQcQRTb37WuGLSbccOJK0VIsRgQejVGDerhe6fEpxvRlA0FuHKmIksx41ZpyQaNmJJwvetqBgzLqJ6zVr3rLHjQ1DCjoxU5g40dxtU+WcXQfDVjgev8UKouxwAFLLvFu5xCUPK2yyxR+IAgEUcLDlXnbklQzWRxmtKHYNq8EoPdf+XS+82ChN2MWjGCy/8aZN0hEim2k4ZVZbAVn0 Z1gaHHEGtqyMANAHtFYygdtaY/mnqq5h1DtoRKhBPtFXe16+ZGA/7xhRO3mDclIoloiy8xjVnUqesW/AtDGX6wKCNEV5nhS7hvmMcweFFlNrUJY5vlPe9sQfZRY8aihHw3YntqxvLt28cRP5cqVon83b/F++LqNBlN1OR6C62i3ajuSgeLqan226QpInuI5g+k23t3o/Cb86798ON6shtVicKKxrplObVonfu8DXcl9lBZTh+6rgg15e5RdXM1r2smj+IokJ5iD4lP6VZlIPIjpVpFLJxFDaDbtBOcA+JBoQBtdiTqtaomhs m2LATy8Rc4Co9J1KyjH2UwnxSxwqVdJEMl7Em9ujRKodR7682El0+IcVoTbZyrDMcCOsVpWyT/FtycG61JrUhxHiXiOjRONMyj5cw8S/zFGKddUR/tyjwsPQCxoWJ5ChPKNEdu8t8T7KeKxj2MNzLI2F7cMaK7ePydqhtf8AfblWl17o8NsxVx3lHvrCrZVcGu65woMWswoB+HGgrkAmruquDxsK/sDHrrWNuCBnjXliJNQ4VfboqsOQAoyyd2IZipYPueqGM4wixzGRvWgNrl25sBxK3woBvEeFWY4qcOvp7eFGbbDDNo+X ZQYXR1OByIpId62iYYJPwPCzCtJIWTit7+49D7bcoHjcW6weYptbk7Yn5cii9x10CzNJ/CgfI1EczWiJFjUchQZF13NDY7saZnwIQacR2UEQX2w8Dfz6Lg2NY91uYq4s3WDWVZGsjWWFXUkGtM4JX94Na9vIG5jIijJGS0QxZRjhQYag1+RovIbq4FhxpWEWsKbqpy9tfS7yENqFtJH61uN073WTwofhHKjuCNMTHBeVX9w9G0qBx1jGsYiB1GhEuow8LnFfbSrI1wfDJz7egxyKGRsCDR3MALwHxJxSrrlVqDx5DxUFk2Qa U3+ff9KkcnTFki8/QwNeI++vEffWd6yHurFR7q8ArUAUPNTQMUvnqP8AScC/voNuYBFLxWwvR3JcDbJbTH11ZLaeAozzEFvhXiTTT7k2jHgi5VjgBkOjD0bVYV3TdD4lryydSjNT4loPGdSmrEXBzFNPsuOLQ/yohhpYYEGmjJ0hxa9ESkBeDc6CqLIuX4mFI7mzrx4Htq6kgHkaWzkgcKEspuF8K8Fqw8Iyq1saBIxq9ujH0QKDqdLDI0LnS/EHJ6uuDjxJxHQZtufL3HHk9NFMpR1NiDXP8fum45GhqQhhxFaUvbiasBQu KFxjWXRj6VqyoG5sMmHClSUgMfC/Buhg6gSgdyQZg0VcWsSAez8PDpxq9YCsFNXYY0C2dYdGXpYdGPRdMV4rQjkxQe9KDxsGU5EVLt5h4SdLdtFgNUQ+IdHV6VqwFZVl0YCsVoFhQGkVgPR51jn0Dl6FhWJrA3oMpswodeanJqadMBIBcdlbiFwGFxqB5EUjqSybgnRFyIoKY9JOfeB09tEdNqtVxVyOjGsBQrAenfMV3RWI6OurVehWArAV11e1Yigrd9Pyom48uYZ9dbBrX77fpVimoG5tRFrYnotasBWC1crhVrV4ava1 Zfg2NWt0YcOi/Ho73oW6e6bDiKVXks23xQHPrqO2AsaOFZY1lXeFZVa1arVgPSzrP8DCr9NquaOGFX4VjjWArKpDbJTUTcLke817KyrL8HD8HDpwoYdGFY1lWArHpkv+1vypMcn/APlSnqH4OH4o6LdFvQx6ZeehvyoEZhx/5VGeaj8vUv/Z --mc0p4Jq0M:2Yt08jU534c0p=========== Content-Type: APLICATION/OCTET-STREAM;name="tt_ultimo.gif" Content-Transfer-Encoding: Base64 Content-ID: <320333313@17092002-0802> R0lGODlhRAAyAPcAABAfjRIgjhYkkRYkkBknkhwpkx4qlB8rlCEtlSIvliMvlyIuliMwlyQxliQwliYymCczmCcymC04mzhDoDlEoT5JokZQpkhSp0pUqFFbqVRdqlZfrFVgq2FpsXh/wHqBwXuBwXqBwHyDwX2Dwn2Ew3+Fw36FwoCGw4CHw4CGwoCHxIKIw4SLwoGIxIOJxYKJxIOKxYSKxYWLxYSLxYWLxoSKxoaMxoaNxoeNx4eMx4eOx4WMxYmPx4mPyYqPyYqPyIqQx4uRxYqQyYuQyIuSyY2TyY6TyYyRyY+UyY+V yo+WypGXypKWy5KXzJKYy5OZzJSZzJSazJWazJabzZedzZeczpmezZidz5mezpqfz5qfzZ2hz56iz5yh0J+j0J6j0Z+k0aGm0qOn06Cl0qKo06So06Wo1KWq1Kaq1Kar1aes1ais1ait1ais1qmu1qyw166z166y162x2K6x2K6y2a+z2a2y2K+02bG117C02bK12bK22bK32bG12rO32rO227S42re727W52be73LS43Le83Lm827i73Lm93bq+3ru/37q+3Ly/37y/3b3B3r3A377B377D373B3b/D4L7B4MDE38LE38DD 4MHD4cHE4cPF4sLG4sTH4sXI48bJ48fJ48bI48fL48fK5MnM48jL5MnM5cvN5cvO5szO5szP587R59DS59DT6NLT6NPV6dPW6dLU6dTW6dTX6dTW6tXX6tbX6tbY69bY6tjZ69nb69jb7NjZ7Nrc7drd7d3f7d7f7t7h7t/i8ODh7+Hh7+Hi7uDi7uHk7+Hj8OLj8eLk8OPm8uTl8efn8+Xm8efo8+fq8+rr8+jq8+nq9Orr9ejq9Ovs9Ozt9e3u9e3u9u7v9u7u9u/w9u/w9/Dw9vDx9/Dy9/Lz+fPz+PHy+PP0+fP0+vT0 +PX1+fT0+fX1+vT1+vX2+/b2+vb3+/j3/Pf4/Pj4+/n5/Pj5/Pr6/Pv7/fr7/fr5/fv8/fz8/f39/f39/v3+//7+/v7+//////7///3+/iH5BAkAAP0ALAAAAABEADIAAAj+APsJHNitA4IHCBMqXMiw4YMEFD4IwUGxosWLFWXQuTewY8eCBx2KHPkw4kSMKC3S2OixJUiSMBlClJiyJo6VHFt+NBizJ8KZJ21ixKlzZ0ifMIEKRUm0qMCXSJOaXDqUpdN+UKOOVEpVpVWnWbU65NqVYlOwHRZAWMt2bQSSEdq2ZTC1rNmv RbNxACCgr18BAwgkEMmAwIC/fgNI8BD0Io0SkCNHHtHG3tV+7wRRscK5s5UtQSosaLhgAostnjtrcaIjB9MrmkR9+uTJ0+xPnXLtu9xvX77fwIEb23CgoQEMsoIrTzbFBUoXbdTxm069Ou/LxDQUZ2jgwiunyKL+OMfoIg266+hbZt++sPv3ouHHXyx/Pr39fuuNewcv/rn5+/blx91+8PVH3n8AoidgewTqFJ9/9SXI24IKuceffBbRJ+F1FCZkYYEYVqThhthpp997Dho4H4IkOtUhQh+mGCJFI7ZY1IsPxNjSgwdGaKN6 Jg6I4o4qZsjijx7hqKNHPK7oI5IDKdkgkTPiUCOUUQbJ4JBMFinikVjip2WFU3ZZ5ZVhSsllR00a+SSWal4IYZgdxQninHQKVEwGBSjg558KEGCBK04d44QKNCSqKA0qnJFOnnry2YADDjRgaQMFDFroEyvY4OmnNqyAxptQlmNJHHvooccerO4BhyP/3Dh1ji6uzGLrrbO4Esw8kPbq66/ABivssMSSyE8+/BS1DzrfQPqPOeIkiAsezRTFDBeqQJqMF60AyA8jHrCi0zyUgMBKPv3MM88958gjEDzgpJNTPvD4No46HdEz zji89kOPISXEgq5A7IATj0fskjMwP5e0IItA+aQDDjz9rPJFDWjw0o8rnphyRi39QHNIGW6csk4/2DCSCylm7KGMQNlggkYamUQbDBUypOFLP/fwkgcZgzAzEDmkrKGGKScz7HA/66DiRhmHQBMIETQU0Qk/crxQhAuoyOOFCF40YYO4v9iwRBdZmBCGPPIMwsMZX4DQSD+szGCDEaP0s4sR/jxgcUIV1vTjTiItLIEECpcg2/DDpvAABhopsLHNICtwwu8fJCDCyzrvJAIKPKy4oEg/whChxDLYTEEENtxkIcUw23xCSz/j 7BGDJ+asY4YNsFwDiQmD9BMMD2MsgwwWOlTTT8O07JPHDa2Yo0q2nahgSz/y9CFDMgO9c8skYcQwujA6xCGQGj5I084bJ3RBiCoU61NJDLr0swwSYrTTTzlDYDFPKicohUAmYYJVLM9h/sgECp5Ah06Aox+aUAGh5FEHIDhDIPWoQxG2gAYcjO8GfsjHPtjgA2r0Yxp+4IEIbFCHe+TDETG43jCIMId3pIsJT3iHKFwgrn6UwgSi/jjgw8aRiSSMAAZlgGALdoG9OhDhgv3QRQneII6yJYJ0IBThGtK3j2owIxqtYMIOrPFC GeSiH9FoQhb0dw0beGEfrEjBJgRSCBPgQoj98EYzoNGLMNCgH5woASK0cY87PFEgqxCBHMBxiBE8Aosh3McWp+ENL0ABGNa4gg28kQ9IoEAR3LhHHE6ACF+cgQSf6IczkoAEVZxCCEsoh9JocY8/8GAV5niDC/rRixXMABD4uIMFBSIOKNRACVQogh3kEYwd8EGEbOABNfiBih/0YAgxiAQ/9mGLFbgAEf2QhhdkkAMXzIFX+VAFNl1whFxMZxIoiAUvo3ADI8QADukCSoQOBBiLSjxQIMtYQhiqwYpQrGMbkqjFPvixikmE ozexeAIQRjGwePQBCNnqRzbYcANH5KQ3snDCFICxm374YhHPAOgXaBAIdwQEADs= --mc0p4Jq0M:2Yt08jU534c0p=========== Content-Type: APLICATION/OCTET-STREAM;name="sun_strategic_dv1.gif" Content-Transfer-Encoding: Base64 Content-ID: <320333313@17092002-0803> R0lGODlhUQBLAKIAAP///8zMzJmZmWZmZjMzMwAAAAAAAAAAACH5BAkAAAAALAAAAABRAEsAAAj+AAEIHEiwoEGCAQIIWMhwYcIAByNKnEixYkQBBDIW2MixY4GMAyBaHEmyZIABHlOq5JiwpMuXAzGunLkyJMybFAMQoMmzJs6fBQX0HLpSAFCcOokqTTng6MsAS6N6JCDSaUWhUrOytEoRq9avVbkWhPq1bIGwYgGQNVs27cCkbMs2dYsyrlmjYr3aLYv259q9ZQlw1QsYrFWeGgsjdkp4qtq/NOuyxYuUJoGmEOEWVahw p1ygjTkOMBoS88yEHAFI/grUc0qqLY0K6MwUQEfNX+fCxM2R6uzZAGSj9mi0I1bXrzuu7lj59eOHnRPORm7a+PAC07EH3yhSJc7Ggh/+Dpi7MLha5IK3byxPFvblzFQJFE/Zd+RywbNbqg6p8LH69QKhNJ5gnjUlwID77XSdcjch91FmEBmVUWzSQSaSRgLtRJVqO9mkoWoqpfeSSr9x1l+F/TmYnlDVpbdVXRA5uJGILq2EX0LhKeQQAAW6htdZIG54nFozEhlifRXNhJlDLY0G4nquhQfkRh5eRhp3wV3mHEw0GRUhiqtp 1lRG2403G3b8aRhhaECO2KV5D8nU25NnsRjcgUDqZGCRag0gY5s18kSaecsVYOBsdaXnWYaGwqXoeFu6KehjliUWolY0lkSUhDNplJGGH804o5YdevbnRw2y9Z6Z43U23mj/C10GK0NahnhToVKBlNGBVr56mayy+qklrtrBxGZgvX1EaqiWhqoSklcpVhhSp0qb60/VWrsUZcZqyxZQkHkblW44EStuT9Bqem5UmX637rZcZfvunFyZO+9WYtk7L7fx3qsSuWLxpqRBaBU81sFuxdQTvwk3fOyGDUdMEJsSVzyxg+laHLBr ACOs8WBYRuQZjp+eJyBB7/EoLEQDppfUXH4KdJKhN+mEJEoHCiSTh6O1idKKAkpoZYa/xpiegPLVLBFKYcWc4Zk/ovSWzyJCVZDTl0VMlm5O87gokXoO1KZnshWQZYw2FdvwzDCLqKVIQmHk8tiwEbmd0AKp7RZ88Ee7zWuAhuIMNtEtQRWSdmTa5hvDR7kmUtfyQRWjzFnbduGLqXEodshpPfRWVYVn9rl/Mnte+uinf6z66qy37nrCOlV+3oQ2n8cySMGRGztln8KNu9dJW8XihESOhpqXU0ae99Q9z2WoUCyf5XzPGZMk FJHIV0Wm02rrNJDUXmcIkXZd21Yc493mLWWxGEH14659DlR54oED+fP7xDNmtuLYi+R+m9ipyv7CR8CP2IRDhQsV+rqlkDydxX/KEhtwBrcdHM0FYgEKT95iBzIAGalYO6GMaP5znhl1h1uJyttC9AaujOnHY2MJC5L895aAAAA= --mc0p4Jq0M:2Yt08jU534c0p=========== Content-Type: APLICATION/OCTET-STREAM;name="ibm_member_par.gif" Content-Transfer-Encoding: Base64 Content-ID: <320333313@17092002-0804> R0lGODlheABBAMQAANTX246fz7a2tn2QxJio1JGqy2Z/vHR/mYmPnJakyHeLs5GgwOzv9ysuNJqoyBweI5inyJmw0EdKVGltd46cyIiYw4KVvJ2ry7bA2bC81aazzqGvzau30v///wAAAGZ+yiH5BAkAAP0ALAAAAAB4AEEAAAj+ADFgyJCBg8GDCAsiXGhQg8OHDjdInEjxgsWLFxxodHDRAYSPEBKIDEmBwgIKFVKqrGByZUqUKS2stECzpkybNStYUKDApkCGCxUCbcgBolGKSDFa3MhxKciQIhMQqGDgg9WrWLNq3cq1 a9afQ8MuNHoUaVKMGzNm1AgyqkiqXuPKnYtVIMG7ePMSFFu0KFmzZ5Uy/ej2bVW6iBPXFciYsV68YTX4JasBsESlaNkm8LggKlzFoOk2bvwYsljKDwFb3IB5rYMEC153Nhy6dtzRdkvf5duQsuWJmDlyFjl7gQXbyLnizv2Y99iyllszfQ0b9oIKybMvxq3b9GmyF6L+B9e49ilt7dmXMy/NF3Xl36wFl4fgceRn9MjVZ1ifl6HQ3n9FV9l4HtEX0kf34VebXRM0oIFACzRwgG4LOSABAgqhBl+EEiSAVkb0aYbgYQouiAEH EnhwgEATeDABBxk4BKNkGzhQlI0OPHCARJJp4MACG1TWFEULLGARAi4KVuBGbSWYFQNQRvlBlFQSYBWVAWBFQJQAePVTihKcmOIEGRzQgARkTiCBBA2o+cAEOa4pwQIamNnmBgegicBEDbZ5QQMuQpDZRwU2SaJWBASgqKIfJLqoogRY+aiVVg3gKKNdfQkoBw400CaSbeo4JqASPOCBBg9IYOacHqj6AAL/Lb4qEQJvHuBiiwc05RpbB3p26FccRErQBycKWxABHHxAUKTJXhUsAQV5eWKoBzSIZotnuugpBgc8kACSqK6I qwfZoimrRBM8AKOnCzwAZEeDEearVwEA0OVVBNhrVb0ADGCVvQAw8MEADAAs109tlqrqBG4i4LCFDXDr4AKnSsitihIecACsDXDAZ8cZlNruu0vFC9V5XP1qlcpdsazctBNc4MEDIU9gqwO25hmxmRpQjOqLnlrgLq4NZjCRAipSPIHQJJfM68kJOJlVAFD6a1UGVEKZ5cBZZ32wmBNgcCYGDIs9swQhh5lnzw9o0ICp7mrQIrkc5Gn0ZemSq4EF/g00LdzTbkmd1QBWX0X44YQb7u/hlRae6XL7DYQBRwT9tJ9BJ564AFEQ WNDX3RNpAJvHF3BAYKEnC264vvgKBDAG935g7wCMcRAA7F9DPtB+/X0nI0SAvdfarm3N2xXtGGB1e/IDC3SVQANEnqjzVxlg/VeQd8ebe+JJx6S8KHOVOFbjD1x44gEwXv4H1v+qn/a+B9h9ZmwVGLjLU3rdtZRYTtklB1xaWQDc9z72tEdDqhmea4oXvhJlCgAawN5oCsK75hxQfmbRFf2eljr8MaADVMofCKNEqREyIEsFM8CWoHSvDWBga88roAUjg8D5bZCBUcOfA2+TPQrFD4OB/tkgr+63w9CoZ3fs+Q9DUBOjIBVl AwZRIEdY85QIXCCHRQQNgzx1pgUgUS8cQICNgCKZyTgEAXdqUJr6Fh+0bKBBCvCIAyqApjnqMItb+ZIH9jizDQhlL0WhGNqM0pDwREQitpKA21q1gQc8AESCugBUNpCiXInEAq26gOrw+DIUPUAglUxXm8K4plTNLE+lnEDPStUABEBgTWd6mwP22MpULYCVubLWmlRkAYVlcpOc1ApBNFBJWqXqAW+71cyypaM9OtIDaCSXI201MzW5SJqVNFWpVJSiVlUyRcmUgCbvGMyrDLObtERjMhkGTR+5CFV9s1XePOUiRyqAAKK8 /6apbPUAAiQSnBeo5MwWgCRxArOc5hSTihDguViNqUUOyMAsJ7ABcl0sXchck60aEIECdGtmmCQX0hrgT2+6CEUqIte3fklOhMLIkzbaz5j2yM4FSHRmtOJozkyVN2x1NACAakAFSEUAbQLKmhMgQCVJRapxIvRrniwdi2jZqhbZ9AI8RWYEckbNVgmNowVQaqsSUMmS0pICYxLrAZBGLpY+lYeuk5xANuDFn5yoIBpQwAUy0NEIcKAAESCAAhbQ144WgAKRglSiFtuTAFAgAIl6bABYQgELREADV1zAR4rE2c56lrMluY5K SgKTnKiEJqfFCU0YowEErCg3u+sLjP5wprEDEPYCBcitbneb26iURGMViKxjSUvalUyWAm75rHI9C5ProES1qIVuBXoCXcbkbYKRO1GQKMZHHXksAuAFrGHDe5EECE0CwYXscBdFAOJCNiWOJcCBQrJc5qKkuDzhCU16ot+dyIS6/KVuTQSyyIghYE1evIDGJGDZvXk1Vhm4paoKwLCT2AxnaLrAV4OrpglUIAE20yhi1cTgANjMZgdGk0nqW6Ti6oS//1XAi1/83xr7FycCQdIeu+oBC+gYmpfFpAT8elRA7ZFNHlDAP7vb LgY/k1zt4qOK5jazCpiKXEZ+k3WWa5LnApjG071JT6YrY/+GGcdTxYCpCP5KLiQ9QAGAdfCQMxBUKNOUmyraJ6C6haZWQWDPplJAi7q5y4+yM1Vn+lF9K6vaMMekzGPur37765OpZmBmEHybPDkAXjkThKfd1ZEphRrqdBW6pN0i6UalLOp+KiCZb7pAfXVSkzH7t7K2znWt9yvgAU+VA/tMdSI5HeRWweqU5GJTAwJKU6EhWkKpAlOe8qyjQZ+NTQpwZABW1c0AbJmzOkktSsY8YxrvF7q9pgnyMJCi1kp5ra3i9HZZbVtA aTMDc8ttiuA2UqHxUQIBuPLMFLBvkM5s23AjV0o4i1px05ol5Tbzjc19Y5usm677WUC1LMAaBNBJRhtwmMMI2/+zah3gApiliUNwZrPg0gQCFTA5YZFZLQUkgALVmoACAsCTkgjaZjKBuEyeK5Mi1aQkO4E4T1Sy9HPvWrWQcwh4p37ZqlNdt1OXugY6rQEC3Hy4j0Uu2Ivaz/ua3SUpIVwFCKeAAfTkuRUoEq1PQmamy/jF1CXz03GybscQm+oRCJLVpy5ewAee6heQr7cV9djIlsTEExjuaCeL9rWvXb9up0mXd0JaM4/7 7mBOSa/TrW7cDIjqQZLI4MF7gcMjfgNVx+wGILB4x6rXvWCffOUJtxO157cktMZv3EVvgdKSe8a1prXFR+Mxs0QEeBAJvOpZQxHMSpL2CYAKYm3/KOL+ktaxL1n7AFDr9razPe9yRy1Mju9oWqeb9Kv1e2/MWEYA+YZHSYnUBrwuEv4XZlEJYHuOghID8BIUwHYVkD5ux3t4hxOUthMABoH5NYEUGH92UX8HAREIwT2hAxxbBwGREoKR8n/dB4COVYCUJX4oeIDmx3sPCIE28YIUOIP5ZYEnMhSERH/Q8R7AEYJSIYIkqCgB OFxD91gqqIKIczgyqFrvF2D8ZQA0uG6AhIP15x7Px4OsAYSRAoIj6BZCqCg6IVngNwBhhzhIuIC8B4MO2IQSSIM1KHIOU1tyOId0WId2eId4qDEMI4cMYzN62IcnBoiCOIiEWIiG2IdSloj/iriIjNiIjviIkBiJkjiJlFiJidgmRiaJfWaJUhYq0MaJoBiKjvhJPwaJDyAAAiCKrSIAbQIAmaiKlYgAqSgAayIAB8CKE0ArAiCLtbhQ/4aKDIAkEyAALTKM5MKKDYCKgIKKOEWLM7OLzugixLiKxriKbcIAAhAh0JSN1RKN zsSL1WSLpuIwuziM6MSICNABDdABBMUAD9ABtwgAEtABEwAAstgBEgAAqTgzIAQA8DgBHYABHXBg6ogA8ggw+JiN74iN9LiODIkmATmQEvBBAHBk+AiQsMMAHhAw/sgAAolOGMCQyRiQ2LiREVkwHSBwiziP6bgAJVkwAhCM7miQ//aSjnMDkCkCABMAJfUoNgxwAPo4jwQFj+WIjx6AivPYIjrJk/q4k+g0j2jijvPYAPr4APIIlc5Ej63SAMHYKilpLxuZJ0bpiFCCilopAOwYMKk4jzLpjhnVkDrpj16Uig4QMGvikQug k9mYlFRJkGjEAPnIjhhAkOCUKhcJmABJlQLwAAygJviITOuIRgeGjToCAFaZijq5jue4iGg5jCnplQ6jlVxJix1QkQ5ziqX5j6Wpk17plrADAGKDiqhplw5pL2+ymo6Zk7kJkGW5kYvZmFBZj+7SjxJSml35kmg0lo0YKrtEU8iUN970JqSyb2yCZNLJR9Z0NnmzS6kyTyn0uE3VZG/b+TaiJCfaBCbkmVFHBp3XaVJs8iYqCYvy+YiaOZ/2mYgBAQA= --mc0p4Jq0M:2Yt08jU534c0p===========-- From drow@false.org Wed Sep 18 15:24:18 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 15:24:19 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:268 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 15:24:18 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rfk7-0005hi-00; Wed, 18 Sep 2002 09:23:51 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17reo6-0004KJ-00; Wed, 18 Sep 2002 09:23:54 -0400 Date: Wed, 18 Sep 2002 09:23:53 -0400 From: Daniel Jacobowitz To: Johannes Stezenbach Cc: "Steven J. Hill" , Stuart Hughes , Linux-MIPS Subject: Re: cannot debug multi-threaded programs with gdb/gdbserver Message-ID: <20020918132353.GA16211@nevyn.them.org> References: <3D876053.C2CD1D8C@zee2.com> <3D87653E.9030702@realitydiluted.com> <20020918121047.GA17744@convergence.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918121047.GA17744@convergence.de> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 02:10:47PM +0200, Johannes Stezenbach wrote: > Steven J. Hill wrote: > > Stuart Hughes wrote: > > > > > >Does anyone know whether there is some special setup needed on > > >gdb/gdbserver to use the multi-threaded gdbserver ?? > ... > > >binutils: Version 2.11.90.0.25 > > > > > Don't use H.J. Lu's binutils, use the released one. Use gcc-3.2 and > > binutils-2.13 as they have fixes for the MIPS debugging symbols with > > regards to DWARF. > > Is this a general recommendation to avoid H.J. Lu's binutils, or do > you just favor the newer binutils version? > What about binutils 2.13.90.0.4? > > I'm currently using gcc-2.95.4 with the Debian patches, and > binutils binutils-2.12.90.0.14, which seem to work well. > I planned to switch to gcc-3.2 but postponed it because I > read about the DWARF debugging problems. Are they solved > with gcc-3.2 / binutils-2.13 / gdb-5.3-CVS ? Yes, they are fixed. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mdharm@momenco.com Wed Sep 18 18:30:41 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 18:30:41 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:55570 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 18:30:41 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8IGUX608973 for ; Wed, 18 Sep 2002 09:30:33 -0700 From: "Matthew Dharm" To: "Linux-MIPS" Subject: RE: fs problem between 2.4.19-rc1 and tip? Date: Wed, 18 Sep 2002 09:30:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Okay... if nobody is going to report seeing a problem like this, can someone confirm that using the CVS tip their SCSI disk works? Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Matthew Dharm > Sent: Monday, September 16, 2002 2:15 PM > To: Linux-MIPS > Subject: fs problem between 2.4.19-rc1 and tip? > > > Is anyone else seeing a problem using SCSI disks (ext2 format) that > was introduced between 2.4.19-rc1 and the tip revision? > > Upon booting the 2.4.20-pre6 (tip of CVS), the root > filesystem throws > an error about an "unaligned directory entry" and then cannot find > init. > > 2.4.19-rc1 with the _same_ hardware configuration works just fine. > > Is it just me, or this this something general? > > Matt > > -- > Matthew D. Dharm Senior Software Designer > Momentum Computer Inc. 1815 Aston Ave. > Suite 107 > (760) 431-8663 X-115 Carlsbad, CA 92008-7310 > Momentum Works For You www.momenco.com > > From brian@murphy.dk Wed Sep 18 18:57:19 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 18:57:20 +0200 (CEST) Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:18239 "EHLO ubik.localnet") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 18:57:19 +0200 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g8IGvD6m010593; Wed, 18 Sep 2002 18:57:13 +0200 Message-ID: <3D88B068.6080303@murphy.dk> Date: Wed, 18 Sep 2002 18:57:12 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS CC: Matthew Dharm Subject: Re: fs problem between 2.4.19-rc1 and tip? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips Matthew Dharm wrote: >Is anyone else seeing a problem using SCSI disks (ext2 format) that >was introduced between 2.4.19-rc1 and the tip revision? > >Upon booting the 2.4.20-pre6 (tip of CVS), the root filesystem throws >an error about an "unaligned directory entry" and then cannot find >init. > > This sounds like a problem I had with cache flushing in pci.h which got triggered by a change in the ide dma driver. Is it a pci driver? If so you could try the fix I submitted a few days ago with ide-dma in the subject line. /Brian From jsun@orion.mvista.com Wed Sep 18 19:06:24 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 19:06:24 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:19698 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 19:06:24 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8IGrkx28492; Wed, 18 Sep 2002 09:53:46 -0700 Date: Wed, 18 Sep 2002 09:53:46 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [RFC] FPU context switch Message-ID: <20020918095346.T17321@mvista.com> References: <20020917110423.E17321@mvista.com> <01ad01c25ea4$435ab220$10eca8c0@grendel> <20020917164520.P17321@mvista.com> <003c01c25eee$cfb41c30$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003c01c25eee$cfb41c30$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 10:38:38AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 10:38:38AM +0200, Kevin D. Kissell wrote: > From: "Jun Sun" > > On Wed, Sep 18, 2002 at 01:44:57AM +0200, Kevin D. Kissell wrote: > > > > > > I'd much prefer something that is simple and processor-local, > > > even if it may be less optimal in some corner cases. For example, > > > Why not simply use CP0.Status.CU1 as a "dirty" bit? If it's set > > > when a process switches out, the FPU state gets saved, and CU1 > > > cleared. If it's not set when a process hits an FP instruction, > > > CU1 gets set and the context gets loaded. This involves no > > > access whatever to shared control variables, indeed, it doesn't > > > even go to memory to make the decision. It will, of course, save > > > some FP contexts that don't need saving, but it is well behaved > > > in the cases I care most about - it avoids saving/restoring FPRs > > > of code that is doing no FP whatsoever, and it ensures that > > > whenever a thread starts up, whatever CPU its on, its full > > > context is available to that CPU, no (coherent) questions asked. > > > > > > > This is basically 2) except for dirty bit difference. > > > > My current implementaion uses bit:1 in task->used_math flag for > > "dirty" bit purpose. > > Which is not a property of the CPU, but of the thread, > meaning that it will be written by one CPU and read by > another, i.e. there will be MP memory traffic and cache > interventions/invalidations/misses around the operation. > In all places the task is "current" process. Therefore no inter-processor traffic. Obiviously it is still less desriable than a bit in cpu regiters.... Jun From jsun@orion.mvista.com Wed Sep 18 19:10:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 19:10:07 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:54005 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 19:10:07 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8IGvUM28498; Wed, 18 Sep 2002 09:57:30 -0700 Date: Wed, 18 Sep 2002 09:57:30 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: [jsun@mvista.com: Re: [RFC] FPU context switch] Message-ID: <20020918095730.U17321@mvista.com> References: <20020917160425.O17321@mvista.com> <01b801c25ea7$ce074ed0$10eca8c0@grendel> <20020917171434.Q17321@mvista.com> <004101c25eef$ba035350$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <004101c25eef$ba035350$10eca8c0@grendel>; from kevink@mips.com on Wed, Sep 18, 2002 at 10:45:08AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Wed, Sep 18, 2002 at 10:45:08AM +0200, Kevin D. Kissell wrote: > From: "Jun Sun" > > On Wed, Sep 18, 2002 at 02:10:17AM +0200, Kevin D. Kissell wrote: > > > Are you able to test this stuff on a proper SMP > > > system, by the way? The efficiency of the code > > > that manipulates interprocessor control variables > > > can reasonably be expected to drop off a bit > > > in a system with MP cache invalidations blasting > > > left and right. > > > > Yes. I understand this effect. Solution 1), 2) > > and 3) don't really suffer from this problem because > > variables tested & manipulated are local - unless the > > process migrates which is a different problem. > > It's not a "different problem", Process migration causeing inter-processor memory access traffic (which should be one-time) belongs to scheduling issue. It is a different problem. > it's the heart of the > problem. If we weren't worried about SMP > behavior, we wouldn't be revisiting this stuff. > While (1) can obviously be done without any > global knowledge, as could something (2)-like > based on CPU-local state such as Status.CU1, > (2), (3) and (4), as you describe them, all depend > to some degree on shared multiprocessor variables > to determine whether to save or restore FP state. > 1), 2), 3) do not depend on global variables with shared access from multiple cpus. Please read again. Please note variables of "current" process do not cause inter-processor traffic and thus not belong to this category. Jun From lyle@zevion.com Wed Sep 18 22:08:57 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 22:08:58 +0200 (CEST) Received: from medtron.medtronic.COM ([144.15.157.122]:15529 "EHLO medtron.medtronic.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 22:08:57 +0200 Received: from RADIUM (localhost [127.0.0.1]) by medtron.medtronic.com (8.10.1/8.10.1) with SMTP id g8IK8ep13793 for ; Wed, 18 Sep 2002 15:08:40 -0500 (CDT) From: "Lyle Bainbridge" To: Subject: Mips Cross Toolchain Date: Wed, 18 Sep 2002 15:08:40 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lyle@zevion.com Precedence: bulk X-list: linux-mips Hi, Firstly, my apologies for resending this message that I sent last friday. My mail server died, so if you read this and replied I wouldn't have received any resonsed. So I am trying again... I have successfully build a mips-linux cross toolchain under RH Linux, but have really intended to be able to do it under Cygwin. I have binutils 2.13, gcc 3.2, glibc 2.2.5. Under Cywin, binutils and the first pass of gcc succeed (c compiler only). Then glibc gets a long way through but exists with the text at the end of this message. My glibc configure options look like this: CC=${TARGET}-gcc AR=${TARGET}-ar RANLIB=${TARGET}-ranlib HOST_CC=gcc BUILD_CC=gcc \ ../${LIBC}/configure --host=${TARGET} --prefix=/usr --with-elf --enable-shar ed --enable-add-ons=linuxthreads --with-headers=${PREFIX}/include -v Is it even possible to build glibc under Cygwin? Any help would be appreciated. Thanks, Lyle Baingridge mips-linux-gcc -nostdlib -nostartfiles -o usr/src/o_libc/iconv/iconv_prog -Wl, -dynamic-linker=/lib/ld.so.1 /usr/src/o_libc/csu/crt1.o /usr/src/o_libc/csu/c rti.o `mips-linux-gcc --print-file-name=crtbegin.o` /usr/src/o_libc/iconv/iconv_ prog.o /usr/src/o_libc/iconv/iconv_charmap.o /usr/src/o_libc/iconv/charmap.o /us r/src/o_libc/iconv/charmap-dir.o /usr/src/o_libc/iconv/linereader.o /usr/src/o_l ibc/iconv/dummy-repertoire.o /usr/src/o_libc/iconv/simple-hash.o /usr/src/o_libc /iconv/xstrdup.o usr/src/o_libc/iconv/xmalloc.o -Wl,-rpath-link=/usr/src/o_lib c:/usr/src/o_libc/math:/usr/src/o_libc/elf:/usr/src/o_libc/dlfcn:/usr/src/o_ libc /nss:/usr/src/o_libc/nis:/usr/src/o_libc/rt:/usr/src/o_libc/resolv:/usr/src/ o_li bc/crypt:/usr/src/o_libc/linuxthreads /usr/src/o_libc/libc.so.6 /usr/src/o_libc/ libc_nonshared.a -lgcc `mips-linux-gcc --print-file-name=crtend.o` /usr/src/o_li bc/csu/crtn.o /usr/src/o_libc/iconv/iconv_prog.o: In function `main': /usr/src/glibc-2.2.5/iconv/iconv_prog.c:265: undefined reference to `open' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:279: undefined reference to `__fxstat' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:285: undefined reference to `close' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:326: undefined reference to `close' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:317: undefined reference to `close' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:142: undefined reference to `exit' /usr/src/o_libc/iconv/iconv_prog.o: In function `process_fd': /usr/src/glibc-2.2.5/iconv/iconv_prog.c:511: undefined reference to `read' /usr/src/glibc-2.2.5/iconv/iconv_prog.c:542: undefined reference to `read' /usr/src/o_libc/iconv/iconv_prog.o: In function `print_known_names': /usr/src/glibc-2.2.5/iconv/iconv_prog.c:726: undefined reference to `isatty' /usr/src/o_libc/iconv/iconv_charmap.o: In function `charmap_conversion': /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:155: undefined reference to `open' /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:169: undefined reference to `__fxstat ' /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:175: undefined reference to `close' /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:215: undefined reference to `close' /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:206: undefined reference to `close' /usr/src/o_libc/iconv/iconv_charmap.o: In function `process_fd': /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:498: undefined reference to `read' /usr/src/glibc-2.2.5/iconv/iconv_charmap.c:529: undefined reference to `read' /usr/src/o_libc/iconv/charmap.o: In function `charmap_read': /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap.c:106: undefined reference to `getenv' /usr/src/o_libc/iconv/charmap.o: In function `parse_charmap': /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap.c:467: undefined reference to `exit' /usr/src/o_libc/iconv/charmap.o: In function `charmap_new_char': /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/o_libc/iconv/charmap-dir.o: In function `charmap_readdir': /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:130: undefined refer ence to `__xstat' /usr/src/o_libc/iconv/charmap-dir.o: In function `fopen_uncompressed': /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:171: undefined refer ence to `open' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:177: undefined refer ence to `__fxstat' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:207: undefined refer ence to `close' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:210: undefined refer ence to `pipe' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:204: undefined refer ence to `close' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:205: undefined refer ence to `close' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:198: undefined refer ence to `close' /usr/src/glibc-2.2.5/iconv/../locale/programs/charmap-dir.c:199: undefined refer ence to `close' /usr/src/o_libc/iconv/linereader.o: In function `get_symname': /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/o_libc/iconv/linereader.o: In function `get_string': /usr/src/glibc-2.2.5/iconv/../stdlib/stdlib.h:308: undefined reference to `__str toul_internal' /usr/src/o_libc/libc.so.6: undefined reference to `__dup' /usr/src/o_libc/libc.so.6: undefined reference to `__strtod_internal' /usr/src/o_libc/libc.so.6: undefined reference to `utime' /usr/src/o_libc/libc.so.6: undefined reference to `lrand48_r' /usr/src/o_libc/libc.so.6: undefined reference to `__strtoull_internal' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_cmp' /usr/src/o_libc/libc.so.6: undefined reference to `__libc_fcntl' /usr/src/o_libc/libc.so.6: undefined reference to `__write' /usr/src/o_libc/libc.so.6: undefined reference to `__getcwd' /usr/src/o_libc/libc.so.6: undefined reference to `__strtol_internal' /usr/src/o_libc/libc.so.6: undefined reference to `bsearch' /usr/src/o_libc/libc.so.6: undefined reference to `__dup2' /usr/src/o_libc/libc.so.6: undefined reference to `qsort' /usr/src/o_libc/libc.so.6: undefined reference to `__strtoll_internal' /usr/src/o_libc/libc.so.6: undefined reference to `__read' /usr/src/o_libc/libc.so.6: undefined reference to `__unlink' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_lshift' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_mul' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_submul_1' /usr/src/o_libc/libc.so.6: undefined reference to `__open' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_construct_float' /usr/src/o_libc/elf/ld.so.1: undefined reference to `__libc_read' /usr/src/o_libc/libc.so.6: undefined reference to `__xstat64' /usr/src/o_libc/libc.so.6: undefined reference to `abort' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_divrem' /usr/src/o_libc/libc.so.6: undefined reference to `__lxstat' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_construct_double' /usr/src/o_libc/libc.so.6: undefined reference to `__chmod' /usr/src/o_libc/libc.so.6: undefined reference to `__strtold_internal' /usr/src/o_libc/libc.so.6: undefined reference to `__strtod_l' /usr/src/o_libc/libc.so.6: undefined reference to `__isatty' /usr/src/o_libc/libc.so.6: undefined reference to `__statfs' /usr/src/o_libc/libc.so.6: undefined reference to `_fpioconst_pow10' /usr/src/o_libc/libc.so.6: undefined reference to `__chdir' /usr/src/o_libc/libc.so.6: undefined reference to `__readlink' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_extract_double' /usr/src/o_libc/libc.so.6: undefined reference to `__secure_getenv' /usr/src/o_libc/libc.so.6: undefined reference to `__mkdir' /usr/src/o_libc/libc.so.6: undefined reference to `__cxa_atexit' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_add_n' /usr/src/o_libc/libc.so.6: undefined reference to `__poll' /usr/src/o_libc/libc.so.6: undefined reference to `__statvfs64' /usr/src/o_libc/libc.so.6: undefined reference to `__pipe' /usr/src/o_libc/libc.so.6: undefined reference to `__libc_open' /usr/src/o_libc/libc.so.6: undefined reference to `__chown' /usr/src/o_libc/libc.so.6: undefined reference to `__random_r' /usr/src/o_libc/libc.so.6: undefined reference to `__initstate_r' /usr/src/o_libc/libc.so.6: undefined reference to `__xmknod' /usr/src/o_libc/libc.so.6: undefined reference to `__lseek' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_rshift' /usr/src/o_libc/libc.so.6: undefined reference to `__srand48_r' /usr/src/o_libc/libc.so.6: undefined reference to `__tens' /usr/src/o_libc/libc.so.6: undefined reference to `__lxstat64' /usr/src/o_libc/libc.so.6: undefined reference to `__ttyname_r' /usr/src/o_libc/libc.so.6: undefined reference to `__rmdir' /usr/src/o_libc/libc.so.6: undefined reference to `__fstatfs' /usr/src/o_libc/libc.so.6: undefined reference to `__close' /usr/src/o_libc/libc.so.6: undefined reference to `__fxstat64' /usr/src/o_libc/libc.so.6: undefined reference to `__mpn_mul_1' /usr/src/o_libc/libc.so.6: undefined reference to `__strtof_internal' /usr/src/o_libc/elf/ld.so.1: undefined reference to `__libc_write' /usr/src/o_libc/libc.so.6: undefined reference to `__fcntl' /usr/src/o_libc/libc.so.6: undefined reference to `__setenv' /usr/src/o_libc/libc.so.6: undefined reference to `__access' /usr/src/o_libc/libc.so.6: undefined reference to `__unsetenv' /usr/src/o_libc/libc.so.6: undefined reference to `__open64' /usr/src/o_libc/libc.so.6: undefined reference to `__fstatvfs64' collect2: ld returned 1 exit status make[2]: *** [/usr/src/o_libc/iconv/iconv_prog] Error 1 make[2]: Leaving directory `/usr/src/glibc-2.2.5/iconv' make[1]: *** [iconv/subdir_install] Error 2 make[1]: Leaving directory `/usr/src/glibc-2.2.5' make: *** [install] Error 2 From mdharm@momenco.com Wed Sep 18 22:52:45 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 22:52:46 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:15379 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 22:52:45 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8IKqD610627; Wed, 18 Sep 2002 13:52:13 -0700 From: "Matthew Dharm" To: "Brian Murphy" , "Linux-MIPS" Subject: RE: fs problem between 2.4.19-rc1 and tip? Date: Wed, 18 Sep 2002 13:52:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3D88B068.6080303@murphy.dk> Importance: Normal Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Well, that makes things significantly better.... I can mount my filesystem now, tho I still get errors like: EXT2-fs error (device sd(8,2)): ext2_check_page: bad entry in directory #894638: unaligned directory entry - offset=4068, inode=544829025, rec_len=28261, name_len=116 But, it does boot. My serial console stopped (standard NS16550) working, tho.... as did a custom NVRAM driver. Oddly enough, it's only /dev/console that stopped working (actually, it no longer appears on my filesystem?!?) -- the getty running on /dev/ttyS0 works just fine. Regardless, the DMA patch should definately go in. I'm still looking into the other problems... we'll see what I come up with. Matt -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com > -----Original Message----- > From: linux-mips-bounce@linux-mips.org > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Brian Murphy > Sent: Wednesday, September 18, 2002 9:57 AM > To: Linux-MIPS > Cc: Matthew Dharm > Subject: Re: fs problem between 2.4.19-rc1 and tip? > > > Matthew Dharm wrote: > > >Is anyone else seeing a problem using SCSI disks (ext2 format) that > >was introduced between 2.4.19-rc1 and the tip revision? > > > >Upon booting the 2.4.20-pre6 (tip of CVS), the root > filesystem throws > >an error about an "unaligned directory entry" and then cannot find > >init. > > > > > This sounds like a problem I had with cache flushing in > pci.h which got > triggered > by a change in the ide dma driver. Is it a pci driver? If > so you could > try the fix > I submitted a few days ago with ide-dma in the subject line. > > /Brian > > From brian@murphy.dk Wed Sep 18 23:06:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 23:06:53 +0200 (CEST) Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:5184 "EHLO ubik.localnet") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 23:06:53 +0200 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g8IL6k6m019583 for ; Wed, 18 Sep 2002 23:06:46 +0200 Message-ID: <3D88EAE6.50909@murphy.dk> Date: Wed, 18 Sep 2002 23:06:46 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS Subject: 2.5 pci Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips Can anybody tell me how pcibios_init is supposed to get called in the 2.5 kernel? I had to add it back to pci_init (pci.c) to make it detect my pci devices. /Brian From brian@murphy.dk Wed Sep 18 23:14:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 23:14:13 +0200 (CEST) Received: from port48.ds1-vbr.adsl.cybercity.dk ([212.242.58.113]:7488 "EHLO ubik.localnet") by linux-mips.org with ESMTP id ; Wed, 18 Sep 2002 23:14:12 +0200 Received: from murphy.dk (brm@brian.localnet [10.0.0.2]) by ubik.localnet (8.12.3/8.12.3/Debian -4) with ESMTP id g8ILE76m019936 for ; Wed, 18 Sep 2002 23:14:07 +0200 Message-ID: <3D88EC9F.3060001@murphy.dk> Date: Wed, 18 Sep 2002 23:14:07 +0200 From: Brian Murphy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Linux-MIPS Subject: pci_unmap_single - 2.5 kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brian@murphy.dk Precedence: bulk X-list: linux-mips In the 2.5 kernel pci_map_sg contains these lines: addr = (unsigned long) page_address(sg->page); if (addr) dma_cache_wback_inv(addr, sg->length); Surely when flushing the offset needs to be added to the page base address (addr)? So that this reads: if (addr) dma_cache_wback_inv(addr + sg->offset, sg->length); /Brian From kwalker@broadcom.com Wed Sep 18 23:29:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 23:29:16 +0200 (CEST) Received: from mms2.broadcom.com ([63.70.210.59]:4357 "HELO mms2.broadcom.com") by linux-mips.org with SMTP id ; Wed, 18 Sep 2002 23:29:15 +0200 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7);); Wed, 18 Sep 2002 14:26:53 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA09736 for ; Wed, 18 Sep 2002 14:29:06 -0700 (PDT) Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id g8ILT6ER017149 for ; Wed, 18 Sep 2002 14:29: 06 -0700 (PDT) Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id OAA30892 for ; Wed, 18 Sep 2002 14:29:06 -0700 Message-ID: <3D88F022.E414C40F@broadcom.com> Date: Wed, 18 Sep 2002 14:29:06 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: ELF32 problem in mips64 kernel X-WSS-ID: 11963017334557-01-01 Content-Type: multipart/mixed; boundary=------------896D68375FC4991AF9B1471E Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kwalker@broadcom.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------896D68375FC4991AF9B1471E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is a faulty check in include/asm-mips64/elf.h: in elf_check_arch, the following access to the "e_flags" field is non-sensical if the binary is ELFCLASS32, because "__h" is typed as an elf64_hdr (through the elfhdr #define), whose e_flags is in a different location from an elf32_hdr. if ((__h->e_ident[EI_CLASS] == ELFCLASS32) && \ ((__h->e_flags & EF_MIPS_ABI2) == 0)) \ __res = 0; \ Should the n32 check (is this what the EF_MIPS_ABI2 check is about?) be punted to another binary format handler? The attached patch removed the ABI2 check. Kip --------------896D68375FC4991AF9B1471E Content-Type: text/plain; charset=us-ascii; name=elf.patch Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=elf.patch Index: include/asm-mips64/elf.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/elf.h,v retrieving revision 1.10.2.2 diff -u -r1.10.2.2 elf.h --- include/asm-mips64/elf.h 2002/08/20 18:42:37 1.10.2.2 +++ include/asm-mips64/elf.h 2002/09/18 21:19:42 @@ -43,8 +43,7 @@ \ if (__h->e_machine != EM_MIPS) \ __res = 0; \ - if ((__h->e_ident[EI_CLASS] == ELFCLASS32) && \ - ((__h->e_flags & EF_MIPS_ABI2) == 0)) \ + if (__h->e_ident[EI_CLASS] == ELFCLASS32) \ __res = 0; \ \ __res; \ @@ -53,7 +52,8 @@ /* * These are used to set parameters in the core dumps. */ -#define ELF_CLASS ELFCLASS64 +//#define ELF_CLASS ELFCLASS64 +#define ELF_CLASS ELFCLASS32 #ifdef __MIPSEB__ #define ELF_DATA ELFDATA2MSB #elif __MIPSEL__ --------------896D68375FC4991AF9B1471E-- From kwalker@broadcom.com Wed Sep 18 23:32:17 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 18 Sep 2002 23:32:18 +0200 (CEST) Received: from mms3.broadcom.com ([63.70.210.38]:21000 "HELO mms3.broadcom.com") by linux-mips.org with SMTP id ; Wed, 18 Sep 2002 23:32:17 +0200 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7);); Wed, 18 Sep 2002 14:32:09 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA10415 for ; Wed, 18 Sep 2002 14:32:09 -0700 (PDT) Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id g8ILW9ER017217 for ; Wed, 18 Sep 2002 14:32: 09 -0700 (PDT) Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id OAA30901 for ; Wed, 18 Sep 2002 14:32:09 -0700 Message-ID: <3D88F0D9.7144D898@broadcom.com> Date: Wed, 18 Sep 2002 14:32:09 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: ELF32 problem in mips64 kernel References: <3D88F022.E414C40F@broadcom.com> X-WSS-ID: 11962F53967367-01-01 Content-Type: multipart/mixed; boundary=------------353DF670F08FCA3D5852D827 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kwalker@broadcom.com Precedence: bulk X-list: linux-mips This is a multi-part message in MIME format. --------------353DF670F08FCA3D5852D827 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, so I didn't mean to include the debugging garbage in that patch :-) Take 2. Kip --------------353DF670F08FCA3D5852D827 Content-Type: text/plain; charset=us-ascii; name=elf.patch Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=elf.patch Index: include/asm-mips64/elf.h =================================================================== RCS file: /cvs/linux/include/asm-mips64/elf.h,v retrieving revision 1.10.2.2 diff -u -r1.10.2.2 elf.h --- include/asm-mips64/elf.h 2002/08/20 18:42:37 1.10.2.2 +++ include/asm-mips64/elf.h 2002/09/18 21:19:42 @@ -43,8 +43,7 @@ \ if (__h->e_machine != EM_MIPS) \ __res = 0; \ - if ((__h->e_ident[EI_CLASS] == ELFCLASS32) && \ - ((__h->e_flags & EF_MIPS_ABI2) == 0)) \ + if (__h->e_ident[EI_CLASS] == ELFCLASS32) \ __res = 0; \ \ __res; \ --------------353DF670F08FCA3D5852D827-- From ilya@theIlya.com Thu Sep 19 02:42:59 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Sep 2002 02:42:59 +0200 (CEST) Received: from 12-234-207-60.client.attbi.com ([12.234.207.60]:64679 "HELO gateway.total-knowledge.com") by linux-mips.org with SMTP id ; Thu, 19 Sep 2002 02:42:59 +0200 Received: (qmail 14316 invoked by uid 502); 19 Sep 2002 00:42:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Sep 2002 00:42:49 -0000 Date: Wed, 18 Sep 2002 17:42:42 -0700 (PDT) From: ilya@theIlya.com X-X-Sender: ilya@ns2.total-knowledge.com To: Brian Murphy cc: Linux-MIPS Subject: Re: 2.5 pci In-Reply-To: <3D88EAE6.50909@murphy.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ilya@theIlya.com Precedence: bulk X-list: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 put in your board pci initalization file subsys_initcall(pcibios_init); (outside of any function) On Wed, 18 Sep 2002, Brian Murphy wrote: > Can anybody tell me how pcibios_init is supposed to get called in the > 2.5 kernel? > I had to add it back to pci_init (pci.c) to make it detect my pci devices. > > /Brian > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE9iR2J84S94bALfyURAvB9AJ91qL6qWwGj4ndoKqEEWHcPz7afqQCggOCR QAw/eiRCTh9pv3MPuEP/5BE= =NKQn -----END PGP SIGNATURE----- From ralf@linux-mips.org Thu Sep 19 15:31:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Sep 2002 15:31:15 +0200 (CEST) Received: from p508B7868.dip.t-dialin.net ([80.139.120.104]:5261 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 19 Sep 2002 15:31:15 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8JDV1n17203; Thu, 19 Sep 2002 15:31:01 +0200 Date: Thu, 19 Sep 2002 15:31:01 +0200 From: Ralf Baechle To: Carsten Langgaard Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org Subject: Re: memcpy Message-ID: <20020919153101.A17133@linux-mips.org> References: <3D805119.5A9E3C42@mips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D805119.5A9E3C42@mips.com>; from carstenl@mips.com on Thu, Sep 12, 2002 at 10:32:25AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 12, 2002 at 10:32:25AM +0200, Carsten Langgaard wrote: > I have found another bug in the 64-bit memcpy function, so I figured it > was time to use the 32-bit version (as it's more or less are prepared > for 64-bit). > With a few fixes the memcpy.S file can now be shared between the 32-bit > and 64-bit kernel (the only difference is the definition of USE_DOUBLE). > > I have attached the patch for arch/mips/lib/memcpy.S and the full file > for the arch/mips64/lib/memcpy.S Will apply. Ralf PS: Same please as to everybody else - always send patches, never send files. Even worse, tarballs. Yet worse, compressed stuff. All a waste of time. From Jon_Burgess@eur.3com.com Thu Sep 19 17:42:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Sep 2002 17:42:16 +0200 (CEST) Received: from ip-161-71-171-238.corp-eur.3com.com ([161.71.171.238]:7613 "EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP id ; Thu, 19 Sep 2002 17:42:15 +0200 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g8JFhAY3019030 for ; Thu, 19 Sep 2002 16:43:48 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g8JFgKu21000 for ; Thu, 19 Sep 2002 16:42:20 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256C39.0056AD3E ; Thu, 19 Sep 2002 16:46:44 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: linux-mips@linux-mips.org Message-ID: <80256C39.0056AAAC.00@notesmta.eur.3com.com> Date: Thu, 19 Sep 2002 16:40:05 +0100 Subject: Problem running Mips2 user space code Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=VbmIrTEGDLodNkTwcYXHOM2JzuWm2ArfCN5qSkMgYf5RhxsFNNb3qsf0" Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Jon_Burgess@eur.3com.com Precedence: bulk X-list: linux-mips --0__=VbmIrTEGDLodNkTwcYXHOM2JzuWm2ArfCN5qSkMgYf5RhxsFNNb3qsf0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline We have an product with an embedded Mips32 processor running CVS linux_2_4_17. Everything seems to work well when we compile our user space code with the default GCC options (i.e. producing mips1 code) but if we optimise the user space code to use the same CPU flags as the kernel (-mips2 -mcpu=r4600) then code crashes intermittently . Has anyone else tried running mips2 user mode code? Both the kernel and user space code are compiled with HJ Lu's toolchain 20020627 RPMs. This toolchain flags the binaries as 'mips2' so I had to copy the include/asm/elf.h file from CVS HEAD to get them to execute. As far as I can tell this should be OK. I can update the kernel to the latest CVS if required, but I need to apply some board specific changes. I have a developed a small (1kb source) test program which exhibits the problem. This source build the executables 'mips1' & mips2'. When these are run the mips2 program iterates a few times but normally stops in a couple of seconds reporting total=7, where as it should be 6. The mips1 program always gets the correct answer and keeps on running. Does the same thing happen for anyone else? I examined the instructions which are involved in causing the crashes and found that it seems to be related to the use of the 'branch likely' instruction in the Mips2 code, generated for the lines 'if (X) bar(X)' in the test program. The same instructions run every loop iteration and it only occasionally gets the wrong answer. The problem seems to be that the branch likely delay slot instruction fails to get nullified even though the branch is not taken. Could a task schedule or exception while executing the branch likely instruction cause a problem? I can send the compiled executable directly if anyone is interested in trying my executables on another board/kernel (total about 16kb) -- just in case it is caused by a toolchain problem. I just read Ralfs comment about not sending files, tars or compressed files to the mailing list, hopefully he won't mind the source. Jon (See attached file: Makefile)(See attached file: bnel2.c) --0__=VbmIrTEGDLodNkTwcYXHOM2JzuWm2ArfCN5qSkMgYf5RhxsFNNb3qsf0 Content-type: application/octet-stream; name="Makefile" Content-Disposition: attachment; filename="Makefile" Content-transfer-encoding: base64 Q1JPU1NfQ09NUElMRSA6PSAvZXhwb3J0L3Rvb2xzL2Jpbi9taXBzLWxpbnV4LQoKQVMgICAgICAg ICAgICAgIDo9ICQoQ1JPU1NfQ09NUElMRSlhcwpMRCAgICAgICAgICAgICAgOj0gJChDUk9TU19D T01QSUxFKWxkCkNDICAgICAgICAgICAgICA6PSAkKENST1NTX0NPTVBJTEUpZ2NjCkNQUCAgICAg ICAgICAgICA6PSAkKENDKSAtRQpBUiAgICAgICAgICAgICAgOj0gJChDUk9TU19DT01QSUxFKWFy Ck5NICAgICAgICAgICAgICA6PSAkKENST1NTX0NPTVBJTEUpbm0KU1RSSVAgICAgICAgICAgIDo9 ICQoQ1JPU1NfQ09NUElMRSlzdHJpcApPQkpDT1BZICAgICAgICAgOj0gJChDUk9TU19DT01QSUxF KW9iamNvcHkKT0JKRFVNUCAgICAgICAgIDo9ICQoQ1JPU1NfQ09NUElMRSlvYmpkdW1wCgpDRkxB R1MgICAgICAgICs9IC1waXBlIC1PIC1XYWxsCgphbGw6IG1pcHMxIG1pcHMyCglAI2NwIC1mIG1p cHMxIG1pcHMyIC90ZnRwYm9vdC8xNjEuNzEuNTQuMjMvc2Jpbi8KCUAjL2V4cG9ydC90b29scy9i aW4vbWlwcy1saW51eC1vYmpkdW1wIC1kIC1tbWlwczppc2EzMiBtaXBzMgoKbWlwczE6IGJuZWwy LmMKCSQoQ0MpICQoQ0ZMQUdTKSAtbyAkQCAkPAoKbWlwczI6IGJuZWwyLmMKCSQoQ0MpICQoQ0ZM QUdTKSAtbWNwdT1yNDYwMCAtbWlwczIgLW8gJEAgJDwKCmNsZWFuOgoJcm0gLWYgbWlwczEgbWlw czIK --0__=VbmIrTEGDLodNkTwcYXHOM2JzuWm2ArfCN5qSkMgYf5RhxsFNNb3qsf0 Content-type: application/octet-stream; name="bnel2.c" Content-Disposition: attachment; filename="bnel2.c" Content-transfer-encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUgPHNp Z25hbC5oPgoKdHlwZWRlZiBzdHJ1Y3QgewogIGNoYXIgc3BhY2VyWzB4MjhdOwogIGludCBwOwog IGNoYXIgc3BhY2VyMls0MF07CiAgaW50IHI7CiAgY2hhciBtZXNzYWdlWzIxMDBdOwogIGludCBx Owp9IHNfdGVzdDsKCmludCB0b3RhbDsKCnZvaWQgc3RhcnRfY2hpbGQoKQp7CiAgaW50IHBpZCA9 IGZvcmsoKTsKCiAgLyogUGFyZW50ICovCiAgaWYgKHBpZCkKICAgIHJldHVybjsKCiAgLyogQ2hp bGQgKi8KICB3aGlsZSgxKQogICAgewogICAgICBzbGVlcCgxKTsKICAgICAgc3lzdGVtKCJscyAt bCIpOwogICAgfQp9Cgp2b2lkIGJhcihpbnQgeCkKewogIHByaW50ZigiVmFyaWFibGUgaXMgJWRc biIsIHgpOwogIHRvdGFsICs9IHg7Cn0KCnZvaWQgZm9vKHNfdGVzdCAqYSkKewogIHByaW50Zigi cCA9ICVkXG4iLCBhLT5wKTsKICBwcmludGYoInEgPSAlZFxuIiwgYS0+cSk7CiAgcHJpbnRmKCJy ID0gJWRcbiIsIGEtPnIpOwogIHByaW50ZigiTWVzc2FnZSBpcyAlc1xuIiwgYS0+bWVzc2FnZSk7 CgogIGlmIChhLT5wKQogICAgYmFyKGEtPnApOwoKICBpZiAoYS0+cSkKICAgIGJhcihhLT5xKTsK CiAgaWYgKGEtPnIpCiAgICBiYXIoYS0+cik7Cn0KCmludCBtYWluKGludCBhcmdjLCBjaGFyICph cmd2W10pCnsKICBjaGFyICpzdHJpbmcgPSAiSGVsbG8gd29ybGQiOwogIHNfdGVzdCBkYXRhOwoK ICBkYXRhLnA9MTsKICBkYXRhLnE9MjsKICBkYXRhLnI9MzsKCiAgc3RyY3B5KGRhdGEubWVzc2Fn ZSwgc3RyaW5nKTsKCiAgc3RhcnRfY2hpbGQoKTsKCiAgd2hpbGUoMSkKICAgIHsKICAgICAgdG90 YWwgPSAwOwoKICAgICAgZm9vKCZkYXRhKTsKCiAgICAgIHByaW50ZigiVG90YWwgJWRcbiIsIHRv dGFsKTsKICAgICAgaWYgKHRvdGFsICE9IDYpCglicmVhazsKICAgIH0KCiAga2lsbCgwLCBTSUdI VVApOyAKCiAgcmV0dXJuIDA7Cn0KCgo= --0__=VbmIrTEGDLodNkTwcYXHOM2JzuWm2ArfCN5qSkMgYf5RhxsFNNb3qsf0-- From Jon_Burgess@eur.3com.com Thu Sep 19 18:42:22 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 19 Sep 2002 18:42:23 +0200 (CEST) Received: from ip-161-71-171-238.corp-eur.3com.com ([161.71.171.238]:39368 "EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP id ; Thu, 19 Sep 2002 18:42:22 +0200 Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50]) by columba.www.eur.3com.com with ESMTP id g8JGhOY3022072 for ; Thu, 19 Sep 2002 17:43:56 +0100 (BST) Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id g8JGgYu25255 for ; Thu, 19 Sep 2002 17:42:34 +0100 (BST) Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256C39.005C4540 ; Thu, 19 Sep 2002 17:47:50 +0100 X-Lotus-FromDomain: 3COM From: "Jon Burgess" To: linux-mips@linux-mips.org Message-ID: <80256C39.005C4310.00@notesmta.eur.3com.com> Date: Thu, 19 Sep 2002 17:41:14 +0100 Subject: Re: Problem running Mips2 user space code Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Jon_Burgess@eur.3com.com Precedence: bulk X-list: linux-mips I just enabled the DEBUG_CACHE in mm/c-mips32.c and the program fails immeadiately after some cache routines have been called. We have already seen a cache related problem with this chip so it looks like be caused by a hardware problem not the kernel. Sorry to trouble you all with this. I'll be in touch again if it looks like a kernel problem. Thanks, Jon From ralf@linux-mips.org Fri Sep 20 02:48:29 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 02:48:30 +0200 (CEST) Received: from p508B48B4.dip.t-dialin.net ([80.139.72.180]:22163 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 02:48:29 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8K0lCg29959; Fri, 20 Sep 2002 02:47:12 +0200 Date: Fri, 20 Sep 2002 02:47:12 +0200 From: Ralf Baechle To: Jon Burgess Cc: linux-mips@linux-mips.org Subject: Re: Problem running Mips2 user space code Message-ID: <20020920024712.A27442@linux-mips.org> References: <80256C39.0056AAAC.00@notesmta.eur.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <80256C39.0056AAAC.00@notesmta.eur.3com.com>; from Jon_Burgess@eur.3com.com on Thu, Sep 19, 2002 at 04:40:05PM +0100 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 19, 2002 at 04:40:05PM +0100, Jon Burgess wrote: > in case it is caused by a toolchain problem. I just read Ralfs comment > about not sending files, tars or compressed files to the mailing list, > hopefully he won't mind the source. The comment was refering to patches sent to me. Having to unzip and untar patch sets is just a waste of time. The easiest thing to deal with my is one inline patch per email, no attachments. For those pour souls that use mails that garble patches (Some Pine versions, Netscape, Mozilla, Lotus Notes, MS stuff) one patch attached per mail. Ralf From g.c.bransby-99@student.lboro.ac.uk Fri Sep 20 10:57:44 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 10:57:45 +0200 (CEST) Received: from fw-cam.cambridge.arm.com ([193.131.176.3]:26601 "EHLO fw-cam.cambridge.arm.com") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 10:57:44 +0200 Received: by fw-cam.cambridge.arm.com; id JAA08659; Fri, 20 Sep 2002 09:57:19 +0100 (BST) Received: from unknown(172.16.9.107) by fw-cam.cambridge.arm.com via smap (V5.5) id xma007885; Fri, 20 Sep 02 09:56:27 +0100 Date: Fri, 20 Sep 2002 09:56:23 +0100 From: Gareth To: linux-mips@linux-mips.org Subject: Cycles for certain instructions Message-Id: <20020920095623.5300295a.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: g.c.bransby-99@student.lboro.ac.uk Precedence: bulk X-list: linux-mips Hi, I am doing an investigation with a mips malta board that has a 4kc processor on it. I am trying to find out how many cycles certain instructions take to execute. The program I am running loops a small piece of code many times. After a few loops of the code the caches will have all the instructions in them and so accesses to memory will be few and far between. So how many cycles do instructions such as load word and store word take? Obviosly if the data is not in the cache the time take will depend on the speed of the external memory. If the data is in the cache is the time taken fairly predictable for a given core? Thanks Gareth From seh@zee2.com Fri Sep 20 11:39:22 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 11:39:23 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:35837 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 11:39:22 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8K9cCM20345; Fri, 20 Sep 2002 10:38:14 +0100 Message-ID: <3D8AEC84.ADA8CE0A@zee2.com> Date: Fri, 20 Sep 2002 10:38:12 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linda Wang , Linux-MIPS Subject: Re: FW: cannot debug multi-threaded programs with gdb/gdbserver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips Hi Linda, I followed the advice from Daniel/Steve and upgraded my toolchain (binutils-2.13/gcc-2.3/glibc-2.2.5/). Now I can do some thread aware gdb/gdbserver debug. It seems to work fine on simple programs, but on some other large applications some behaviour is not predictable (this may well be the application, as it issues SIGSTOP/SIGCONT to control threads, and I think this causes gdb to get confused). One thing that is not obvious is that you need to set (either at the command line or in a .gdbinit file): set heuristic-fence-post 20 // not sure if this is actually needed set solib-absolute-prefix /dev/null set solib-search-path : In my case: is /usr/local/mipsel-linux NOTE: no lib component (this is passed back from the location on the target ???). This is only needed if you have your own shared libs. NOTE: The path on the host must contain the basename component, but this must not be given in the For instance, if I build on the host and the library ends up in /home/seh/project/test/lib, but the library ends up on the target in /apps/custom/mylibs You would need to: - make a symlink on the homst from lib -> mylibs - set to /home/seh/project/test Regards, Stuart Linda Wang wrote: > > Hi Stuart, > > Have you manage to get gdb to work with 5.3 version, with pthread > without seeing the Warning problems? > > We are encountered the same problem on our system as well, but > we have different mips processor. > > any further info would be greatly appreciated. > thanks, > -linda > > -----Original Message----- > From: Stuart Hughes [mailto:seh@zee2.com] > Sent: Tuesday, September 17, 2002 10:03 AM > Subject: cannot debug multi-threaded programs with gdb/gdbserver > > Hi, > > I managed to get gdb to do multi-threaded debug using a gdb on the > target, after Daniel J helped with a patch to sys/procfs.h > > I am now trying to do host target with gdb/gdbserver. The program on > the target uses pthreads. > > I can connect, but as soon as you try to continue (to a breakpoint) I > get: > > Program received signal SIG32, Real-time event 32. > warning: Warning: GDB can't find the start of the function at > 0x2abee684. > .... > > I know that SIG32 is used for the thread control on the target, but I'm > not sure if the host gdb is supposed to receive this. I tried "set > handle SIG32 pass noprint nostop" > and variations, but this didn't help. > > Does anyone know whether there is some special setup needed on > gdb/gdbserver to use the multi-threaded gdbserver ?? > > My environment is as follows: > > CPU: NEC VR5432 > kernel: linux-2.4.18 + patches > glibc: 2.2.3 + patches > gdb: 5.2/3 from CVS > gcc: 3.1 > binutils: Version 2.11.90.0.25 > > cross-gdb configured using: > > configure --prefix=/usr --target=mipsel-linux --disable-sim > --disable-tcl --enable-threads --enable-shared > > gdbserver configured using: > > configure --prefix=/usr --host=mipsel-linux --target=mipsel-linux > --enable-threads --enable-shared > > Regards, Stuart From kevink@mips.com Fri Sep 20 12:55:05 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 12:55:06 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:1420 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 12:55:05 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8KAsoUD018986; Fri, 20 Sep 2002 03:54:50 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA27733; Fri, 20 Sep 2002 03:55:05 -0700 (PDT) Message-ID: <008401c26094$794952f0$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Gareth" , References: <20020920095623.5300295a.g.c.bransby-99@student.lboro.ac.uk> Subject: Re: Cycles for certain instructions Date: Fri, 20 Sep 2002 12:57:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > I am doing an investigation with a mips malta board that has a 4kc processor on > it. I am trying to find out how many cycles certain instructions take to > execute. > > The program I am running loops a small piece of code many times. After a few > loops of the code the caches will have all the instructions in them and so > accesses to memory will be few and far between. So how many cycles do > instructions such as load word and store word take? Obviosly if the data is not > in the cache the time take will depend on the speed of the external memory. If > the data is in the cache is the time taken fairly predictable for a given core? On a 4Kc, and indeed on the vast majority of MIPS CPUs, if the data is in the cache, a load will pipeline fully. Which is to say, the following instruction will issue on the next clock. *However*, if that following instruction uses the loaded data, it will stall by one cycle waiting for the data to come back from the cache. Compilers for MIPS will generally try to stick some useful instructions between load and load data use. Regards, Kevin K. From dom@mudchute.algor.co.uk Fri Sep 20 13:15:18 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 13:15:19 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:19952 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 13:15:18 +0200 Received: from mudchute.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g8KBF9r05092; Fri, 20 Sep 2002 12:15:09 +0100 (BST) Received: (from dom@localhost) by mudchute.algor.co.uk (8.8.5/8.8.5) id MAA15989; Fri, 20 Sep 2002 12:15:03 +0100 (BST) Date: Fri, 20 Sep 2002 12:15:03 +0100 (BST) Message-Id: <200209201115.MAA15989@mudchute.algor.co.uk> From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Gareth Cc: linux-mips@linux-mips.org Subject: Re: Cycles for certain instructions In-Reply-To: <20020920095623.5300295a.g.c.bransby-99@student.lboro.ac.uk> References: <20020920095623.5300295a.g.c.bransby-99@student.lboro.ac.uk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Gareth, > I am doing an investigation with a mips malta board that has a 4kc > processor on it. I am trying to find out how many cycles certain > instructions take to execute. > > The program I am running loops a small piece of code many > times. After a few loops of the code the caches will have all the > instructions in them and so accesses to memory will be few and far > between. Some 4Kx CPUs have write-through caches. If yours is one of them, write traffic will continue to flow to memory. There's a FIFO on the CPU to hold write address/data, but unless your writes are sparse the FIFO will rapidly fill, and the program will run only as fast as the memory can process the writes. 4Kx CPUs with writeback caches can still be configured with the cache disabled or (in some cases) in write-through. > So how many cycles do instructions such as load word and store word > take? One. But the operation is pipelined: if you try to use the data you loaded in the very next instruction, the CPU will wait one extra clock. Strange things may happen if you put loads shortly after a store to the same location. > Obviosly if the data is not in the cache the time take will depend > on the speed of the external memory. Yes. > If the data is in the cache is the time taken fairly predictable for > a given core? Very predictable! -- Dominic Sweetman, MIPS Technologies (UK) - formerly Algorithmics The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205 http://www.algor.co.uk From macro@ds2.pg.gda.pl Fri Sep 20 14:30:03 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 14:30:04 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:20100 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 14:30:03 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA00176; Fri, 20 Sep 2002 14:30:25 +0200 (MET DST) Date: Fri, 20 Sep 2002 14:30:25 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Kip Walker cc: linux-mips@linux-mips.org Subject: Re: ELF32 problem in mips64 kernel In-Reply-To: <3D88F022.E414C40F@broadcom.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Wed, 18 Sep 2002, Kip Walker wrote: > in elf_check_arch, the following access to the "e_flags" field is > non-sensical if the binary is ELFCLASS32, because "__h" is typed as an > elf64_hdr (through the elfhdr #define), whose e_flags is in a different > location from an elf32_hdr. Thanks for pointing it out. > if ((__h->e_ident[EI_CLASS] == ELFCLASS32) && \ > ((__h->e_flags & EF_MIPS_ABI2) == 0)) \ > __res = 0; \ > > Should the n32 check (is this what the EF_MIPS_ABI2 check is about?) be > punted to another binary format handler? The attached patch removed the > ABI2 check. Since the layout of the ELF32 header much differs from the ELF64 one it doesn't really make sense to handle both formats together. The change looks OK. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@linux-mips.org Fri Sep 20 18:06:59 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 18:07:00 +0200 (CEST) Received: from p508B48B4.dip.t-dialin.net ([80.139.72.180]:7068 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 18:06:59 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8KG6qI32633 for linux-mips@linux-mips.org; Fri, 20 Sep 2002 18:06:52 +0200 Date: Fri, 20 Sep 2002 18:06:51 +0200 From: Ralf Baechle To: linux-mips@linux-mips.org Subject: CVS server moved Message-ID: <20020920180651.A32600@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips I moved the cvs archive to ftp.linux-mips.org two days ago. If you already have a checked out copy, here is how to avoid having to checkout again: cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login The password for anonymous cvs is cvs. cd find . -name Root | while read n; do echo ftp.linux-mips.org:/home/cvs > $n done There are still a few loose bits but here and there but those should not become visible to normal users. Ralf From Geert.Uytterhoeven@sonycom.com Fri Sep 20 18:17:43 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 18:17:44 +0200 (CEST) Received: from mail2.sonytel.be ([195.0.45.172]:38536 "EHLO mail.sonytel.be") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 18:17:43 +0200 Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26]) by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id SAA07301; Fri, 20 Sep 2002 18:17:31 +0200 (MET DST) Date: Fri, 20 Sep 2002 18:17:32 +0200 (MEST) From: Geert Uytterhoeven To: Ralf Baechle cc: Linux/MIPS Development Subject: Re: CVS server moved In-Reply-To: <20020920180651.A32600@linux-mips.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: linux-mips On Fri, 20 Sep 2002, Ralf Baechle wrote: > I moved the cvs archive to ftp.linux-mips.org two days ago. If you already > have a checked out copy, here is how to avoid having to checkout again: > > cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login > > The password for anonymous cvs is cvs. > > cd > find . -name Root | while read n; do > echo ftp.linux-mips.org:/home/cvs > $n > done People who use anonymous CVS want to prepend `:pserver:cvs@', i.e. | cd | find . -name Root | while read n; do | echo :pserver:cvs@ftp.linux-mips.org:/home/cvs > $n | done 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 drow@false.org Fri Sep 20 18:24:51 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 18:24:52 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:53766 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 18:24:51 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17sRW3-0000yf-00; Fri, 20 Sep 2002 12:24:31 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17sQa1-0003As-00; Fri, 20 Sep 2002 12:24:33 -0400 Date: Fri, 20 Sep 2002 12:24:33 -0400 From: Daniel Jacobowitz To: Stuart Hughes Cc: Linda Wang , Linux-MIPS Subject: Re: FW: cannot debug multi-threaded programs with gdb/gdbserver Message-ID: <20020920162433.GA12166@nevyn.them.org> References: <3D8AEC84.ADA8CE0A@zee2.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8AEC84.ADA8CE0A@zee2.com> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Fri, Sep 20, 2002 at 10:38:12AM +0100, Stuart Hughes wrote: > Hi Linda, > > I followed the advice from Daniel/Steve and upgraded my toolchain > (binutils-2.13/gcc-2.3/glibc-2.2.5/). Now I can do some thread aware > gdb/gdbserver debug. > > It seems to work fine on simple programs, but on some other large > applications some behaviour is not predictable (this may well be the > application, as it issues SIGSTOP/SIGCONT to control threads, and I > think this causes gdb to get confused). This should not confuse gdbserver. I'm not sure what it'll do to native GDB, but I don't think it'll confuse that either... > set heuristic-fence-post 20 // not sure if this is actually needed > set solib-absolute-prefix /dev/null > set solib-search-path > : > > In my case: > is /usr/local/mipsel-linux > > NOTE: no lib component (this is passed back from the location on the > target ???). > > This is only needed if you have your own > shared libs. > > NOTE: The path on the host must contain the basename component, but this > must not be given in the > > For instance, if I build on the host and the library ends up in > /home/seh/project/test/lib, but the library ends up on the target in > /apps/custom/mylibs > > You would need to: > - make a symlink on the homst from lib -> mylibs > - set to /home/seh/project/test You should not be doing it this way; life will be much easier if you just set the shared libraries up in the same hierarchy on target and host and set solib-absolute-prefix /location/of/host/lib/tree. That is, /location/of/host/lib/tree/lib/ld-2.2.5.so /location/of/host/lib/tree/usr/lib/libz.so et cetera. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From seh@zee2.com Fri Sep 20 18:47:55 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 20 Sep 2002 18:47:56 +0200 (CEST) Received: from [212.74.13.151] ([212.74.13.151]:36848 "EHLO dell.zee2.com") by linux-mips.org with ESMTP id ; Fri, 20 Sep 2002 18:47:55 +0200 Received: from zee2.com (localhost [127.0.0.1]) by dell.zee2.com (8.11.6/8.11.6) with ESMTP id g8KGkhM24567; Fri, 20 Sep 2002 17:46:44 +0100 Message-ID: <3D8B50F2.760D2BDC@zee2.com> Date: Fri, 20 Sep 2002 17:46:42 +0100 From: Stuart Hughes Organization: Zee2 Ltd X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Linda Wang , Linux-MIPS Subject: Re: FW: cannot debug multi-threaded programs with gdb/gdbserver References: <3D8AEC84.ADA8CE0A@zee2.com> <20020920162433.GA12166@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: seh@zee2.com Precedence: bulk X-list: linux-mips Daniel Jacobowitz wrote: > > On Fri, Sep 20, 2002 at 10:38:12AM +0100, Stuart Hughes wrote: > > Hi Linda, > > > > It seems to work fine on simple programs, but on some other large > > applications some behaviour is not predictable (this may well be the > > application, as it issues SIGSTOP/SIGCONT to control threads, and I > > think this causes gdb to get confused). > > This should not confuse gdbserver. I'm not sure what it'll do to > native GDB, but I don't think it'll confuse that either... I explained it badly. By confused I mean that these signals cause the debugger to stop and print the fact they they received SIGCONT. I just want these signals handled by the application and not intercepted by the debugger, I played with "handle SIGCONT" but I didn't manage to get it to work as I wanted ( I tried: pass noprint nostop) > > You would need to: > > - make a symlink on the homst from lib -> mylibs > > - set to /home/seh/project/test > > You should not be doing it this way; life will be much easier if you > just set the shared libraries up in the same hierarchy on target and > host and set solib-absolute-prefix /location/of/host/lib/tree. That > is, > /location/of/host/lib/tree/lib/ld-2.2.5.so > /location/of/host/lib/tree/usr/lib/libz.so > et cetera. Thanks for the hint, this is a much better way to do it. Regards, Stuart From dinesh_nagpure@ivivity.com Sat Sep 21 20:28:04 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 21 Sep 2002 20:28:05 +0200 (CEST) Received: from [64.238.111.99] ([64.238.111.99]:64015 "EHLO mail.ivivity.com") by linux-mips.org with ESMTP id ; Sat, 21 Sep 2002 20:28:04 +0200 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Sep 2002 14:27:55 -0400 Message-ID: From: Dinesh Nagpure To: linux-mips@linux-mips.org Subject: RM5231A: problems in timer using COUNT/COMPARE register. Date: Sat, 21 Sep 2002 14:27:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dinesh_nagpure@ivivity.com Precedence: bulk X-list: linux-mips Hello, I am in the process of porting Linux to our FPGA platform using RM5231A processor. The COUNT/COMPARE register timer is acting funny with me. When I set the compare register value to something like 0x0100_0000 or less I get timer interrupt as expected but if I set the COMPARE register to a greater value timer interrupt never happens. I have verified this using our boot loader also and the results are the same. I am waiting for a reply from PMC but would also like to know if there is anyone out there who faced similar problems with RM5231A. From data sheets and user manual I know the count register is 32 bit but apparently there is some hitch somewhere that I need to discover. Dinesh iVivity From kevink@mips.com Tue Sep 24 09:49:23 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 09:49:24 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:49797 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 09:49:23 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8O7n7rZ001883 for ; Tue, 24 Sep 2002 00:49:07 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id AAA07450 for ; Tue, 24 Sep 2002 00:49:27 -0700 (PDT) Message-ID: <008801c2639f$385b1b80$10eca8c0@grendel> From: "Kevin D. Kissell" To: Subject: FCSR Management Date: Tue, 24 Sep 2002 09:51:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips In looking at some anomalous behavior on another software platform, I checked the current MIPS/Linux kernel sources and I wonder if we don't have yet another FP context problem lurking under the surface. On most, if not all, MIPS CPUs with integrated FPUs, the act of writing a value to the FP CSR (Control and Status Register, fcr31) which has the "E" bit, or any matching pair of Enable/Cause bits for the V/Z/O/U/I IEEE exceptions set will trigger a floating point exception. In the case of the Unimplemented Operation exception (the "E" bit), the emulator is invoked and all of the Cause bits are cleared in the context before user execution is resumed. In the case of other FP exceptions, the default behavior is to dump core, so the user never executes again. But *if* the user has registered a handler for SIGFPE, and one of the IEEE exceptions occurs, I don't see where the associated Cause bit is being cleared, and I would think that the consequence would be that the process would get into an endless loop of trapping, posting the signal, restoring the FCSR from the context with the bits set, and trapping again, whether or not the PC is modified to avoid re-executing the faulting instruction. Am I missing something, or is this a problem? Regards, Kevin K. From fake@apollo.bingo-ev.de Tue Sep 24 10:24:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 10:24:52 +0200 (CEST) Received: from apollo.bingo-ev.de ([213.70.214.67]:16341 "EHLO apollo.bingo-ev.de") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 10:24:52 +0200 Received: from fake by apollo.bingo-ev.de with local (Exim 3.35 #1 (Debian)) id 17tkzs-0007Pb-00 for ; Tue, 24 Sep 2002 10:24:44 +0200 Date: Tue, 24 Sep 2002 10:24:44 +0200 From: FrAnKenstEin To: linux-mips@linux-mips.org Subject: EF_MIPS_ABI and EF_MIPS_ABI2 undefined in 2.4.20-pre7 Message-ID: <20020924082444.GA28416@apollo.bingo-ev.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fake@bingo-ev.de Precedence: bulk X-list: linux-mips hi, ralf, since your sync in pre7 of the 2.4 kernel, i get 2 missing defines (in include/linux/elf.h if i am not mistaken)... EF_MIPS_ABI and EF_MIPS_ABI2. in the latest binutils mips.h and in /usr/include/elf.h those are defined. whats up? ;) i also have problems with unresolved symbols in ip22-setup.o since 2.4.18 - setup_console is unresolved, but that is devfs-specific if i am not mistaken... i will have a look at it as i find some spare time. thanks in advance, FAKE From dom@algor.co.uk Tue Sep 24 10:41:01 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 10:41:01 +0200 (CEST) Received: from alg133.algor.co.uk ([62.254.210.133]:28413 "EHLO oval.algor.co.uk") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 10:41:01 +0200 Received: from gladsmuir.algor.co.uk (pubfw.algor.co.uk [62.254.210.129]) by oval.algor.co.uk (8.11.6/8.10.1) with ESMTP id g8O8enr15158; Tue, 24 Sep 2002 09:40:54 +0100 (BST) From: Dominic Sweetman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15760.9489.29819.536681@gladsmuir.algor.co.uk> Date: Tue, 24 Sep 2002 09:40:49 +0100 To: Dinesh Nagpure Cc: linux-mips@linux-mips.org Subject: Re: RM5231A: problems in timer using COUNT/COMPARE register. In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dom@algor.co.uk Precedence: bulk X-list: linux-mips Dinesh, > I am in the process of porting Linux to our FPGA platform using RM5231A > processor. The COUNT/COMPARE register timer is acting funny with me. When I > set the compare register value to something like 0x0100_0000 or less I get > timer interrupt as expected but if I set the COMPARE register to a greater > value timer interrupt never happens. I have verified this using our boot > loader also and the results are the same. I am waiting for a reply from PMC > but would also like to know if there is anyone out there who faced similar > problems with RM5231A. From data sheets and user manual I know the count > register is 32 bit but apparently there is some hitch somewhere that I need > to discover. I'd be really surprised if there's a hardware bug; the RM5231A is an old core and it always seemed to work. Standard practice is to leave COUNT free-running, and to get timer interrupts by setting COMPARE ahead of it; this relies totally on being able to use the whole range of values, and running seamlessly while COUNT overflows back to zero... Unless you've already done a really low-level, nothing-else-running software sanity check on this, it seems more likely that some piece of software is periodically resetting COUNT, or changing COMPARE, behind your back. Dominic Sweetman MIPS Technologies From dinesh_nagpure@ivivity.com Tue Sep 24 10:58:14 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 10:58:14 +0200 (CEST) Received: from [64.238.111.99] ([64.238.111.99]:16651 "EHLO mail.ivivity.com") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 10:58:14 +0200 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 04:58:06 -0400 Message-ID: From: Dinesh Nagpure To: 'Dominic Sweetman' , Dinesh Nagpure Cc: linux-mips@linux-mips.org Subject: RE: RM5231A: problems in timer using COUNT/COMPARE register. Date: Tue, 24 Sep 2002 04:57:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dinesh_nagpure@ivivity.com Precedence: bulk X-list: linux-mips Dominic, For the timer to work correctly, boot mode bitstream bit 18 needs to be zero (This in the documentation is marked as reserved) which can cause similar problems. In our case the problem was still different, bumping the PClock to SysClock multiplier to 9 made the timer work. Dinesh -----Original Message----- From: Dominic Sweetman [mailto:dom@algor.co.uk] Sent: Tuesday, September 24, 2002 4:41 AM To: Dinesh Nagpure Cc: linux-mips@linux-mips.org Subject: Re: RM5231A: problems in timer using COUNT/COMPARE register. Dinesh, > I am in the process of porting Linux to our FPGA platform using RM5231A > processor. The COUNT/COMPARE register timer is acting funny with me. When I > set the compare register value to something like 0x0100_0000 or less I get > timer interrupt as expected but if I set the COMPARE register to a greater > value timer interrupt never happens. I have verified this using our boot > loader also and the results are the same. I am waiting for a reply from PMC > but would also like to know if there is anyone out there who faced similar > problems with RM5231A. From data sheets and user manual I know the count > register is 32 bit but apparently there is some hitch somewhere that I need > to discover. I'd be really surprised if there's a hardware bug; the RM5231A is an old core and it always seemed to work. Standard practice is to leave COUNT free-running, and to get timer interrupts by setting COMPARE ahead of it; this relies totally on being able to use the whole range of values, and running seamlessly while COUNT overflows back to zero... Unless you've already done a really low-level, nothing-else-running software sanity check on this, it seems more likely that some piece of software is periodically resetting COUNT, or changing COMPARE, behind your back. Dominic Sweetman MIPS Technologies From macro@ds2.pg.gda.pl Tue Sep 24 13:42:25 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 13:42:26 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:61890 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 13:42:25 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA29466; Tue, 24 Sep 2002 13:42:47 +0200 (MET DST) Date: Tue, 24 Sep 2002 13:42:47 +0200 (MET DST) From: "Maciej W. Rozycki" To: "Kevin D. Kissell" cc: linux-mips@linux-mips.org Subject: Re: FCSR Management In-Reply-To: <008801c2639f$385b1b80$10eca8c0@grendel> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Tue, 24 Sep 2002, Kevin D. Kissell wrote: > dump core, so the user never executes again. But *if* > the user has registered a handler for SIGFPE, and one > of the IEEE exceptions occurs, I don't see where the > associated Cause bit is being cleared, and I would think > that the consequence would be that the process would > get into an endless loop of trapping, posting the signal, > restoring the FCSR from the context with the bits set, > and trapping again, whether or not the PC is modified > to avoid re-executing the faulting instruction. Obviously user code is responsible to clear the bit it acted upon in the saved context. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From kevink@mips.com Tue Sep 24 14:36:26 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 14:36:27 +0200 (CEST) Received: from ftp.mips.com ([206.31.31.227]:33160 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 14:36:26 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8OCZgrZ002710; Tue, 24 Sep 2002 05:35:42 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA14048; Tue, 24 Sep 2002 05:36:00 -0700 (PDT) Message-ID: <00e301c263c7$3cc80b60$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Maciej W. Rozycki" Cc: References: Subject: Re: FCSR Management Date: Tue, 24 Sep 2002 14:37:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips > On Tue, 24 Sep 2002, Kevin D. Kissell wrote: > > > dump core, so the user never executes again. But *if* > > the user has registered a handler for SIGFPE, and one > > of the IEEE exceptions occurs, I don't see where the > > associated Cause bit is being cleared, and I would think > > that the consequence would be that the process would > > get into an endless loop of trapping, posting the signal, > > restoring the FCSR from the context with the bits set, > > and trapping again, whether or not the PC is modified > > to avoid re-executing the faulting instruction. > > Obviously user code is responsible to clear the bit it acted upon in the > saved context. It may be obvious that someone *intended* that user code clear the bit. But the FCSR value containing the trapping condition seems to be saved as part of both the thread and the signal contexts, thus (a) it could be restored as part of the sigcontext load of the signal handler, causing a re-entrant trap, possibly ad infinitum, and (b) will be restored in the thread state after the execution of the signal in any case, since we don't allow signals to have side-effects on the FP register state, including the FCSR. So even if the signal handler executed far enough to clear the relevant Cause bit, it looks to me as if it would simply be re-set the next time the thread loaded the FPU context. I haven't seen anyone complaining about threads hanging when SIGFPE's are being caught, so things may be working somehow - but we may be blundering through some number of spurious traps for no good reason before we get there. I'll be delighted if someone on the list could point out how the probelem is being bypassed.. Kevin K. From jsun@orion.mvista.com Tue Sep 24 19:38:19 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 19:38:20 +0200 (CEST) Received: from gateway-1237.mvista.com ([12.44.186.158]:762 "EHLO orion.mvista.com") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 19:38:19 +0200 Received: (from jsun@localhost) by orion.mvista.com (8.11.6/8.11.6) id g8OHb3q17138; Tue, 24 Sep 2002 10:37:03 -0700 Date: Tue, 24 Sep 2002 10:37:03 -0700 From: Jun Sun To: "Kevin D. Kissell" Cc: linux-mips@linux-mips.org, jsun@mvista.com Subject: Re: FCSR Management Message-ID: <20020924103703.P14312@mvista.com> References: <008801c2639f$385b1b80$10eca8c0@grendel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <008801c2639f$385b1b80$10eca8c0@grendel>; from kevink@mips.com on Tue, Sep 24, 2002 at 09:51:18AM +0200 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jsun@mvista.com Precedence: bulk X-list: linux-mips On Tue, Sep 24, 2002 at 09:51:18AM +0200, Kevin D. Kissell wrote: > In looking at some anomalous behavior on another software > platform, I checked the current MIPS/Linux kernel sources > and I wonder if we don't have yet another FP context problem > lurking under the surface. > > On most, if not all, MIPS CPUs with integrated FPUs, > the act of writing a value to the FP CSR (Control and > Status Register, fcr31) which has the "E" bit, or any matching > pair of Enable/Cause bits for the V/Z/O/U/I IEEE exceptions > set will trigger a floating point exception. In the case of > the Unimplemented Operation exception (the "E" bit), > the emulator is invoked and all of the Cause bits are cleared > in the context before user execution is resumed. In the > case of other FP exceptions, the default behavior is to > dump core, so the user never executes again. But *if* > the user has registered a handler for SIGFPE, and one > of the IEEE exceptions occurs, I don't see where the > associated Cause bit is being cleared, and I would think > that the consequence would be that the process would > get into an endless loop of trapping, posting the signal, > restoring the FCSR from the context with the bits set, > and trapping again, whether or not the PC is modified > to avoid re-executing the faulting instruction. > > Am I missing something, or is this a problem? > FPE exceptions, actually almost all exceptions, are cleared before their handlers are invoked. See kernel/entry.S and look for BUILD_HANDLER(). Those macro defines are really mind-twisting and usually don't show up on grep radar... Jun From kevink@mips.com Tue Sep 24 21:27:18 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Sep 2002 21:27:19 +0200 (CEST) Received: from mx2.mips.com ([206.31.31.227]:34701 "EHLO mx2.mips.com") by linux-mips.org with ESMTP id ; Tue, 24 Sep 2002 21:27:18 +0200 Received: from newman.mips.com (ns-dmz [206.31.31.225]) by mx2.mips.com (8.12.5/8.12.5) with ESMTP id g8OJR7rZ004326; Tue, 24 Sep 2002 12:27:08 -0700 (PDT) Received: from grendel (grendel [192.168.236.16]) by newman.mips.com (8.9.3/8.9.0) with SMTP id MAA28160; Tue, 24 Sep 2002 12:27:26 -0700 (PDT) Message-ID: <002501c26400$b7fc0640$10eca8c0@grendel> From: "Kevin D. Kissell" To: "Jun Sun" Cc: References: <008801c2639f$385b1b80$10eca8c0@grendel> <20020924103703.P14312@mvista.com> Subject: Re: FCSR Management Date: Tue, 24 Sep 2002 21:29:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kevink@mips.com Precedence: bulk X-list: linux-mips From: "Jun Sun" > > Am I missing something, or is this a problem? > > > > FPE exceptions, actually almost all exceptions, are cleared before their > handlers are invoked. See kernel/entry.S and look for BUILD_HANDLER(). > > Those macro defines are really mind-twisting and usually don't show up on > grep radar... Right you are. Thanks. Maciej gave me a bit of a scare there. ;-) In an ideal universe, the unmodified FCSR which is correctly passed as a parameter to handle_fpe() (now that I look at entry.S, it all comes back.. ;-) would be passed on as part of the signal "payload" if SIGFPE is caught, but at least things aren't drastically broken. Kevin K. From adevries@linuxcare.com Thu Sep 26 09:37:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 09:37:13 +0200 (CEST) Received: from mail.linuxcare.com ([216.88.157.164]:10476 "EHLO mail.linuxcare.com") by linux-mips.org with ESMTP id ; Thu, 26 Sep 2002 09:37:12 +0200 Received: from linuxcare.com (dmz-gw.linuxcare.com [216.88.157.161]) by mail.linuxcare.com (Postfix) with ESMTP id E3BDE8FBC2 for ; Thu, 26 Sep 2002 00:31:41 -0700 (PDT) Message-ID: <3D92B80A.3080802@linuxcare.com> Date: Thu, 26 Sep 2002 03:32:26 -0400 From: Alex deVries Organization: Linuxcare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Format of bootable Indy CDs? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adevries@linuxcare.com Precedence: bulk X-list: linux-mips I'm curious about the possibility of making a Linux installer for the Indy that boots from CD; is there any description of the format of bootable IRIX CDs out there? What does the firmware expect? I know that sash is involved somehow... - Alex -- Alex deVries Principal Architect, Linuxcare Canada, Inc. (613) 562 2759 Linuxcare. Simplifying Server Consolidation. From flo@rfc822.org Thu Sep 26 19:11:17 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 19:11:18 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:1298 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Thu, 26 Sep 2002 19:11:17 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 572C5843; Thu, 26 Sep 2002 19:11:10 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 23A9D3717F; Thu, 26 Sep 2002 19:10:33 +0200 (CEST) Date: Thu, 26 Sep 2002 19:10:33 +0200 From: Florian Lohoff To: Alex deVries Cc: linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020926171033.GA13337@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <3D92B80A.3080802@linuxcare.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2002 at 03:32:26AM -0400, Alex deVries wrote: > I'm curious about the possibility of making a Linux installer for the=20 > Indy that boots from CD; is there any description of the format of=20 > bootable IRIX CDs out there? What does the firmware expect? The firmware loads an ecoff file from a volume header - The volume header is a special partition with a "minimalistic" filesystem in it - This can be modified by "dvhtool".=20 I succeeded in booting an indy by creating a fake "volume header" on the ISO filesystem CD. (ISO Specifies the first 8k of an image to be for the bootloader and partitioning etc). Then i created directory entrys for the kernels on the iso in the pseudo volume header. As the ISO filesystems needs all files to be contigues (same for the volume header) the machine was able to boot from the cd although booting the ecoff kernel image including the ramdisk directly. Having a bootloader would be much nicer. > I know that sash is involved somehow... "sash" is proprietary IRIX. The IRIX CDs are EFS BTW. If you plan to work on this - Feel free to come around in Oldenburg this weekend - We will have a Kernel Hacker meeting in the University Oldenburg. I'll bring a Burner and CD-RW's=20 with me to test this. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9kz+JUaz2rXW+gJcRAkXxAJ4vsPIdarEZp/TI7piUGcPdxZy5TQCcC/yf P7lJoos9PlbsMwMxFrzNpIQ= =PE4N -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From adevries@linuxcare.com Thu Sep 26 21:24:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 21:24:59 +0200 (CEST) Received: from mail.linuxcare.com ([216.88.157.164]:5857 "EHLO mail.linuxcare.com") by linux-mips.org with ESMTP id ; Thu, 26 Sep 2002 21:24:58 +0200 Received: from linuxcare.com (dmz-gw.linuxcare.com [216.88.157.161]) by mail.linuxcare.com (Postfix) with ESMTP id 569C78FBD0; Thu, 26 Sep 2002 12:19:25 -0700 (PDT) Message-ID: <3D935DE6.7020206@linuxcare.com> Date: Thu, 26 Sep 2002 15:20:06 -0400 From: Alex deVries Organization: Linuxcare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Lohoff Cc: linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adevries@linuxcare.com Precedence: bulk X-list: linux-mips Florian Lohoff wrote: > The firmware loads an ecoff file from a volume header - The volume > header is a special partition with a "minimalistic" filesystem > in it - This can be modified by "dvhtool". Okay. I see an example of that mentioned in your mail in http://lists.debian.org/debian-mips/2002/debian-mips-200204/msg00056.html . That seems to match with an EFS volume header. So making a tool that writes the 8k volume header is easy. If I understand properly, that points to a filename on the EFS filesystem that follows it. What open source tools do we have to create such an EFS filesystem? > If you plan to work on this - Feel free to come around in > Oldenburg this weekend - We will have a Kernel Hacker meeting > in the University Oldenburg. I'll bring a Burner and CD-RW's > with me to test this. Sadly, I have other plans this weekend. - Alex -- Alex deVries Principal Architect, Linuxcare Canada, Inc. (613) 562 2759 Linuxcare. Simplifying Server Consolidation. From ralf@linux-mips.org Thu Sep 26 22:56:27 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 22:56:28 +0200 (CEST) Received: from p508B7AB5.dip.t-dialin.net ([80.139.122.181]:19332 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 26 Sep 2002 22:56:27 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8QKuCG26843; Thu, 26 Sep 2002 22:56:12 +0200 Date: Thu, 26 Sep 2002 22:56:11 +0200 From: Ralf Baechle To: Alex deVries Cc: Florian Lohoff , linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020926225611.A26300@linux-mips.org> References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> <3D935DE6.7020206@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D935DE6.7020206@linuxcare.com>; from adevries@linuxcare.com on Thu, Sep 26, 2002 at 03:20:06PM -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 26, 2002 at 03:20:06PM -0400, Alex deVries wrote: Nice to hear from you again after years of silence. > So making a tool that writes the 8k volume header is easy. If I > understand properly, that points to a filename on the EFS filesystem > that follows it. > > What open source tools do we have to create such an EFS filesystem? None. The in-kernel EFS filesystem is read-only. Ralf From adevries@linuxcare.com Thu Sep 26 23:07:56 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 23:07:56 +0200 (CEST) Received: from mail.linuxcare.com ([216.88.157.164]:64386 "EHLO mail.linuxcare.com") by linux-mips.org with ESMTP id ; Thu, 26 Sep 2002 23:07:56 +0200 Received: from linuxcare.com (dmz-gw.linuxcare.com [216.88.157.161]) by mail.linuxcare.com (Postfix) with ESMTP id B99928FC6F; Thu, 26 Sep 2002 14:02:23 -0700 (PDT) Message-ID: <3D937609.3010201@linuxcare.com> Date: Thu, 26 Sep 2002 17:03:05 -0400 From: Alex deVries Organization: Linuxcare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Baechle Cc: Florian Lohoff , linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> <3D935DE6.7020206@linuxcare.com> <20020926225611.A26300@linux-mips.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adevries@linuxcare.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Thu, Sep 26, 2002 at 03:20:06PM -0400, Alex deVries wrote >>What open source tools do we have to create such an EFS filesystem? > > None. The in-kernel EFS filesystem is read-only. Okay. Let me look at that. EFS seems pretty simple, but is there a filesystem described apart from the .h files? - Alex -- Alex deVries Principal Architect, Linuxcare Canada, Inc. (613) 562 2759 Linuxcare. Simplifying Server Consolidation. From ralf@linux-mips.org Thu Sep 26 23:32:06 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 26 Sep 2002 23:32:07 +0200 (CEST) Received: from p508B7AB5.dip.t-dialin.net ([80.139.122.181]:42116 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Thu, 26 Sep 2002 23:32:06 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8QLVvo31298; Thu, 26 Sep 2002 23:31:57 +0200 Date: Thu, 26 Sep 2002 23:31:57 +0200 From: Ralf Baechle To: Alex deVries Cc: Florian Lohoff , linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020926233157.A30002@linux-mips.org> References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> <3D935DE6.7020206@linuxcare.com> <20020926225611.A26300@linux-mips.org> <3D937609.3010201@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D937609.3010201@linuxcare.com>; from adevries@linuxcare.com on Thu, Sep 26, 2002 at 05:03:05PM -0400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Sep 26, 2002 at 05:03:05PM -0400, Alex deVries wrote: > > On Thu, Sep 26, 2002 at 03:20:06PM -0400, Alex deVries wrote > >>What open source tools do we have to create such an EFS filesystem? > > > > None. The in-kernel EFS filesystem is read-only. > > Okay. Let me look at that. > > EFS seems pretty simple, but is there a filesystem described apart from > the .h files? No. EFS is not a very complex filesystem, roughly as complex as for example UFS. However later PROMs also know about XFS I think and that's the trivial case. Anyway, as afair the EFS CDROMs are partitioned like disks a bootloader there could also be made to contain something like libext2fs and boot the rest of a ext2 on the CDROM. ISOfs if you have a nice library to use for that. Ralf From flo@rfc822.org Fri Sep 27 00:19:04 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 00:19:05 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:48646 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 00:19:04 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 9683786B; Fri, 27 Sep 2002 00:18:50 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 702303717F; Fri, 27 Sep 2002 00:17:31 +0200 (CEST) Date: Fri, 27 Sep 2002 00:17:31 +0200 From: Florian Lohoff To: Alex deVries Cc: linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020926221731.GA14223@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> <3D935DE6.7020206@linuxcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <3D935DE6.7020206@linuxcare.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2002 at 03:20:06PM -0400, Alex deVries wrote: > Florian Lohoff wrote: > >The firmware loads an ecoff file from a volume header - The volume > >header is a special partition with a "minimalistic" filesystem > >in it - This can be modified by "dvhtool".=20 >=20 > Okay. I see an example of that mentioned in your mail in > http://lists.debian.org/debian-mips/2002/debian-mips-200204/msg00056.html > . That seems to match with an EFS volume header. >=20 > So making a tool that writes the 8k volume header is easy. If I=20 > understand properly, that points to a filename on the EFS filesystem=20 > that follows it. >=20 > What open source tools do we have to create such an EFS filesystem? None .. Its not EFS - The Volume Header filesystem is MUCH simpler ... Look into dvhtool to understand it ... Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9k4d7Uaz2rXW+gJcRAlOiAJ4xYMMdlHJmXQ0Lyynj2oeWn4fSlwCguNvZ im+87WBePnjIgy+M4/GYEZw= =XksZ -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From mikehill@hgeng.com Fri Sep 27 00:30:06 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 00:30:07 +0200 (CEST) Received: from snog.front.onramp.ca ([198.163.180.7]:36295 "HELO snog.front.onramp.ca") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 00:30:06 +0200 Received: (qmail 10288 invoked from network); 26 Sep 2002 22:29:56 -0000 Received: from gateway.hgeng.com (HELO shadowfax.hgeng.com) (199.246.74.82) by 0 with SMTP; 26 Sep 2002 22:29:56 -0000 Received: from [192.168.1.6] (dilbert.hgeng.com [192.168.1.6]) by shadowfax.hgeng.com (8.12.5/8.12.5/Debian-1) with ESMTP id g8QMTsGO019354 for ; Thu, 26 Sep 2002 18:29:54 -0400 Subject: Re: Format of bootable Indy CDs? From: Michael Hill To: linux-mips@linux-mips.org Content-Type: text/plain Organization: Message-Id: <1033079394.1549.28.camel@dilbert.hgeng.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 26 Sep 2002 18:29:54 -0400 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mikehill@hgeng.com Precedence: bulk X-list: linux-mips On Thu, 2002-09-26 at 15:20, Alex deVries wrote: > Florian Lohoff wrote: > > If you plan to work on this - Feel free to come around in > > Oldenburg this weekend - We will have a Kernel Hacker meeting > > in the University Oldenburg. I'll bring a Burner and CD-RW's > > with me to test this. > > Sadly, I have other plans this weekend. I'd like to volunteer. Mike From mips@illuminatus.org Fri Sep 27 02:25:13 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 02:25:14 +0200 (CEST) Received: from h24-83-212-10.vc.shawcable.net ([24.83.212.10]:34555 "EHLO bard.illuminatus.org") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 02:25:13 +0200 Received: from templar ([10.0.0.2]) by bard.illuminatus.org with esmtp (Exim 3.35 #1 (Debian)) id 17ui9o-00055c-00 for ; Thu, 26 Sep 2002 16:34:56 -0700 Subject: Re: Format of bootable Indy CDs? From: Mike Nugent To: linux-mips@linux-mips.org In-Reply-To: <20020926171033.GA13337@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 26 Sep 2002 17:23:32 -0700 Message-Id: <1033086212.13264.26.camel@templar> Mime-Version: 1.0 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mips@illuminatus.org Precedence: bulk X-list: linux-mips Could we not just make an image file with an arcboot header and burn that to cd? On Thu, 2002-09-26 at 10:10, Florian Lohoff wrote: > On Thu, Sep 26, 2002 at 03:32:26AM -0400, Alex deVries wrote: > > I'm curious about the possibility of making a Linux installer for the > > Indy that boots from CD; is there any description of the format of > > bootable IRIX CDs out there? What does the firmware expect? > > The firmware loads an ecoff file from a volume header - The volume > header is a special partition with a "minimalistic" filesystem > in it - This can be modified by "dvhtool". > > I succeeded in booting an indy by creating a fake "volume header" > on the ISO filesystem CD. (ISO Specifies the first 8k of an image > to be for the bootloader and partitioning etc). Then i created > directory entrys for the kernels on the iso in the pseudo > volume header. As the ISO filesystems needs all files to be > contigues (same for the volume header) the machine was able > to boot from the cd although booting the ecoff kernel image > including the ramdisk directly. Having a bootloader would > be much nicer. > > > I know that sash is involved somehow... > > "sash" is proprietary IRIX. The IRIX CDs are EFS BTW. > > If you plan to work on this - Feel free to come around in > Oldenburg this weekend - We will have a Kernel Hacker meeting > in the University Oldenburg. I'll bring a Burner and CD-RW's > with me to test this. > I'd be interested in working on this, but I'm not 100% sure that I know enough about my indigo2 yet. I'll start by seeing what I can do with arcboot. -- Mike Nugent Programmer/Author mike@illuminatus.org "I believe the use of noise to make music will increase until we reach a music produced through the aid of electrical instruments which will make available for musical purposes any and all sounds that can be heard." -- composer John Cage, 1937 From flo@rfc822.org Fri Sep 27 03:53:41 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 03:53:42 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:60168 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 03:53:41 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id E9D01843; Fri, 27 Sep 2002 03:53:34 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 82BCE3717F; Fri, 27 Sep 2002 03:52:54 +0200 (CEST) Date: Fri, 27 Sep 2002 03:52:54 +0200 From: Florian Lohoff To: Mike Nugent Cc: linux-mips@linux-mips.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020927015254.GA23473@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> <20020926171033.GA13337@paradigm.rfc822.org> <1033086212.13264.26.camel@templar> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <1033086212.13264.26.camel@templar> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2002 at 05:23:32PM -0700, Mike Nugent wrote: >=20 > I'd be interested in working on this, but I'm not 100% sure that I know > enough about my indigo2 yet. I'll start by seeing what I can do with > arcboot. >=20 Grab SILO or PALO - Both have enough ISO9660 support to load a file from an ISO image - Then look at the existing ARCBOOT code and make some kind of minimalistic "filesystem detection" of the devices media. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9k7n2Uaz2rXW+gJcRAqcmAKCkWmEp+AuAwWec0Gb1AcU0NeUAVgCgl61P 7shVPlTSOnR9d/wK0EW/vRE= =Nw5y -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From atulsrivastava9@rediffmail.com Fri Sep 27 15:04:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 15:04:59 +0200 (CEST) Received: from webmail23.rediffmail.com ([203.199.83.145]:12196 "HELO webmail23.rediffmail.com") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 15:04:58 +0200 Received: (qmail 4100 invoked by uid 510); 27 Sep 2002 13:09:55 -0000 Date: 27 Sep 2002 13:09:55 -0000 Message-ID: <20020927130955.4099.qmail@webmail23.rediffmail.com> Received: from unknown (202.54.89.85) by rediffmail.com via HTTP; 27 Sep 2002 13:09:55 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: ioremap in MIPS-IDT..? Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips Hello, I am using MIPs-IDT79S334A. just now i noted that there is no ioremap.c file in source tree. this made me to think if physical memory that is normally ioremapped is already a part of processor memory map after startup hence no need to call it explicitly in drivers . Am i thinking right ..? pls let me know . Best Regards, Atul __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From atulsrivastava9@rediffmail.com Fri Sep 27 16:41:29 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 16:41:30 +0200 (CEST) Received: from [203.199.83.245] ([203.199.83.245]:44244 "HELO mailweb33.rediffmail.com") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 16:41:29 +0200 Received: (qmail 23181 invoked by uid 510); 27 Sep 2002 14:46:41 -0000 Date: 27 Sep 2002 14:46:41 -0000 Message-ID: <20020927144641.23180.qmail@mailweb33.rediffmail.com> Received: from unknown (202.54.89.98) by rediffmail.com via HTTP; 27 Sep 2002 14:46:41 -0000 MIME-Version: 1.0 From: "atul srivastava" Reply-To: "atul srivastava" To: linux-mips@linux-mips.org Subject: mips kseg1 mapping.. Content-type: text/plain; format=flowed Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: atulsrivastava9@rediffmail.com Precedence: bulk X-list: linux-mips I am relatively new on MIPS architecture. working on BSP for MIPS R32xx on IDT . i have a basic question. 1.PCI BAR 1 of my eepro100 card has been initialised with address 0x18800100 for 64 bytes. this is a valid PCI IO address as per manual. 2.what i understand is that lower 0 - 512 MB physical is mapped to 0xa000-0000 to 0xb7ff-ffff virtual and also access to this range in uncached. 3.when i am loading my eepro100 driver , in do_eeprom_cmd() when it refers the address( ioaddr + SCBeeprom) my kernel panicks with message "unable to handle kernel paging request at 0xd100010e. this virtual address is in range 0xa000-0000 to 0xb7ff-ffff. now my question is what all i have to do so that this access is passed i mean i get a valid virtual-physical mapping for this address. where i need to take care of kseg1 translation in my BSP Best Regards, Ashish __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From brad@ltc.com Fri Sep 27 17:15:56 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 17:15:57 +0200 (CEST) Received: from vsat-148-63-243-254.c004.g4.mrt.starband.net ([148.63.243.254]:49669 "EHLO lahoo.mshome.net") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 17:15:56 +0200 Received: from prefect.mshome.net ([192.168.0.188] helo=prefect) by lahoo.mshome.net with smtp (Exim 3.12 #1 (Debian)) id 17uwkz-0003OD-00; Fri, 27 Sep 2002 11:10:17 -0400 Message-ID: <048701c26638$bb357640$bc00a8c0@prefect> From: "Bradley D. LaRonde" To: "atul srivastava" , References: <20020927144641.23180.qmail@mailweb33.rediffmail.com> Subject: Re: mips kseg1 mapping.. Date: Fri, 27 Sep 2002 11:15:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: brad@ltc.com Precedence: bulk X-list: linux-mips ----- Original Message ----- From: "atul srivastava" To: Sent: Friday, September 27, 2002 10:46 AM Subject: mips kseg1 mapping.. > 1.PCI BAR 1 of my eepro100 card has been initialised with > address 0x18800100 for 64 bytes. > this is a valid PCI IO address as per manual. > > 2.what i understand is that lower 0 - 512 MB physical is mapped to > 0xa000-0000 to 0xb7ff-ffff virtual and also access to this range > in uncached. > > 3.when i am loading my eepro100 driver , in do_eeprom_cmd() when > it refers the address( ioaddr + SCBeeprom) my kernel panicks with > message "unable to handle kernel paging request at 0xd100010e. > > this virtual address is in range 0xa000-0000 to 0xb7ff-ffff. KSEG1 is always mapped (you can think of it as wired). PCI bus addresses should be remapped through ioremap. Is ioremap returning the address you expect? Regards, Brad From ralf@linux-mips.org Fri Sep 27 17:22:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 17:22:30 +0200 (CEST) Received: from p508B64E2.dip.t-dialin.net ([80.139.100.226]:16525 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 17:22:30 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8RFMJZ01132; Fri, 27 Sep 2002 17:22:19 +0200 Date: Fri, 27 Sep 2002 17:22:19 +0200 From: Ralf Baechle To: atul srivastava Cc: linux-mips@linux-mips.org Subject: Re: mips kseg1 mapping.. Message-ID: <20020927172219.E29970@linux-mips.org> References: <20020927144641.23180.qmail@mailweb33.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020927144641.23180.qmail@mailweb33.rediffmail.com>; from atulsrivastava9@rediffmail.com on Fri, Sep 27, 2002 at 02:46:41PM -0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Sep 27, 2002 at 02:46:41PM -0000, atul srivastava wrote: > 0xa000-0000 to 0xb7ff-ffff virtual and also access to this range > in uncached. > > 3.when i am loading my eepro100 driver , in do_eeprom_cmd() when > it refers the address( ioaddr + SCBeeprom) my kernel panicks with > message "unable to handle kernel paging request at 0xd100010e. > > this virtual address is in range 0xa000-0000 to 0xb7ff-ffff. Your numbers are wrong - KSEG1 is 0xa0000000 to 0xbfffffff. Ralf From ralf@linux-mips.org Fri Sep 27 17:27:40 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 17:27:41 +0200 (CEST) Received: from p508B64E2.dip.t-dialin.net ([80.139.100.226]:23693 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 17:27:40 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8RFRUQ01811; Fri, 27 Sep 2002 17:27:30 +0200 Date: Fri, 27 Sep 2002 17:27:30 +0200 From: Ralf Baechle To: atul srivastava Cc: linux-mips@linux-mips.org Subject: Re: ioremap in MIPS-IDT..? Message-ID: <20020927172730.F29970@linux-mips.org> References: <20020927130955.4099.qmail@webmail23.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020927130955.4099.qmail@webmail23.rediffmail.com>; from atulsrivastava9@rediffmail.com on Fri, Sep 27, 2002 at 01:09:55PM -0000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Sep 27, 2002 at 01:09:55PM -0000, atul srivastava wrote: > just now i noted that there is no ioremap.c file in > source tree. In which case the small green dots on your kernel source tree is the mould. Time for an upgrade :-) Kernel's that don't have arch/mips/mm/ioremap.c can only support ioremap() for physical addresses < 0x20000000. Ralf From hjl@lucon.org Fri Sep 27 17:59:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 17:59:39 +0200 (CEST) Received: from rwcrmhc52.attbi.com ([216.148.227.88]:64967 "EHLO rwcrmhc52.attbi.com") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 17:59:38 +0200 Received: from lucon.org ([12.234.88.146]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020927155930.ITCH1696.rwcrmhc52.attbi.com@lucon.org>; Fri, 27 Sep 2002 15:59:30 +0000 Received: by lucon.org (Postfix, from userid 1000) id 003432C58F; Fri, 27 Sep 2002 08:59:27 -0700 (PDT) Date: Fri, 27 Sep 2002 08:59:27 -0700 From: "H. J. Lu" To: GNU C Library , Kenneth Albanowski , Mat Hostetter , Warner Losh , linux-mips@linux-mips.org, Ron Guilmette , "Polstra; John" , Ralf Baechle , Linas Vepstas , Feher Janos , Leonard Zubkoff , "Steven J. Hill" , gcc@gcc.gnu.org Subject: Re: The untested Linux binutils 2.13.90.0.5 Message-ID: <20020927085927.A3790@lucon.org> References: <20020927084523.A3538@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020927084523.A3538@lucon.org>; from hjl@lucon.org on Fri, Sep 27, 2002 at 08:45:23AM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips On Fri, Sep 27, 2002 at 08:45:23AM -0700, H. J. Lu wrote: > The last Linux binutils was made more than a month ago. Now it is the > time for a new one. However, the current binutils in CVS is unstable. > I put the untested Linux binutils 2.13.90.0.5 at > > http://ftp.kernel.org/pub/linux/devel/binutils/binutils-2.13.90.0.5.tar.gz > > It is based on binutils 2002 0927 in CVS on sourecs.redhat.com. Give it > a try if you need the new features in it. Please report any problems to > hjl@lucon.org. > > Thanks. > Ooops. It is at http://ftp.kernel.org/pub/linux/devel/binutils/test/binutils-2.13.90.0.5.tar.gz H.J. From flo@rfc822.org Fri Sep 27 18:01:15 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 18:01:16 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:49936 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 18:01:15 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 10F22805; Fri, 27 Sep 2002 18:01:08 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3A4593717F; Fri, 27 Sep 2002 18:00:00 +0200 (CEST) Date: Fri, 27 Sep 2002 18:00:00 +0200 From: Florian Lohoff To: Alex deVries Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020927160000.GB622@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p4qYPpj5QlsIQJ0K" Content-Disposition: inline In-Reply-To: <3D92B80A.3080802@linuxcare.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --p4qYPpj5QlsIQJ0K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 26, 2002 at 03:32:26AM -0400, Alex deVries wrote: > I'm curious about the possibility of making a Linux installer for the=20 > Indy that boots from CD; is there any description of the format of=20 > bootable IRIX CDs out there? What does the firmware expect? >=20 > I know that sash is involved somehow... Ok - i reworked the procedure a bit whil beeing in Oldenburg. flo@split:~/projects/boot$ mkisofs -J -R -V testboot -o iso tftpboot-r4k-ip22.img Total translation table size: 0 Total rockridge attributes bytes: 262 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 6644 2208 extents written (4 Mb) flo@split:~/projects/boot$ isoinfo -l -R -i iso Directory listing of / dr-xr-xr-x 2 1750 1750 2048 Sep 27 2002 [ 28] . ?--------- 0 1750 1750 2048 Sep 27 2002 [ 28] .. -rwxr-xr-x 1 1750 1750 4414116 Sep 12 2002 [ 31] tftpboot-r4k= -ip22.img flo@split:~/projects/boot$ echo $[ 31 * 4 ] 124 flo@split:~/projects/boot$ genisovh-0.1/genisovh iso sashARCS:124,4414116 i= p22:124,4414116 The last command adds a "volume header" in the first 512 byte into the iso file. This volume header spans the whole iso filesystem and lists 2 files at identical positions which is the ECOFF tftpboot-r4k-ip22.img. The name sashARCS is coded in the Indys prom for the installer when using your mouse and "Install System Software" and "Local cdrom". Now one needs to write a wrapper for the Indy bootfloppys aka debian-cd to produce bootable cds. I put up the stuff: http://www.silicon-verl.de/home/flo/software/ip22test.iso http://www.silicon-verl.de/home/flo/software/genisovh-0.1.tgz Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --p4qYPpj5QlsIQJ0K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lIB/Uaz2rXW+gJcRAnNkAJ4zOvuP8eE2GGRCmGpzvbAtjxj54wCbBY+8 se/imWqY7jgWl+vCfI8OXkc= =K1vg -----END PGP SIGNATURE----- --p4qYPpj5QlsIQJ0K-- From flo@rfc822.org Fri Sep 27 18:07:27 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 18:07:28 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:57104 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 18:07:27 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id BD255873; Fri, 27 Sep 2002 18:07:21 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id AE97A3717F; Fri, 27 Sep 2002 18:06:43 +0200 (CEST) Date: Fri, 27 Sep 2002 18:06:43 +0200 From: Florian Lohoff To: Alex deVries Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020927160643.GA6960@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> <20020927160000.GB622@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20020927160000.GB622@paradigm.rfc822.org> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2002 at 06:00:00PM +0200, Florian Lohoff wrote: > Now one needs to write a wrapper for the Indy bootfloppys aka debian-cd > to produce bootable cds. >=20 > I put up the stuff: >=20 > http://www.silicon-verl.de/home/flo/software/ip22test.iso > http://www.silicon-verl.de/home/flo/software/genisovh-0.1.tgz BTW: I was not able to boot from a cd-rom drive which was not able to=20 read 512 byte blocked. Burning on a 2048 byte blocked burner is no problem though. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lIITUaz2rXW+gJcRAo/SAJ4rZijUHkiLtLA7ZWDGbKrKyJX7UwCeLoFe ZoI1TCsLTd+CzX+kjbPIvLY= =1VXW -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From flo@rfc822.org Fri Sep 27 18:10:44 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 18:10:45 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:58384 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 18:10:44 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 09DCA873; Fri, 27 Sep 2002 18:10:39 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5C3FB3717F; Fri, 27 Sep 2002 18:07:37 +0200 (CEST) Date: Fri, 27 Sep 2002 18:07:37 +0200 From: Florian Lohoff To: William Jhun Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] ip22 console selection fixes Message-ID: <20020927160737.GB6960@paradigm.rfc822.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E39vaYmALEf/7YXx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --E39vaYmALEf/7YXx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 05:11:21AM -0400, William Jhun wrote: > This patch fixes some problems in selecting which console to use on the > ip22s. >=20 > - Replace unobvious ttyS with arc for the arc console device name > - If ARC var console=3Dd*, use serial. If 'g', use Newport only. If > neither or not set, default to ARC. Old code was disabling ARC > console and using serial console if CONFIG_ARC_CONSOLE was set. (why?!) > - ArcGetEnvironmentVariable() can conceivably return NULL, so don't > blindly dereference. >=20 After trying this patch or better current CVS i see the point - Ralf - This patch should go in - Otherwise the whole console stuff is broken on the Indy. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --E39vaYmALEf/7YXx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lIJJUaz2rXW+gJcRAihbAKCtarT2EuE7CtCi9V6zMTupqjRoLQCfTQkU VkjKcrjQI8Z6mdL0V6r2Qzo= =wtt+ -----END PGP SIGNATURE----- --E39vaYmALEf/7YXx-- From adevries@linuxcare.com Fri Sep 27 18:27:28 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 18:27:28 +0200 (CEST) Received: from mail.linuxcare.com ([216.88.157.164]:16299 "EHLO mail.linuxcare.com") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 18:27:28 +0200 Received: from linuxcare.com (dmz-gw.linuxcare.com [216.88.157.161]) by mail.linuxcare.com (Postfix) with ESMTP id 54D0F8FBC1; Fri, 27 Sep 2002 09:21:47 -0700 (PDT) Message-ID: <3D9485C8.90301@linuxcare.com> Date: Fri, 27 Sep 2002 12:22:32 -0400 From: Alex deVries Organization: Linuxcare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Lohoff Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? References: <3D92B80A.3080802@linuxcare.com> <20020927160000.GB622@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adevries@linuxcare.com Precedence: bulk X-list: linux-mips Florian, Cool! As soon as I can find a 512-byte ro CDROM, I'll try this. I've got part of mkefs working, BTW, which I realize is not required to make bootable CDs, but might be helpful anyway. - Alex Florian Lohoff wrote: > On Thu, Sep 26, 2002 at 03:32:26AM -0400, Alex deVries wrote: > >>I'm curious about the possibility of making a Linux installer for the >>Indy that boots from CD; is there any description of the format of >>bootable IRIX CDs out there? What does the firmware expect? >> >>I know that sash is involved somehow... > > > Ok - i reworked the procedure a bit whil beeing in Oldenburg. > > flo@split:~/projects/boot$ mkisofs -J -R -V testboot -o iso > tftpboot-r4k-ip22.img > Total translation table size: 0 > Total rockridge attributes bytes: 262 > Total directory bytes: 0 > Path table size(bytes): 10 > Max brk space used 6644 > 2208 extents written (4 Mb) > flo@split:~/projects/boot$ isoinfo -l -R -i iso > > Directory listing of / > dr-xr-xr-x 2 1750 1750 2048 Sep 27 2002 [ 28] . > ?--------- 0 1750 1750 2048 Sep 27 2002 [ 28] .. > -rwxr-xr-x 1 1750 1750 4414116 Sep 12 2002 [ 31] tftpboot-r4k-ip22.img > flo@split:~/projects/boot$ echo $[ 31 * 4 ] > 124 > flo@split:~/projects/boot$ genisovh-0.1/genisovh iso sashARCS:124,4414116 ip22:124,4414116 > > The last command adds a "volume header" in the first 512 byte into the > iso file. This volume header spans the whole iso filesystem and lists 2 > files at identical positions which is the ECOFF tftpboot-r4k-ip22.img. > The name sashARCS is coded in the Indys prom for the installer when > using your mouse and "Install System Software" and "Local cdrom". > > Now one needs to write a wrapper for the Indy bootfloppys aka debian-cd > to produce bootable cds. > > I put up the stuff: > > http://www.silicon-verl.de/home/flo/software/ip22test.iso > http://www.silicon-verl.de/home/flo/software/genisovh-0.1.tgz > > Flo -- Alex deVries Principal Architect, Linuxcare Canada, Inc. (613) 562 2759 Linuxcare. Simplifying Server Consolidation. From lsorense@opengraphics.com Fri Sep 27 19:20:32 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 19:20:32 +0200 (CEST) Received: from opengraphics.com ([216.208.162.194]:59665 "EHLO hurricane.opengraphics.com") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 19:20:32 +0200 Received: from lsorense by hurricane.opengraphics.com with local (Exim 3.35 #1 (Debian)) id 17uyml-0001uT-00; Fri, 27 Sep 2002 13:20:15 -0400 Date: Fri, 27 Sep 2002 13:20:15 -0400 To: Alex deVries Cc: Florian Lohoff , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020927172015.GI17028@opengraphics.com> References: <3D92B80A.3080802@linuxcare.com> <20020927160000.GB622@paradigm.rfc822.org> <3D9485C8.90301@linuxcare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D9485C8.90301@linuxcare.com> User-Agent: Mutt/1.3.28i From: Len Sorensen X-Scanner: exiscan *17uyml-0001uT-00*cQpEiE9uFLQ* (OpenGraphics Corp, Toronto, Canada) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: lsorense@opengraphics.com Precedence: bulk X-list: linux-mips On Fri, Sep 27, 2002 at 12:22:32PM -0400, Alex deVries wrote: > Cool! As soon as I can find a 512-byte ro CDROM, I'll try this. > > I've got part of mkefs working, BTW, which I realize is not required to > make bootable CDs, but might be helpful anyway. Any plextor scsi drive should do. It has a jumper to enable 512byte block access. They can be bought for fairly cheap for read only drives. Len Sorensen From gerald.champagne@esstech.com Fri Sep 27 22:56:53 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 22:56:54 +0200 (CEST) Received: from mail.esstech.com ([64.152.86.3]:6206 "HELO [64.152.86.3]") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 22:56:53 +0200 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; Fri, 27 Sep 2002 13:56:52 -0700 Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.12.2/8.12.2) with SMTP id g8RKvc0A015889 for ; Fri, 27 Sep 2002 13:57:38 -0700 (PDT) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id NAA02926; Fri, 27 Sep 2002 13:55:49 -0700 Received: from [193.5.206.150] by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id PAA24928; Fri, 27 Sep 2002 15:47:16 -0500 Subject: [PATCH] show register names in show_regs From: Gerald Champagne To: Linux Mips Mailing List Content-Type: multipart/mixed; boundary="=-5vVoK+lbMkeNgBDv4NHI" X-Mailer: Ximian Evolution 1.0.8 Date: 27 Sep 2002 15:47:08 -0500 Message-Id: <1033159633.26894.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gerald.champagne@esstech.com Precedence: bulk X-list: linux-mips --=-5vVoK+lbMkeNgBDv4NHI Content-Type: text/plain Content-Transfer-Encoding: 7bit The following trivial patch makes show_regs display register names before each value. I find this format much faster to read when comparing register dumps to assembly code. The results look like this: $0: at=00000000 v0=90008400 v1=00000037 $4: a0=8023a934 a1=00000001 a2=81275e64 a3=00000562 $8: t0=00000562 t1=81275d38 t2=7a797877 t3=4a494847 $12: t4=80268356 t5=fffffffe t6=00000010 t7=4e4d4c4b $16: s0=ffffffff s1=b8000800 s2=802647b0 s3=00000000 $20: s4=00000000 s5=00000000 s6=00000004 s7=000000ff $24: t8=ffffffff t9=00000001 k0=........ k1=........ $28: gp=81274000 sp=81275e20 fp=00000000 ra=80211c6c Is this acceptable, or do people prefer the existing method without the register names? Gerald --=-5vVoK+lbMkeNgBDv4NHI Content-Disposition: attachment; filename=show_regs.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=show_regs.patch; charset=ISO-8859-1 --- linux.orig/arch/mips/kernel/traps.c Sun Dec 2 05:34:38 2001 +++ linux/arch/mips/kernel/traps.c Fri Sep 27 15:28:08 2002 @@ -291,17 +291,21 @@ /* * Saved main processor registers */ - printk("$0 : %08x %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - 0, regs->regs[1], regs->regs[2], regs->regs[3], + printk(" $0: at=3D%08lx v0=3D%08lx v1=3D%08lx\n", + 0, regs->regs[1], regs->regs[2], regs->regs[3]); + printk(" $4: a0=3D%08lx a1=3D%08lx a2=3D%08lx a3=3D%08lx\n", regs->regs[4], regs->regs[5], regs->regs[6], regs->regs[7]); - printk("$8 : %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11], + printk(" $8: t0=3D%08lx t1=3D%08lx t2=3D%08lx t3=3D%08lx\n", + regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11]); + printk("$12: t4=3D%08lx t5=3D%08lx t6=3D%08lx t7=3D%08lx\n", regs->regs[12], regs->regs[13], regs->regs[14], regs->regs[= 15]); - printk("$16: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19], + printk("$16: s0=3D%08lx s1=3D%08lx s2=3D%08lx s3=3D%08lx\n", + regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19]); + printk("$20: s4=3D%08lx s5=3D%08lx s6=3D%08lx s7=3D%08lx\n", regs->regs[20], regs->regs[21], regs->regs[22], regs->regs[= 23]); - printk("$24: %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[24], regs->regs[25], + printk("$24: t8=3D%08lx t9=3D%08lx k0=3D........ k1=3D........\n", + regs->regs[24], regs->regs[25]); + printk("$28: gp=3D%08lx sp=3D%08lx fp=3D%08lx ra=3D%08lx\n", regs->regs[28], regs->regs[29], regs->regs[30], regs->regs[31]); printk("Hi : %08lx\n", regs->hi); printk("Lo : %08lx\n", regs->lo); --=-5vVoK+lbMkeNgBDv4NHI-- From gerald.champagne@esstech.com Fri Sep 27 23:04:55 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:04:56 +0200 (CEST) Received: from mail.esstech.com ([64.152.86.3]:4940 "HELO [64.152.86.3]") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 23:04:55 +0200 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; Fri, 27 Sep 2002 14:04:54 -0700 Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.12.2/8.12.2) with SMTP id g8RL5f0A016591 for ; Fri, 27 Sep 2002 14:05:41 -0700 (PDT) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id OAA02930; Fri, 27 Sep 2002 14:03:53 -0700 Received: from [193.5.206.150] by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id PAA24976; Fri, 27 Sep 2002 15:55:19 -0500 Subject: Re: [PATCH] show register names in show_regs From: Gerald Champagne To: Linux Mips Mailing List In-Reply-To: <1033159633.26894.50.camel@localhost.localdomain> References: <1033159633.26894.50.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-8UcRJplF+BLpBd2GsULP" X-Mailer: Ximian Evolution 1.0.8 Date: 27 Sep 2002 15:55:11 -0500 Message-Id: <1033160116.26894.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gerald.champagne@esstech.com Precedence: bulk X-list: linux-mips --=-8UcRJplF+BLpBd2GsULP Content-Type: text/plain Content-Transfer-Encoding: 7bit Oops, the last patch has a stupid mistake displaying r1-r3. Fixed patch attached. Gerald On Fri, 2002-09-27 at 15:47, Gerald Champagne wrote: > The following trivial patch makes show_regs display register names > before each value. I find this format much faster to read when > comparing register dumps to assembly code. The results look like this: > > $0: at=00000000 v0=90008400 v1=00000037 > $4: a0=8023a934 a1=00000001 a2=81275e64 a3=00000562 > $8: t0=00000562 t1=81275d38 t2=7a797877 t3=4a494847 > $12: t4=80268356 t5=fffffffe t6=00000010 t7=4e4d4c4b > $16: s0=ffffffff s1=b8000800 s2=802647b0 s3=00000000 > $20: s4=00000000 s5=00000000 s6=00000004 s7=000000ff > $24: t8=ffffffff t9=00000001 k0=........ k1=........ > $28: gp=81274000 sp=81275e20 fp=00000000 ra=80211c6c > > Is this acceptable, or do people prefer the existing method without the > register names? > > Gerald > > > ---- > > --- linux.orig/arch/mips/kernel/traps.c Sun Dec 2 05:34:38 2001 > +++ linux/arch/mips/kernel/traps.c Fri Sep 27 15:28:08 2002 > @@ -291,17 +291,21 @@ > /* > * Saved main processor registers > */ > - printk("$0 : %08x %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", > - 0, regs->regs[1], regs->regs[2], regs->regs[3], > + printk(" $0: at=%08lx v0=%08lx v1=%08lx\n", > + 0, regs->regs[1], regs->regs[2], regs->regs[3]); > + printk(" $4: a0=%08lx a1=%08lx a2=%08lx a3=%08lx\n", > regs->regs[4], regs->regs[5], regs->regs[6], regs->regs[7]); > - printk("$8 : %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", > - regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11], > + printk(" $8: t0=%08lx t1=%08lx t2=%08lx t3=%08lx\n", > + regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11]); > + printk("$12: t4=%08lx t5=%08lx t6=%08lx t7=%08lx\n", > regs->regs[12], regs->regs[13], regs->regs[14], regs->regs[15]); > - printk("$16: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", > - regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19], > + printk("$16: s0=%08lx s1=%08lx s2=%08lx s3=%08lx\n", > + regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19]); > + printk("$20: s4=%08lx s5=%08lx s6=%08lx s7=%08lx\n", > regs->regs[20], regs->regs[21], regs->regs[22], regs->regs[23]); > - printk("$24: %08lx %08lx %08lx %08lx %08lx %08lx\n", > - regs->regs[24], regs->regs[25], > + printk("$24: t8=%08lx t9=%08lx k0=........ k1=........\n", > + regs->regs[24], regs->regs[25]); > + printk("$28: gp=%08lx sp=%08lx fp=%08lx ra=%08lx\n", > regs->regs[28], regs->regs[29], regs->regs[30], regs->regs[31]); > printk("Hi : %08lx\n", regs->hi); > printk("Lo : %08lx\n", regs->lo); --=-8UcRJplF+BLpBd2GsULP Content-Disposition: attachment; filename=show_regs.patch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=show_regs.patch; charset=ISO-8859-1 --- linux.orig/arch/mips/kernel/traps.c Sun Dec 2 05:34:38 2001 +++ linux/arch/mips/kernel/traps.c Fri Sep 27 15:51:06 2002 @@ -291,17 +291,21 @@ /* * Saved main processor registers */ - printk("$0 : %08x %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - 0, regs->regs[1], regs->regs[2], regs->regs[3], + printk(" $0: at=3D%08lx v0=3D%08lx v1=3D%08lx\n", + regs->regs[1], regs->regs[2], regs->regs[3]); + printk(" $4: a0=3D%08lx a1=3D%08lx a2=3D%08lx a3=3D%08lx\n", regs->regs[4], regs->regs[5], regs->regs[6], regs->regs[7]); - printk("$8 : %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11], + printk(" $8: t0=3D%08lx t1=3D%08lx t2=3D%08lx t3=3D%08lx\n", + regs->regs[8], regs->regs[9], regs->regs[10], regs->regs[11]); + printk("$12: t4=3D%08lx t5=3D%08lx t6=3D%08lx t7=3D%08lx\n", regs->regs[12], regs->regs[13], regs->regs[14], regs->regs[= 15]); - printk("$16: %08lx %08lx %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19], + printk("$16: s0=3D%08lx s1=3D%08lx s2=3D%08lx s3=3D%08lx\n", + regs->regs[16], regs->regs[17], regs->regs[18], regs->regs[19]); + printk("$20: s4=3D%08lx s5=3D%08lx s6=3D%08lx s7=3D%08lx\n", regs->regs[20], regs->regs[21], regs->regs[22], regs->regs[= 23]); - printk("$24: %08lx %08lx %08lx %08lx %08lx %08lx\n", - regs->regs[24], regs->regs[25], + printk("$24: t8=3D%08lx t9=3D%08lx k0=3D........ k1=3D........\n", + regs->regs[24], regs->regs[25]); + printk("$28: gp=3D%08lx sp=3D%08lx fp=3D%08lx ra=3D%08lx\n", regs->regs[28], regs->regs[29], regs->regs[30], regs->regs[31]); printk("Hi : %08lx\n", regs->hi); printk("Lo : %08lx\n", regs->lo); --=-8UcRJplF+BLpBd2GsULP-- From adevries@linuxcare.com Fri Sep 27 23:13:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:13:10 +0200 (CEST) Received: from mail.linuxcare.com ([216.88.157.164]:18903 "EHLO mail.linuxcare.com") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 23:13:09 +0200 Received: from linuxcare.com (dmz-gw.linuxcare.com [216.88.157.161]) by mail.linuxcare.com (Postfix) with ESMTP id 0A60D8FC18; Fri, 27 Sep 2002 14:07:32 -0700 (PDT) Message-ID: <3D94C8BF.5090902@linuxcare.com> Date: Fri, 27 Sep 2002 17:08:15 -0400 From: Alex deVries Organization: Linuxcare User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Lohoff Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? References: <3D92B80A.3080802@linuxcare.com> <20020927160000.GB622@paradigm.rfc822.org> <20020927160643.GA6960@paradigm.rfc822.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: adevries@linuxcare.com Precedence: bulk X-list: linux-mips Florian Lohoff wrote: > BTW: I was not able to boot from a cd-rom drive which was not able to > read 512 byte blocked. Burning on a 2048 byte blocked burner is no > problem though. I have a cdrom connected to my Indy which has been configured to 512. I think this hw is good, but will double check when I find an IRIX CD. When I boot, it complains "invalid partition". I wrote the ISO you posted on an i386 box with cdrecord. I suspect my problem I didn't use set the blocksize to 512; exactly how did you burn this CD? - Alex -- Alex deVries Principal Architect, Linuxcare Canada, Inc. (613) 562 2759 Linuxcare. Simplifying Server Consolidation. From macro@ds2.pg.gda.pl Fri Sep 27 23:18:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:18:07 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:7418 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 23:18:07 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA23269; Fri, 27 Sep 2002 23:18:25 +0200 (MET DST) Date: Fri, 27 Sep 2002 23:18:24 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Gerald Champagne cc: Linux Mips Mailing List Subject: Re: [PATCH] show register names in show_regs In-Reply-To: <1033159633.26894.50.camel@localhost.localdomain> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On 27 Sep 2002, Gerald Champagne wrote: > The following trivial patch makes show_regs display register names > before each value. I find this format much faster to read when > comparing register dumps to assembly code. The results look like this: [...] > Is this acceptable, or do people prefer the existing method without the > register names? Note that the format is selected to optimize the space consumed as a serial console is not always available and it's better not to let some essential information scroll away from the virtual terminal. Also ksymoops will probably be unhappy with format changes (though it tries to be flexible, so it might actually survive). How about writing a small program or a script that would parse register dumps and output them in your favourite layout? -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From flo@rfc822.org Fri Sep 27 23:18:46 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:18:46 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:18707 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 23:18:46 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 53130873; Fri, 27 Sep 2002 23:18:40 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id EE51E3717F; Fri, 27 Sep 2002 23:17:59 +0200 (CEST) Date: Fri, 27 Sep 2002 23:17:59 +0200 From: Florian Lohoff To: Alex deVries Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? Message-ID: <20020927211759.GC7706@paradigm.rfc822.org> References: <3D92B80A.3080802@linuxcare.com> <20020927160000.GB622@paradigm.rfc822.org> <20020927160643.GA6960@paradigm.rfc822.org> <3D94C8BF.5090902@linuxcare.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NU0Ex4SbNnrxsi6C" Content-Disposition: inline In-Reply-To: <3D94C8BF.5090902@linuxcare.com> User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --NU0Ex4SbNnrxsi6C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 27, 2002 at 05:08:15PM -0400, Alex deVries wrote: > I have a cdrom connected to my Indy which has been configured to 512. I= =20 > think this hw is good, but will double check when I find an IRIX CD.=20 > When I boot, it complains "invalid partition". >=20 > I wrote the ISO you posted on an i386 box with cdrecord. I suspect my=20 > problem I didn't use set the blocksize to 512; exactly how did you burn= =20 > this CD? cdrecord with xcdroast - But burning does not care about block sizes it seems. Can you try to dump the volume header with "decodevh" from http://amaya.mediaways.net/homes/flo/software/decodevh.tgz Compile and decode with devodevh /dev/scd0 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --NU0Ex4SbNnrxsi6C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lMsHUaz2rXW+gJcRAk7ZAJ4mTb0zMVs0ldgzjsS9bFywjoIW2gCfa2eq t3xg/bM7d5PBJRAqq6m9yVc= =iuu9 -----END PGP SIGNATURE----- --NU0Ex4SbNnrxsi6C-- From macro@ds2.pg.gda.pl Fri Sep 27 23:51:38 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:51:39 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:46586 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Fri, 27 Sep 2002 23:51:38 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA23848; Fri, 27 Sep 2002 23:52:00 +0200 (MET DST) Date: Fri, 27 Sep 2002 23:51:59 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Alex deVries cc: Florian Lohoff , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Format of bootable Indy CDs? In-Reply-To: <3D94C8BF.5090902@linuxcare.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Fri, 27 Sep 2002, Alex deVries wrote: > I wrote the ISO you posted on an i386 box with cdrecord. I suspect my > problem I didn't use set the blocksize to 512; exactly how did you burn > this CD? Blocks on CD media are always 2048 bytes long (disregarding correction data). The 512-byte block size as implemented by a few CD drives is simply an ability to present chunks of native blocks in 512-byte amounts. This is just an artifical feature to fulfill a requirement of broken firmware that asserts that disks have 512-byte sectors. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From gerald.champagne@esstech.com Fri Sep 27 23:51:58 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 27 Sep 2002 23:51:58 +0200 (CEST) Received: from mail.esstech.com ([64.152.86.3]:2720 "HELO [64.152.86.3]") by linux-mips.org with SMTP id ; Fri, 27 Sep 2002 23:51:52 +0200 Received: from mail.esstech.com by [64.152.86.3] via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; Fri, 27 Sep 2002 14:51:51 -0700 Received: from venus (venus.esstech.com [193.5.205.5]) by mail.esstech.com (8.12.2/8.12.2) with SMTP id g8RLqa0A020533; Fri, 27 Sep 2002 14:52:36 -0700 (PDT) Received: from bud.austin.esstech.com by venus (SMI-8.6/SMI-SVR4) id OAA02950; Fri, 27 Sep 2002 14:50:49 -0700 Received: from [193.5.206.150] by bud.austin.esstech.com (SMI-8.6/SMI-SVR4) id QAA25279; Fri, 27 Sep 2002 16:42:13 -0500 Subject: Re: [PATCH] show register names in show_regs From: Gerald Champagne To: "Maciej W. Rozycki" Cc: Linux Mips Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 27 Sep 2002 16:42:06 -0500 Message-Id: <1033162931.2314.103.camel@localhost.localdomain> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: gerald.champagne@esstech.com Precedence: bulk X-list: linux-mips > Note that the format is selected to optimize the space consumed as a > serial console is not always available and it's better not to let some > essential information scroll away from the virtual terminal. Ah, I only use a serial console and I forgot about people that can't scroll back. > Also > ksymoops will probably be unhappy with format changes (though it tries to > be flexible, so it might actually survive). I thought that the scripts only used the stack values. Now I see that it seems to read ra as well. But it does still work, for what it's worth... > How about writing a small > program or a script that would parse register dumps and output them in > your favourite layout? I just wanted something simple that I could use in real-time without processing. Thanks for the information. Now I know why it's done the way it's done. Gerald From mdharm@momenco.com Sat Sep 28 02:55:01 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 02:55:02 +0200 (CEST) Received: from jeeves.momenco.com ([64.169.228.99]:12555 "EHLO host099.momenco.com") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 02:55:01 +0200 Received: from beagle (natbox.momenco.com [64.169.228.98]) by host099.momenco.com (8.11.6/8.11.6) with SMTP id g8S0sr617800; Fri, 27 Sep 2002 17:54:53 -0700 From: "Matthew Dharm" To: "Ralf Baechle" Cc: "Linux-MIPS" Subject: PATCH: Momentum Computer Ocelot-G: fix memory and reset Date: Fri, 27 Sep 2002 17:54:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mdharm@momenco.com Precedence: bulk X-list: linux-mips Ralf -- The attached patch fixes kernels on boards with 512MByte of memory. It also allows software reboot to work. Please apply to the 2.4 and 2.5 branches. Matthew Dharm -- Matthew D. Dharm Senior Software Designer Momentum Computer Inc. 1815 Aston Ave. Suite 107 (760) 431-8663 X-115 Carlsbad, CA 92008-7310 Momentum Works For You www.momenco.com From flo@rfc822.org Sat Sep 28 04:00:37 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 04:00:38 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:24069 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Sat, 28 Sep 2002 04:00:37 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 999FF874; Sat, 28 Sep 2002 04:00:30 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 457EA3717F; Sat, 28 Sep 2002 03:59:47 +0200 (CEST) Date: Sat, 28 Sep 2002 03:59:47 +0200 From: Florian Lohoff To: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: [PATCH] dec_esp.c repair mmu_sglist breakage Message-ID: <20020928015947.GE7706@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/aVve/J9H4Wl5yVO" Content-Disposition: inline User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --/aVve/J9H4Wl5yVO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, through the whole issue of the mmu_sglist confusion and the broken reimplantation of mmu_sglist the dec_esp broke. Here is a fix to really remove the mmu_sglist and use scatterlist instead. With this the Decstation on this desk at least finds its partitions again and does not crash. I vote for removal of the struct mmu_sglist as at least it now breaks on compile time and not confusion at runtime. Flo Index: drivers/scsi/dec_esp.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvs/linux/drivers/scsi/dec_esp.c,v retrieving revision 1.10.2.3 diff -u -r1.10.2.3 dec_esp.c --- drivers/scsi/dec_esp.c 23 Aug 2002 09:49:51 -0000 1.10.2.3 +++ drivers/scsi/dec_esp.c 28 Sep 2002 01:57:16 -0000 @@ -443,13 +443,13 @@ =20 static void dma_mmu_get_scsi_sgl(struct NCR_ESP *esp, Scsi_Cmnd * sp) { - int sz =3D sp->SCp.buffers_residual; - struct mmu_sglist *sg =3D (struct mmu_sglist *) sp->SCp.buffer; + int sz =3D sp->SCp.buffers_residual; + struct scatterlist *sg =3D sp->SCp.buffer; =20 - while (sz >=3D 0) { - sg[sz].dvma_addr =3D PHYSADDR(sg[sz].addr); - sz--; - } + while (sz >=3D 0) { + sg[sz].dma_address =3D PHYSADDR(sg[sz].address); + sz--; + } sp->SCp.ptr =3D (char *) ((unsigned long) sp->SCp.buffer->dma_address); } =20 Index: include/asm-mips/scatterlist.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvs/linux/include/asm-mips/scatterlist.h,v retrieving revision 1.4.2.3 diff -u -r1.4.2.3 scatterlist.h --- include/asm-mips/scatterlist.h 23 Aug 2002 09:50:00 -0000 1.4.2.3 +++ include/asm-mips/scatterlist.h 28 Sep 2002 01:57:16 -0000 @@ -10,13 +10,6 @@ unsigned int length; }; =20 -struct mmu_sglist { - char *addr; - char *__dont_touch; - unsigned int len; - dma_addr_t dvma_addr; -}; - #define ISA_DMA_THRESHOLD (0x00ffffff) =20 #endif /* __ASM_SCATTERLIST_H */ --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --/aVve/J9H4Wl5yVO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lQ0TUaz2rXW+gJcRAnqWAKC1EaCQjU1YW4UARbtstA5vhExPXACdFqXQ IzlvwvEoW6KLuRuvs28qTpI= =jwL+ -----END PGP SIGNATURE----- --/aVve/J9H4Wl5yVO-- From hjl@lucon.org Sat Sep 28 09:34:19 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 09:34:20 +0200 (CEST) Received: from rwcrmhc52.attbi.com ([216.148.227.88]:48602 "EHLO rwcrmhc52.attbi.com") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 09:34:19 +0200 Received: from lucon.org ([12.234.88.146]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020928073412.MLIN1696.rwcrmhc52.attbi.com@lucon.org>; Sat, 28 Sep 2002 07:34:12 +0000 Received: by lucon.org (Postfix, from userid 1000) id CA0592C593; Sat, 28 Sep 2002 00:34:11 -0700 (PDT) Date: Sat, 28 Sep 2002 00:34:11 -0700 From: "H. J. Lu" To: linux-mips@linux-mips.org Cc: Ralf Baechle Subject: Re: Does swap on IDE HD work on malta/mipsel? Message-ID: <20020928003411.A18015@lucon.org> References: <20020927230307.A4100@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020927230307.A4100@lucon.org>; from hjl@lucon.org on Fri, Sep 27, 2002 at 11:03:07PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips On Fri, Sep 27, 2002 at 11:03:07PM -0700, H. J. Lu wrote: > I compiled today's 2.4 kernel from CVS. Swap on IDE HD doesn't work. I > got > > # mkswap /dev/hda3 > Setting up swapspace version 1, size = 512060K > # swapon /dev/hda3 > swapon: /dev/hda3: Invalid argument > > and kernel reported > > Unable to find swap-space signature > > BTW, it used to work fine. > After switching to 2.4.19 with # cvs update -A -r linux_2_4_19 -dP swap works fine. H.J. From merker@linuxtag.org Sat Sep 28 12:38:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 12:38:53 +0200 (CEST) Received: from cassidy.nuernberg.linuxtag.net ([212.204.83.80]:26125 "EHLO cassidy.nuernberg.linuxtag.net") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 12:38:52 +0200 Received: by cassidy.nuernberg.linuxtag.net (Postfix, from userid 1006) id 79901EC277; Sat, 28 Sep 2002 12:42:39 +0200 (CEST) Received: from hydra.linuxtag.uni-kl.de (VPN-Hydra [192.168.0.1]) by cassidy.nuernberg.linuxtag.net (Postfix) with ESMTP id 59FF5EC0F5 for ; Sat, 28 Sep 2002 12:42:35 +0200 (CEST) Received: by hydra.linuxtag.uni-kl.de (Postfix, from userid 1034) id 288576A09; Sat, 28 Sep 2002 12:38:40 +0200 (CEST) Date: Sat, 28 Sep 2002 12:38:40 +0200 From: Karsten Merker To: linux-mips@linux-mips.org Subject: Re: [PATCH] dec_esp.c repair mmu_sglist breakage Message-ID: <20020928103840.GA23300@linuxtag.org> Mail-Followup-To: Karsten Merker , linux-mips@linux-mips.org References: <20020928015947.GE7706@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020928015947.GE7706@paradigm.rfc822.org> User-Agent: Mutt/1.3.28i X-No-Archive: yes Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: karsten@excalibur.cologne.de Precedence: bulk X-list: linux-mips On Sat, Sep 28, 2002 at 03:59:47AM +0200, Florian Lohoff wrote: > through the whole issue of the mmu_sglist confusion and the broken > reimplantation of mmu_sglist the dec_esp broke. Here is a fix > to really remove the mmu_sglist and use scatterlist instead. With > this the Decstation on this desk at least finds its partitions > again and does not crash. I tested the patch on my DS 5000/150 and it works there, too. Could you please check it into the cvs? Without it the kernel is de facto unusable on DECstations. Regards, Karsten -- #include Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder Meinungsforschung. From flo@rfc822.org Sat Sep 28 15:33:45 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 15:33:45 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:9993 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Sat, 28 Sep 2002 15:33:45 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 58ABB83A; Sat, 28 Sep 2002 15:33:36 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 82E813717F; Sat, 28 Sep 2002 15:33:23 +0200 (CEST) Date: Sat, 28 Sep 2002 15:33:23 +0200 From: Florian Lohoff To: linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Bootable iso image for IP22 Message-ID: <20020928133323.GC18156@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, i produced a full first Debian ISO image cd which is bootable on IP22 (I2 and Indy - R4/R5k) - Simply enter prom and click on Software installation from local cdrom. Now follow the normal debian steps to install (Now aunt Tilly can install a Debian on an Indy).=20 For all those Broadband users out there: http://source.rfc822.org/pub/local/debtestiso/sgi-mips-bootable-bf3.0.24-de= bian-1-binary.iso Ah - BTW - It uses newer Debian bootfloppies which have a couple of fixes - Thanks Guido. Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9la+jUaz2rXW+gJcRAnz5AJ0ezUnD7w5ZADMZNy2liQerSxthtwCfZxkS HKG1krPcLqEKJKJzWIBQMEs= =K6En -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From macro@ds2.pg.gda.pl Sat Sep 28 20:49:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 20:49:31 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:19081 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 20:49:30 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA11477; Sat, 28 Sep 2002 20:49:52 +0200 (MET DST) Date: Sat, 28 Sep 2002 20:49:52 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: Karsten Merker , Florian Lohoff cc: linux-mips@linux-mips.org Subject: Re: [PATCH] dec_esp.c repair mmu_sglist breakage In-Reply-To: <20020928103840.GA23300@linuxtag.org> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Sat, 28 Sep 2002, Karsten Merker wrote: > > through the whole issue of the mmu_sglist confusion and the broken > > reimplantation of mmu_sglist the dec_esp broke. Here is a fix > > to really remove the mmu_sglist and use scatterlist instead. With > > this the Decstation on this desk at least finds its partitions > > again and does not crash. > > I tested the patch on my DS 5000/150 and it works there, too. Thanks for the report -- since I have no means to test the SCSI driver I was going to ask people for testing to have another confirmation. I'm not sure why it got broken (I'll check the details to find out) as the changes were to revert to the original behaviour, but since struct mmu_sglist got deprecated, I'm happy to see an update to struct scatterlist. Since the change works for both of you, I'm checking it in now. > Could you please check it into the cvs? Without it the kernel > is de facto unusable on DECstations. Well, it depends on the actual configuration -- I haven't noticed anything wrong. ;-) -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ladis@psi.cz Sat Sep 28 22:07:13 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 22:07:14 +0200 (CEST) Received: from p042.as-l025.contactel.cz ([212.65.234.42]:5636 "EHLO kopretinka") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 22:07:13 +0200 Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian)) id 17vNgk-0000GW-00; Sat, 28 Sep 2002 21:55:42 +0200 Date: Sat, 28 Sep 2002 21:55:42 +0200 To: "Maciej W. Rozycki" Cc: Guido Guenther , linux-mips@linux-mips.org Subject: Re: [patch] GIO bus support Message-ID: <20020928195542.GA990@kopretinka> References: <20020626205956.GA2079@kopretinka> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Ladislav Michl Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ladis@psi.cz Precedence: bulk X-list: linux-mips On Thu, Jun 27, 2002 at 02:21:30PM +0200, Maciej W. Rozycki wrote: > On Wed, 26 Jun 2002, Ladislav Michl wrote: > > > +int be_ip22_handler(struct pt_regs *regs, int is_fixup) > > +{ > > + save_and_clear_buserr(); > > + if (nofault) { > > + nofault = 0; > > + compute_return_epc(regs); > > + return MIPS_BE_DISCARD; > > + } > > + return MIPS_BE_FIXUP; > > +} > > I wouldn't use nofault -- it leads to reentrancy problems and I don't > think you really need it. You probably need to code it like this: > > { > save_and_clear_buserr(); > > return is_fixup ? MIPS_BE_FIXUP : MIPS_BE_FATAL; > } > > unless: > > 1. There is a condition when for is_fixup true you should ignore the fixup > anyway (e.g. what the bus error logic reports is irrelevant to fixups). > You should choose between MIPS_BE_FATAL and MIPS_BE_DISCARD then. > > 2. There is a condition when for is_fixup false, an error is not fatal and > execution should get restarted. You should return MIPS_BE_DISCARD then. There are no such conditions (or I'm missing something). I wrote it as you suggested: int be_ip22_handler(struct pt_regs *regs, int is_fixup) { DBG("BE exception (%s)\n", is_fixup ? "fixup" : "no fixup"); save_and_clear_buserr(); if (is_fixup) return MIPS_BE_FIXUP; print_buserr(); return MIPS_BE_FATAL; } try to read status register addr = KSEG1ADDR(gio_slot_base_addr); DBG("get_dbe\n"); if (!get_dbe(id, addr)) { ... ok } > > +int ip22_baddr(unsigned int *val, unsigned long addr) > > +{ > > + nofault = 1; > > + *val = *(volatile unsigned int *) addr; > > + __asm__ __volatile__("nop;nop;nop;nop"); > > + if (nofault) { > > + nofault = 0; > > + return 0; > > + } > > + return -EFAULT; > > +} > > Why not simply: > > { > int err; > > err = get_dbe(*val, (volatile unsigned int *) addr); > > return err ? -EFAULT : 0; > } > > It was designed exactly for this purpose. You may consider using "u32" > instead of "unsigned int" for hardware accesses to assure the type will > always be 32-bit. This way gives following result: get_dbe BE exception (no fixup) Dump of MC registers shows that timeout occurs when accessing nonexistant memory. Of course it is posible return MIPS_BE_DISCARD than (and regs->cp0_epc += 4), but how to force get_dbe fail then? Not mentioning that in such case is better to avoid use of get_dbe... Suggestions are welcome as always. Thanks a lot, Ladis From flo@rfc822.org Sat Sep 28 22:21:25 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 22:21:25 +0200 (CEST) Received: from noose.gt.owl.de ([62.52.19.4]:40971 "HELO noose.gt.owl.de") by linux-mips.org with SMTP id ; Sat, 28 Sep 2002 22:21:25 +0200 Received: by noose.gt.owl.de (Postfix, from userid 10) id 8C010873; Sat, 28 Sep 2002 22:21:17 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 5B8D93717F; Sat, 28 Sep 2002 22:19:58 +0200 (CEST) Date: Sat, 28 Sep 2002 22:19:58 +0200 From: Florian Lohoff To: "Maciej W. Rozycki" Cc: Karsten Merker , linux-mips@linux-mips.org Subject: Re: [PATCH] dec_esp.c repair mmu_sglist breakage Message-ID: <20020928201958.GE18156@paradigm.rfc822.org> References: <20020928103840.GA23300@linuxtag.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Organization: rfc822 - pure communication Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: flo@rfc822.org Precedence: bulk X-list: linux-mips --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 28, 2002 at 08:49:52PM +0200, Maciej W. Rozycki wrote: > On Sat, 28 Sep 2002, Karsten Merker wrote: >=20 > > > through the whole issue of the mmu_sglist confusion and the broken > > > reimplantation of mmu_sglist the dec_esp broke. Here is a fix > > > to really remove the mmu_sglist and use scatterlist instead. With > > > this the Decstation on this desk at least finds its partitions > > > again and does not crash. > >=20 > > I tested the patch on my DS 5000/150 and it works there, too. >=20 > Thanks for the report -- since I have no means to test the SCSI driver I > was going to ask people for testing to have another confirmation. I'm not > sure why it got broken (I'll check the details to find out) as the changes > were to revert to the original behaviour, but since struct mmu_sglist got It wasnt reverted - The problem was that the original Framework NCR53C9x and dec_esp.c used the different structs which were not the same (Order changed) after the change so it broke. > deprecated, I'm happy to see an update to struct scatterlist. Since the > change works for both of you, I'm checking it in now.=20 Flo --=20 Florian Lohoff flo@rfc822.org +49-5201-669912 Heisenberg may have been here. --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9lg7uUaz2rXW+gJcRAuYAAKDaguL51/GneWibJ9gemWZLGVuFhACfdaOs IYmUroXaQn4YYeyK+spo3JE= =7shc -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8-- From jochen@scram.de Sat Sep 28 22:31:09 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 22:31:09 +0200 (CEST) Received: from mail.scram.de ([195.226.127.117]:2503 "EHLO mail.scram.de") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 22:31:09 +0200 Received: from alpha.bocc.de (p5080D5A5.dip.t-dialin.net [80.128.213.165]) (authenticated) by mail.scram.de (8.11.6+3.4W/8.11.0) with ESMTP id g8SKV2A28090 for ; Sat, 28 Sep 2002 22:31:02 +0200 (CEST) Date: Sat, 28 Sep 2002 22:30:56 +0200 (CEST) From: Jochen Friedrich X-X-Sender: jochen@alpha.bocc.de To: linux-mips@linux-mips.org Subject: R4600 status? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jochen@scram.de Precedence: bulk X-list: linux-mips Hi, i tried to boot the current (unstable) Debian kernel (2.4.18-r4k-ip22) and get the infamous hangs on my Indy at various stages, but very early, during boot. ARCH: SGI-IP22 PROMLIB: ARC firmware Version 1 Revision 10 CPU: MIPS-R4600 FPU ICACHE DCACHE CPU revision is: 00002010 FPU revision is: 00002000 Primary instruction cache 16kb, linesize 32 bytes. Primary data cache 16kb, linesize 32 bytes. Linux version 2.4.17-r4k-ip22 (root@nocontrol) (gcc version 2.95.4 20011002 (Deb ian prerelease)) #1 Mon Apr 29 12:10:32 CEST 2002 MC: SGI memory controller Revision 3 Does this machine suffer from the V1.7 problems, as well? Where can i find the current patch? Thanks, --jochen From macro@ds2.pg.gda.pl Sat Sep 28 23:39:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 28 Sep 2002 23:39:30 +0200 (CEST) Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:18827 "EHLO delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP id ; Sat, 28 Sep 2002 23:39:30 +0200 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA13594; Sat, 28 Sep 2002 23:39:53 +0200 (MET DST) Date: Sat, 28 Sep 2002 23:39:52 +0200 (MET DST) From: "Maciej W. Rozycki" To: Jochen Friedrich cc: linux-mips@linux-mips.org Subject: Re: R4600 status? In-Reply-To: Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@ds2.pg.gda.pl Precedence: bulk X-list: linux-mips On Sat, 28 Sep 2002, Jochen Friedrich wrote: > CPU revision is: 00002010 [...] > Does this machine suffer from the V1.7 problems, as well? Where can i find > the current patch? CPU revision 2010 is R4600 v.1.7. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From drow@false.org Sun Sep 29 04:13:12 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Sep 2002 04:13:12 +0200 (CEST) Received: from crack.them.org ([65.125.64.184]:26633 "EHLO crack.them.org") by linux-mips.org with ESMTP id ; Sun, 29 Sep 2002 04:13:12 +0200 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17vUVl-0002Rn-00; Sat, 28 Sep 2002 22:12:49 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17vTa9-0001kt-00; Sat, 28 Sep 2002 22:13:17 -0400 Date: Sat, 28 Sep 2002 22:13:17 -0400 From: Daniel Jacobowitz To: "H. J. Lu" Cc: binutils@sources.redhat.com, linux-mips@linux-mips.org Subject: Re: The current binutils in CVS is broken on Linux/mips Message-ID: <20020929021316.GA6731@nevyn.them.org> Mail-Followup-To: "H. J. Lu" , binutils@sources.redhat.com, linux-mips@linux-mips.org References: <20020928161704.A9102@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020928161704.A9102@lucon.org> User-Agent: Mutt/1.5.1i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Sat, Sep 28, 2002 at 04:17:04PM -0700, H. J. Lu wrote: > I recompiled my mipsel kernel with binutils in CVS as of 20020928. The > resulting kernel doesn't work. I got > > Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn, > line: > $0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > $8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > $16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > $24: 00000000 00000000 00000000 00000000 00000000 00000000 > Hi : 00000000 > Lo : 00000000 > epc : 00000000 Not tainted > Status: 00000000 > Cause : 00000000 > Process sleep (pid: 16, stackpage=87e8c000) Could you try with the 2.13.1-branch - I believe it should be fine but I haven't tested MIPS in a few merges. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From jbglaw@dvmwest.gt.owl.de Sun Sep 29 10:40:36 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Sep 2002 10:40:37 +0200 (CEST) Received: from dvmwest.gt.owl.de ([62.52.24.140]:59663 "EHLO dvmwest.gt.owl.de") by linux-mips.org with ESMTP id ; Sun, 29 Sep 2002 10:40:36 +0200 Received: by dvmwest.gt.owl.de (Postfix, from userid 1001) id E0FD813376; Sun, 29 Sep 2002 10:40:29 +0200 (CEST) Date: Sun, 29 Sep 2002 10:40:29 +0200 From: Jan-Benedict Glaw To: linux-mips@linux-mips.org Subject: Re: R4600 status? Message-ID: <20020929084029.GJ30466@lug-owl.de> Mail-Followup-To: linux-mips@linux-mips.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mhOzvPhkurUs4vA9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux mail 2.4.18 x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB x-gpg-key: wwwkeys.de.pgp.net Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jbglaw@lug-owl.de Precedence: bulk X-list: linux-mips --mhOzvPhkurUs4vA9 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 2002-09-28 22:30:56 +0200, Jochen Friedrich wrote in message : > Hi, >=20 > i tried to boot the current (unstable) Debian kernel (2.4.18-r4k-ip22) and > get the infamous hangs on my Indy at various stages, but very early, > during boot. >=20 > ARCH: SGI-IP22 > PROMLIB: ARC firmware Version 1 Revision 10 > CPU: MIPS-R4600 FPU ICACHE DCACHE > CPU revision is: 00002010 That's V1.7 > Does this machine suffer from the V1.7 problems, as well? Where can i find > the current patch? I've send out some patches some time ago, search for them in list archives. However, I was told that this CPU is quite broken, and that it is more-or-less unacceptable to import the changes I send around. When I'm a bit more experienced with this special MIPS CPU, I'll probably go and implement it in the way Maciej told... For now, try the old patch, or fetch a new CPU:-) MfG, JBG --=20 - Eine Freie Meinung in einem Freien Kopf f=FCr - einen Freien Staat voll Freier B=FCrger Gegen Zensur im Internet Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481 -- New APT-Proxy written in shell script -- http://lug-owl.de/~jbglaw/software/ap2/ --mhOzvPhkurUs4vA9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lrx9Hb1edYOZ4bsRAn8YAKCBrLNz2f9ayPg7oZ/HlxplmPr3HgCfcVRB Jg0m5aM+czPE3fh2XrKkeXc= =BhSG -----END PGP SIGNATURE----- --mhOzvPhkurUs4vA9-- From jochen@scram.de Sun Sep 29 11:31:54 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Sep 2002 11:31:54 +0200 (CEST) Received: from mail.scram.de ([195.226.127.117]:33992 "EHLO mail.scram.de") by linux-mips.org with ESMTP id ; Sun, 29 Sep 2002 11:31:54 +0200 Received: from alpha.bocc.de (p5080D7EC.dip.t-dialin.net [80.128.215.236]) (authenticated) by mail.scram.de (8.11.6+3.4W/8.11.0) with ESMTP id g8T9VeA03260; Sun, 29 Sep 2002 11:31:42 +0200 (CEST) Date: Sun, 29 Sep 2002 11:31:32 +0200 (CEST) From: Jochen Friedrich X-X-Sender: jochen@alpha.bocc.de To: linux-mips@linux-mips.org cc: debian-ipv6@lists.debian.org Subject: IPv6 support on Indy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jochen@scram.de Precedence: bulk X-list: linux-mips Hi, it looks like IPv6 support on Indy is pretty bad because the builtin ethernet doesn't receive multicast frames (Protocols like OSPF or RIP2 suffer problems, as well). The following patch is supposed to fix this. I guess my Indy is the first one talking IPv6 under Linux then ;-) --jochen --- sgiseeq.c.orig 2002-09-29 08:58:12.000000000 +0200 +++ sgiseeq.c 2002-09-29 11:24:48.000000000 +0200 @@ -161,12 +161,6 @@ seeq_load_eaddr(dev, sp->sregs); - /* XXX for now just accept packets directly to us - * XXX and ether-broadcast. Will do multicast and - * XXX promiscuous mode later. -davem - */ - sp->mode = SEEQ_RCMD_RBCAST; - /* Setup tx ring. */ for(i = 0; i < SEEQ_TX_BUFFERS; i++) { if(!ib->tx_desc[i].tdma.pbuf) { @@ -333,10 +327,15 @@ /* Copy out of kseg1 to avoid silly cache flush. */ eth_copy_and_sum(skb, pkt_pointer + 2, len, 0); skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); - dev->last_rx = jiffies; - sp->stats.rx_packets++; - sp->stats.rx_bytes += len; + if (memcmp(skb->mac.ethernet->h_source, dev->dev_addr, 6)) { + netif_rx(skb); + dev->last_rx = jiffies; + sp->stats.rx_packets++; + sp->stats.rx_bytes += len; + } else { + /* Silently drop my own packets */ + dev_kfree_skb_irq(skb); + } } else { printk ("%s: Memory squeeze, deferring packet.\n", dev->name); @@ -579,6 +578,22 @@ static void sgiseeq_set_multicast(struct net_device *dev) { + struct sgiseeq_private *sp = (struct sgiseeq_private *) dev->priv; + unsigned char oldmode = sp->mode; + + if(dev->flags & IFF_PROMISC) + sp->mode = SEEQ_RCMD_RANY; + else if ((dev->flags & IFF_ALLMULTI) || dev->mc_count) + sp->mode = SEEQ_RCMD_RBMCAST; + else + sp->mode = SEEQ_RCMD_RBCAST; + + /* XXX I know this sucks, but is there a better way to reprogram + * XXX the receiver? At least, this shouldn't happen too often. + */ + + if (oldmode != sp->mode) + sgiseeq_reset(dev); } static inline void setup_tx_ring(struct sgiseeq_tx_desc *buf, int nbufs) @@ -642,6 +657,7 @@ sp->sregs = sregs; sp->hregs = hregs; sp->name = sgiseeqstr; + sp->mode = SEEQ_RCMD_RBCAST; sp->srings.rx_desc = (struct sgiseeq_rx_desc *) (KSEG1ADDR(ALIGNED(&sp->srings.rxvector[0]))); From hjl@lucon.org Sun Sep 29 17:20:30 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 29 Sep 2002 17:20:30 +0200 (CEST) Received: from rwcrmhc53.attbi.com ([204.127.198.39]:3761 "EHLO rwcrmhc53.attbi.com") by linux-mips.org with ESMTP id ; Sun, 29 Sep 2002 17:20:30 +0200 Received: from lucon.org ([12.234.88.146]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020929152022.QUEC15492.rwcrmhc53.attbi.com@lucon.org>; Sun, 29 Sep 2002 15:20:22 +0000 Received: by lucon.org (Postfix, from userid 1000) id 1889A2C59B; Sun, 29 Sep 2002 08:20:21 -0700 (PDT) Date: Sun, 29 Sep 2002 08:20:21 -0700 From: "H. J. Lu" To: binutils@sources.redhat.com, linux-mips@linux-mips.org Subject: Re: The current binutils in CVS is broken on Linux/mips Message-ID: <20020929082021.A11843@lucon.org> References: <20020928161704.A9102@lucon.org> <20020929021316.GA6731@nevyn.them.org> <20020928191653.A2384@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020928191653.A2384@lucon.org>; from hjl@lucon.org on Sat, Sep 28, 2002 at 07:16:53PM -0700 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: hjl@lucon.org Precedence: bulk X-list: linux-mips On Sat, Sep 28, 2002 at 07:16:53PM -0700, H. J. Lu wrote: > On Sat, Sep 28, 2002 at 10:13:17PM -0400, Daniel Jacobowitz wrote: > > On Sat, Sep 28, 2002 at 04:17:04PM -0700, H. J. Lu wrote: > > > I recompiled my mipsel kernel with binutils in CVS as of 20020928. The > > > resulting kernel doesn't work. I got > > > > > > Unhandled kernel unaligned access in unaligned.c::emulate_load_store_insn, > > > line: > > > $0 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > $8 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > $16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > > $24: 00000000 00000000 00000000 00000000 00000000 00000000 > > > Hi : 00000000 > > > Lo : 00000000 > > > epc : 00000000 Not tainted > > > Status: 00000000 > > > Cause : 00000000 > > > Process sleep (pid: 16, stackpage=87e8c000) > > > > Could you try with the 2.13.1-branch - I believe it should be fine but > > I haven't tested MIPS in a few merges. > > > > I don't have resources to try 2.13.1. The Linux binutils 2.13.90.0.4 > based on 20020814 CVS is ok. I will try to fix CVS. > Linker seems ok. It is as which is broken. H.J. From nemoto@toshiba-tops.co.jp Mon Sep 30 06:55:07 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Sep 2002 06:55:08 +0200 (CEST) Received: from topsns.toshiba-tops.co.jp ([202.230.225.5]:15398 "HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP id ; Mon, 30 Sep 2002 06:55:07 +0200 Received: from inside-ms1.toshiba-tops.co.jp by topsns.toshiba-tops.co.jp via smtpd (for mail.linux-mips.org [80.63.7.146]) with SMTP; 30 Sep 2002 04:55:05 UT Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id C156AB474; Mon, 30 Sep 2002 13:54:55 +0900 (JST) Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP id NAA33773; Mon, 30 Sep 2002 13:54:55 +0900 (JST) Date: Mon, 30 Sep 2002 13:57:17 +0900 (JST) Message-Id: <20020930.135717.39150888.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: CVS Update@ftp.linux-mips.org: linux From: Atsushi Nemoto In-Reply-To: <20020929014920Z1121744-9213+239@linux-mips.org> References: <20020929014920Z1121744-9213+239@linux-mips.org> X-Fingerprint: EC 9D B9 17 2E 89 D2 25 CE F5 5D 3D 12 29 2A AD X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1 Organization: TOSHIBA Personal Computer System Corporation X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nemoto@toshiba-tops.co.jp Precedence: bulk X-list: linux-mips It seems some necessary codes for non-r4k CPUs were lost by this change. > CVSROOT: /home/cvs > Module name: linux > Changes by: ralf@ftp.linux-mips.org 02/09/29 03:49:20 > > Modified files: > arch/mips/kernel: Tag: linux_2_4 traps.c > arch/mips/mm : Tag: linux_2_4 c-sb1.c tlb-sb1.c > arch/mips64/kernel: Tag: linux_2_4 traps.c > arch/mips64/mm : Tag: linux_2_4 Makefile c-sb1.c loadmmu.c > tlb-r4k.c tlb-sb1.c tlbex-r4k.S > Added files: > arch/mips64/mm : Tag: linux_2_4 c-andes.c c-r4k.c pg-andes.c > pg-r4k.c tlb-andes.c > Removed files: > arch/mips64/mm : Tag: linux_2_4 andes.c r4xx0.c > > Log message: > Reorganize arch/mips64/mm along the line of it's 32-bit equivalent. This is a patch to revert the change. diff -ur linux-mips-cvs/arch/mips/kernel/traps.c linux.new/arch/mips/kernel/traps.c --- linux-mips-cvs/arch/mips/kernel/traps.c Sun Sep 29 19:45:07 2002 +++ linux.new/arch/mips/kernel/traps.c Mon Sep 30 13:41:23 2002 @@ -1015,6 +1015,30 @@ memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, 0x80); } + } else switch (mips_cpu.cputype) { + case CPU_SB1: + /* + * XXX - This should be folded in to the "cleaner" handling, + * above + */ + memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, 0x80); + break; + case CPU_R6000: + case CPU_R6000A: + case CPU_R2000: + case CPU_R3000: + case CPU_R3000A: + case CPU_R3041: + case CPU_R3051: + case CPU_R3052: + case CPU_R3081: + case CPU_R3081E: + case CPU_TX3912: + case CPU_TX3922: + case CPU_TX3927: + case CPU_TX39XX: + memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80); + break; } if (mips_cpu.cputype == CPU_R6000 || mips_cpu.cputype == CPU_R6000A) { --- Atsushi Nemoto From ralf@linux-mips.org Mon Sep 30 08:24:59 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Sep 2002 08:25:00 +0200 (CEST) Received: from p508B5F38.dip.t-dialin.net ([80.139.95.56]:54703 "EHLO dea.linux-mips.net") by linux-mips.org with ESMTP id ; Mon, 30 Sep 2002 08:24:59 +0200 Received: (from ralf@localhost) by dea.linux-mips.net (8.11.6/8.11.6) id g8U6Oi903070; Mon, 30 Sep 2002 08:24:44 +0200 Date: Mon, 30 Sep 2002 08:24:43 +0200 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: CVS Update@ftp.linux-mips.org: linux Message-ID: <20020930082443.A2046@linux-mips.org> References: <20020929014920Z1121744-9213+239@linux-mips.org> <20020930.135717.39150888.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020930.135717.39150888.nemoto@toshiba-tops.co.jp>; from nemoto@toshiba-tops.co.jp on Mon, Sep 30, 2002 at 01:57:17PM +0900 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Sep 30, 2002 at 01:57:17PM +0900, Atsushi Nemoto wrote: > It seems some necessary codes for non-r4k CPUs were lost by this change. Mercyfully sent to /dev/null you wanted to say. > + case CPU_SB1: > + /* > + * XXX - This should be folded in to the "cleaner" handling, > + * above > + */ > + memcpy((void *)(KSEG0 + 0x180), &except_vec3_r4000, 0x80); > + break; This was a bug. Except_vec3_r4000 is only intended for the R4000/R4400, the only MIPS CPUs which support the virtual coherency exception. SB1 should use except_vec4_generic instead. > + case CPU_TX39XX: > + memcpy((void *)(KSEG0 + 0x80), &except_vec3_generic, 0x80); Eeek, will fix. Consider the switch gone however. Ralf From kwalker@broadcom.com Mon Sep 30 18:23:52 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Sep 2002 18:23:53 +0200 (CEST) Received: from mms2.broadcom.com ([63.70.210.59]:1799 "HELO mms2.broadcom.com") by linux-mips.org with SMTP id ; Mon, 30 Sep 2002 18:23:52 +0200 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom MMS-2 SMTP Relay (MMS v4.7);); Mon, 30 Sep 2002 09:21:20 -0700 X-Server-Uuid: 2a12fa22-b688-11d4-a6a1-00508bfc9626 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id JAA20416 for ; Mon, 30 Sep 2002 09:23:36 -0700 (PDT) Received: from dt-sj3-158.sj.broadcom.com (dt-sj3-158 [10.21.64.158]) by mail-sj1-5.sj.broadcom.com (8.12.4/8.12.4/SSF) with ESMTP id g8UGNZER019194 for ; Mon, 30 Sep 2002 09:23: 36 -0700 (PDT) Received: from broadcom.com (IDENT:kwalker@localhost [127.0.0.1]) by dt-sj3-158.sj.broadcom.com (8.9.3/8.9.3) with ESMTP id JAA22138 for ; Mon, 30 Sep 2002 09:23:35 -0700 Message-ID: <3D987A87.8B855D01@broadcom.com> Date: Mon, 30 Sep 2002 09:23:35 -0700 From: "Kip Walker" Organization: Broadcom Corp. BPBU X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.5-beta4va3.20 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: unaligned exception handling X-WSS-ID: 1186A58A866434-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kwalker@broadcom.com Precedence: bulk X-list: linux-mips After inspecting a strange case in the mips64 kernel with address errors, I'm starting to think there's a problem in the do_ade() implementation. I think the 32-bit kernel may have a similar problem, but I haven't really inspected it. The issue is where the kernel's emulation of an address error causes another address error (NOT a page fault). Basically, I don't see how the exception table stuff in emulate_load_store_insn is going to work. Consider this scenario: - user process does a 'sw' (for example) to an illegal address above xuseg but below xsseg - do_ade calls emulate_load_store_insn, which tries swl/swr - the swl again hits an illegal address, this time in the kernel's context - do_ade does NOT check the exception table for the swl - emulate_load_store_insn goes to the 'swl' part of the switch - die_if_kernel DOES __die before the SIGBUS is delivered. So I don't see how the ex_table stuff is useful at all. Shouldn't do_ade() do the exception table grovelling before calling emulate_load_store_insn? Kip From dinesh_nagpure@ivivity.com Mon Sep 30 23:32:41 2002 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 30 Sep 2002 23:32:42 +0200 (CEST) Received: from [64.238.111.99] ([64.238.111.99]:64005 "EHLO mail.ivivity.com") by linux-mips.org with ESMTP id ; Mon, 30 Sep 2002 23:32:41 +0200 Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 16:21:35 -0400 Message-ID: From: Dinesh Nagpure To: linux-mips@linux-mips.org, gcc-help@gcc.gnu.org Subject: un handled paging request, kernel v2.4.16 Date: Mon, 30 Sep 2002 16:21:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C268BE.F60BF950" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dinesh_nagpure@ivivity.com Precedence: bulk X-list: linux-mips This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C268BE.F60BF950 Content-Type: text/plain; charset="iso-8859-1" Hi, In porting Linux kernel version 2.4.16 to our platform using the RM5231A, I am struggling with this page fault for a couple of days now and would very much appreciate any input to fix this. Here is what I see is happening, after completing the initial boot up when it is time to start the user-mode stuff I get a un handled paging request fault. From the printk statements and the Oops dump I can see that execution goes as far as start_thread( ) function called from load_elf_binary( ) and also EPC and SP passed to start_thread( ) appear valid. After putting the thread to execution, load_elf_binary( ) returns zero and system Oops with a page fault. Control never comes back to search_binary_handler( ) I can see the load_elf_binary( ) address still on the stack (8015e4ac). I am running the kernel uncached. I have already tried 1) Disabling the use of wait instruction, thinking that it may be the cause. 2) Disabling the FPU with no success. Could this be a page fault on instruction in delay slot which is not being handled properly? To avoid this I modified save_fp_context( ) in r4k_fpu.S but again with no success. May be I am using a wrong ramdisk.gz image, but the same image works fine on my Malta board (this one has a 4Kc core), I am creating my ramdisk image using busybox and tinylogin. Could this be a toolchain problem? While compiling, I do get warnings which says: mcpu option is deprecated, pls use -march and -mtune instead. and then, the -march option is incompatible to -mipsN and therefore ignored. All this essentially means it is taking -mtune=r5000 and -mips2 options for generating/scheduling instructions. Tool chain I am using is built from binutils-2.11.92.0.7, gcc-3.0.2 and glibc-2.2.3 (Were there any recommended versions for building kernel v2.4.16?) Are there any special flag I should be using to build busybox ramdisk for RM5231A (which is very unlikely if the ramdisk is working well on a MIPS Malta board with 4Kc core) Could this be a hardware bug? ;) Here are the boot time messages and the Oops dump. Objdump -t of vmlinux is in the attached file idisx13log PAGING_INIT : max_dmable_pfn<4096> max_low_pfn<16384> On node 0 totalpages: 16384 Required map size to hold all the page structs <983100> zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: console=ttyS0,38400 Have QED style interrupt Value in Status reg 0x90000400 time_init : Entered RTC port based at 0xb411fff0 for 200MHz CPU clock, r4k_offset is 000f4240(1000000) In idisx_rtc_read_data In idisx_rtc_read_data In idisx_rtc_read_data In idisx_rtc_read_data In idisx_rtc_read_data In idisx_rtc_read_data Value in Status reg 0x90008000 BEFORE console_init Dinesh : serial_console_setup : Entered............ Dinesh : UART_LCR = 0x93 Dinesh : UART_DLL = 0x6 Dinesh : UART_DLM = 0x0 Dinesh : UART_LCR = 0x13 Dinesh : UART_MCR = 0x3 Primary instruction cache 32kb, linesize 32 bytes. Primary data cache 32kb, linesize 32 bytes. offset=lmem_map - mem_map = <0> AFTER console_init AFTER init_modules before kmem_cache_init before sti Value in Status reg 0x90008000 Value in Debug reg 0x0 Value in Status reg 0x90008001 before calibrate_delay Calibrating delay loop... 0.81 BogoMIPS before mem_init Memory: 61272k/62244k available (1025k kernel code, 972k reserved, 1041k data, 6 0k init) before kmem_cache_sizes_init before fork_init before proc_caches_init before vfs_caches_init Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) before buffer_init Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) before page_cache_init Page-cache hash table entries: 16384 (order: 4, 65536 bytes) before signals_init before proc_root_init before ipc_init before check_bugs POSIX conformance testing by UNIFIX before smp_init before rest_init do_basic_setup : Entering sock_init : Entering Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 start_context_thread : Entering do_initcalls : Entering Starting kswapd do_gettimeofday : Entered do_fast_gettimeoffset : Entering do_fast_gettimeoffset : 1 do_fast_gettimeoffset : 2 do_fast_gettimeoffset : 3 do_fast_gettimeoffset : Done do_gettimeofday : Leaving pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled block: 128 slots per queue, batch=32 RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. prepare_namespace : Entering RAMDISK: Compressed image found at block 0 Leaving : identify_ramdisk_image Freeing initrd memory: 976k freed EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 60k freed Dinesh : Initial console opened successfully After first dup After second dup trying sbin init do_execve : Entered executing /sbin/init do_execve : before PTR_ERR do_execve : before IS_ERR do_execve : In IS_ERR clause trying etc/init do_execve : Entered executing /etc/init do_execve : before PTR_ERR do_execve : before IS_ERR do_execve : In IS_ERR clause trying bin init do_execve : Entered executing /bin/init do_execve : before PTR_ERR do_execve : before IS_ERR do_execve : Computing top of mem do_execve : bprm.p = 0x1fffc do_execve : before memset on bprm.page 1 do_execve : 7 prepare_binprm : Entered prepare_binprm : mode = 33261 prepare_binprm : bprm->e_uid = 0 prepare_binprm : bprm->e_gid = 0 prepare_binprm : Clearing capabilities prepare_binprm : memset of bprm->buf, size 128 chars prepare_binprm : reading 128 chars from file kernel_read : Entered kernel_read : calling get_fs kernel_read : calling set_fs kernel_read : calling read from file kernel_read : calling set_fs again to restore old_fs do_execve : 8 do_execve : 9 do_execve : 10 do_execve : 11 do_execve : 12 do_execve : 13 do_execve : 14 do_execve : 15 search_binary_handler : Entered search_binary_handler : Before set_fs search_binary_handler : Before for loop of try search_binary_handler : In for loop with try = 0 search_binary_handler : In for loop searching formats for a match search_binary_handler : calling fn fn is 8015e4ac kernel_read : Entered kernel_read : calling get_fs kernel_read : calling set_fs kernel_read : calling read from file kernel_read : calling set_fs again to restore old_fs load_elf_binary : in for loop1 with i=0 limit=4 load_elf_binary : in for loop1 with i=1 limit=4 load_elf_binary : in for loop1 with i=2 limit=4 load_elf_binary : in for loop1 with i=3 limit=4 load_elf_binary : out of for loop1 load_elf_binary : Before start_thread load_elf_binary : New Thread info load_elf_binary : cp0_epc = 0x400190 load_elf_binary : sp = 0x7fff7f40 load_elf_binary : After start thread load_elf_binary : did not send sigtrap Unable to handle kernel paging request at virtual address 00000000, epc == 00000 000, ra == 8014a68c Oops in fault.c:do_page_fault, line 204: $0 : 00000000 90008000 00000000 00000000 801ecb28 00000001 00000001 000007f8 $8 : 000007f8 ffffc7f8 000007f8 00000000 00000000 00000000 80318ec1 fffffff4 $16: 8015e4ac 8021b1c0 00000001 8035dd88 00000000 00000000 fffffff8 8035dd38 $24: 00000010 8035dacf 8035c000 8035dd20 8035def8 8014a68c Hi : 00000000 Lo : 00000120 epc : 00000000 Not tainted Status: 90008003 Cause : 00800408 Process init (pid: 1, stackpage=8035c000) Stack: 801ecaa8 8015e4ac 0000000a 8035dd24 ffffffff 8020f62c 00000313 fffffced 8020f650 00000000 90008003 00808400 00000000 80221000 80212d7c 80212d54 8035def8 00000000 00000000 00000000 800af880 8014a920 801eccbc 00000000 0000000a 8035dd7c 464c457f 00010101 00000000 00000000 00080002 00000001 00400190 00000034 0011429c 00000005 00200034 00280004 00120013 70000000 000000e0 ... Call Trace: [<801ecaa8>] [<8015e4ac>] [<8014a920>] [<801eccbc>] [<8014be70>] [<8 01082cc>] [<8010c280>] [<801082cc>] [<8010ca24>] [<801e868c>] [<801e8678>] [<80108c9c>] [<80108020>] [<80108c8c>] Code: (Bad address in epc) Kernel panic: Attempted to kill init! <> Thanks, Dinesh iViVITY Inc. ------_=_NextPart_000_01C268BE.F60BF950 Content-Type: application/octet-stream; name="idisx13objdump" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="idisx13objdump" =0A= vmlinux: file format elf32-tradlittlemips=0A= =0A= SYMBOL TABLE:=0A= 80100000 l d .text 00000000 =0A= 801f9970 l d .fixup 00000000 =0A= 801fa758 l d .kstrtab 00000000 =0A= 801fd590 l d __ex_table 00000000 =0A= 801ff080 l d __dbe_table 00000000 =0A= 801ff080 l d __ksymtab 00000000 =0A= 80202000 l d .text.init 00000000 =0A= 8020f9c0 l d .data.init 00000000 =0A= 8020ff70 l d .setup.init 00000000 =0A= 80210038 l d .initcall.init 00000000 =0A= 80211000 l d .data.cacheline_aligned 00000000 =0A= 80211a60 l d .reginfo 00000000 =0A= 80211a80 l d .data 00000000 =0A= 80316000 l d .bss 00000000 =0A= 80336420 l d .comment 00000000 =0A= 00000000 l d .pdr 00000000 =0A= 00000000 l d *ABS* 00000000 =0A= 00000000 l d *ABS* 00000000 =0A= 00000000 l d *ABS* 00000000 =0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/bootinfo.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cachectl.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/asm/current= .h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/threads.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/threads.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/init.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/init.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 head.S=0A= 80106000 l .text 00000000 dummy=0A= 00000000 l df *ABS* 00000000 init_task.c=0A= 80211ac0 l O .data 00000020 init_fs=0A= 80211ae0 l O .data 0000019c init_files=0A= 80211c7c l O .data 00001004 init_signals=0A= 00000000 l df *ABS* 00000000 init/main.c=0A= 80212d04 l O .data 00000028 argv_init=0A= 80212d2c l O .data 00000028 envp_init=0A= 80212d54 l O .data 00000028 argv_init1=0A= 80212d7c l O .data 00000028 envp_init1=0A= 80202000 l F .text.init 00000000 profile_setup=0A= 8020f9c0 l O .data.init 00000009 __setup_str_profile_setup=0A= 8020ff70 l O .setup.init 00000008 __setup_profile_setup=0A= 8020f9cc l O .data.init 00000268 root_dev_names=0A= 80202144 l F .text.init 00000000 root_dev_setup=0A= 8020fc34 l O .data.init 00000006 __setup_str_root_dev_setup=0A= 8020ff78 l O .setup.init 00000008 __setup_root_dev_setup=0A= 8020225c l F .text.init 00000000 checksetup=0A= 80202490 l F .text.init 00000000 readonly=0A= 802024c0 l F .text.init 00000000 readwrite=0A= 802024f4 l F .text.init 00000000 debug_kernel=0A= 8020251c l F .text.init 00000000 quiet_kernel=0A= 8020fc3c l O .data.init 00000003 __setup_str_readonly=0A= 8020ff80 l O .setup.init 00000008 __setup_readonly=0A= 8020fc40 l O .data.init 00000003 __setup_str_readwrite=0A= 8020ff88 l O .setup.init 00000008 __setup_readwrite=0A= 8020fc44 l O .data.init 00000006 __setup_str_debug_kernel=0A= 8020ff90 l O .setup.init 00000008 __setup_debug_kernel=0A= 8020fc4c l O .data.init 00000006 __setup_str_quiet_kernel=0A= 8020ff98 l O .setup.init 00000008 __setup_quiet_kernel=0A= 80202544 l F .text.init 00000000 parse_options=0A= 80108000 l F .text 00000000 rest_init=0A= 801082cc l F .text 00000000 init=0A= 80212da8 l O .data 00000008 argv.0=0A= 80108038 l F .text 00000000 do_linuxrc=0A= 80202a40 l F .text.init 00000000 do_initcalls=0A= 80202a94 l F .text.init 00000000 do_basic_setup=0A= 8010812c l F .text 00000000 prepare_namespace=0A= 00000000 l df *ABS* 00000000 init/version.c=0A= 00000000 l df *ABS* 00000000 branch.c=0A= 00000000 l df *ABS* 00000000 process.c=0A= 00000000 l df *ABS* 00000000 signal.c=0A= 80108edc l F .text 00000000 _sys_sigsuspend=0A= 80109084 l F .text 00000000 _sys_rt_sigsuspend=0A= 8010a120 l F .text 00000000 setup_sigcontext=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 syscalls.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 syscalls.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/unistd.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/fpregdef.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/errno.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/current.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cacheops.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/asm/addrspa= ce.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/sys.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/init.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/init.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 entry.S=0A= 8010a500 l .text 00000000 tracesys_exit=0A= 8010a528 l .text 00000000 reschedule=0A= 8010a624 l F .text 00000000 signal_return=0A= 80202b54 l .text.init 00000000 handle_vced=0A= 80202b80 l .text.init 00000000 handle_vcei=0A= 00000000 l df *ABS* 00000000 traps.c=0A= 80218f40 l O .data 00000008 archdata.0=0A= 80218f50 l O .data 00000004 ll_task=0A= 8010abfc l F .text 00000000 default_be_board_handler=0A= 00000000 l df *ABS* 00000000 ptrace.c=0A= 00000000 l df *ABS* 00000000 vm86.c=0A= 00000000 l df *ABS* 00000000 ioport.c=0A= 00000000 l df *ABS* 00000000 reset.c=0A= 00000000 l df *ABS* 00000000 semaphore.c=0A= 00000000 l df *ABS* 00000000 setup.c=0A= 80218f70 l O .data 0000001c code_resource=0A= 80218f8c l O .data 0000001c data_resource=0A= 80203c98 l F .text.init 00000000 print_memory_map=0A= 80316328 l O .bss 00000050 command_line=0A= 8020fc54 l O .data.init 00000006 __setup_str_fpu_disable=0A= 8020ffa0 l O .setup.init 00000008 __setup_fpu_disable=0A= 00000000 l df *ABS* 00000000 syscall.c=0A= 8010c168 l F .text 00000000 _sys_fork=0A= 8010c1c8 l F .text 00000000 _sys_clone=0A= 00000000 l df *ABS* 00000000 sysmips.c=0A= 00000000 l df *ABS* 00000000 ipc.c=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/unistd.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sysmips.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/current.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/errno.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/errno.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/errno.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 scall_o32.S=0A= 8010cc0c l .text 00000000 illegal_syscall=0A= 8010cb94 l .text 00000000 stackargs=0A= 8010ca08 l .text 00000000 stack_done=0A= 8010cb28 l .text 00000000 trace_a_syscall=0A= 8010cb18 l .text 00000000 o32_reschedule=0A= 8010cad0 l F .text 00000000 signal_return=0A= 8010ca6c l .text 00000000 restore_all=0A= 8010cbf4 l .text 00000000 bad_stack=0A= 8010cc9c l .text 00000000 no_mem=0A= 00000000 l df *ABS* 00000000 unaligned.c=0A= 00000000 l df *ABS* 00000000 mips_ksyms.c=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/fpregdef.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/errno.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 r4k_fpu.S=0A= 8010d07c l F .text 00000000 fault=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asmmacro.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asmmacro.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/fpregdef.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/current.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cachectl.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/bootinfo.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 r4k_switch.S=0A= 00000000 l df *ABS* 00000000 irq.c=0A= 8010d308 l F .text 00000000 enable_none=0A= 8010d310 l F .text 00000000 startup_none=0A= 8010d318 l F .text 00000000 disable_none=0A= 8010d320 l F .text 00000000 ack_none=0A= 80219030 l O .data 00000010 probe_sem=0A= 00000000 l df *ABS* 00000000 i8259.c=0A= 8010e180 l F .text 00000000 end_8259A_irq=0A= 8010e1c0 l F .text 00000000 startup_8259A_irq=0A= 80219040 l O .data 00000020 i8259A_irq_type=0A= 80219060 l O .data 00000004 cached_irq_mask=0A= 80219064 l O .data 00000004 spurious_irq_mask.0=0A= 80219068 l O .data 00000018 irq2=0A= 80219080 l O .data 0000001c pic1_io_resource=0A= 8021909c l O .data 0000001c pic2_io_resource=0A= 00000000 l df *ABS* 00000000 proc.c=0A= 802190c0 l O .data 000000b0 cpu_name=0A= 8010e5c0 l F .text 00000000 show_cpuinfo=0A= 8010e868 l F .text 00000000 c_start=0A= 8010e874 l F .text 00000000 c_next=0A= 8010e8ac l F .text 00000000 c_stop=0A= 00000000 l df *ABS* 00000000 extable.c=0A= 00000000 l df *ABS* 00000000 init.c=0A= 80316494 l O .bss 00000004 totalram_pages=0A= 00000000 l df *ABS* 00000000 ioremap.c=0A= 8010eee0 l F .text 00000000 remap_area_pages=0A= 00000000 l df *ABS* 00000000 fault.c=0A= 00000000 l df *ABS* 00000000 loadmmu.c=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cacheops.h=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 pg-r4k.S=0A= 00000000 l df *ABS* 00000000 c-r4k.c=0A= 8010fff0 l F .text 00000000 no_sc_noop=0A= 80219180 l O .data 00000010 no_sc_ops=0A= 8010fff8 l F .text 00000000 r4k_flush_cache_range_s16d16i16=0A= 803164e4 l O .bss 00000004 dcache_size=0A= 803164e0 l O .bss 00000004 icache_size=0A= 803164f0 l O .bss 00000004 scache_size=0A= 801103ec l F .text 00000000 r4k_flush_cache_range_s32d16i16=0A= 801107e0 l F .text 00000000 r4k_flush_cache_range_s64d16i16=0A= 80110c44 l F .text 00000000 r4k_flush_cache_range_s128d16i16=0A= 80111018 l F .text 00000000 r4k_flush_cache_range_s32d32i32=0A= 8011140c l F .text 00000000 r4k_flush_cache_range_s64d32i32=0A= 80111870 l F .text 00000000 r4k_flush_cache_range_s128d32i32=0A= 80111c44 l F .text 00000000 r4k_flush_cache_range_d16i16=0A= 80111dfc l F .text 00000000 r4k_flush_cache_range_d32i32=0A= 80111fb4 l F .text 00000000 r4k_flush_cache_mm_s16d16i16=0A= 8011221c l F .text 00000000 r4k_flush_cache_mm_s32d16i16=0A= 80112484 l F .text 00000000 r4k_flush_cache_mm_s64d16i16=0A= 801126ec l F .text 00000000 r4k_flush_cache_mm_s128d16i16=0A= 80112954 l F .text 00000000 r4k_flush_cache_mm_s32d32i32=0A= 80112bbc l F .text 00000000 r4k_flush_cache_mm_s64d32i32=0A= 80112e24 l F .text 00000000 r4k_flush_cache_mm_s128d32i32=0A= 8011308c l F .text 00000000 r4k_flush_cache_mm_d16i16=0A= 80113244 l F .text 00000000 r4k_flush_cache_mm_d32i32=0A= 801133fc l F .text 00000000 r4k_flush_cache_page_s16d16i16=0A= 801136a8 l F .text 00000000 r4k_flush_cache_page_s32d16i16=0A= 80113954 l F .text 00000000 r4k_flush_cache_page_s64d16i16=0A= 80113c00 l F .text 00000000 r4k_flush_cache_page_s128d16i16=0A= 80113e70 l F .text 00000000 r4k_flush_cache_page_s32d32i32=0A= 8011411c l F .text 00000000 r4k_flush_cache_page_s64d32i32=0A= 801143c8 l F .text 00000000 r4k_flush_cache_page_s128d32i32=0A= 80114638 l F .text 00000000 r4k_flush_cache_page_d16i16=0A= 8011483c l F .text 00000000 r4k_flush_cache_page_d32i32=0A= 80114a64 l F .text 00000000 r4k_flush_cache_page_d32i32_r4600=0A= 80114d34 l F .text 00000000 r4k_flush_page_to_ram_s16=0A= 80114de0 l F .text 00000000 r4k_flush_page_to_ram_s32=0A= 80114e8c l F .text 00000000 r4k_flush_page_to_ram_s64=0A= 80114f38 l F .text 00000000 r4k_flush_page_to_ram_s128=0A= 80114fc4 l F .text 00000000 r4k_flush_page_to_ram_d16=0A= 80115070 l F .text 00000000 r4k_flush_page_to_ram_d32=0A= 80115134 l F .text 00000000 r4k_flush_page_to_ram_d32_r4600=0A= 8011523c l F .text 00000000 r4k_flush_icache_page_s=0A= 80115244 l F .text 00000000 r4k_flush_icache_range=0A= 80115268 l F .text 00000000 r4k_flush_icache_page_p=0A= 80115298 l F .text 00000000 r4k_dma_cache_wback_inv_pc=0A= 803164ec l O .bss 00000004 dc_lsize=0A= 8011535c l F .text 00000000 r4k_dma_cache_wback_inv_sc=0A= 803164f4 l O .bss 00000004 sc_lsize=0A= 801153cc l F .text 00000000 r4k_dma_cache_inv_pc=0A= 80115490 l F .text 00000000 r4k_dma_cache_inv_sc=0A= 80115500 l F .text 00000000 r4k_dma_cache_wback=0A= 80115518 l F .text 00000000 r4k_flush_cache_sigtramp=0A= 803164e8 l O .bss 00000004 ic_lsize=0A= 80115558 l F .text 00000000 r4600v20k_flush_cache_sigtramp=0A= 80204958 l F .text.init 00000000 probe_icache=0A= 802049f0 l F .text.init 00000000 probe_dcache=0A= 80204a88 l F .text.init 00000000 probe_scache=0A= 80204c84 l F .text.init 00000000 setup_noscache_funcs=0A= 80116804 l F .text 00000000 r4k_flush_cache_all_d32i32=0A= 80116658 l F .text 00000000 r4k_flush_cache_all_d16i16=0A= 80204e44 l F .text.init 00000000 setup_scache_funcs=0A= 801155d4 l F .text 00000000 r4k_flush_cache_all_s16d16i16=0A= 801163fc l F .text 00000000 r4k_flush_cache_all_s128d32i32=0A= 80115ce8 l F .text 00000000 r4k_flush_cache_all_s128d16i16=0A= 801161a0 l F .text 00000000 r4k_flush_cache_all_s64d32i32=0A= 80115a8c l F .text 00000000 r4k_flush_cache_all_s64d16i16=0A= 80115f44 l F .text 00000000 r4k_flush_cache_all_s32d32i32=0A= 80115830 l F .text 00000000 r4k_flush_cache_all_s32d16i16=0A= 00000000 l df *ABS* 00000000 tlb-r4k.c=0A= 8020fc5c l O .data.init 00000004 temp_tlb_entry=0A= 80205530 l F .text.init 00000000 probe_tlb=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/asm/process= or.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/pgtable.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/page.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/fpregdef.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cachectl.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/bootinfo.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/current.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/init.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/linux/init.= h=0A= 00000000 l df *ABS* 00000000 tlbex-r4k.S=0A= 80117000 l .text 00000000 invalid_tlbl=0A= 80117084 l .text 00000000 nopage_tlbl=0A= 80117204 l .text 00000000 nopage_tlbs=0A= 80117380 l .text 00000000 nowrite_mod=0A= 00000000 l df *ABS* 00000000 sched.c=0A= 802191a8 l O .data 00000008 runqueue_head=0A= 80211800 l O .data.cacheline_aligned 00000020 aligned_data=0A= 8011749c l F .text 00000000 reschedule_idle=0A= 80117574 l F .text 00000000 process_timeout=0A= 801185c4 l F .text 00000000 setscheduler=0A= 802191b0 l O .data 00000018 stat_nam.0=0A= 80118ba0 l F .text 00000000 show_task=0A= 00000000 l df *ABS* 00000000 dma.c=0A= 802191d0 l O .data 00000040 dma_chan_busy=0A= 00000000 l df *ABS* 00000000 fork.c=0A= 80219210 l O .data 00000004 next_safe.0=0A= 801194a0 l F .text 00000000 get_pid=0A= 80119658 l F .text 00000000 mm_init=0A= 801198a0 l F .text 00000000 copy_mm=0A= 80119dac l F .text 00000000 count_open_files=0A= 80119de4 l F .text 00000000 copy_files=0A= 00000000 l df *ABS* 00000000 exec_domain.c=0A= 80219220 l O .data 00000004 exec_domains=0A= 80219224 l O .data 00000000 exec_domains_lock=0A= 80219224 l O .data 00000080 ident_map=0A= 8011a950 l F .text 00000000 default_handler=0A= 8011a9cc l F .text 00000000 lookup_exec_domain=0A= 802192e0 l O .data 00000134 abi_table=0A= 80219414 l O .data 00000058 abi_root_table=0A= 80205e64 l F .text.init 00000000 abi_register_sysctl=0A= 80210038 l O .initcall.init 00000004 = __initcall_abi_register_sysctl=0A= 00000000 l df *ABS* 00000000 panic.c=0A= 80205e8c l F .text.init 00000000 panic_setup=0A= 8020fc60 l O .data.init 00000007 __setup_str_panic_setup=0A= 8020ffa8 l O .setup.init 00000008 __setup_panic_setup=0A= 80318a80 l O .bss 00000400 buf.0=0A= 80318e80 l O .bss 00000014 buf.1=0A= 00000000 l df *ABS* 00000000 printk.c=0A= 80219498 l O .data 00000010 console_sem=0A= 802194a8 l O .data 00000000 logbuf_lock=0A= 802194a8 l O .data 00000004 preferred_console=0A= 8020fc68 l O .data.init 00000009 __setup_str_console_setup=0A= 8020ffb0 l O .setup.init 00000008 __setup_console_setup=0A= 8031d2a8 l O .bss 00000004 log_start=0A= 8031d2b0 l O .bss 00000004 log_end=0A= 803192a8 l O .bss 00004000 log_buf=0A= 8031d2b4 l O .bss 00000004 logged_chars=0A= 8011b4e8 l F .text 00000000 __call_console_drivers=0A= 8011b570 l F .text 00000000 _call_console_drivers=0A= 802194ac l O .data 00000004 msg_level.0=0A= 8011b5f0 l F .text 00000000 call_console_drivers=0A= 8011b774 l F .text 00000000 emit_log_char=0A= 8031d2ac l O .bss 00000004 con_start=0A= 80318ea0 l O .bss 00000400 printk_buf.1=0A= 802194b0 l O .data 00000004 log_level_unknown.2=0A= 8031d338 l O .bss 00000004 console_may_schedule=0A= 00000000 l df *ABS* 00000000 module.c=0A= 802194c0 l O .data 00000008 archdata.0=0A= 8021952c l O .data 00000008 ime_list=0A= 80219534 l O .data 00000000 ime_lock=0A= 8031d340 l O .bss 00000004 kmalloc_failed=0A= 80219534 l O .data 00000000 unload_lock=0A= 8011d24c l F .text 00000000 qm_modules=0A= 8011d3b8 l F .text 00000000 qm_deps=0A= 8011d598 l F .text 00000000 qm_refs=0A= 8011d744 l F .text 00000000 qm_symbols=0A= 8011d958 l F .text 00000000 qm_info=0A= 8011e3f8 l F .text 00000000 s_start=0A= 8011e4b0 l F .text 00000000 s_next=0A= 8011e530 l F .text 00000000 s_stop=0A= 8011e56c l F .text 00000000 s_show=0A= 00000000 l df *ABS* 00000000 exit.c=0A= 8011e83c l F .text 00000000 will_become_orphaned_pgrp=0A= 8011ee24 l F .text 00000000 exit_notify=0A= 00000000 l df *ABS* 00000000 itimer.c=0A= 8011f870 l F .text 00000000 tvtojiffies=0A= 8011f8c0 l F .text 00000000 jiffiestotv=0A= 00000000 l df *ABS* 00000000 info.c=0A= 00000000 l df *ABS* 00000000 time.c=0A= 8011fe40 l F .text 00000000 do_normal_gettime=0A= 80219554 l O .data 00000004 firsttime.0=0A= 00000000 l df *ABS* 00000000 softirq.c=0A= 80211860 l O .data.cacheline_aligned 00000100 softirq_vec=0A= 80120c30 l F .text 00000000 tasklet_action=0A= 80120d80 l F .text 00000000 tasklet_hi_action=0A= 80120fb0 l F .text 00000000 bh_action=0A= 8031d620 l O .bss 00000080 bh_base=0A= 8012119c l F .text 00000000 ksoftirqd=0A= 8020617c l F .text.init 00000000 spawn_ksoftirqd=0A= 8021003c l O .initcall.init 00000004 __initcall_spawn_ksoftirqd=0A= 00000000 l df *ABS* 00000000 resource.c=0A= 802195a8 l O .data 00000000 resource_lock=0A= 801212e0 l F .text 00000000 do_resource_list=0A= 80121414 l F .text 00000000 __request_resource=0A= 80121494 l F .text 00000000 __release_resource=0A= 80121570 l F .text 00000000 find_resource=0A= 802195a8 l O .data 00000004 reserved.0=0A= 8031d6a0 l O .bss 00000070 reserve.1=0A= 80206208 l F .text.init 00000000 reserve_setup=0A= 8020fc74 l O .data.init 00000009 __setup_str_reserve_setup=0A= 8020ffb8 l O .setup.init 00000008 __setup_reserve_setup=0A= 00000000 l df *ABS* 00000000 sysctl.c=0A= 802195b0 l O .data 00000004 maxolduid=0A= 802195b4 l O .data 0000000c root_table_header=0A= 80219648 l O .data 00000160 root_table=0A= 80122218 l F .text 00000000 proc_readsys=0A= 80122250 l F .text 00000000 proc_writesys=0A= 80219608 l O .data 00000040 proc_sys_inode_operations=0A= 80122288 l F .text 00000000 proc_sys_permission=0A= 802197a8 l O .data 000004d0 kern_table=0A= 80219c78 l O .data 00000160 vm_table=0A= 80219dd8 l O .data 0000002c proc_table=0A= 80219e04 l O .data 00000210 fs_table=0A= 8021a014 l O .data 0000002c debug_table=0A= 8021a040 l O .data 0000002c dev_table=0A= 801224ec l F .text 00000000 proc_doutsstring=0A= 8031d710 l O .bss 00000004 minolduid=0A= 80121f28 l F .text 00000000 register_proc_table=0A= 80121adc l F .text 00000000 parse_table=0A= 80121a78 l F .text 00000000 test_perm=0A= 80122088 l F .text 00000000 unregister_proc_table=0A= 80122148 l F .text 00000000 do_rw_proc=0A= 801225a8 l F .text 00000000 do_proc_dointvec=0A= 80122f38 l F .text 00000000 do_proc_doulongvec_minmax=0A= 00000000 l df *ABS* 00000000 acct.c=0A= 00000000 l df *ABS* 00000000 capability.c=0A= 801239c4 l F .text 00000000 cap_set_pg=0A= 80123a18 l F .text 00000000 cap_set_all=0A= 00000000 l df *ABS* 00000000 ptrace.c=0A= 801240ac l F .text 00000000 access_one_page=0A= 8012432c l F .text 00000000 access_mm=0A= 00000000 l df *ABS* 00000000 timer.c=0A= 801eaf80 l O .text 00000014 tvecs=0A= 8031df78 l O .bss 00000804 tv1=0A= 8031dd74 l O .bss 00000204 tv2=0A= 8031db70 l O .bss 00000204 tv3=0A= 8031d96c l O .bss 00000204 tv4=0A= 8031d768 l O .bss 00000204 tv5=0A= 8031e77c l O .bss 00000004 timer_jiffies=0A= 80124b30 l F .text 00000000 second_overflow=0A= 80124e48 l F .text 00000000 update_wall_time_one_tick=0A= 80124f44 l F .text 00000000 update_wall_time=0A= 801251f4 l F .text 00000000 count_active_tasks=0A= 8021a0b8 l O .data 00000004 count.0=0A= 00000000 l df *ABS* 00000000 user.c=0A= 8021a0c0 l O .data 00000000 uidhash_lock=0A= 8031e790 l O .bss 00000004 uid_cachep=0A= 8031e794 l O .bss 00000400 uidhash_table=0A= 8020634c l F .text.init 00000000 uid_cache_init=0A= 80210040 l O .initcall.init 00000004 __initcall_uid_cache_init=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/sched.h=0A= 00000000 l df *ABS* 00000000 signal.c=0A= 8031eba0 l O .bss 00000004 sigqueue_cachep=0A= 80125b10 l F .text 00000000 next_signal=0A= 80125bd0 l F .text 00000000 flush_sigqueue=0A= 80125ea0 l F .text 00000000 collect_signal=0A= 8012619c l F .text 00000000 rm_from_queue=0A= 80126294 l F .text 00000000 rm_sig_from_queue=0A= 80126358 l F .text 00000000 signal_type=0A= 801263cc l F .text 00000000 ignored_signal=0A= 80126430 l F .text 00000000 handle_stop_signal=0A= 801264dc l F .text 00000000 send_signal=0A= 801266ac l F .text 00000000 deliver_signal=0A= 80126b1c l F .text 00000000 kill_something_info=0A= 80126d5c l F .text 00000000 wake_up_parent=0A= 80127ea4 l F .text 00000000 recalc_sigpending=0A= 00000000 l df *ABS* 00000000 sys.c=0A= 8031ebb0 l O .bss 00000004 reboot_notifier_list=0A= 8012806c l F .text 00000000 proc_sel=0A= 801284f8 l F .text 00000000 deferred_cad=0A= 8021a108 l O .data 00000014 cad_tq.0=0A= 8012877c l F .text 00000000 set_user=0A= 80129580 l F .text 00000000 supplemental_group_member=0A= 00000000 l df *ABS* 00000000 kmod.c=0A= 8021a230 l O .data 00000010 envp.0=0A= 8012a45c l F .text 00000000 exec_modprobe=0A= 8021a240 l O .data 00000004 kmod_concurrent.1=0A= 8031ebc0 l O .bss 00000004 kmod_loop_msg.2=0A= 8012a82c l F .text 00000000 ____call_usermodehelper=0A= 8012a868 l F .text 00000000 __call_usermodehelper=0A= 8021a248 l O .data 00000010 dev_probe_sem=0A= 00000000 l df *ABS* 00000000 context.c=0A= 8021a260 l O .data 00000008 tq_context=0A= 8021a268 l O .data 00000008 context_task_wq=0A= 8021a270 l O .data 00000008 context_task_done=0A= 8012aa60 l F .text 00000000 need_keventd=0A= 8031ebd0 l O .bss 00000004 keventd_running=0A= 8031ebd4 l O .bss 00000004 keventd_task=0A= 8012abc0 l F .text 00000000 context_thread=0A= 8031ebd8 l O .bss 00000014 dummy_task=0A= 8020fc80 l O .data.init 0000000c startup.0=0A= 00000000 l df *ABS* 00000000 ksyms.c=0A= 00000000 l df *ABS* 00000000 memory.c=0A= 8012b648 l F .text 00000000 follow_page=0A= 8012c2a0 l F .text 00000000 do_wp_page=0A= 8012c5a8 l F .text 00000000 vmtruncate_list=0A= 8012c870 l F .text 00000000 do_swap_page=0A= 8012ca30 l F .text 00000000 do_anonymous_page=0A= 8012cbac l F .text 00000000 do_no_page=0A= 00000000 l df *ABS* 00000000 mmap.c=0A= 8012d2f4 l F .text 00000000 find_vma_prepare=0A= 8012d37c l F .text 00000000 __vma_link=0A= 8012d460 l F .text 00000000 vma_merge=0A= 8012df1c l F .text 00000000 unmap_fixup=0A= 8012e0fc l F .text 00000000 free_pgtables=0A= 00000000 l df *ABS* 00000000 filemap.c=0A= 8012eb20 l F .text 00000000 add_page_to_hash_queue=0A= 8012ee14 l F .text 00000000 do_flushpage=0A= 8012ee58 l F .text 00000000 truncate_complete_page=0A= 8012eedc l F .text 00000000 truncate_list_pages=0A= 8012f174 l F .text 00000000 invalidate_list_pages2=0A= 8012f3d8 l F .text 00000000 writeout_one_page=0A= 8012f4cc l F .text 00000000 do_buffer_fdatasync=0A= 8012fb6c l F .text 00000000 page_cache_read=0A= 8012fc8c l F .text 00000000 read_cluster_nonblocking=0A= 8012fe98 l F .text 00000000 __lock_page=0A= 801300a4 l F .text 00000000 __find_lock_page_helper=0A= 8013043c l F .text 00000000 generic_file_readahead=0A= 80130c1c l F .text 00000000 generic_file_direct_IO=0A= 801310b4 l F .text 00000000 file_send_actor=0A= 801313fc l F .text 00000000 do_readahead=0A= 8013157c l F .text 00000000 nopage_sequential_readahead=0A= 8021a2dc l O .data 0000000c generic_file_vm_ops=0A= 80131dbc l F .text 00000000 msync_interval=0A= 8013202c l F .text 00000000 madvise_fixup_start=0A= 80132198 l F .text 00000000 madvise_fixup_end=0A= 80132304 l F .text 00000000 madvise_fixup_middle=0A= 80132534 l F .text 00000000 madvise_behavior=0A= 80132604 l F .text 00000000 madvise_willneed=0A= 801327cc l F .text 00000000 madvise_dontneed=0A= 8013280c l F .text 00000000 madvise_vma=0A= 801329ac l F .text 00000000 mincore_page=0A= 80132a44 l F .text 00000000 mincore_vma=0A= 00000000 l df *ABS* 00000000 mprotect.c=0A= 801337c0 l F .text 00000000 change_protection=0A= 801339d8 l F .text 00000000 mprotect_fixup=0A= 00000000 l df *ABS* 00000000 mlock.c=0A= 80134190 l F .text 00000000 mlock_fixup=0A= 80134590 l F .text 00000000 do_mlock=0A= 801347f8 l F .text 00000000 do_mlockall=0A= 00000000 l df *ABS* 00000000 mremap.c=0A= 80134990 l F .text 00000000 move_one_page=0A= 80134ac8 l F .text 00000000 move_page_tables=0A= 00000000 l df *ABS* 00000000 vmalloc.c=0A= 00000000 l df *ABS* 00000000 slab.c=0A= 8021a2f0 l O .data 00000004 slab_break_gfp_order=0A= 8021a2f4 l O .data 000000a8 cache_sizes=0A= 8021a39c l O .data 0000006c cache_cache=0A= 8021a408 l O .data 00000004 clock_searchp=0A= 80135c20 l F .text 00000000 kmem_cache_estimate=0A= 8031ec48 l O .bss 00000010 cache_chain_sem=0A= 8031ec40 l O .bss 00000004 offslab_limit=0A= 80210044 l O .initcall.init 00000004 = __initcall_kmem_cpucache_init=0A= 80135ccc l F .text 00000000 kmem_slab_destroy=0A= 801362a0 l F .text 00000000 __kmem_cache_shrink=0A= 801365e0 l F .text 00000000 kmem_cache_grow=0A= 80137328 l F .text 00000000 proc_getdata=0A= 00000000 l df *ABS* 00000000 bootmem.c=0A= 80206750 l F .text.init 00000000 init_bootmem_core=0A= 80206830 l F .text.init 00000000 reserve_bootmem_core=0A= 802069c8 l F .text.init 00000000 free_bootmem_core=0A= 80206afc l F .text.init 00000000 __alloc_bootmem_core=0A= 80206eb0 l F .text.init 00000000 free_all_bootmem_core=0A= 00000000 l df *ABS* 00000000 swap.c=0A= 00000000 l df *ABS* 00000000 vmscan.c=0A= 80137980 l F .text 00000000 swap_out=0A= 80137f58 l F .text 00000000 shrink_cache=0A= 801383ac l F .text 00000000 refill_inactive=0A= 80138590 l F .text 00000000 shrink_caches=0A= 801386d8 l F .text 00000000 check_classzone_need_balance=0A= 80138718 l F .text 00000000 kswapd_balance_pgdat=0A= 801387f0 l F .text 00000000 kswapd_balance=0A= 80138838 l F .text 00000000 kswapd_can_sleep_pgdat=0A= 80138884 l F .text 00000000 kswapd_can_sleep=0A= 802072a4 l F .text.init 00000000 kswapd_init=0A= 80210048 l O .initcall.init 00000004 __initcall_kswapd_init=0A= 00000000 l df *ABS* 00000000 page_io.c=0A= 801389d0 l F .text 00000000 rw_swap_page_base=0A= 00000000 l df *ABS* 00000000 page_alloc.c=0A= 8021a430 l O .data 0000000c zone_names=0A= 8020fc8c l O .data.init 0000000c zone_balance_ratio=0A= 8020fc98 l O .data.init 0000000c zone_balance_min=0A= 8020fca4 l O .data.init 0000000c zone_balance_max=0A= 80138d70 l F .text 00000000 __free_pages_ok=0A= 8013922c l F .text 00000000 rmqueue=0A= 80139698 l F .text 00000000 balance_classzone=0A= 80207894 l F .text.init 00000000 setup_mem_frac=0A= 8020fcb0 l O .data.init 00000009 __setup_str_setup_mem_frac=0A= 8020ffc0 l O .setup.init 00000008 __setup_setup_mem_frac=0A= 00000000 l df *ABS* 00000000 swap_state.c=0A= 8013a040 l F .text 00000000 swap_writepage=0A= 8021a440 l O .data 00000024 swap_aops=0A= 8031eca0 l O .bss 00000018 swap_cache_info=0A= 00000000 l df *ABS* 00000000 swapfile.c=0A= 801ebbf0 l O .text 00000015 Bad_file=0A= 801ebc08 l O .text 00000018 Unused_file=0A= 801ebc20 l O .text 00000017 Bad_offset=0A= 801ebc38 l O .text 0000001a Unused_offset=0A= 8013a838 l F .text 00000000 swap_info_get=0A= 8013a94c l F .text 00000000 swap_info_put=0A= 8013a954 l F .text 00000000 swap_entry_free=0A= 8013aa0c l F .text 00000000 exclusive_swap_page=0A= 8013adbc l F .text 00000000 unuse_vma=0A= 8013b070 l F .text 00000000 unuse_process=0A= 8013b0e8 l F .text 00000000 find_next_to_unuse=0A= 8013b140 l F .text 00000000 try_to_unuse=0A= 8031f348 l O .bss 00000004 swap_overflow=0A= 8021a4a8 l O .data 00000004 least_priority.0=0A= 00000000 l df *ABS* 00000000 numa.c=0A= 8031f350 l O .bss 00000014 contig_bootmem_data=0A= 00000000 l df *ABS* 00000000 oom_kill.c=0A= 8013c7c0 l F .text 00000000 int_sqrt=0A= 8013c810 l F .text 00000000 badness=0A= 8013c940 l F .text 00000000 select_bad_process=0A= 8013ca48 l F .text 00000000 oom_kill=0A= 8031f370 l O .bss 00000004 first.0=0A= 8031f374 l O .bss 00000004 last.1=0A= 8031f378 l O .bss 00000004 count.2=0A= 00000000 l df *ABS* 00000000 shmem.c=0A= 8021a7d8 l O .data 00000000 shmem_ilock=0A= 8013cb90 l F .text 00000000 shmem_recalc_inode=0A= 8013cbdc l F .text 00000000 shmem_swp_entry=0A= 8013cc84 l F .text 00000000 shmem_free_swp=0A= 8013ccfc l F .text 00000000 shmem_truncate=0A= 8013cfdc l F .text 00000000 shmem_delete_inode=0A= 8013d060 l F .text 00000000 shmem_clear_swp=0A= 8013d0d8 l F .text 00000000 shmem_unuse_inode=0A= 8013d270 l F .text 00000000 shmem_writepage=0A= 8013d428 l F .text 00000000 shmem_getpage_locked=0A= 8013d7a8 l F .text 00000000 shmem_getpage=0A= 8013da14 l F .text 00000000 shmem_mmap=0A= 8021a950 l O .data 0000000c shmem_vm_ops=0A= 8021a7dc l O .data 00000024 shmem_aops=0A= 8021a8d0 l O .data 00000040 shmem_dir_inode_operations=0A= 8021a888 l O .data 00000048 shmem_dir_operations=0A= 8021a848 l O .data 00000040 shmem_inode_operations=0A= 8021a800 l O .data 00000048 shmem_file_operations=0A= 8013dc10 l F .text 00000000 shmem_set_size=0A= 8013dc64 l F .text 00000000 shmem_read_super=0A= 8021a910 l O .data 00000040 shmem_ops=0A= 8021a95c l O .data 0000001c tmpfs_fs_type=0A= 80207968 l F .text.init 00000000 init_shmem_fs=0A= 8031f380 l O .bss 00000004 shm_mnt=0A= 8021004c l O .initcall.init 00000004 __initcall_init_shmem_fs=0A= 00000000 l df *ABS* 00000000 open.c=0A= 8013f274 l F .text 00000000 chown_common=0A= 8021a980 l O .data 00000008 kill_list.0=0A= 00000000 l df *ABS* 00000000 read_write.c=0A= 801401f8 l F .text 00000000 do_readv_writev=0A= 00000000 l df *ABS* 00000000 devices.c=0A= 8021a9e0 l O .data 00000000 chrdevs_lock=0A= 8031f3d0 l O .bss 000007f8 chrdevs=0A= 801408f8 l F .text 00000000 get_chrfops=0A= 8021a9e0 l O .data 00000048 def_chr_fops=0A= 8031f390 l O .bss 00000020 buffer.0=0A= 8031f3b0 l O .bss 00000020 buffer.1=0A= 80140c90 l F .text 00000000 sock_no_open=0A= 8021aa28 l O .data 00000048 bad_sock_fops=0A= 00000000 l df *ABS* 00000000 file_table.c=0A= 8021aa7c l O .data 00000008 anon_list=0A= 8021aa84 l O .data 00000008 free_list=0A= 8021aa8c l O .data 00000004 old_max.0=0A= 00000000 l df *ABS* 00000000 buffer.c=0A= 8021aa90 l O .data 00000000 hash_table_lock=0A= 8021aa90 l O .data 00000000 lru_list_lock=0A= 8021aa90 l O .data 00000000 unused_list_lock=0A= 8021aa90 l O .data 00000008 buffer_wait=0A= 80141448 l F .text 00000000 write_locked_buffers=0A= 801414a0 l F .text 00000000 write_some_buffers=0A= 8031fbdc l O .bss 0000000c lru_list=0A= 8031fbe8 l O .bss 0000000c nr_buffers_type=0A= 80142bf4 l F .text 00000000 __refile_buffer=0A= 801415fc l F .text 00000000 write_unlocked_buffers=0A= 8014164c l F .text 00000000 wait_for_buffers=0A= 8014175c l F .text 00000000 wait_for_locked_buffers=0A= 80141cb4 l F .text 00000000 __insert_into_lru_list=0A= 8031fbf4 l O .bss 0000000c size_buffers_type=0A= 80141da0 l F .text 00000000 __remove_from_lru_list=0A= 80141e30 l F .text 00000000 __remove_from_queues=0A= 80141e70 l F .text 00000000 remove_from_queues=0A= 8031fbd4 l O .bss 00000004 bh_hash_shift=0A= 8031fbd0 l O .bss 00000004 bh_hash_mask=0A= 8031fbd8 l O .bss 00000004 hash_table=0A= 80141fc0 l F .text 00000000 __remove_inode_queue=0A= 8014223c l F .text 00000000 free_more_memory=0A= 8021ab08 l O .data 00000000 page_uptodate_lock.0=0A= 801422c4 l F .text 00000000 end_buffer_io_async=0A= 80145064 l F .text 00000000 grow_buffers=0A= 80142a5c l F .text 00000000 balance_dirty_state=0A= 80142dd8 l F .text 00000000 __put_unused_buffer_head=0A= 8031fc04 l O .bss 00000004 nr_unused_buffer_heads=0A= 8031fc00 l O .bss 00000004 unused_list=0A= 80142fd8 l F .text 00000000 create_buffers=0A= 801430e8 l F .text 00000000 discard_buffer=0A= 8014342c l F .text 00000000 unmap_underlying_metadata=0A= 801434d0 l F .text 00000000 __block_write_full_page=0A= 801436f0 l F .text 00000000 __block_prepare_write=0A= 801439cc l F .text 00000000 __block_commit_write=0A= 801446b4 l F .text 00000000 end_buffer_io_kiobuf=0A= 80144728 l F .text 00000000 wait_kio=0A= 80144e2c l F .text 00000000 grow_dev_page=0A= 80144f40 l F .text 00000000 hash_page_buffers=0A= 8014522c l F .text 00000000 sync_page_buffers=0A= 8014554c l F .text 00000000 sync_old_buffers=0A= 8020fcbc l O .data.init 0000000c startup.1=0A= 80207b74 l F .text.init 00000000 bdflush_init=0A= 80210050 l O .initcall.init 00000004 __initcall_bdflush_init=0A= 00000000 l df *ABS* 00000000 super.c=0A= 8021ab18 l O .data 00000000 file_systems_lock=0A= 80145ad0 l F .text 00000000 get_filesystem=0A= 80145b08 l F .text 00000000 put_filesystem=0A= 80145b40 l F .text 00000000 find_filesystem=0A= 8031fc14 l O .bss 00000004 file_systems=0A= 80145c88 l F .text 00000000 fs_index=0A= 80145d60 l F .text 00000000 fs_name=0A= 80145e18 l F .text 00000000 fs_maxindex=0A= 8014602c l F .text 00000000 put_super=0A= 801463f0 l F .text 00000000 alloc_super=0A= 80146508 l F .text 00000000 read_super=0A= 8031fc18 l O .bss 00000020 unnamed_dev_in_use=0A= 801467e4 l F .text 00000000 grab_super=0A= 80146868 l F .text 00000000 get_sb_bdev=0A= 80146bf0 l F .text 00000000 get_sb_nodev=0A= 80146c8c l F .text 00000000 get_sb_single=0A= 80207bdc l F .text.init 00000000 root_data_setup=0A= 8020fce0 l O .data.init 00000004 root_mount_data=0A= 80207bec l F .text.init 00000000 fs_names_setup=0A= 8020fce4 l O .data.init 00000004 root_fs_names=0A= 8020fcc8 l O .data.init 0000000b __setup_str_root_data_setup=0A= 8020ffc8 l O .setup.init 00000008 __setup_root_data_setup=0A= 8020fcd4 l O .data.init 0000000c __setup_str_fs_names_setup=0A= 8020ffd0 l O .setup.init 00000008 __setup_fs_names_setup=0A= 80207bfc l F .text.init 00000000 get_fs_names=0A= 00000000 l df *ABS* 00000000 block_dev.c=0A= 80147470 l F .text 00000000 max_block=0A= 80147514 l F .text 00000000 blkdev_size=0A= 80147560 l F .text 00000000 kill_bdev=0A= 80147700 l F .text 00000000 blkdev_get_block=0A= 8014776c l F .text 00000000 blkdev_direct_IO=0A= 80147798 l F .text 00000000 blkdev_writepage=0A= 801477bc l F .text 00000000 blkdev_readpage=0A= 801477e4 l F .text 00000000 blkdev_prepare_write=0A= 80147814 l F .text 00000000 blkdev_commit_write=0A= 80147838 l F .text 00000000 block_llseek=0A= 80147920 l F .text 00000000 __block_fsync=0A= 8014796c l F .text 00000000 block_fsync=0A= 8021ab20 l O .data 00000040 sops.0=0A= 8014798c l F .text 00000000 bd_read_super=0A= 8021ab60 l O .data 0000001c bd_type=0A= 8021ab7c l O .data 00000000 bdev_lock=0A= 80147a80 l F .text 00000000 init_once=0A= 8031fc64 l O .bss 00000200 bdev_hashtable=0A= 8031fe64 l O .bss 00000004 bdev_cachep=0A= 8031fc60 l O .bss 00000004 bd_mnt=0A= 80147af0 l F .text 00000000 bdfind=0A= 8031fe68 l O .bss 000007f8 blkdevs=0A= 80148194 l F .text 00000000 do_open=0A= 80148618 l F .text 00000000 blkdev_ioctl=0A= 8031fc40 l O .bss 00000020 buffer.1=0A= 00000000 l df *ABS* 00000000 char_dev.c=0A= 8021abf0 l O .data 00000000 cdev_lock=0A= 801486c0 l F .text 00000000 init_once=0A= 80320660 l O .bss 00000200 cdev_hashtable=0A= 80320860 l O .bss 00000004 cdev_cachep=0A= 80148724 l F .text 00000000 cdfind=0A= 00000000 l df *ABS* 00000000 stat.c=0A= 8021abf0 l O .data 00000004 warncount.0=0A= 801488b0 l F .text 00000000 cp_old_stat=0A= 801489c8 l F .text 00000000 cp_new_stat=0A= 80148f90 l F .text 00000000 cp_new_stat64=0A= 00000000 l df *ABS* 00000000 exec.c=0A= 8021ac00 l O .data 00000000 binfmt_lock=0A= 80320874 l O .bss 00000004 formats=0A= 801494c4 l F .text 00000000 count=0A= 80149bb4 l F .text 00000000 exec_mmap=0A= 00000000 l df *ABS* 00000000 pipe.c=0A= 8014ad98 l F .text 00000000 pipe_read=0A= 8014b058 l F .text 00000000 pipe_write=0A= 8014b3b8 l F .text 00000000 pipe_lseek=0A= 8014b3c4 l F .text 00000000 bad_pipe_r=0A= 8014b3cc l F .text 00000000 bad_pipe_w=0A= 8014b3d4 l F .text 00000000 pipe_ioctl=0A= 8014b418 l F .text 00000000 pipe_poll=0A= 8014b4ac l F .text 00000000 pipe_release=0A= 8014b5bc l F .text 00000000 pipe_read_release=0A= 8014b5dc l F .text 00000000 pipe_write_release=0A= 8014b5fc l F .text 00000000 pipe_rdwr_release=0A= 8014b624 l F .text 00000000 pipe_read_open=0A= 8014b6c8 l F .text 00000000 pipe_write_open=0A= 8014b76c l F .text 00000000 pipe_rdwr_open=0A= 8014b904 l F .text 00000000 pipefs_delete_dentry=0A= 8021adb0 l O .data 00000018 pipefs_dentry_operations=0A= 8014b90c l F .text 00000000 get_pipe_inode=0A= 80320880 l O .bss 00000004 pipe_mnt=0A= 8014bd44 l F .text 00000000 pipefs_statfs=0A= 8021adc8 l O .data 00000040 pipefs_ops=0A= 8014bd68 l F .text 00000000 pipefs_read_super=0A= 8021ae08 l O .data 0000001c pipe_fs_type=0A= 80208330 l F .text.init 00000000 init_pipe_fs=0A= 80210054 l O .initcall.init 00000004 __initcall_init_pipe_fs=0A= 00000000 l df *ABS* 00000000 namei.c=0A= 8021ae30 l O .data 00000000 arbitration_lock=0A= 8014c1a4 l F .text 00000000 cached_lookup=0A= 8014c228 l F .text 00000000 real_lookup=0A= 8014d020 l F .text 00000000 __emul_lookup_dentry=0A= 8014de2c l F .text 00000000 lookup_create=0A= 8014e4f8 l F .text 00000000 d_unhash=0A= 80150458 l F .text 00000000 page_getlink=0A= 00000000 l df *ABS* 00000000 fcntl.c=0A= 801507b0 l F .text 00000000 expand_files=0A= 80150828 l F .text 00000000 locate_fd=0A= 80150980 l F .text 00000000 dupfd=0A= 80150c10 l F .text 00000000 setfl=0A= 80150d78 l F .text 00000000 do_fcntl=0A= 8021ae70 l O .data 00000018 band_table=0A= 8015116c l F .text 00000000 send_sigio_to_task=0A= 8021ae88 l O .data 00000000 fasync_lock=0A= 80320890 l O .bss 00000004 fasync_cache=0A= 802083b0 l F .text.init 00000000 fasync_init=0A= 80210058 l O .initcall.init 00000004 __initcall_fasync_init=0A= 00000000 l df *ABS* 00000000 ioctl.c=0A= 801515a0 l F .text 00000000 file_ioctl=0A= 00000000 l df *ABS* 00000000 readdir.c=0A= 80151cac l F .text 00000000 fillonedir=0A= 80151e00 l F .text 00000000 filldir=0A= 80151fd4 l F .text 00000000 filldir64=0A= 00000000 l df *ABS* 00000000 select.c=0A= 80152378 l F .text 00000000 max_select_fd=0A= 801526e8 l F .text 00000000 select_bits_alloc=0A= 80152714 l F .text 00000000 select_bits_free=0A= 80152b8c l F .text 00000000 do_pollfd=0A= 80152c80 l F .text 00000000 do_poll=0A= 00000000 l df *ABS* 00000000 fifo.c=0A= 801530c0 l F .text 00000000 wait_for_partner=0A= 80153120 l F .text 00000000 wake_up_partner=0A= 80153144 l F .text 00000000 fifo_open=0A= 00000000 l df *ABS* 00000000 locks.c=0A= 8021aef0 l O .data 00000008 blocked_list=0A= 80153490 l F .text 00000000 locks_alloc_lock=0A= 803208a0 l O .bss 00000004 filelock_cache=0A= 8015354c l F .text 00000000 init_once=0A= 801535f8 l F .text 00000000 flock_make_lock=0A= 80153680 l F .text 00000000 assign_type=0A= 801536a4 l F .text 00000000 flock_to_posix_lock=0A= 801537b4 l F .text 00000000 flock64_to_posix_lock=0A= 80153938 l F .text 00000000 lease_alloc=0A= 80153a64 l F .text 00000000 locks_delete_block=0A= 80153aa4 l F .text 00000000 locks_insert_block=0A= 80153b64 l F .text 00000000 locks_wake_up_blocks=0A= 80153c48 l F .text 00000000 locks_insert_lock=0A= 80153ca8 l F .text 00000000 locks_delete_lock=0A= 80153dc0 l F .text 00000000 locks_conflict=0A= 80153e0c l F .text 00000000 posix_locks_conflict=0A= 80153ee0 l F .text 00000000 flock_locks_conflict=0A= 80153f48 l F .text 00000000 interruptible_sleep_on_locked=0A= 80153ff4 l F .text 00000000 locks_block_on=0A= 8015403c l F .text 00000000 locks_block_on_timeout=0A= 8015444c l F .text 00000000 flock_lock_file=0A= 80154f18 l F .text 00000000 lease_modify=0A= 80155e78 l F .text 00000000 lock_get_status=0A= 8015612c l F .text 00000000 move_lock_status=0A= 80208400 l F .text.init 00000000 filelock_init=0A= 8021005c l O .initcall.init 00000004 __initcall_filelock_init=0A= 00000000 l df *ABS* 00000000 dcache.c=0A= 8021af00 l O .data 00000008 dentry_unused=0A= 803208c0 l O .bss 00000004 dentry_cache=0A= 80156d5c l F .text 00000000 select_parent=0A= 803208c8 l O .bss 00000004 d_hash_shift=0A= 803208c4 l O .bss 00000004 d_hash_mask=0A= 803208cc l O .bss 00000004 dentry_hashtable=0A= 80208458 l F .text.init 00000000 dcache_init=0A= 80157c08 l F .text 00000000 init_buffer_head=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 8021af20 l O .data 00000008 inode_in_use=0A= 8021af28 l O .data 00000008 inode_unused=0A= 8021af30 l O .data 00000008 anon_hash_chain=0A= 8021af38 l O .data 00000000 inode_lock=0A= 80157c60 l F .text 00000000 destroy_inode=0A= 803209a8 l O .bss 00000004 inode_cachep=0A= 80157cb8 l F .text 00000000 init_once=0A= 80157e60 l F .text 00000000 __wait_on_inode=0A= 8015838c l F .text 00000000 get_super_to_sync=0A= 80158494 l F .text 00000000 try_to_sync_unused_inodes=0A= 80158b84 l F .text 00000000 dispose_list=0A= 80158c20 l F .text 00000000 invalidate_list=0A= 803209ac l O .bss 00000014 unused_inodes_flush_task=0A= 80159008 l F .text 00000000 find_inode=0A= 803208d0 l O .bss 00000024 empty_aops.0=0A= 803208f4 l O .bss 00000040 empty_iops.1=0A= 80320934 l O .bss 00000048 empty_fops.2=0A= 801590b8 l F .text 00000000 clean_inode=0A= 8032097c l O .bss 00000004 last_ino.3=0A= 80159214 l F .text 00000000 get_new_inode=0A= 8021af38 l O .data 00000004 counter.4=0A= 803209a0 l O .bss 00000004 i_hash_shift=0A= 8032099c l O .bss 00000004 i_hash_mask=0A= 803209a4 l O .bss 00000004 inode_hashtable=0A= 00000000 l df *ABS* 00000000 attr.c=0A= 80159e48 l F .text 00000000 setattr_mask=0A= 00000000 l df *ABS* 00000000 bad_inode.c=0A= 8015a030 l F .text 00000000 bad_follow_link=0A= 8015a0b8 l F .text 00000000 return_EIO=0A= 8021af40 l O .data 00000048 bad_file_ops=0A= 00000000 l df *ABS* 00000000 file.c=0A= 00000000 l df *ABS* 00000000 iobuf.c=0A= 8015a660 l F .text 00000000 kiobuf_init=0A= 00000000 l df *ABS* 00000000 dnotify.c=0A= 8021afd4 l O .data 00000000 dn_lock=0A= 8015aa80 l F .text 00000000 redo_inode_mask=0A= 803209c0 l O .bss 00000004 dn_cache=0A= 802087f0 l F .text.init 00000000 dnotify_init=0A= 80210060 l O .initcall.init 00000004 __initcall_dnotify_init=0A= 00000000 l df *ABS* 00000000 filesystems.c=0A= 00000000 l df *ABS* 00000000 namespace.c=0A= 8021afe0 l O .data 00000008 vfsmntlist=0A= 8021afe8 l O .data 00000010 mount_sem=0A= 803209dc l O .bss 00000004 mnt_cache=0A= 803209d8 l O .bss 00000004 hash_bits=0A= 803209d4 l O .bss 00000004 hash_mask=0A= 803209d0 l O .bss 00000004 mount_hashtable=0A= 8015af24 l F .text 00000000 check_mnt=0A= 8015af54 l F .text 00000000 detach_mnt=0A= 8015afb8 l F .text 00000000 attach_mnt=0A= 8015b0e8 l F .text 00000000 next_mnt=0A= 8015b124 l F .text 00000000 clone_mnt=0A= 8015b240 l F .text 00000000 m_start=0A= 8015b2f0 l F .text 00000000 m_next=0A= 8015b330 l F .text 00000000 m_stop=0A= 8021aff8 l O .data 0000006c nfs_info.0=0A= 8015b37c l F .text 00000000 show_nfs_mount=0A= 8021b064 l O .data 00000028 fs_info.1=0A= 8021b08c l O .data 00000020 mnt_info.2=0A= 8015b59c l F .text 00000000 show_vfsmnt=0A= 8015baf0 l F .text 00000000 do_umount=0A= 8015bd78 l F .text 00000000 mount_is_safe=0A= 8015bdac l F .text 00000000 copy_tree=0A= 8015c044 l F .text 00000000 do_loopback=0A= 8015c200 l F .text 00000000 do_remount=0A= 8015c2f8 l F .text 00000000 do_add_mount=0A= 8015c47c l F .text 00000000 copy_mount_options=0A= 8015c7f8 l F .text 00000000 chroot_fs_refs=0A= 8015ce8c l F .text 00000000 rootfs_lookup=0A= 8021b0bc l O .data 00000048 rootfs_dir_operations=0A= 8021b104 l O .data 00000040 rootfs_dir_inode_operations=0A= 8021b144 l O .data 00000040 s_ops.3=0A= 8015cec4 l F .text 00000000 rootfs_read_super=0A= 8021b184 l O .data 0000001c root_fs_type=0A= 80208840 l F .text.init 00000000 init_mount_tree=0A= 00000000 l df *ABS* 00000000 seq_file.c=0A= 8015d418 l F .text 00000000 traverse=0A= 00000000 l df *ABS* 00000000 noquot.c=0A= 00000000 l df *ABS* 00000000 binfmt_script.c=0A= 8015d9e0 l F .text 00000000 load_script=0A= 80208d1c l F .text.init 00000000 init_script_binfmt=0A= 80210064 l O .initcall.init 00000004 = __initcall_init_script_binfmt=0A= 00000000 l df *ABS* 00000000 binfmt_elf.c=0A= 8021b1c0 l O .data 00000018 elf_format=0A= 8015e4ac l F .text 00000000 load_elf_binary=0A= 8015f0a4 l F .text 00000000 load_elf_library=0A= 8015f4f0 l F .text 00000000 elf_core_dump=0A= 8015dc90 l F .text 00000000 set_brk=0A= 8015dcd8 l F .text 00000000 padzero=0A= 8015dd34 l F .text 00000000 create_elf_tables=0A= 8015e020 l F .text 00000000 load_elf_interp=0A= 8015e334 l F .text 00000000 load_aout_interp=0A= 8015f310 l F .text 00000000 dump_write=0A= 8015f34c l F .text 00000000 dump_seek=0A= 8015f3d8 l F .text 00000000 notesize=0A= 8015f424 l F .text 00000000 writenote=0A= 80208d40 l F .text.init 00000000 init_elf_binfmt=0A= 80210068 l O .initcall.init 00000004 __initcall_init_elf_binfmt=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 8015fdd4 l F .text 00000000 proc_delete_inode=0A= 8015fe58 l F .text 00000000 proc_read_inode=0A= 8015fe70 l F .text 00000000 proc_statfs=0A= 8021b1e0 l O .data 00000040 proc_sops=0A= 8015fe9c l F .text 00000000 parse_options=0A= 00000000 l df *ABS* 00000000 root.c=0A= 8021b220 l O .data 0000001c proc_fs_type=0A= 801602b0 l F .text 00000000 proc_root_lookup=0A= 80160320 l F .text 00000000 proc_root_readdir=0A= 8021b23c l O .data 00000048 proc_root_operations=0A= 8021b284 l O .data 00000040 proc_root_inode_operations=0A= 00000000 l df *ABS* 00000000 base.c=0A= 801603a0 l F .text 00000000 proc_fd_link=0A= 80160454 l F .text 00000000 proc_exe_link=0A= 80160598 l F .text 00000000 proc_cwd_link=0A= 8016067c l F .text 00000000 proc_root_link=0A= 80160760 l F .text 00000000 proc_pid_environ=0A= 801607e4 l F .text 00000000 proc_pid_cmdline=0A= 801608fc l F .text 00000000 proc_check_root=0A= 80160a90 l F .text 00000000 proc_permission=0A= 80160ad4 l F .text 00000000 pid_maps_read=0A= 8021b320 l O .data 00000048 proc_maps_operations=0A= 80160b18 l F .text 00000000 proc_info_read=0A= 8021b368 l O .data 00000048 proc_info_file_operations=0A= 80160ca8 l F .text 00000000 mem_open=0A= 80160cb8 l F .text 00000000 mem_read=0A= 8021b3b0 l O .data 00000048 proc_mem_operations=0A= 8021b3f8 l O .data 00000040 proc_mem_inode_operations=0A= 80160e80 l F .text 00000000 proc_pid_follow_link=0A= 80160f2c l F .text 00000000 do_proc_readlink=0A= 801610d0 l F .text 00000000 proc_pid_readlink=0A= 8021b438 l O .data 00000040 proc_pid_link_inode_operations=0A= 8021b478 l O .data 000000c0 base_stuff=0A= 801611d8 l F .text 00000000 proc_readfd=0A= 80161438 l F .text 00000000 proc_base_readdir=0A= 80161614 l F .text 00000000 task_dumpable=0A= 80161630 l F .text 00000000 proc_pid_make_inode=0A= 8016174c l F .text 00000000 pid_fd_revalidate=0A= 80161754 l F .text 00000000 pid_base_revalidate=0A= 80161798 l F .text 00000000 pid_delete_dentry=0A= 8021b538 l O .data 00000018 pid_fd_dentry_operations=0A= 8021b550 l O .data 00000018 pid_dentry_operations=0A= 8021b568 l O .data 00000018 pid_base_dentry_operations=0A= 801617a0 l F .text 00000000 proc_lookupfd=0A= 8021b580 l O .data 00000048 proc_fd_operations=0A= 8021b5c8 l O .data 00000040 proc_fd_inode_operations=0A= 80161978 l F .text 00000000 proc_base_lookup=0A= 8021b608 l O .data 00000048 proc_base_operations=0A= 8021b650 l O .data 00000040 proc_base_inode_operations=0A= 80161bb8 l F .text 00000000 proc_self_readlink=0A= 80161c18 l F .text 00000000 proc_self_follow_link=0A= 8021b690 l O .data 00000040 proc_self_inode_operations=0A= 80161efc l F .text 00000000 get_pid_list=0A= 00000000 l df *ABS* 00000000 generic.c=0A= 8021b6d0 l O .data 00000048 proc_file_operations=0A= 801623c0 l F .text 00000000 proc_file_lseek=0A= 80162160 l F .text 00000000 proc_file_read=0A= 80162388 l F .text 00000000 proc_file_write=0A= 80162474 l F .text 00000000 xlate_proc_name=0A= 80162520 l F .text 00000000 make_inode_number=0A= 80320a30 l O .bss 00000200 proc_alloc_map=0A= 801625b8 l F .text 00000000 proc_readlink=0A= 801625e0 l F .text 00000000 proc_follow_link=0A= 8021b718 l O .data 00000040 proc_link_inode_operations=0A= 80162608 l F .text 00000000 proc_delete_dentry=0A= 8021b758 l O .data 00000018 proc_dentry_operations=0A= 8021b770 l O .data 00000048 proc_dir_operations=0A= 8021b7b8 l O .data 00000040 proc_dir_inode_operations=0A= 801628c8 l F .text 00000000 proc_register=0A= 801629ac l F .text 00000000 proc_kill_inodes=0A= 80162a48 l F .text 00000000 proc_create=0A= 00000000 l df *ABS* 00000000 array.c=0A= 8021b800 l O .data 00000018 task_state_array=0A= 80162f30 l F .text 00000000 collect_sigign_sigcatch=0A= 801636d4 l F .text 00000000 statm_pgd_range=0A= 80163ac8 l F .text 00000000 proc_pid_maps_get_line=0A= 00000000 l df *ABS* 00000000 kmsg.c=0A= 80163fd0 l F .text 00000000 kmsg_open=0A= 80163ff4 l F .text 00000000 kmsg_release=0A= 8016401c l F .text 00000000 kmsg_read=0A= 80164038 l F .text 00000000 kmsg_poll=0A= 00000000 l df *ABS* 00000000 proc_tty.c=0A= 80164090 l F .text 00000000 tty_drivers_read_proc=0A= 80164308 l F .text 00000000 tty_ldiscs_read_proc=0A= 80320c34 l O .bss 00000004 proc_tty_driver=0A= 80320c30 l O .bss 00000004 proc_tty_ldisc=0A= 00000000 l df *ABS* 00000000 proc_misc.c=0A= 80164510 l F .text 00000000 proc_calc_metrics=0A= 80164554 l F .text 00000000 loadavg_read_proc=0A= 80164660 l F .text 00000000 uptime_read_proc=0A= 80164738 l F .text 00000000 meminfo_read_proc=0A= 801649e8 l F .text 00000000 version_read_proc=0A= 80164a74 l F .text 00000000 cpuinfo_open=0A= 8021b870 l O .data 00000048 proc_cpuinfo_operations=0A= 80164a9c l F .text 00000000 modules_read_proc=0A= 80164b04 l F .text 00000000 ksyms_open=0A= 8021b8b8 l O .data 00000048 proc_ksyms_operations=0A= 80164b2c l F .text 00000000 kstat_read_proc=0A= 80164de8 l F .text 00000000 devices_read_proc=0A= 80164e50 l F .text 00000000 partitions_read_proc=0A= 80164e8c l F .text 00000000 interrupts_read_proc=0A= 80164ef4 l F .text 00000000 filesystems_read_proc=0A= 80164f5c l F .text 00000000 dma_read_proc=0A= 80164fc4 l F .text 00000000 ioports_read_proc=0A= 8016503c l F .text 00000000 cmdline_read_proc=0A= 801650bc l F .text 00000000 locks_read_proc=0A= 801650f8 l F .text 00000000 execdomains_read_proc=0A= 80165160 l F .text 00000000 swaps_read_proc=0A= 801651c8 l F .text 00000000 memory_read_proc=0A= 80165240 l F .text 00000000 read_profile=0A= 80165364 l F .text 00000000 write_profile=0A= 8021b900 l O .data 00000048 proc_profile_operations=0A= 801653a8 l F .text 00000000 mounts_open=0A= 8021b948 l O .data 00000048 proc_mounts_operations=0A= 801653d0 l F .text 00000000 create_seq_entry=0A= 80320c40 l O .bss 00000004 p.0=0A= 8021b990 l O .data 00000090 simple_ones.1=0A= 00000000 l df *ABS* 00000000 kcore.c=0A= 80165400 l F .text 00000000 open_kcore=0A= 801658c4 l F .text 00000000 read_kcore=0A= 80165430 l F .text 00000000 get_kcore_size=0A= 801654c0 l F .text 00000000 notesize=0A= 8016550c l F .text 00000000 storenote=0A= 801655d0 l F .text 00000000 elf_kcore_store_hdr=0A= 00000000 l df *ABS* 00000000 check.c=0A= 8021ba74 l O .data 00000008 check_part=0A= 8021ba7c l O .data 00000004 first_time.0=0A= 80166060 l F .text 00000000 check_partition=0A= 00000000 l df *ABS* 00000000 msdos.c=0A= 801664d0 l F .text 00000000 partition_name=0A= 801664ec l F .text 00000000 extended_partition=0A= 801667f8 l F .text 00000000 solaris_x86_partition=0A= 80166800 l F .text 00000000 bsd_partition=0A= 80166808 l F .text 00000000 netbsd_partition=0A= 80166810 l F .text 00000000 openbsd_partition=0A= 80166818 l F .text 00000000 unixware_partition=0A= 80166820 l F .text 00000000 minix_partition=0A= 8021ba80 l O .data 00000038 subtypes=0A= 80166828 l F .text 00000000 handle_ide_mess=0A= 00000000 l df *ABS* 00000000 balloc.c=0A= 80166c70 l F .text 00000000 read_block_bitmap=0A= 80166d3c l F .text 00000000 __load_block_bitmap=0A= 00000000 l df *ABS* 00000000 bitmap.c=0A= 8021bac0 l O .data 00000040 nibblemap=0A= 00000000 l df *ABS* 00000000 dir.c=0A= 80167f60 l F .text 00000000 ext2_commit_chunk=0A= 80168008 l F .text 00000000 ext2_check_page=0A= 80168254 l F .text 00000000 ext2_get_page=0A= 8021bb00 l O .data 00000008 ext2_filetype_table=0A= 8021bb08 l O .data 0000000f ext2_type_by_mode=0A= 80168300 l F .text 00000000 ext2_readdir=0A= 00000000 l df *ABS* 00000000 file.c=0A= 80168f70 l F .text 00000000 ext2_release_file=0A= 00000000 l df *ABS* 00000000 fsync.c=0A= 00000000 l df *ABS* 00000000 ialloc.c=0A= 80169050 l F .text 00000000 read_inode_bitmap=0A= 801690e8 l F .text 00000000 load_inode_bitmap=0A= 80169524 l F .text 00000000 find_group_dir=0A= 80169638 l F .text 00000000 find_group_other=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 8016b4bc l F .text 00000000 ext2_update_inode=0A= 80169cf4 l F .text 00000000 ext2_alloc_block=0A= 80169da8 l F .text 00000000 ext2_block_to_path=0A= 80169ec4 l F .text 00000000 ext2_get_branch=0A= 8016a024 l F .text 00000000 ext2_alloc_branch=0A= 8016a2a8 l F .text 00000000 ext2_get_block=0A= 8016a770 l F .text 00000000 ext2_writepage=0A= 8016a794 l F .text 00000000 ext2_readpage=0A= 8016a7bc l F .text 00000000 ext2_prepare_write=0A= 8016a7ec l F .text 00000000 ext2_bmap=0A= 8016a810 l F .text 00000000 ext2_direct_IO=0A= 8016a83c l F .text 00000000 ext2_find_shared=0A= 8016a9ec l F .text 00000000 ext2_free_branches=0A= 00000000 l df *ABS* 00000000 ioctl.c=0A= 00000000 l df *ABS* 00000000 namei.c=0A= 8016bbd0 l F .text 00000000 ext2_lookup=0A= 8016bc54 l F .text 00000000 ext2_create=0A= 8016bd28 l F .text 00000000 ext2_mknod=0A= 8016bdfc l F .text 00000000 ext2_symlink=0A= 8016bf8c l F .text 00000000 ext2_link=0A= 8016c06c l F .text 00000000 ext2_mkdir=0A= 8016c1cc l F .text 00000000 ext2_unlink=0A= 8016c254 l F .text 00000000 ext2_rmdir=0A= 8016c300 l F .text 00000000 ext2_rename=0A= 00000000 l df *ABS* 00000000 super.c=0A= 80320c50 l O .bss 00000400 error_buf=0A= 8021bc60 l O .data 00000040 ext2_sops=0A= 8016c950 l F .text 00000000 parse_options=0A= 8016d0a8 l F .text 00000000 ext2_setup_super=0A= 8016d24c l F .text 00000000 ext2_check_descriptors=0A= 8016d374 l F .text 00000000 ext2_max_size=0A= 8016dd54 l F .text 00000000 ext2_commit_super=0A= 8021bca0 l O .data 0000001c ext2_fs_type=0A= 802090f0 l F .text.init 00000000 init_ext2_fs=0A= 8021006c l O .initcall.init 00000004 __initcall_init_ext2_fs=0A= 00000000 l df *ABS* 00000000 symlink.c=0A= 8016e090 l F .text 00000000 ext2_readlink=0A= 8016e0b4 l F .text 00000000 ext2_follow_link=0A= 00000000 l df *ABS* 00000000 dir.c=0A= 8016e0e0 l F .text 00000000 autofs_dir_lookup=0A= 00000000 l df *ABS* 00000000 dirhash.c=0A= 8016e120 l F .text 00000000 autofs_init_usage=0A= 8016e14c l F .text 00000000 autofs_delete_usage=0A= 00000000 l df *ABS* 00000000 init.c=0A= 8021bd90 l O .data 0000001c autofs_fs_type=0A= 80209114 l F .text.init 00000000 init_autofs_fs=0A= 80210070 l O .initcall.init 00000004 __initcall_init_autofs_fs=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 8016e990 l F .text 00000000 autofs_put_super=0A= 8021bdb0 l O .data 00000040 autofs_sops=0A= 8016f008 l F .text 00000000 autofs_read_inode=0A= 8016efe8 l F .text 00000000 autofs_statfs=0A= 8016ea48 l F .text 00000000 parse_options=0A= 00000000 l df *ABS* 00000000 root.c=0A= 8016f160 l F .text 00000000 autofs_root_readdir=0A= 8016fdc8 l F .text 00000000 autofs_root_ioctl=0A= 8016f618 l F .text 00000000 autofs_root_lookup=0A= 8016fa0c l F .text 00000000 autofs_root_unlink=0A= 8016f798 l F .text 00000000 autofs_root_symlink=0A= 8016fc58 l F .text 00000000 autofs_root_mkdir=0A= 8016fb6c l F .text 00000000 autofs_root_rmdir=0A= 8016f330 l F .text 00000000 try_to_fill_dentry=0A= 8016f518 l F .text 00000000 autofs_revalidate=0A= 8021be78 l O .data 00000018 autofs_dentry_operations=0A= 00000000 l df *ABS* 00000000 symlink.c=0A= 801700c0 l F .text 00000000 autofs_readlink=0A= 801700e8 l F .text 00000000 autofs_follow_link=0A= 00000000 l df *ABS* 00000000 waitq.c=0A= 8021bed0 l O .data 00000004 autofs_next_wait_queue=0A= 801701ac l F .text 00000000 autofs_write=0A= 80170320 l F .text 00000000 autofs_notify_daemon=0A= 00000000 l df *ABS* 00000000 init.c=0A= 8021bee0 l O .data 0000001c autofs_fs_type=0A= 80209138 l F .text.init 00000000 init_autofs4_fs=0A= 80210074 l O .initcall.init 00000004 __initcall_init_autofs4_fs=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 801707f0 l F .text 00000000 ino_lnkfree=0A= 80170958 l F .text 00000000 autofs4_put_super=0A= 8021bf00 l O .data 00000040 autofs4_sops=0A= 80170fe0 l F .text 00000000 autofs4_statfs=0A= 801709bc l F .text 00000000 parse_options=0A= 80170d5c l F .text 00000000 autofs4_mkroot=0A= 00000000 l df *ABS* 00000000 root.c=0A= 80171dd8 l F .text 00000000 autofs4_root_ioctl=0A= 801716d4 l F .text 00000000 autofs4_root_lookup=0A= 80171a58 l F .text 00000000 autofs4_dir_unlink=0A= 80171898 l F .text 00000000 autofs4_dir_symlink=0A= 80171c10 l F .text 00000000 autofs4_dir_mkdir=0A= 80171b44 l F .text 00000000 autofs4_dir_rmdir=0A= 80171698 l F .text 00000000 autofs4_dir_lookup=0A= 80171120 l F .text 00000000 autofs4_update_usage=0A= 8017118c l F .text 00000000 try_to_fill_dentry=0A= 80171454 l F .text 00000000 autofs4_root_revalidate=0A= 801715dc l F .text 00000000 autofs4_revalidate=0A= 8017163c l F .text 00000000 autofs4_dentry_release=0A= 8021c050 l O .data 00000018 autofs4_root_dentry_operations=0A= 8021c068 l O .data 00000018 autofs4_dentry_operations=0A= 00000000 l df *ABS* 00000000 symlink.c=0A= 80172090 l F .text 00000000 autofs4_readlink=0A= 801720b4 l F .text 00000000 autofs4_follow_link=0A= 00000000 l df *ABS* 00000000 waitq.c=0A= 8021c0c0 l O .data 00000004 autofs4_next_wait_queue=0A= 8017219c l F .text 00000000 autofs4_write=0A= 80172310 l F .text 00000000 autofs4_notify_daemon=0A= 00000000 l df *ABS* 00000000 expire.c=0A= 801728e0 l F .text 00000000 check_vfsmnt=0A= 80172a44 l F .text 00000000 is_tree_busy=0A= 80172c18 l F .text 00000000 autofs4_expire=0A= 00000000 l df *ABS* 00000000 root.c=0A= 80172f70 l F .text 00000000 devpts_root_readdir=0A= 80173170 l F .text 00000000 devpts_root_lookup=0A= 8021c158 l O .data 00000018 devpts_dentry_operations=0A= 80173138 l F .text 00000000 devpts_revalidate=0A= 00000000 l df *ABS* 00000000 inode.c=0A= 801732b0 l F .text 00000000 devpts_put_super=0A= 8021c170 l O .data 00000040 devpts_sops=0A= 801737a8 l F .text 00000000 devpts_statfs=0A= 801735c8 l F .text 00000000 devpts_remount=0A= 80173368 l F .text 00000000 devpts_parse_options=0A= 8021c1b0 l O .data 0000001c devpts_fs_type=0A= 80321050 l O .bss 00000004 devpts_mnt=0A= 8020915c l F .text.init 00000000 init_devpts_fs=0A= 80210078 l O .initcall.init 00000004 __initcall_init_devpts_fs=0A= 00000000 l df *ABS* 00000000 util.c=0A= 80173988 l F .text 00000000 grow_ary=0A= 00000000 l df *ABS* 00000000 msg.c=0A= 8021c1dc l O .data 00000004 msg_bytes=0A= 8021c1e0 l O .data 00000004 msg_hdrs=0A= 80321060 l O .bss 00000028 msg_ids=0A= 80175380 l F .text 00000000 sysvipc_msg_read_proc=0A= 80173e10 l F .text 00000000 newque=0A= 80173f00 l F .text 00000000 free_msg=0A= 80173f48 l F .text 00000000 load_msg=0A= 801740a4 l F .text 00000000 store_msg=0A= 80174184 l F .text 00000000 ss_wakeup=0A= 801741e0 l F .text 00000000 expunge_all=0A= 80174238 l F .text 00000000 freeque=0A= 80174bb8 l F .text 00000000 testmsg=0A= 00000000 l df *ABS* 00000000 sem.c=0A= 80321090 l O .bss 00000028 sem_ids=0A= 803210b8 l O .bss 00000004 used_sems=0A= 80177178 l F .text 00000000 sysvipc_sem_read_proc=0A= 801756e0 l F .text 00000000 newary=0A= 801759f4 l F .text 00000000 sem_revalidate=0A= 80175aa8 l F .text 00000000 try_atomic_semop=0A= 80175c40 l F .text 00000000 update_queue=0A= 80175d18 l F .text 00000000 count_semncnt=0A= 80175d84 l F .text 00000000 count_semzcnt=0A= 80175df0 l F .text 00000000 freeary=0A= 80175ea0 l F .text 00000000 copy_semid_to_user=0A= 8017696c l F .text 00000000 freeundos=0A= 801769d4 l F .text 00000000 alloc_undo=0A= 00000000 l df *ABS* 00000000 shm.c=0A= 803210c0 l O .bss 00000028 shm_ids=0A= 80178740 l F .text 00000000 sysvipc_shm_read_proc=0A= 801773a0 l F .text 00000000 shm_open=0A= 8017745c l F .text 00000000 shm_destroy=0A= 803210e8 l O .bss 00000004 shm_tot=0A= 801774c8 l F .text 00000000 shm_close=0A= 80177614 l F .text 00000000 shm_mmap=0A= 8021c254 l O .data 0000000c shm_vm_ops=0A= 8021c20c l O .data 00000048 shm_file_operations=0A= 80177704 l F .text 00000000 newseg=0A= 80177a7c l F .text 00000000 shm_get_stat=0A= 00000000 l df *ABS* 00000000 cp1emu.c=0A= 801f0a50 l O .text 00000004 ieee_rm=0A= 801f0a54 l O .text 00000020 fpucondbit=0A= 80178980 l F .text 00000000 isBranchInstr=0A= 80178a24 l F .text 00000000 mips_get_word=0A= 80178a74 l F .text 00000000 mips_get_dword=0A= 80178ad0 l F .text 00000000 mips_put_word=0A= 80178b1c l F .text 00000000 mips_put_dword=0A= 80178b70 l F .text 00000000 cop1Emulate=0A= 80179e1c l F .text 00000000 fpu_emu=0A= 80179310 l F .text 00000000 mips_dsemul=0A= 801798a8 l F .text 00000000 fpux_emu=0A= 801f0d08 l O .text 00000008 cmptab=0A= 80179424 l F .text 00000000 fpemu_dp_recip=0A= 80179474 l F .text 00000000 fpemu_dp_rsqrt=0A= 801794d0 l F .text 00000000 fpemu_sp_recip=0A= 80179510 l F .text 00000000 fpemu_sp_rsqrt=0A= 80179558 l F .text 00000000 fpemu_dp_madd=0A= 801795c4 l F .text 00000000 fpemu_dp_msub=0A= 80179630 l F .text 00000000 fpemu_dp_nmadd=0A= 801796ac l F .text 00000000 fpemu_dp_nmsub=0A= 80179728 l F .text 00000000 fpemu_sp_madd=0A= 80179780 l F .text 00000000 fpemu_sp_msub=0A= 801797d8 l F .text 00000000 fpemu_sp_nmadd=0A= 80179840 l F .text 00000000 fpemu_sp_nmsub=0A= 00000000 l df *ABS* 00000000 ieee754m.c=0A= 00000000 l df *ABS* 00000000 ieee754d.c=0A= 00000000 l df *ABS* 00000000 ieee754dp.c=0A= 8017b3a0 l F .text 00000000 get_rounding=0A= 00000000 l df *ABS* 00000000 ieee754sp.c=0A= 8017bd5c l F .text 00000000 get_rounding=0A= 00000000 l df *ABS* 00000000 ieee754.c=0A= 00000000 l df *ABS* 00000000 ieee754xcpt.c=0A= 801f1204 l O .text 00000014 rtnames=0A= 00000000 l df *ABS* 00000000 dp_frexp.c=0A= 00000000 l df *ABS* 00000000 dp_modf.c=0A= 00000000 l df *ABS* 00000000 dp_div.c=0A= 00000000 l df *ABS* 00000000 dp_mul.c=0A= 00000000 l df *ABS* 00000000 dp_sub.c=0A= 00000000 l df *ABS* 00000000 dp_add.c=0A= 00000000 l df *ABS* 00000000 dp_fsp.c=0A= 00000000 l df *ABS* 00000000 dp_cmp.c=0A= 00000000 l df *ABS* 00000000 dp_logb.c=0A= 00000000 l df *ABS* 00000000 dp_scalb.c=0A= 00000000 l df *ABS* 00000000 dp_simple.c=0A= 00000000 l df *ABS* 00000000 dp_tint.c=0A= 00000000 l df *ABS* 00000000 dp_fint.c=0A= 00000000 l df *ABS* 00000000 dp_tlong.c=0A= 00000000 l df *ABS* 00000000 dp_flong.c=0A= 00000000 l df *ABS* 00000000 sp_frexp.c=0A= 00000000 l df *ABS* 00000000 sp_modf.c=0A= 00000000 l df *ABS* 00000000 sp_div.c=0A= 00000000 l df *ABS* 00000000 sp_mul.c=0A= 00000000 l df *ABS* 00000000 sp_sub.c=0A= 00000000 l df *ABS* 00000000 sp_add.c=0A= 00000000 l df *ABS* 00000000 sp_fdp.c=0A= 00000000 l df *ABS* 00000000 sp_cmp.c=0A= 00000000 l df *ABS* 00000000 sp_logb.c=0A= 00000000 l df *ABS* 00000000 sp_scalb.c=0A= 00000000 l df *ABS* 00000000 sp_simple.c=0A= 00000000 l df *ABS* 00000000 sp_tint.c=0A= 00000000 l df *ABS* 00000000 sp_fint.c=0A= 00000000 l df *ABS* 00000000 sp_tlong.c=0A= 00000000 l df *ABS* 00000000 sp_flong.c=0A= 00000000 l df *ABS* 00000000 dp_sqrt.c=0A= 801f19a0 l O .text 00000080 table=0A= 00000000 l df *ABS* 00000000 sp_sqrt.c=0A= 00000000 l df *ABS* 00000000 kernel_linkage.c=0A= 8021c260 l O .data 00000004 first.0=0A= 00000000 l df *ABS* 00000000 mem.c=0A= 80184940 l F .text 00000000 do_write_mem=0A= 801849cc l F .text 00000000 read_mem=0A= 80184a8c l F .text 00000000 write_mem=0A= 80184af8 l F .text 00000000 mmap_mem=0A= 80184bcc l F .text 00000000 read_kmem=0A= 80184d5c l F .text 00000000 write_kmem=0A= 80184db8 l F .text 00000000 read_null=0A= 80184dc0 l F .text 00000000 write_null=0A= 80184dc8 l F .text 00000000 read_zero=0A= 80185088 l F .text 00000000 mmap_zero=0A= 801850e0 l F .text 00000000 write_full=0A= 801850e8 l F .text 00000000 null_lseek=0A= 801850fc l F .text 00000000 memory_lseek=0A= 80185160 l F .text 00000000 open_port=0A= 8021c270 l O .data 00000048 mem_fops=0A= 8021c2b8 l O .data 00000048 kmem_fops=0A= 8021c300 l O .data 00000048 null_fops=0A= 8021c348 l O .data 00000048 zero_fops=0A= 8021c390 l O .data 00000048 full_fops=0A= 80185190 l F .text 00000000 memory_open=0A= 801f1ae8 l O .text 00000070 list.0=0A= 8021c3d8 l O .data 00000048 memory_fops=0A= 8021007c l O .initcall.init 00000004 __initcall_chr_dev_init=0A= 00000000 l df *ABS* 00000000 tty_io.c=0A= 80185270 l F .text 00000000 alloc_tty_struct=0A= 801852b8 l F .text 00000000 _tty_make_name=0A= 801f1b8c l O .text 00000038 badmagic.0=0A= 801f1bc4 l O .text 00000025 badtty.1=0A= 80185360 l F .text 00000000 check_tty_count=0A= 801854e0 l F .text 00000000 tty_set_ldisc=0A= 80185860 l F .text 00000000 hung_up_tty_read=0A= 8018587c l F .text 00000000 hung_up_tty_write=0A= 80185898 l F .text 00000000 hung_up_tty_poll=0A= 801858a0 l F .text 00000000 hung_up_tty_ioctl=0A= 8021c420 l O .data 00000048 tty_fops=0A= 80185f10 l F .text 00000000 tty_read=0A= 8018602c l F .text 00000000 tty_write=0A= 80187348 l F .text 00000000 tty_poll=0A= 80186f40 l F .text 00000000 tty_open=0A= 80187328 l F .text 00000000 tty_release=0A= 80187408 l F .text 00000000 tty_fasync=0A= 8021c468 l O .data 00000048 hung_up_tty_fops=0A= 8021c4b0 l O .data 00000010 tty_sem=0A= 801862a8 l F .text 00000000 down_tty_sem=0A= 801862f4 l F .text 00000000 up_tty_sem=0A= 80186340 l F .text 00000000 init_dev=0A= 8018854c l F .text 00000000 initialize_tty_struct=0A= 8018689c l F .text 00000000 release_mem=0A= 80186998 l F .text 00000000 release_dev=0A= 80321120 l O .bss 00000004 nr_warns.2=0A= 80187554 l F .text 00000000 tiocsti=0A= 80187610 l F .text 00000000 tiocgwinsz=0A= 8018766c l F .text 00000000 tiocswinsz=0A= 80187774 l F .text 00000000 tioccons=0A= 80187800 l F .text 00000000 fionbio=0A= 80187858 l F .text 00000000 tiocsctty=0A= 80187930 l F .text 00000000 tiocgpgrp=0A= 80187978 l F .text 00000000 tiocspgrp=0A= 80187a40 l F .text 00000000 tiocgsid=0A= 80187a94 l F .text 00000000 tiocttygstruct=0A= 80187aec l F .text 00000000 tiocsetd=0A= 80187b3c l F .text 00000000 send_break=0A= 801880f0 l F .text 00000000 __do_SAK=0A= 80188250 l F .text 00000000 flush_to_ldisc=0A= 8021c4c0 l O .data 0000007c baud_table=0A= 8021c53c l O .data 00000004 n_baud_table=0A= 80321554 l O .bss 000000c0 dev_tty_driver=0A= 80321614 l O .bss 000000c0 dev_syscons_driver=0A= 803216d4 l O .bss 000000c0 dev_ptmx_driver=0A= 00000000 l df *ABS* 00000000 n_tty.c=0A= 801889b0 l F .text 00000000 check_unthrottle=0A= 80188a08 l F .text 00000000 reset_buffer_flags=0A= 80188b84 l F .text 00000000 opost=0A= 80188d70 l F .text 00000000 opost_block=0A= 80188f7c l F .text 00000000 echo_char=0A= 80189018 l F .text 00000000 eraser=0A= 80189504 l F .text 00000000 n_tty_receive_room=0A= 80189540 l F .text 00000000 n_tty_receive_buf=0A= 8018a510 l F .text 00000000 n_tty_set_termios=0A= 8018a9a0 l F .text 00000000 n_tty_close=0A= 8018a9e0 l F .text 00000000 n_tty_open=0A= 8018aa94 l F .text 00000000 read_chan=0A= 8018b434 l F .text 00000000 write_chan=0A= 8018b678 l F .text 00000000 normal_poll=0A= 00000000 l df *ABS* 00000000 tty_ioctl.c=0A= 8018b8cc l F .text 00000000 unset_locked_termios=0A= 8018b9dc l F .text 00000000 change_termios=0A= 8018bc30 l F .text 00000000 set_termios=0A= 8018be84 l F .text 00000000 get_termio=0A= 8018bf5c l F .text 00000000 inq_canon=0A= 8018bfe0 l F .text 00000000 get_sgflags=0A= 8018c03c l F .text 00000000 get_sgttyb=0A= 8018c0c4 l F .text 00000000 set_sgflags=0A= 8018c160 l F .text 00000000 set_sgttyb=0A= 8018c24c l F .text 00000000 get_ltchars=0A= 8018c2d4 l F .text 00000000 set_ltchars=0A= 00000000 l df *ABS* 00000000 raw.c=0A= 8021c580 l O .data 00000048 raw_fops=0A= 8021c5c8 l O .data 00000048 raw_ctl_fops=0A= 802096dc l F .text.init 00000000 raw_init=0A= 803217a0 l O .bss 00002000 raw_devices=0A= 80210080 l O .initcall.init 00000004 __initcall_raw_init=0A= 8018d014 l F .text 00000000 rw_raw_dev=0A= 00000000 l df *ABS* 00000000 pty.c=0A= 8018d3c0 l F .text 00000000 pty_close=0A= 8018d51c l F .text 00000000 pty_unthrottle=0A= 8018d598 l F .text 00000000 pty_write=0A= 8018d790 l F .text 00000000 pty_write_room=0A= 8018d7d4 l F .text 00000000 pty_chars_in_buffer=0A= 8018d838 l F .text 00000000 pty_get_device_number=0A= 8018d878 l F .text 00000000 pty_set_lock=0A= 8018d8f8 l F .text 00000000 pty_bsd_ioctl=0A= 8018d944 l F .text 00000000 pty_unix98_ioctl=0A= 8018d9a4 l F .text 00000000 pty_flush_buffer=0A= 8018da14 l F .text 00000000 pty_open=0A= 8018db28 l F .text 00000000 pty_set_termios=0A= 80325124 l O .bss 00000c00 pty_state=0A= 803237a0 l O .bss 000000c0 pty_driver=0A= 80323920 l O .bss 00000004 pty_refcount=0A= 80323924 l O .bss 00000400 pty_table=0A= 80323d24 l O .bss 00000400 pty_termios=0A= 80324124 l O .bss 00000400 pty_termios_locked=0A= 80323860 l O .bss 000000c0 pty_slave_driver=0A= 80324524 l O .bss 00000400 ttyp_table=0A= 80324924 l O .bss 00000400 ttyp_termios=0A= 80324d24 l O .bss 00000400 ttyp_termios_locked=0A= 803276a4 l O .bss 00000c00 ptm_state=0A= 803272a4 l O .bss 00000400 pts_termios_locked=0A= 80326ea4 l O .bss 00000400 pts_termios=0A= 80326aa4 l O .bss 00000400 pts_table=0A= 803266a4 l O .bss 00000400 ptm_termios_locked=0A= 803262a4 l O .bss 00000400 ptm_termios=0A= 80325ea4 l O .bss 00000400 ptm_table=0A= 00000000 l df *ABS* 00000000 misc.c=0A= 8021c610 l O .data 00000018 misc_list=0A= 8021c628 l O .data 00000010 misc_sem=0A= 8018db50 l F .text 00000000 misc_read_proc=0A= 8018dc6c l F .text 00000000 misc_open=0A= 8021c638 l O .data 00000048 misc_fops=0A= 803282b0 l O .bss 00000004 devfs_handle.0=0A= 803282b4 l O .bss 00000008 misc_minors=0A= 00000000 l df *ABS* 00000000 random.c=0A= 8021c680 l O .data 00000004 random_read_wakeup_thresh=0A= 8021c684 l O .data 00000004 random_write_wakeup_thresh=0A= 8021c688 l O .data 000000c0 poolinfo_table=0A= 8021c748 l O .data 00000008 random_read_wait=0A= 8021c750 l O .data 00000008 random_write_wait=0A= 8018e280 l F .text 00000000 create_entropy_store=0A= 8018e3b4 l F .text 00000000 clear_entropy_store=0A= 8018e3f0 l F .text 00000000 free_entropy_store=0A= 801f23b0 l O .text 00000020 twist_table.0=0A= 8018e42c l F .text 00000000 add_entropy_words=0A= 8018e574 l F .text 00000000 credit_entropy_store=0A= 80209e78 l F .text.init 00000000 batch_entropy_init=0A= 80328338 l O .bss 00000004 batch_entropy_pool=0A= 8032834c l O .bss 00000014 batch_tqueue=0A= 8032833c l O .bss 00000004 batch_entropy_credit=0A= 8018e6ec l F .text 00000000 batch_entropy_process=0A= 80328340 l O .bss 00000004 batch_max=0A= 80328348 l O .bss 00000004 batch_tail=0A= 80328344 l O .bss 00000004 batch_head=0A= 80328334 l O .bss 00000004 sec_random_state=0A= 80328330 l O .bss 00000004 random_state=0A= 8018e828 l F .text 00000000 add_timer_randomness=0A= 803282c0 l O .bss 00000001 last_scancode.1=0A= 80328360 l O .bss 00000010 keyboard_timer_state=0A= 80328370 l O .bss 00000010 mouse_timer_state=0A= 80328390 l O .bss 00000100 irq_timer_state=0A= 80328490 l O .bss 000003fc blkdev_timer_state=0A= 8018ea38 l F .text 00000000 SHATransform=0A= 8018ebd0 l F .text 00000000 extract_entropy=0A= 80328380 l O .bss 00000010 extract_timer_state=0A= 8018eff4 l F .text 00000000 init_std_data=0A= 8018fce4 l F .text 00000000 sysctl_init_random=0A= 8018f18c l F .text 00000000 random_read=0A= 8018f2ec l F .text 00000000 urandom_read=0A= 8018f310 l F .text 00000000 random_poll=0A= 8018f3b0 l F .text 00000000 random_write=0A= 8018f4c4 l F .text 00000000 random_ioctl=0A= 8018f8f4 l F .text 00000000 change_poolsize=0A= 8018f974 l F .text 00000000 proc_do_poolsize=0A= 8032888c l O .bss 00000004 sysctl_poolsize=0A= 8018f9f8 l F .text 00000000 poolsize_strategy=0A= 8018faa4 l F .text 00000000 proc_do_uuid=0A= 8018fbd0 l F .text 00000000 uuid_strategy=0A= 80328890 l O .bss 00000004 min_read_thresh=0A= 80328894 l O .bss 00000004 max_read_thresh=0A= 80328898 l O .bss 00000004 min_write_thresh=0A= 8032889c l O .bss 00000004 max_write_thresh=0A= 803288a0 l O .bss 00000010 sysctl_bootid=0A= 8018fd20 l F .text 00000000 halfMD4Transform=0A= 803282c4 l O .bss 00000004 rekey_time.2=0A= 803282c8 l O .bss 00000004 count.3=0A= 803282cc l O .bss 00000030 secret.4=0A= 803282fc l O .bss 00000004 rekey_time.5=0A= 80328300 l O .bss 00000030 secret.6=0A= 00000000 l df *ABS* 00000000 serial.c=0A= 8021c920 l O .data 00000004 serial_version=0A= 8021c924 l O .data 00000004 serial_revdate=0A= 8021c928 l O .data 00000004 serial_name=0A= 8021c92c l O .data 00000008 tq_serial=0A= 8021c934 l O .data 000000b4 uart_config=0A= 8021c9e8 l O .data 00000188 rs_table=0A= 8021cb70 l O .data 00000010 tmp_buf_sem=0A= 801902a0 l F .text 00000000 serial_in=0A= 801902ec l F .text 00000000 serial_out=0A= 801903e4 l F .text 00000000 rs_stop=0A= 801904b0 l F .text 00000000 rs_start=0A= 8019059c l F .text 00000000 rs_sched_event=0A= 80190684 l F .text 00000000 receive_chars=0A= 8021cb84 l O .data 0000002c sercons=0A= 80328c54 l O .bss 00000004 lsr_break_flag=0A= 801908f4 l F .text 00000000 transmit_chars=0A= 80190a44 l F .text 00000000 check_modem_status=0A= 80190be4 l F .text 00000000 rs_interrupt_single=0A= 80328a54 l O .bss 00000100 IRQ_ports=0A= 80190cc0 l F .text 00000000 do_serial_bh=0A= 80190cf4 l F .text 00000000 do_softint=0A= 803288b0 l O .bss 00000004 last_strobe.0=0A= 80190d74 l F .text 00000000 rs_timer=0A= 80328a40 l O .bss 00000014 serial_timer=0A= 80328b54 l O .bss 00000100 IRQ_timeout=0A= 80190eec l F .text 00000000 figure_IRQ_timeout=0A= 80190f70 l F .text 00000000 enable_rsa=0A= 80191020 l F .text 00000000 disable_rsa=0A= 801910e4 l F .text 00000000 startup=0A= 80191b28 l F .text 00000000 change_speed=0A= 801917b8 l F .text 00000000 shutdown=0A= 8019221c l F .text 00000000 rs_put_char=0A= 801922e8 l F .text 00000000 rs_flush_chars=0A= 80192398 l F .text 00000000 rs_write=0A= 80328c70 l O .bss 00000004 tmp_buf=0A= 801926d8 l F .text 00000000 rs_write_room=0A= 801926f4 l F .text 00000000 rs_chars_in_buffer=0A= 8019270c l F .text 00000000 rs_flush_buffer=0A= 801927b4 l F .text 00000000 rs_send_xchar=0A= 801927fc l F .text 00000000 rs_throttle=0A= 801928b4 l F .text 00000000 rs_unthrottle=0A= 80192984 l F .text 00000000 get_serial_info=0A= 80192a80 l F .text 00000000 set_serial_info=0A= 80193004 l F .text 00000000 get_lsr_info=0A= 80193118 l F .text 00000000 get_modem_info=0A= 8019323c l F .text 00000000 set_modem_info=0A= 80193484 l F .text 00000000 do_autoconfig=0A= 80195414 l F .text 00000000 autoconfig=0A= 80194e84 l F .text 00000000 detect_uart_irq=0A= 80193558 l F .text 00000000 rs_break=0A= 8019360c l F .text 00000000 rs_ioctl=0A= 80193b5c l F .text 00000000 rs_set_termios=0A= 80193d40 l F .text 00000000 rs_close=0A= 8019406c l F .text 00000000 rs_wait_until_sent=0A= 80194188 l F .text 00000000 rs_hangup=0A= 80194210 l F .text 00000000 block_til_ready=0A= 801945e8 l F .text 00000000 get_async_struct=0A= 80194740 l F .text 00000000 rs_open=0A= 8020fce8 l O .data.init 0000001c serial_options=0A= 80194e34 l F .text 00000000 show_serial_version=0A= 80195040 l F .text 00000000 size_fifo=0A= 8019520c l F .text 00000000 autoconfig_startech_uarts=0A= 8020a048 l F .text.init 00000000 rs_init=0A= 803288bc l O .bss 000000c0 serial_driver=0A= 80328a3c l O .bss 00000004 serial_refcount=0A= 80328c58 l O .bss 00000008 serial_table=0A= 80328c60 l O .bss 00000008 serial_termios=0A= 80328c68 l O .bss 00000008 serial_termios_locked=0A= 8032897c l O .bss 000000c0 callout_driver=0A= 80210084 l O .initcall.init 00000004 __initcall_rs_init=0A= 8021cb80 l O .data 00000004 info.1=0A= 80328c74 l O .bss 000000ac async_sercons=0A= 80195e04 l F .text 00000000 serial_console_write=0A= 803288b4 l O .bss 00000004 info.2=0A= 8019609c l F .text 00000000 serial_console_wait_key=0A= 8019613c l F .text 00000000 serial_console_device=0A= 803288b8 l O .bss 00000004 info.3=0A= 8020a7b0 l F .text.init 00000000 serial_console_setup=0A= 00000000 l df *ABS* 00000000 ll_rw_blk.c=0A= 80196150 l F .text 00000000 __blk_cleanup_queue=0A= 8033208c l O .bss 00000004 request_cachep=0A= 80332090 l O .bss 00000004 queue_nr_requests=0A= 8019625c l F .text 00000000 ll_back_merge_fn=0A= 801962a8 l F .text 00000000 ll_front_merge_fn=0A= 801962f4 l F .text 00000000 ll_merge_requests_fn=0A= 80196344 l F .text 00000000 generic_plug_device=0A= 80196484 l F .text 00000000 blk_init_free_list=0A= 801969c8 l F .text 00000000 __make_request=0A= 80196650 l F .text 00000000 __get_request_wait=0A= 80332094 l O .bss 00000004 batch_requests=0A= 80332098 l O .bss 00001fe0 ro_bits=0A= 8019685c l F .text 00000000 attempt_merge=0A= 00000000 l df *ABS* 00000000 blkpg.c=0A= 00000000 l df *ABS* 00000000 genhd.c=0A= 80210088 l O .initcall.init 00000004 __initcall_device_init=0A= 80334084 l O .bss 00000000 gendisk_lock=0A= 00000000 l df *ABS* 00000000 elevator.c=0A= 80334090 l O .bss 00000004 queue_ID.0=0A= 00000000 l df *ABS* 00000000 rd.c=0A= 00000000 l df *ABS* 00000000 rd.c=0A= 8020ac74 l F .text.init 00000000 no_initrd=0A= 8020fd04 l O .data.init 00000009 __setup_str_no_initrd=0A= 8020ffd8 l O .setup.init 00000008 __setup_no_initrd=0A= 8020ac84 l F .text.init 00000000 ramdisk_start_setup=0A= 8020acb0 l F .text.init 00000000 load_ramdisk=0A= 8020ace0 l F .text.init 00000000 prompt_ramdisk=0A= 8020ad10 l F .text.init 00000000 ramdisk_size=0A= 8020ad3c l F .text.init 00000000 ramdisk_size2=0A= 8020ad58 l F .text.init 00000000 ramdisk_blocksize=0A= 8020fd10 l O .data.init 0000000f __setup_str_ramdisk_start_setup=0A= 8020ffe0 l O .setup.init 00000008 __setup_ramdisk_start_setup=0A= 8020fd20 l O .data.init 0000000e __setup_str_load_ramdisk=0A= 8020ffe8 l O .setup.init 00000008 __setup_load_ramdisk=0A= 8020fd30 l O .data.init 00000010 __setup_str_prompt_ramdisk=0A= 8020fff0 l O .setup.init 00000008 __setup_prompt_ramdisk=0A= 8020fd40 l O .data.init 00000009 __setup_str_ramdisk_size=0A= 8020fff8 l O .setup.init 00000008 __setup_ramdisk_size=0A= 8020fd4c l O .data.init 0000000e __setup_str_ramdisk_size2=0A= 80210000 l O .setup.init 00000008 __setup_ramdisk_size2=0A= 8020fd5c l O .data.init 00000013 __setup_str_ramdisk_blocksize=0A= 80210008 l O .setup.init 00000008 __setup_ramdisk_blocksize=0A= 80198a70 l F .text 00000000 ramdisk_readpage=0A= 80198ad8 l F .text 00000000 ramdisk_prepare_write=0A= 80198b4c l F .text 00000000 ramdisk_commit_write=0A= 8021cbd0 l O .data 00000024 ramdisk_aops=0A= 80198b54 l F .text 00000000 rd_blkdev_pagecache_IO=0A= 803341bc l O .bss 00000040 rd_bdev=0A= 80198d30 l F .text 00000000 rd_make_request=0A= 803340b8 l O .bss 00000040 rd_length=0A= 80198df0 l F .text 00000000 rd_ioctl=0A= 80334178 l O .bss 00000040 rd_kbsize=0A= 80199008 l F .text 00000000 initrd_read=0A= 801990b0 l F .text 00000000 initrd_release=0A= 803340b4 l O .bss 00000004 initrd_users=0A= 8021cbf4 l O .data 00000048 initrd_fops=0A= 8019911c l F .text 00000000 rd_open=0A= 8021cc3c l O .data 00000018 rd_bd_op=0A= 803340f8 l O .bss 00000040 rd_hardsec=0A= 80334138 l O .bss 00000040 rd_blocksizes=0A= 803341b8 l O .bss 00000004 devfs_handle=0A= 8020af40 l F .text.init 00000000 identify_ramdisk_image=0A= 8020b1cc l F .text.init 00000000 rd_load_image=0A= 8020b99c l F .text.init 00000000 crd_load=0A= 8020b6e4 l F .text.init 00000000 rd_load_disk=0A= 801f3398 l O .text 0000004c border=0A= 801f33e4 l O .text 0000003e cplens=0A= 801f3424 l O .text 0000003e cplext=0A= 801f3464 l O .text 0000003c cpdist=0A= 801f34a0 l O .text 0000003c cpdext=0A= 801f34dc l O .text 00000022 mask_bits=0A= 801f3500 l O .text 00000004 lbits=0A= 801f3504 l O .text 00000004 dbits=0A= 801991dc l F .text 00000000 huft_build=0A= 8020b7e0 l F .text.init 00000000 malloc=0A= 80334228 l O .bss 00000004 hufts=0A= 801997b4 l F .text 00000000 huft_free=0A= 8020b7fc l F .text.init 00000000 free=0A= 801997f0 l F .text 00000000 inflate_codes=0A= 80334220 l O .bss 00000004 bb=0A= 80334224 l O .bss 00000004 bk=0A= 8033420c l O .bss 00000004 outcnt=0A= 80334208 l O .bss 00000004 inptr=0A= 80334204 l O .bss 00000004 insize=0A= 803341fc l O .bss 00000004 inbuf=0A= 80334200 l O .bss 00000004 window=0A= 8020b8a0 l F .text.init 00000000 flush_window=0A= 8020b828 l F .text.init 00000000 fill_inbuf=0A= 80199dac l F .text 00000000 inflate_stored=0A= 8019a020 l F .text 00000000 inflate_fixed=0A= 8019a1cc l F .text 00000000 inflate_dynamic=0A= 8020b968 l F .text.init 00000000 error=0A= 8019a9d8 l F .text 00000000 inflate_block=0A= 8019ab84 l F .text 00000000 inflate=0A= 8020b818 l F .text.init 00000000 gzip_mark=0A= 8020b820 l F .text.init 00000000 gzip_release=0A= 801f3540 l O .text 00000038 p.0=0A= 8019ac6c l F .text 00000000 makecrc=0A= 8033422c l O .bss 00000400 crc_32_tab=0A= 8033462c l O .bss 00000004 crc=0A= 8019ad18 l F .text 00000000 gunzip=0A= 80334214 l O .bss 00000004 bytes_out=0A= 80334210 l O .bss 00000004 exit_code=0A= 80334218 l O .bss 00000004 crd_infp=0A= 8033421c l O .bss 00000004 crd_outfp=0A= 00000000 l df *ABS* 00000000 loop.c=0A= 8021cc60 l O .data 00000004 max_loop=0A= 8019b5b0 l F .text 00000000 transfer_none=0A= 8019b604 l F .text 00000000 transfer_xor=0A= 8019b670 l F .text 00000000 none_status=0A= 8019b684 l F .text 00000000 xor_status=0A= 8019b69c l F .text 00000000 compute_loop_size=0A= 8019b72c l F .text 00000000 figure_loop_size=0A= 80334634 l O .bss 00000004 loop_sizes=0A= 8019b774 l F .text 00000000 lo_send=0A= 8019ba38 l F .text 00000000 lo_read_actor=0A= 8019bb5c l F .text 00000000 lo_receive=0A= 8019bbe8 l F .text 00000000 do_bh_filebacked=0A= 8019bcd0 l F .text 00000000 loop_put_buffer=0A= 8019be2c l F .text 00000000 loop_end_io_transfer=0A= 8019bd28 l F .text 00000000 loop_add_bh=0A= 8019bdcc l F .text 00000000 loop_get_bh=0A= 80334630 l O .bss 00000004 loop_dev=0A= 8019bf00 l F .text 00000000 loop_get_buffer=0A= 8019c090 l F .text 00000000 loop_make_request=0A= 8019c3c8 l F .text 00000000 loop_thread=0A= 8019c6e0 l F .text 00000000 loop_set_fd=0A= 8019c920 l F .text 00000000 loop_release_xfer=0A= 8019c9a8 l F .text 00000000 loop_init_xfer=0A= 8019ca40 l F .text 00000000 loop_clr_fd=0A= 8019cbf4 l F .text 00000000 loop_set_status=0A= 8019cdb4 l F .text 00000000 loop_get_status=0A= 8019cf0c l F .text 00000000 lo_ioctl=0A= 8019d1dc l F .text 00000000 lo_open=0A= 8019d308 l F .text 00000000 lo_release=0A= 8021ccec l O .data 00000018 lo_fops=0A= 8033463c l O .bss 00000004 devfs_handle=0A= 80334638 l O .bss 00000004 loop_blksizes=0A= 8021008c l O .initcall.init 00000004 __initcall_loop_init=0A= 8020bd38 l F .text.init 00000000 max_loop_setup=0A= 8020fd70 l O .data.init 0000000a __setup_str_max_loop_setup=0A= 80210010 l O .setup.init 00000008 __setup_max_loop_setup=0A= 00000000 l df *ABS* 00000000 Space.c=0A= 8020bd64 l F .text.init 00000000 probe_list=0A= 8020fd7c l O .data.init 00000008 eisa_probes=0A= 8020fd84 l O .data.init 00000008 mca_probes=0A= 8020fd8c l O .data.init 00000008 isa_probes=0A= 8020fd94 l O .data.init 00000008 parport_probes=0A= 8020fd9c l O .data.init 00000008 m68k_probes=0A= 8020fda4 l O .data.init 00000008 sgi_probes=0A= 8020fdac l O .data.init 00000008 mips_probes=0A= 8020be00 l F .text.init 00000000 ethif_probe=0A= 8021cd10 l O .data 00000130 eth7_dev=0A= 8021ce40 l O .data 00000130 eth6_dev=0A= 8021cf70 l O .data 00000130 eth5_dev=0A= 8021d0a0 l O .data 00000130 eth4_dev=0A= 8021d1d0 l O .data 00000130 eth3_dev=0A= 8021d300 l O .data 00000130 eth2_dev=0A= 8021d430 l O .data 00000130 eth1_dev=0A= 8021d560 l O .data 00000130 eth0_dev=0A= 00000000 l df *ABS* 00000000 setup.c=0A= 8020fdb4 l O .data.init 00000008 pci_probes=0A= 8020bf04 l F .text.init 00000000 network_probe=0A= 8020bf4c l F .text.init 00000000 network_ldisc_init=0A= 8020bf54 l F .text.init 00000000 special_device_init=0A= 00000000 l df *ABS* 00000000 net_init.c=0A= 8019d5b0 l F .text 00000000 alloc_netdev=0A= 8019d674 l F .text 00000000 init_alloc_dev=0A= 8019d6fc l F .text 00000000 init_netdev=0A= 8019d864 l F .text 00000000 eth_mac_addr=0A= 8019d8a8 l F .text 00000000 eth_change_mtu=0A= 00000000 l df *ABS* 00000000 loopback.c=0A= 8019da60 l F .text 00000000 loopback_xmit=0A= 8019dbc8 l F .text 00000000 get_stats=0A= 00000000 l df *ABS* 00000000 auto_irq.c=0A= 80334640 l O .bss 00000004 irqs=0A= 00000000 l df *ABS* 00000000 socket.c=0A= 8021d7d0 l O .data 00000048 socket_file_ops=0A= 8019e42c l F .text 00000000 sock_lseek=0A= 8019e438 l F .text 00000000 sock_read=0A= 8019e4b8 l F .text 00000000 sock_write=0A= 8019e748 l F .text 00000000 sock_poll=0A= 8019e71c l F .text 00000000 sock_ioctl=0A= 8019e780 l F .text 00000000 sock_mmap=0A= 8019e1b4 l F .text 00000000 sock_no_open=0A= 8019e7b8 l F .text 00000000 sock_close=0A= 8019e80c l F .text 00000000 sock_fasync=0A= 8019e664 l F .text 00000000 sock_readv=0A= 8019e6c0 l F .text 00000000 sock_writev=0A= 8019e55c l F .text 00000000 sock_sendpage=0A= 80211960 l O .data.cacheline_aligned 00000020 sockets_in_use=0A= 8019dd54 l F .text 00000000 sockfs_statfs=0A= 8021d818 l O .data 00000040 sockfs_ops=0A= 8019dd78 l F .text 00000000 sockfs_read_super=0A= 8021d858 l O .data 0000001c sock_fs_type=0A= 8019de58 l F .text 00000000 sockfs_delete_dentry=0A= 8021d874 l O .data 00000018 sockfs_dentry_operations=0A= 8019de60 l F .text 00000000 sock_map_fd=0A= 803346e4 l O .bss 00000004 sock_mnt=0A= 80334660 l O .bss 00000004 warned.0=0A= 80334664 l O .bss 00000080 net_families=0A= 8021d88c l O .data 00000012 nargs=0A= 00000000 l df *ABS* 00000000 sock.c=0A= 8019fd90 l F .text 00000000 sock_set_timeout=0A= 80334700 l O .bss 00000004 sk_cachep=0A= 801a0c78 l F .text 00000000 sock_wait_for_wmem=0A= 801a11b0 l F .text 00000000 sklist_destroy_timer=0A= 00000000 l df *ABS* 00000000 skbuff.c=0A= 8021d8c4 l O .data 00000004 count.0=0A= 80334714 l O .bss 00000020 skb_head_pool=0A= 80334710 l O .bss 00000004 skbuff_head_cache=0A= 801a1b08 l F .text 00000000 skb_drop_fraglist=0A= 801a1b80 l F .text 00000000 skb_clone_fraglist=0A= 801a1bbc l F .text 00000000 skb_release_data=0A= 801a206c l F .text 00000000 copy_skb_header=0A= 801a37f8 l F .text 00000000 skb_headerinit=0A= 00000000 l df *ABS* 00000000 iovec.c=0A= 00000000 l df *ABS* 00000000 datagram.c=0A= 801a3ed0 l F .text 00000000 wait_for_packet=0A= 00000000 l df *ABS* 00000000 scm.c=0A= 801a4a70 l F .text 00000000 scm_fp_copy=0A= 00000000 l df *ABS* 00000000 sysctl_net_core.c=0A= 00000000 l df *ABS* 00000000 dev.c=0A= 8021db5c l O .data 00000004 ptype_all=0A= 8021db60 l O .data 00000004 netdev_chain=0A= 803347a0 l O .bss 00000040 ptype_base=0A= 803347e0 l O .bss 00000100 dev_boot_setup=0A= 8020fdbc l O .data.init 00000008 __setup_str_netdev_boot_setup=0A= 80210018 l O .setup.init 00000008 __setup_netdev_boot_setup=0A= 801a5a78 l F .text 00000000 default_rebuild_header=0A= 801a62b4 l F .text 00000000 get_sample_stats=0A= 8021db7c l O .data 00000000 net_bh_lock.0=0A= 801a652c l F .text 00000000 deliver_to_old_ones=0A= 801a663c l F .text 00000000 net_tx_action=0A= 801a67f0 l F .text 00000000 net_rx_action=0A= 803348e0 l O .bss 00000080 gifconf_list=0A= 801a6c14 l F .text 00000000 dev_ifname=0A= 801a6ce4 l F .text 00000000 dev_ifconf=0A= 801a6e28 l F .text 00000000 sprintf_stats=0A= 801a6f58 l F .text 00000000 dev_get_info=0A= 801a7040 l F .text 00000000 dev_proc_stats=0A= 801a74d8 l F .text 00000000 dev_ifsioc=0A= 80334740 l O .bss 00000004 ifindex.1=0A= 8021db7c l O .data 00000004 dev_boot_phase=0A= 00000000 l df *ABS* 00000000 dev_mcast.c=0A= 801a8250 l F .text 00000000 __dev_mc_upload=0A= 801a8710 l F .text 00000000 dev_mc_read_proc=0A= 00000000 l df *ABS* 00000000 dst.c=0A= 8021db80 l O .data 00000004 dst_total=0A= 8021db84 l O .data 00000000 dst_lock=0A= 8021db84 l O .data 00000004 dst_gc_timer_inc=0A= 8021db88 l O .data 00000014 dst_gc_timer=0A= 801a8920 l F .text 00000000 dst_run_gc=0A= 80334960 l O .bss 00000004 dst_garbage_list=0A= 80334964 l O .bss 00000004 dst_gc_timer_expires=0A= 801a8a0c l F .text 00000000 dst_discard=0A= 801a8a64 l F .text 00000000 dst_blackhole=0A= 801a8dec l F .text 00000000 dst_dev_event=0A= 00000000 l df *ABS* 00000000 neighbour.c=0A= 8021dbb0 l O .data 00000000 neigh_tbl_lock=0A= 801a8fe0 l F .text 00000000 neigh_blackhole=0A= 801a9074 l F .text 00000000 neigh_forced_gc=0A= 801a91ec l F .text 00000000 neigh_del_timer=0A= 801a9264 l F .text 00000000 pneigh_queue_purge=0A= 801a9df8 l F .text 00000000 pneigh_ifdown=0A= 801a95e0 l F .text 00000000 neigh_alloc=0A= 801aa418 l F .text 00000000 neigh_timer_handler=0A= 80334970 l O .bss 00000004 neigh_glbl_allocs=0A= 801aa148 l F .text 00000000 neigh_suspect=0A= 801aa17c l F .text 00000000 neigh_connect=0A= 801aa1b0 l F .text 00000000 neigh_sync=0A= 801aa264 l F .text 00000000 neigh_periodic_timer=0A= 801aaf00 l F .text 00000000 neigh_hh_init=0A= 801ab550 l F .text 00000000 neigh_proxy_process=0A= 80334974 l O .bss 00000004 neigh_tables=0A= 00000000 l df *ABS* 00000000 rtnetlink.c=0A= 00000000 l df *ABS* 00000000 utils.c=0A= 8021e010 l O .data 00000004 net_rand_seed=0A= 8021e01c l O .data 00000000 ratelimit_lock.0=0A= 8021e01c l O .data 00000004 toks.1=0A= 80334980 l O .bss 00000004 last_msg.2=0A= 80334984 l O .bss 00000004 missed.3=0A= 00000000 l df *ABS* 00000000 eth.c=0A= 8020fdc4 l O .data.init 00000007 __setup_str_netdev_boot_setup=0A= 80210020 l O .setup.init 00000008 __setup_netdev_boot_setup=0A= 00000000 l df *ABS* 00000000 sysctl_net_ether.c=0A= 00000000 l df *ABS* 00000000 p8023.c=0A= 801ac4d0 l F .text 00000000 p8023_datalink_header=0A= 00000000 l df *ABS* 00000000 sysctl_net_802.c=0A= 00000000 l df *ABS* 00000000 sch_generic.c=0A= 801ac6d8 l F .text 00000000 dev_watchdog=0A= 801ac7f8 l F .text 00000000 dev_watchdog_init=0A= 801ac888 l F .text 00000000 dev_watchdog_up=0A= 801ac8e8 l F .text 00000000 dev_watchdog_down=0A= 801ac974 l F .text 00000000 noop_enqueue=0A= 801ac9cc l F .text 00000000 noop_dequeue=0A= 801ac9d4 l F .text 00000000 noop_requeue=0A= 801f4d04 l O .text 00000010 prio2band=0A= 801aca4c l F .text 00000000 pfifo_fast_enqueue=0A= 801acb28 l F .text 00000000 pfifo_fast_dequeue=0A= 801acb98 l F .text 00000000 pfifo_fast_requeue=0A= 801acbf8 l F .text 00000000 pfifo_fast_reset=0A= 801acd04 l F .text 00000000 pfifo_fast_init=0A= 8021e1c0 l O .data 00000040 pfifo_fast_ops=0A= 00000000 l df *ABS* 00000000 utils.c=0A= 803349a0 l O .bss 00000012 buff.0=0A= 00000000 l df *ABS* 00000000 route.c=0A= 801adaa0 l F .text 00000000 rt_garbage_collect=0A= 801af2f4 l F .text 00000000 ipv4_dst_check=0A= 801af31c l F .text 00000000 ipv4_dst_reroute=0A= 801af324 l F .text 00000000 ipv4_dst_destroy=0A= 801aec80 l F .text 00000000 ipv4_negative_advice=0A= 801af3e8 l F .text 00000000 ipv4_link_failure=0A= 801ad2b0 l F .text 00000000 rt_cache_get_info=0A= 80334a08 l O .bss 00000004 rt_hash_mask=0A= 80334a04 l O .bss 00000004 rt_hash_table=0A= 801ad538 l F .text 00000000 rt_cache_stat_get_info=0A= 803349c0 l O .bss 00000004 rover.0=0A= 801ad610 l F .text 00000000 rt_check_expire=0A= 80334a0c l O .bss 00000004 rt_hash_log=0A= 803349f0 l O .bss 00000014 rt_periodic_timer=0A= 801ad818 l F .text 00000000 rt_run_flush=0A= 803349d8 l O .bss 00000004 rt_deadline=0A= 8021e274 l O .data 00000000 rt_flush_lock=0A= 803349dc l O .bss 00000014 rt_flush_timer=0A= 8021e274 l O .data 00000004 expire.1=0A= 803349c4 l O .bss 00000004 last_gc.2=0A= 803349c8 l O .bss 00000004 rover.3=0A= 803349cc l O .bss 00000004 equilibrium.4=0A= 801adf18 l F .text 00000000 rt_intern_hash=0A= 8021e278 l O .data 00000000 rt_peer_lock.5=0A= 8021e278 l O .data 00000000 ip_fb_id_lock.6=0A= 803349d0 l O .bss 00000004 ip_fallback_id.7=0A= 801ae3ec l F .text 00000000 ip_select_fb_ident=0A= 801ae580 l F .text 00000000 rt_del=0A= 801aeea4 l F .text 00000000 ip_error=0A= 8021e278 l O .data 00000014 mtu_plateau=0A= 801af44c l F .text 00000000 ip_rt_bug=0A= 801af630 l F .text 00000000 rt_set_nexthop=0A= 801af748 l F .text 00000000 ip_route_input_mc=0A= 801b0d74 l F .text 00000000 ipv4_sysctl_rtcache_flush=0A= 80334a38 l O .bss 00000004 flush_delay=0A= 801b0db4 l F .text 00000000 ipv4_sysctl_rtcache_flush_strategy=0A= 00000000 l df *ABS* 00000000 inetpeer.c=0A= 8021e5b0 l O .data 00000028 peer_fake_node=0A= 8021e5d8 l O .data 00000004 peer_root=0A= 8021e5dc l O .data 00000000 peer_pool_lock=0A= 8021e5ec l O .data 00000014 peer_periodic_timer=0A= 801b16fc l F .text 00000000 peer_check_expire=0A= 80334a44 l O .bss 00000004 peer_cachep=0A= 801b0e20 l F .text 00000000 unlink_from_unused=0A= 801b0eb4 l F .text 00000000 peer_avl_rebalance=0A= 801b1008 l F .text 00000000 unlink_from_pool=0A= 80334a48 l O .bss 00000004 peer_total=0A= 801b12ec l F .text 00000000 cleanup_once=0A= 00000000 l df *ABS* 00000000 proc.c=0A= 801b1870 l F .text 00000000 fold_prot_inuse=0A= 801b19c0 l F .text 00000000 fold_field=0A= 00000000 l df *ABS* 00000000 protocol.c=0A= 8021e610 l O .data 00000018 tcp_protocol=0A= 8021e628 l O .data 00000018 udp_protocol=0A= 8021e640 l O .data 00000018 icmp_protocol=0A= 00000000 l df *ABS* 00000000 ip_input.c=0A= 801b1ff4 l F .text 00000000 ip_run_ipprot=0A= 00000000 l df *ABS* 00000000 ip_fragment.c=0A= 8021e66c l O .data 00000000 ipfrag_lock=0A= 801b2810 l F .text 00000000 ip_frag_destroy=0A= 801b292c l F .text 00000000 ip_evictor=0A= 80334ba0 l O .bss 00000100 ipq_hash=0A= 801b2ac8 l F .text 00000000 ip_expire=0A= 801b2c58 l F .text 00000000 ip_frag_intern=0A= 801b2d20 l F .text 00000000 ip_frag_create=0A= 801b2e10 l F .text 00000000 ip_frag_queue=0A= 801b32bc l F .text 00000000 ip_frag_reasm=0A= 00000000 l df *ABS* 00000000 ip_forward.c=0A= 00000000 l df *ABS* 00000000 ip_options.c=0A= 00000000 l df *ABS* 00000000 ip_output.c=0A= 801b4e90 l F .text 00000000 ip_dev_loopback_xmit=0A= 801b5d08 l F .text 00000000 ip_build_xmit_slow=0A= 801b6cf0 l F .text 00000000 ip_reply_glue_bits=0A= 8021e688 l O .data 00000014 ip_packet_type=0A= 00000000 l df *ABS* 00000000 ip_sockglue.c=0A= 801b7170 l F .text 00000000 ip_cmsg_recv_pktinfo=0A= 801b71cc l F .text 00000000 ip_cmsg_recv_ttl=0A= 801b7204 l F .text 00000000 ip_cmsg_recv_tos=0A= 801b7234 l F .text 00000000 ip_cmsg_recv_opts=0A= 00000000 l df *ABS* 00000000 tcp.c=0A= 801b98c8 l F .text 00000000 tcp_listen_stop=0A= 801b9b8c l F .text 00000000 wait_for_tcp_connect=0A= 801b9db4 l F .text 00000000 wait_for_tcp_memory=0A= 801ba0a0 l F .text 00000000 tcp_error=0A= 801bc0f8 l F .text 00000000 tcp_recv_urg=0A= 801bc1fc l F .text 00000000 cleanup_rbuf=0A= 801bc374 l F .text 00000000 tcp_data_wait=0A= 801bc50c l F .text 00000000 tcp_prequeue_process=0A= 8021e6c0 l O .data 00000010 new_state=0A= 801bcf44 l F .text 00000000 tcp_close_state=0A= 801be0b0 l F .text 00000000 wait_for_connect=0A= 00000000 l df *ABS* 00000000 tcp_input.c=0A= 801bf300 l F .text 00000000 tcp_incr_quickack=0A= 801bf37c l F .text 00000000 tcp_fixup_sndbuf=0A= 801bf3c0 l F .text 00000000 __tcp_grow_window=0A= 801bf45c l F .text 00000000 tcp_fixup_rcvbuf=0A= 801bf4c0 l F .text 00000000 tcp_init_buffer_space=0A= 801bf608 l F .text 00000000 tcp_clamp_window=0A= 801bf73c l F .text 00000000 tcp_event_data_recv=0A= 801bfc90 l F .text 00000000 tcp_init_metrics=0A= 801bfe1c l F .text 00000000 tcp_update_reordering=0A= 801bfeac l F .text 00000000 tcp_sacktag_write_queue=0A= 801c0778 l F .text 00000000 tcp_check_sack_reneging=0A= 801c0894 l F .text 00000000 tcp_time_to_recover=0A= 801c0ae0 l F .text 00000000 tcp_check_reno_reordering=0A= 801c0b40 l F .text 00000000 tcp_add_reno_sack=0A= 801c0bb0 l F .text 00000000 tcp_remove_reno_sacks=0A= 801c0c40 l F .text 00000000 tcp_mark_head_lost=0A= 801c0d6c l F .text 00000000 tcp_update_scoreboard=0A= 801c0ecc l F .text 00000000 tcp_cwnd_down=0A= 801c0f48 l F .text 00000000 tcp_undo_cwr=0A= 801c0ff4 l F .text 00000000 tcp_try_undo_recovery=0A= 801c1110 l F .text 00000000 tcp_try_undo_dsack=0A= 801c1170 l F .text 00000000 tcp_try_undo_partial=0A= 801c1274 l F .text 00000000 tcp_try_undo_loss=0A= 801c1370 l F .text 00000000 tcp_try_to_open=0A= 801c14cc l F .text 00000000 tcp_fastretrans_alert=0A= 801c1a50 l F .text 00000000 tcp_ack_saw_tstamp=0A= 801c1b90 l F .text 00000000 tcp_ack_no_tstamp=0A= 801c1cc8 l F .text 00000000 tcp_clean_rtx_queue=0A= 801c2058 l F .text 00000000 tcp_ack_probe=0A= 801c213c l F .text 00000000 tcp_ack_update_window=0A= 801c22a0 l F .text 00000000 tcp_ack=0A= 801c2920 l F .text 00000000 tcp_disordered_ack=0A= 801c29fc l F .text 00000000 tcp_reset=0A= 801c2b50 l F .text 00000000 tcp_fin=0A= 801c2e0c l F .text 00000000 tcp_send_dupack=0A= 801c2f24 l F .text 00000000 tcp_sack_maybe_coalesce=0A= 801c3024 l F .text 00000000 tcp_sack_new_ofo_skb=0A= 801c3184 l F .text 00000000 tcp_sack_remove=0A= 801c32a0 l F .text 00000000 tcp_ofo_queue=0A= 801c3520 l F .text 00000000 tcp_data_queue=0A= 801c46a4 l F .text 00000000 tcp_prune_queue=0A= 801c416c l F .text 00000000 tcp_collapse=0A= 801c45e0 l F .text 00000000 tcp_collapse_ofo_queue=0A= 801c495c l F .text 00000000 tcp_new_space=0A= 801c4a34 l F .text 00000000 __tcp_data_snd_check=0A= 801c4b44 l F .text 00000000 tcp_check_urg=0A= 801c4d0c l F .text 00000000 tcp_copy_to_iovec=0A= 801c4e3c l F .text 00000000 __tcp_checksum_complete_user=0A= 801c5888 l F .text 00000000 tcp_rcv_synsent_state_process=0A= 00000000 l df *ABS* 00000000 tcp_output.c=0A= 801c6ba0 l F .text 00000000 tcp_advertise_mss=0A= 801c6bd0 l F .text 00000000 tcp_cwnd_restart=0A= 801c7890 l F .text 00000000 skb_split=0A= 801c7b00 l F .text 00000000 tcp_fragment=0A= 801c83dc l F .text 00000000 tcp_retrans_try_collapse=0A= 801ca3a4 l F .text 00000000 tcp_xmit_probe_skb=0A= 00000000 l df *ABS* 00000000 tcp_timer.c=0A= 801cb4f0 l F .text 00000000 tcp_write_timer=0A= 801cadec l F .text 00000000 tcp_delack_timer=0A= 801cb9a4 l F .text 00000000 tcp_keepalive_timer=0A= 801ca920 l F .text 00000000 tcp_write_err=0A= 801caa50 l F .text 00000000 tcp_out_of_resources=0A= 801cac50 l F .text 00000000 tcp_orphan_retries=0A= 801cac88 l F .text 00000000 tcp_write_timeout=0A= 801cb044 l F .text 00000000 tcp_probe_timer=0A= 801cb12c l F .text 00000000 tcp_retransmit_timer=0A= 801cb644 l F .text 00000000 tcp_synack_timer=0A= 00000000 l df *ABS* 00000000 tcp_ipv4.c=0A= 8021e730 l O .data 00000004 tcp_socket=0A= 80334d98 l O .bss 000001d8 tcp_inode=0A= 801cbd70 l F .text 00000000 tcp_v4_get_port=0A= 801cc228 l F .text 00000000 tcp_v4_hash=0A= 801cc498 l F .text 00000000 __tcp_v4_lookup_listener=0A= 801cc51c l F .text 00000000 tcp_v4_check_established=0A= 801ccd8c l F .text 00000000 tcp_v4_search_req=0A= 801cce58 l F .text 00000000 tcp_v4_synq_add=0A= 801cd854 l F .text 00000000 tcp_v4_send_reset=0A= 801cda38 l F .text 00000000 tcp_v4_send_ack=0A= 801cdc78 l F .text 00000000 tcp_v4_timewait_ack=0A= 801cdcf0 l F .text 00000000 tcp_v4_or_send_ack=0A= 801cdd28 l F .text 00000000 tcp_v4_route_req=0A= 801cde54 l F .text 00000000 tcp_v4_send_synack=0A= 801cdf9c l F .text 00000000 tcp_v4_or_free=0A= 80334d90 l O .bss 00000004 warntime.0=0A= 801ce7a8 l F .text 00000000 tcp_v4_hnd_req=0A= 801ce998 l F .text 00000000 tcp_v4_checksum_init=0A= 801cf544 l F .text 00000000 __tcp_v4_rehash=0A= 801cf584 l F .text 00000000 tcp_v4_reselect_saddr=0A= 801cf8e8 l F .text 00000000 v4_addr2sockaddr=0A= 801cfbac l F .text 00000000 tcp_v4_init_sock=0A= 801cfca4 l F .text 00000000 tcp_v4_destroy_sock=0A= 801cfeb4 l F .text 00000000 get_openreq=0A= 801cff70 l F .text 00000000 get_tcp_sock=0A= 801d0150 l F .text 00000000 get_timewait_sock=0A= 00000000 l df *ABS* 00000000 tcp_minisocks.c=0A= 801d0f94 l F .text 00000000 __tcp_tw_hashdance=0A= 8021e824 l O .data 00000004 tcp_tw_death_row_slot=0A= 8021e828 l O .data 00000000 tw_death_lock=0A= 8021e828 l O .data 00000014 tcp_tw_timer=0A= 801d13a0 l F .text 00000000 tcp_twkill=0A= 80334f70 l O .bss 00000020 tcp_tw_death_row=0A= 8021e83c l O .data 00000004 tcp_twcal_hand=0A= 8021e840 l O .data 00000014 tcp_twcal_timer=0A= 801d1784 l F .text 00000000 tcp_twcal_tick=0A= 80334f94 l O .bss 00000080 tcp_twcal_row=0A= 80334f90 l O .bss 00000004 tcp_twcal_jiffie=0A= 00000000 l df *ABS* 00000000 raw.c=0A= 801d2200 l F .text 00000000 raw_v4_hash=0A= 801d22c0 l F .text 00000000 raw_v4_unhash=0A= 801d2664 l F .text 00000000 raw_rcv_skb=0A= 801d28b4 l F .text 00000000 raw_getfrag=0A= 801d28d8 l F .text 00000000 raw_getrawfrag=0A= 80335020 l O .bss 00000004 complained.0=0A= 801d2a24 l F .text 00000000 raw_sendmsg=0A= 801d2d7c l F .text 00000000 raw_close=0A= 801d2db0 l F .text 00000000 raw_bind=0A= 801d300c l F .text 00000000 raw_init=0A= 801d3030 l F .text 00000000 raw_seticmpfilter=0A= 801d3094 l F .text 00000000 raw_geticmpfilter=0A= 801d3148 l F .text 00000000 raw_setsockopt=0A= 801d31b0 l F .text 00000000 raw_getsockopt=0A= 801d3218 l F .text 00000000 raw_ioctl=0A= 801d32dc l F .text 00000000 get_raw_sock=0A= 00000000 l df *ABS* 00000000 udp.c=0A= 801d34d0 l F .text 00000000 udp_v4_get_port=0A= 801d37d4 l F .text 00000000 udp_v4_hash=0A= 801d3804 l F .text 00000000 udp_v4_unhash=0A= 801d3b80 l F .text 00000000 udp_check=0A= 801d3be4 l F .text 00000000 udp_getfrag=0A= 801d3d34 l F .text 00000000 udp_getfrag_nosum=0A= 801d48cc l F .text 00000000 udp_close=0A= 801d48e8 l F .text 00000000 udp_queue_rcv_skb=0A= 801d4a70 l F .text 00000000 udp_v4_mcast_deliver=0A= 801d4c74 l F .text 00000000 udp_checksum_init=0A= 801d50c8 l F .text 00000000 get_udp_sock=0A= 00000000 l df *ABS* 00000000 arp.c=0A= 8021e980 l O .data 00000020 arp_generic_ops=0A= 801d567c l F .text 00000000 arp_solicit=0A= 801d55f8 l F .text 00000000 arp_error_report=0A= 8021e9a0 l O .data 00000020 arp_hh_ops=0A= 8021e9c0 l O .data 00000020 arp_direct_ops=0A= 801d5420 l F .text 00000000 arp_hash=0A= 801d5450 l F .text 00000000 arp_constructor=0A= 801d5ef4 l F .text 00000000 parp_redo=0A= 801d57d8 l F .text 00000000 arp_filter=0A= 801d5894 l F .text 00000000 arp_set_predefined=0A= 801d6770 l F .text 00000000 arp_state_to_flags=0A= 801d67a0 l F .text 00000000 arp_req_get=0A= 801d6c7c l F .text 00000000 arp_get_info=0A= 8021ebb0 l O .data 00000014 arp_packet_type=0A= 00000000 l df *ABS* 00000000 icmp.c=0A= 8021ec5c l O .data 00000004 icmp_xmit_holder=0A= 801d70a0 l F .text 00000000 icmp_xmit_lock_bh=0A= 801d70b0 l F .text 00000000 icmp_xmit_unlock_bh=0A= 801d7128 l F .text 00000000 icmp_out_count=0A= 8021ec60 l O .data 00000130 icmp_pointers=0A= 801d71ac l F .text 00000000 icmp_glue_bits=0A= 801d726c l F .text 00000000 icmp_reply=0A= 801d78c0 l F .text 00000000 icmp_unreach=0A= 801d7be8 l F .text 00000000 icmp_redirect=0A= 801d7cac l F .text 00000000 icmp_echo=0A= 801d7d14 l F .text 00000000 icmp_timestamp=0A= 801d7e74 l F .text 00000000 icmp_address=0A= 801d7e7c l F .text 00000000 icmp_address_reply=0A= 801d8064 l F .text 00000000 icmp_discard=0A= 00000000 l df *ABS* 00000000 devinet.c=0A= 8021edc8 l O .data 00000038 ipv4_devconf_dflt=0A= 801d82a0 l F .text 00000000 inet_alloc_ifa=0A= 801d9fbc l F .text 00000000 devinet_sysctl_register=0A= 801d8618 l F .text 00000000 inetdev_destroy=0A= 801d8870 l F .text 00000000 inet_del_ifa=0A= 801da118 l F .text 00000000 devinet_sysctl_unregister=0A= 80335620 l O .bss 00000004 inetaddr_chain=0A= 801d8b50 l F .text 00000000 inet_insert_ifa=0A= 801d8e0c l F .text 00000000 inet_set_ifa=0A= 801d9998 l F .text 00000000 inet_gifconf=0A= 801d9c30 l F .text 00000000 inetdev_event=0A= 801d9f1c l F .text 00000000 devinet_sysctl_forward=0A= 8021ee0c l O .data 000003cc devinet_sysctl=0A= 00000000 l df *ABS* 00000000 af_inet.c=0A= 801da4c4 l F .text 00000000 inet_autobind=0A= 801da7fc l F .text 00000000 inet_create=0A= 801dab10 l F .text 00000000 inet_bind=0A= 801dae88 l F .text 00000000 inet_wait_for_connect=0A= 801db520 l F .text 00000000 inet_getname=0A= 801db89c l F .text 00000000 inet_ioctl=0A= 8021f278 l O .data 00000060 inetsw_array=0A= 8020d06c l F .text.init 00000000 inet_init=0A= 80210090 l O .initcall.init 00000004 __initcall_inet_init=0A= 00000000 l df *ABS* 00000000 igmp.c=0A= 801dbd40 l F .text 00000000 ip_ma_put=0A= 801dbdbc l F .text 00000000 ip_mc_filter_add=0A= 801dbe10 l F .text 00000000 ip_mc_filter_del=0A= 801dbe64 l F .text 00000000 igmp_group_dropped=0A= 801dbe98 l F .text 00000000 igmp_group_added=0A= 801dc58c l F .text 00000000 ip_mc_find_dev=0A= 00000000 l df *ABS* 00000000 sysctl_net_ipv4.c=0A= 8021f2f0 l O .data 00000004 tcp_retr1_max=0A= 8021f2f4 l O .data 00000008 ip_local_port_range_min=0A= 8021f2fc l O .data 00000008 ip_local_port_range_max=0A= 801dcae0 l F .text 00000000 ipv4_sysctl_forward=0A= 801dcb50 l F .text 00000000 ipv4_sysctl_forward_strategy=0A= 00000000 l df *ABS* 00000000 fib_frontend.c=0A= 801dcc1c l F .text 00000000 fib_get_procinfo=0A= 801dd340 l F .text 00000000 fib_magic=0A= 801dd498 l F .text 00000000 fib_add_ifaddr=0A= 801dd628 l F .text 00000000 fib_del_ifaddr=0A= 801dd818 l F .text 00000000 fib_disable_ip=0A= 801dd868 l F .text 00000000 fib_inetaddr_event=0A= 801dd8f8 l F .text 00000000 fib_netdev_event=0A= 00000000 l df *ABS* 00000000 fib_semantics.c=0A= 8021fbf0 l O .data 00000000 fib_info_lock=0A= 8021fbf0 l O .data 00000068 fib_props=0A= 80335920 l O .bss 00000004 fib_info_list=0A= 801ddbec l F .text 00000000 fib_check_nh=0A= 8021fc58 l O .data 00000030 type2flags.0=0A= 801de95c l F .text 00000000 fib_flag_trans=0A= 00000000 l df *ABS* 00000000 fib_hash.c=0A= 8021fc90 l O .data 00000000 fib_hash_lock=0A= 801deac0 l F .text 00000000 fn_free_node=0A= 80335930 l O .bss 00000004 fn_hash_kmem=0A= 801deaf8 l F .text 00000000 fn_new_zone=0A= 801decc0 l F .text 00000000 fn_hash_lookup=0A= 8021fc90 l O .data 00000004 fn_hash_last_dflt=0A= 801dee64 l F .text 00000000 fib_detect_death=0A= 801def64 l F .text 00000000 fn_hash_select_default=0A= 801df1c8 l F .text 00000000 fn_hash_insert=0A= 801df650 l F .text 00000000 fn_hash_delete=0A= 80335934 l O .bss 00000004 fib_hash_zombies=0A= 801df978 l F .text 00000000 fn_hash_flush=0A= 801dfac4 l F .text 00000000 fn_hash_get_info=0A= 00000000 l df *ABS* 00000000 ipconfig.c=0A= 8020fef0 l O .data.init 00000010 user_dev_name=0A= 8020ff00 l O .data.init 00000004 ic_proto_have_if=0A= 8021fca4 l O .data 00000000 ic_recv_lock=0A= 8020ff04 l O .data.init 00000004 ic_got_reply=0A= 8020ff08 l O .data.init 00000004 ic_first_dev=0A= 8020ff0c l O .data.init 00000004 ic_dev=0A= 8020d408 l F .text.init 00000000 ic_open_devs=0A= 8020d700 l F .text.init 00000000 ic_close_devs=0A= 8020d7d4 l F .text.init 00000000 ic_dev_ioctl=0A= 8020d804 l F .text.init 00000000 ic_route_ioctl=0A= 8020d834 l F .text.init 00000000 ic_setup_if=0A= 8020d944 l F .text.init 00000000 ic_setup_routes=0A= 8020da24 l F .text.init 00000000 ic_defaults=0A= 8020ff10 l O .data.init 00000014 bootp_packet_type=0A= 8020e10c l F .text.init 00000000 ic_bootp_recv=0A= 801f879c l O .text 00000004 ic_bootp_cookie=0A= 8020db80 l F .text.init 00000000 ic_bootp_init_ext=0A= 8020dc54 l F .text.init 00000000 ic_bootp_send_if=0A= 8020df44 l F .text.init 00000000 ic_bootp_string=0A= 8020df9c l F .text.init 00000000 ic_do_bootp_ext=0A= 8020e464 l F .text.init 00000000 ic_dynamic=0A= 801dfc00 l F .text 00000000 pnp_get_info=0A= 8020e7a8 l F .text.init 00000000 ip_auto_config=0A= 80210094 l O .initcall.init 00000004 __initcall_ip_auto_config=0A= 8020ea58 l F .text.init 00000000 ic_proto_name=0A= 8020eb74 l F .text.init 00000000 ip_auto_config_setup=0A= 8020ee48 l F .text.init 00000000 nfsaddrs_config_setup=0A= 8020ff24 l O .data.init 00000004 = __setup_str_ip_auto_config_setup=0A= 80210028 l O .setup.init 00000008 __setup_ip_auto_config_setup=0A= 8020ff28 l O .data.init 0000000a = __setup_str_nfsaddrs_config_setup=0A= 80210030 l O .setup.init 00000008 __setup_nfsaddrs_config_setup=0A= 00000000 l df *ABS* 00000000 af_unix.c=0A= 8021fcb4 l O .data 00000004 unix_nr_socks=0A= 801dfd60 l F .text 00000000 unix_mkname=0A= 801dfe10 l F .text 00000000 __unix_remove_socket=0A= 801dfe80 l F .text 00000000 __unix_insert_socket=0A= 801dff00 l F .text 00000000 __unix_find_socket_byname=0A= 801dff90 l F .text 00000000 unix_find_socket_byinode=0A= 801dffe4 l F .text 00000000 unix_write_space=0A= 801e006c l F .text 00000000 unix_dgram_disconnected=0A= 801e01ac l F .text 00000000 unix_sock_destructor=0A= 801e0368 l F .text 00000000 unix_release_sock=0A= 801e0670 l F .text 00000000 unix_listen=0A= 801e0728 l F .text 00000000 unix_create1=0A= 801e0830 l F .text 00000000 unix_create=0A= 801e08b8 l F .text 00000000 unix_release=0A= 8021fcb8 l O .data 00000004 ordernum.0=0A= 801e08ec l F .text 00000000 unix_autobind=0A= 801e0ad4 l F .text 00000000 unix_find_other=0A= 801e0c2c l F .text 00000000 unix_bind=0A= 801e0ff8 l F .text 00000000 unix_dgram_connect=0A= 801e1174 l F .text 00000000 unix_wait_for_peer=0A= 801e1244 l F .text 00000000 unix_stream_connect=0A= 801e16e0 l F .text 00000000 unix_socketpair=0A= 801e176c l F .text 00000000 unix_accept=0A= 801e1870 l F .text 00000000 unix_getname=0A= 801e1960 l F .text 00000000 unix_detach_fds=0A= 801e19d4 l F .text 00000000 unix_destruct_fds=0A= 801e1a38 l F .text 00000000 unix_attach_fds=0A= 801e1ab4 l F .text 00000000 unix_dgram_sendmsg=0A= 801e1f88 l F .text 00000000 unix_stream_sendmsg=0A= 801e2378 l F .text 00000000 unix_copy_addr=0A= 801e23c0 l F .text 00000000 unix_dgram_recvmsg=0A= 801e252c l F .text 00000000 unix_stream_data_wait=0A= 801e266c l F .text 00000000 unix_stream_recvmsg=0A= 801e2c34 l F .text 00000000 unix_shutdown=0A= 801e2d90 l F .text 00000000 unix_ioctl=0A= 801e2e50 l F .text 00000000 unix_poll=0A= 801e2f14 l F .text 00000000 unix_read_proc=0A= 8020ff34 l O .data.init 00000038 banner=0A= 8020ee64 l F .text.init 00000000 af_unix_init=0A= 80210098 l O .initcall.init 00000004 __initcall_af_unix_init=0A= 00000000 l df *ABS* 00000000 garbage.c=0A= 8021fd60 l O .data 00000004 gc_current=0A= 8021fd68 l O .data 00000010 unix_gc_sem.0=0A= 00000000 l df *ABS* 00000000 sysctl_net_unix.c=0A= 8021fdd8 l O .data 00000058 unix_net_table=0A= 8021fe30 l O .data 00000058 unix_root_table=0A= 80335da0 l O .bss 00000004 unix_sysctl_header=0A= 00000000 l df *ABS* 00000000 netsyms.c=0A= 00000000 l df *ABS* 00000000 sysctl_net.c=0A= 00000000 l df *ABS* 00000000 csum_partial.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 csum_partial.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 csum_partial.S=0A= 801e3760 l .text 00000000 small_csumcpy=0A= 801e3d38 l .text 00000000 out=0A= 801e383c l .text 00000000 hword_align=0A= 801e3864 l .text 00000000 word_align=0A= 801e3888 l .text 00000000 dword_align=0A= 801e3cf0 l .text 00000000 do_end_words=0A= 801e38b8 l .text 00000000 qword_align=0A= 801e38ec l .text 00000000 oword_align=0A= 801e3940 l .text 00000000 begin_movement=0A= 801e3948 l .text 00000000 move_128bytes=0A= 801e3b5c l .text 00000000 move_64bytes=0A= 801e3c68 l .text 00000000 move_32bytes=0A= 801e3d14 l .text 00000000 maybe_end_cruft=0A= 801e3cf8 l .text 00000000 end_words=0A= 801e3d18 l .text 00000000 small_memcpy=0A= 801e3d28 l .text 00000000 end_bytes=0A= 00000000 l df *ABS* 00000000 csum_partial_copy.c=0A= 00000000 l df *ABS* 00000000 rtc-no.c=0A= 80335db0 l O .bss 00000004 called.0=0A= 801e3e50 l F .text 00000000 shouldnt_happen=0A= 00000000 l df *ABS* 00000000 memcpy.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 memcpy.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 memcpy.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 memcpy.S=0A= 801e3ea4 l .text 00000000 __memcpy=0A= 801e3ec0 l .text 00000000 can_align=0A= 801e41e4 l .text 00000000 memcpy_u_src=0A= 801e41bc l .text 00000000 small_memcpy=0A= 801e41dc l .text 00000000 out=0A= 801e3ed0 l .text 00000000 hword_align=0A= 801e3ef0 l .text 00000000 word_align=0A= 801e4654 l .text 00000000 l_fixup=0A= 801e4670 l .text 00000000 s_fixup=0A= 801e3f10 l .text 00000000 dword_align=0A= 801e4198 l .text 00000000 do_end_words=0A= 801e3f3c l .text 00000000 qword_align=0A= 801e3f64 l .text 00000000 oword_align=0A= 801e3f9c l .text 00000000 begin_movement=0A= 801e3fa4 l .text 00000000 move_128bytes=0A= 801e40bc l .text 00000000 move_64bytes=0A= 801e414c l .text 00000000 move_32bytes=0A= 801e41b8 l .text 00000000 maybe_end_cruft=0A= 801e41a0 l .text 00000000 end_words=0A= 801e41c4 l .text 00000000 end_bytes=0A= 801e458c l .text 00000000 u_do_end_words=0A= 801e4238 l .text 00000000 u_qword_align=0A= 801e4268 l .text 00000000 u_oword_align=0A= 801e42b0 l .text 00000000 u_begin_movement=0A= 801e42b8 l .text 00000000 u_move_128bytes=0A= 801e4450 l .text 00000000 u_move_64bytes=0A= 801e4520 l .text 00000000 u_move_32bytes=0A= 801e45b0 l .text 00000000 u_maybe_end_cruft=0A= 801e4594 l .text 00000000 u_end_words=0A= 801e45b4 l .text 00000000 u_cannot_optimize=0A= 801e45bc l .text 00000000 u_end_bytes=0A= 801e462c l .text 00000000 r_out=0A= 801e4634 l .text 00000000 r_end_bytes_up=0A= 801e4614 l .text 00000000 r_end_bytes=0A= 00000000 l df *ABS* 00000000 memset.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 memset.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 memset.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 memset.S=0A= 801e4788 l .text 00000000 small_memset=0A= 801e47a4 l .text 00000000 first_fixup=0A= 801e471c l .text 00000000 memset_partial=0A= 801e47ac l .text 00000000 fwd_fixup=0A= 801e47c0 l .text 00000000 partial_fixup=0A= 801e47d4 l .text 00000000 last_fixup=0A= 00000000 l df *ABS* 00000000 strlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 strlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 strlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 strlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 strlen_user.S=0A= 801e4808 l .text 00000000 fault=0A= 00000000 l df *ABS* 00000000 strncpy_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 strncpy_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 strncpy_user.S=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 strncpy_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/errno.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/errno.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/errno.h=0A= 00000000 l df *ABS* 00000000 strncpy_user.S=0A= 801e485c l .text 00000000 fault=0A= 00000000 l df *ABS* 00000000 strnlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 strnlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 strnlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 strnlen_user.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 strnlen_user.S=0A= 801e48a4 l .text 00000000 fault=0A= 00000000 l df *ABS* 00000000 dump_tlb.c=0A= 00000000 l df *ABS* 00000000 errno.c=0A= 00000000 l df *ABS* 00000000 ctype.c=0A= 00000000 l df *ABS* 00000000 string.c=0A= 00000000 l df *ABS* 00000000 vsprintf.c=0A= 801e5698 l F .text 00000000 skip_atoi=0A= 801e5700 l F .text 00000000 number=0A= 00000000 l df *ABS* 00000000 cmdline.c=0A= 00000000 l df *ABS* 00000000 rbtree.c=0A= 801e6ac0 l F .text 00000000 __rb_rotate_left=0A= 801e6b0c l F .text 00000000 __rb_rotate_right=0A= 801e6c9c l F .text 00000000 __rb_erase_color=0A= 00000000 l df *ABS* 00000000 rwsem-spinlock.c=0A= 00000000 l df *ABS* 00000000 idisx_int.c=0A= 00000000 l df *ABS* 00000000 time.c=0A= 80220080 l O .data 00000004 last_rtc_update=0A= 80220084 l O .data 00000004 timer_tick_count=0A= 80220088 l O .data 0000001e display_string=0A= 802200a8 l O .data 00000004 display_count=0A= 801e7300 l F .text 00000000 set_rtc_mmss=0A= 80335de0 l O .bss 00000004 r4k_offset=0A= 80335de4 l O .bss 00000004 r4k_cur=0A= 8020eefc l F .text.init 00000000 get_mips_time=0A= 802200ac l O .data 00000004 timerhi=0A= 802200b0 l O .data 00000004 timerlo=0A= 802200b4 l O .data 00000004 last_jiffies.0=0A= 802200b8 l O .data 00000004 cached_quotient.1=0A= 801e7534 l F .text 00000000 do_fast_gettimeoffset=0A= 00000000 l df *ABS* 00000000 idisx_setup.c=0A= 00000000 l df *ABS* 00000000 init.c=0A= 00000000 l df *ABS* 00000000 memory.c=0A= 802200d0 l O .data 0000000c mtypes=0A= 8020f448 l F .text.init 00000000 prom_memtype_classify=0A= 00000000 l df *ABS* 00000000 printf.c=0A= 801e7860 l F .text 00000000 serial_in=0A= 801e78ac l F .text 00000000 serial_out=0A= 802200e0 l O .data 00000188 rs_table=0A= 80220268 l O .data 000000ac prom_port_info=0A= 80335fa0 l O .bss 00000400 buf=0A= 00000000 l df *ABS* 00000000 display.c=0A= 00000000 l df *ABS* 00000000 cmdline.c=0A= 00000000 l df *ABS* 00000000 gdb_hook.c=0A= 80220320 l O .data 00000188 rs_table=0A= 802204a8 l O .data 000000ac kdb_port_info=0A= 00000000 l df *ABS* 00000000 idisx_rtc.c=0A= 80220560 l O .data 00000004 baseaddr=0A= 801e7c30 l F .text 00000000 idisx_rtc_read_data=0A= 801e7cb4 l F .text 00000000 idisx_rtc_write_data=0A= 801e7d50 l F .text 00000000 idisx_rtc_bcd_mode=0A= 00000000 l df *ABS* 00000000 reset.c=0A= 801e7d80 l F .text 00000000 idisx_machine_restart=0A= 801e7d94 l F .text 00000000 idisx_machine_halt=0A= 801e7da8 l F .text 00000000 idisx_machine_power_off=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/offset.h=0A= 00000000 l df *ABS* 00000000 /opt/iDISX/src/linux/include/asm/stackfr= ame.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/isadep.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/cache.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/processor.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/addrspace.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/stackframe.h=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/regdef.h=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/linkage.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/mipsregs.h=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/sgidefs.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/asm/asm.h=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/autoconf.h=0A= 00000000 l df *ABS* 00000000 = /opt/iDISX/src/linux/include/linux/config.h=0A= 00000000 l df *ABS* 00000000 idisxIRQ.S=0A= 00000000 l df *ABS* 00000000 pci.c=0A= 00000000 l df *ABS* 00000000 mqb_int.c=0A= 802205a8 l O .data 00000004 count.0=0A= 00000000 l df *ABS* 00000000 ddr.c=0A= 80154ee4 g F .text 00000000 fcntl_getlease=0A= 8019f468 g F .text 00000000 sys_recv=0A= 8020baa0 g F .text.init 00000000 loop_init=0A= 8011e8c8 g F .text 00000000 is_orphaned_pgrp=0A= 80200078 g O __ksymtab 00000008 __ksymtab_blk_queue_make_request=0A= 801595bc g F .text 00000000 iget4=0A= 8021ba20 g O .data 00000048 proc_kcore_operations=0A= 80148770 g F .text 00000000 cdget=0A= 8021a0fc g O .data 00000004 fs_overflowgid=0A= 801ffe08 g O __ksymtab 00000008 __ksymtab_get_empty_inode=0A= 80320870 g O .bss 00000004 core_uses_pid=0A= 801ffd18 g O __ksymtab 00000008 __ksymtab_simple_strtoul=0A= 801db59c g F .text 00000000 inet_recvmsg=0A= 80154088 g F .text 00000000 posix_test_lock=0A= 8010c6d0 g F .text 00000000 sys_pause=0A= 8021ee00 g O .data 00000000 inetdev_lock=0A= 802004e8 g O __ksymtab 00000008 = __ksymtab_register_inetaddr_notifier=0A= 8012575c g F .text 00000000 sys_getgid=0A= 802070d4 g F .text.init 00000000 init_bootmem=0A= 8018cccc g F .text 00000000 raw_ctl_ioctl=0A= 8019f488 g F .text 00000000 sys_setsockopt=0A= 801ff220 g O __ksymtab 00000008 __ksymtab_abi_defhandler_elf=0A= 80116e90 g F .text 00000000 update_mmu_cache=0A= 801b3bd0 g F .text 00000000 ip_options_build=0A= 8012f0c4 g F .text 00000000 truncate_inode_pages=0A= 80335640 g O .bss 00000058 inetsw=0A= 801568f0 g F .text 00000000 prune_dcache=0A= 801ff950 g O __ksymtab 00000008 __ksymtab_unlock_page=0A= 801421ec g F .text 00000000 __invalidate_buffers=0A= 801ff5d0 g O __ksymtab 00000008 __ksymtab___mark_inode_dirty=0A= 801fcf90 g O .kstrtab 00000009 __kstrtab_arp_send=0A= 8017aa30 g F .text 00000000 ieee754dp_ceil=0A= 8012b374 g F .text 00000000 zap_page_range=0A= 8013f4b4 g F .text 00000000 filp_open=0A= 801fad6c g O .kstrtab 00000019 = __kstrtab_inter_module_get_request=0A= 801541d4 g F .text 00000000 locks_mandatory_area=0A= 801ff088 g O __ksymtab 00000008 __ksymtab_isa_slot_offset=0A= 801faef0 g O .kstrtab 00000011 __kstrtab_kmem_cache_alloc=0A= 801a4204 g F .text 00000000 skb_free_datagram=0A= 801fc928 g O .kstrtab 0000000b __kstrtab_sock_alloc=0A= 8013fb00 g F .text 00000000 sys_close=0A= 801ff168 g O __ksymtab 00000008 __ksymtab__flush_page_to_ram=0A= 8020ff70 g O *ABS* 00000000 __setup_start=0A= 8021e220 g O .data 00000004 ip_rt_error_cost=0A= 801ff720 g O __ksymtab 00000008 __ksymtab_generic_commit_write=0A= 801fbb40 g O .kstrtab 00000012 __kstrtab_unregister_binfmt=0A= 80147ee8 g F .text 00000000 get_blkfops=0A= 801ff558 g O __ksymtab 00000008 __ksymtab_dcache_lock=0A= 801fb3a4 g O .kstrtab 00000012 __kstrtab_generic_direct_IO=0A= 8012941c g F .text 00000000 sys_setsid=0A= 8016625c g F .text 00000000 devfs_register_partitions=0A= 801fff80 g O __ksymtab 00000008 __ksymtab_proc_symlink=0A= 801ff328 g O __ksymtab 00000008 __ksymtab_in_egroup_p=0A= 8010f340 g F .text 00000000 bust_spinlocks=0A= 801949ec g F .text 00000000 rs_read_proc=0A= 8015ad70 g F .text 00000000 alloc_vfsmnt=0A= 801ff5b0 g O __ksymtab 00000008 __ksymtab___d_path=0A= 801fb088 g O .kstrtab 0000000c __kstrtab___user_walk=0A= 801ff678 g O __ksymtab 00000008 __ksymtab_notify_change=0A= 801ffac8 g O __ksymtab 00000008 __ksymtab_register_sysctl_table=0A= 8017430c g F .text 00000000 sys_msgget=0A= 801fcf3c g O .kstrtab 00000014 __kstrtab_ip_route_output_key=0A= 801fcf0c g O .kstrtab 00000016 __kstrtab_inet_register_protosw=0A= 8021ed90 g O .data 00000038 ipv4_devconf=0A= 801ff538 g O __ksymtab 00000008 __ksymtab___user_walk=0A= 801ffe98 g O __ksymtab 00000008 __ksymtab_tasklet_hi_vec=0A= 802192d4 g O .data 00000004 abi_defhandler_elf=0A= 8010bc08 g F .text 00000000 sys_iopl=0A= 801fd420 g O .kstrtab 0000000e __kstrtab_dev_mc_delete=0A= 8020f688 g F .text.init 00000000 prom_getcmdline=0A= 801fd4b4 g O .kstrtab 0000000e __kstrtab_qdisc_restart=0A= 803363a0 g O .bss 00000050 arcs_cmdline=0A= 8012de04 g F .text 00000000 find_extend_vma=0A= 8010d98c g F .text 00000000 free_irq=0A= 801e7820 g F .text 00000000 get_system_type=0A= 801fade8 g O .kstrtab 00000008 __kstrtab_exit_fs=0A= 801fb150 g O .kstrtab 00000012 __kstrtab_mark_buffer_dirty=0A= 80200320 g O __ksymtab 00000008 __ksymtab_neigh_lookup=0A= 801abfc4 g F .text 00000000 net_srandom=0A= 801fc060 g O .kstrtab 00000008 __kstrtab_uts_sem=0A= 801ff358 g O __ksymtab 00000008 __ksymtab_inter_module_register=0A= 8021a0a4 g O .data 00000004 time_tolerance=0A= 8011e8e4 g F .text 00000000 put_files_struct=0A= 801cb92c g F .text 00000000 tcp_set_keepalive=0A= 8011c1ec g F .text 00000000 inter_module_unregister=0A= 8010f91c g F .text 00000038 r4k_clear_page_s64=0A= 801fbd10 g O .kstrtab 00000014 __kstrtab_wait_for_completion=0A= 801ffff8 g O __ksymtab 00000008 __ksymtab_misc_deregister=0A= 801fcfac g O .kstrtab 00000012 __kstrtab___ip_select_ident=0A= 80162110 g F .text 00000000 proc_match=0A= 801fffe0 g O __ksymtab 00000008 __ksymtab_tty_unregister_devfs=0A= 801fffc0 g O __ksymtab 00000008 __ksymtab_proc_bus=0A= 80119084 g F .text 00000000 daemonize=0A= 801fb300 g O .kstrtab 0000000e __kstrtab_set_blocksize=0A= 801ff7b0 g O __ksymtab 00000008 __ksymtab_posix_unblock_lock=0A= 801444dc g F .text 00000000 generic_block_bmap=0A= 80126ca4 g F .text 00000000 kill_pg=0A= 8015adf0 g F .text 00000000 free_vfsmnt=0A= 801ae488 g F .text 00000000 __ip_select_ident=0A= 801d0204 g F .text 00000000 tcp_get_info=0A= 801ffa90 g O __ksymtab 00000008 __ksymtab_register_binfmt=0A= 8014c0d4 g F .text 00000000 get_write_access=0A= 80200408 g O __ksymtab 00000008 __ksymtab_inet_register_protosw=0A= 803164c8 g O .bss 00000004 _flush_cache_sigtramp=0A= 801faa74 g O .kstrtab 00000013 __kstrtab_abi_defhandler_elf=0A= 801facbc g O .kstrtab 0000000c __kstrtab_in_egroup_p=0A= 803163e0 g O .bss 00000004 unaligned_instructions=0A= 801fc8b4 g O .kstrtab 0000000e __kstrtab_sock_register=0A= 801fbcfc g O .kstrtab 00000012 __kstrtab_remove_wait_queue=0A= 8021ec50 g O .data 00000004 sysctl_icmp_ratelimit=0A= 801214d4 g F .text 00000000 request_resource=0A= 801c7f54 g F .text 00000000 tcp_write_xmit=0A= 801b1878 g F .text 00000000 afinet_get_info=0A= 801abe5c g F .text 00000000 rtnl_unlock=0A= 801fc10c g O .kstrtab 0000000d __kstrtab_csum_partial=0A= 803164ac g O .bss 00000004 ___flush_cache_all=0A= 801ff3d8 g O __ksymtab 00000008 __ksymtab___get_free_pages=0A= 801fbdc4 g O .kstrtab 0000000c __kstrtab_lock_kiovec=0A= 801fff10 g O __ksymtab 00000008 __ksymtab_pidhash=0A= 801fd048 g O .kstrtab 0000000d __kstrtab_ip_cmsg_recv=0A= 801faadc g O .kstrtab 00000007 __kstrtab_printk=0A= 801fd128 g O .kstrtab 00000011 __kstrtab_dev_set_allmulti=0A= 80155e2c g F .text 00000000 posix_block_lock=0A= 801ffc10 g O __ksymtab 00000008 __ksymtab_check_resource=0A= 8010d78c g F .text 00000000 do_IRQ=0A= 801b6fd8 g F .text 00000000 ip_finish_output=0A= 802006d8 g O __ksymtab 00000008 __ksymtab_noop_qdisc=0A= 801ac130 g F .text 00000000 eth_header=0A= 801fb0d8 g O .kstrtab 00000009 __kstrtab_d_delete=0A= 80181110 g F .text 00000000 ieee754sp_mul=0A= 801ffd80 g O __ksymtab 00000008 __ksymtab_csum_partial=0A= 801ffd08 g O __ksymtab 00000008 __ksymtab_bdevname=0A= 801fcf60 g O .kstrtab 0000000a __kstrtab_icmp_send=0A= 80157050 g F .text 00000000 d_instantiate=0A= 801fce6c g O .kstrtab 0000000b __kstrtab_scm_fp_dup=0A= 801663e4 g F .text 00000000 read_dev_sector=0A= 8031d738 g O .bss 0000000c avenrun=0A= 801ff300 g O __ksymtab 00000008 = __ksymtab_notifier_chain_unregister=0A= 80147c84 g F .text 00000000 bdput=0A= 801bf34c g F .text 00000000 tcp_enter_quickack_mode=0A= 80173c90 g F .text 00000000 ipcperms=0A= 801ff6d8 g O __ksymtab 00000008 __ksymtab_unlock_buffer=0A= 801fa758 g O .kstrtab 00000012 __kstrtab_mips_io_port_base=0A= 801ff8f8 g O __ksymtab 00000008 __ksymtab_lease_get_mtime=0A= 8018e164 g F .text 00000000 misc_deregister=0A= 80120160 g F .text 00000000 sys_settimeofday=0A= 80126e8c g F .text 00000000 sys_rt_sigprocmask=0A= 8013795c g F .text 00000000 lru_cache_del=0A= 80202af0 g F .text.init 00000014 except_vec1_generic=0A= 80200460 g O __ksymtab 00000008 __ksymtab_ip_fragment=0A= 801ff160 g O __ksymtab 00000008 __ksymtab_csum_partial_copy=0A= 801fb054 g O .kstrtab 0000000b __kstrtab_lookup_mnt=0A= 801ad068 g F .text 00000000 dev_init_scheduler=0A= 801a6790 g F .text 00000000 net_call_rx_atomic=0A= 801ff738 g O __ksymtab 00000008 __ksymtab_waitfor_one_page=0A= 8011fa28 g F .text 00000000 it_real_fn=0A= 801a9cc4 g F .text 00000000 pneigh_delete=0A= 80172838 g F .text 00000000 autofs4_wait_release=0A= 8013e938 g F .text 00000000 sys_utime=0A= 80182b38 g F .text 00000000 ieee754sp_neg=0A= 8015a9b8 g F .text 00000000 kiobuf_wait_for_io=0A= 801b22c4 g F .text 00000000 ip_rcv=0A= 801fbb30 g O .kstrtab 00000010 __kstrtab_register_binfmt=0A= 80316044 g O .bss 00000004 rows=0A= 801e6fc4 g F .text 00000000 __down_read=0A= 801de2cc g F .text 00000000 fib_semantic_match=0A= 8021e8f0 g O .data 00000000 udp_hash_lock=0A= 801c0544 g F .text 00000000 tcp_clear_retrans=0A= 8021aac0 g O .data 00000024 bdflush_min=0A= 80158a5c g F .text 00000000 clear_inode=0A= 801fc270 g O .kstrtab 0000000d __kstrtab_is_bad_inode=0A= 801fd3ec g O .kstrtab 00000009 __kstrtab_dev_base=0A= 801ff550 g O __ksymtab 00000008 __ksymtab_sys_close=0A= 801ff1c8 g O __ksymtab 00000008 __ksymtab_enable_irq=0A= 801ff7c8 g O __ksymtab 00000008 __ksymtab_dput=0A= 8010b0b4 g F .text 00000000 do_ri=0A= 8013f3e0 g F .text 00000000 sys_lchown=0A= 801d38b8 g F .text 00000000 udp_v4_lookup_longway=0A= 801c93d0 g F .text 00000000 tcp_send_synack=0A= 8021a0b8 g O .data 00000000 tqueue_lock=0A= 80159eb8 g F .text 00000000 notify_change=0A= 801a5490 g F .text 00000000 netdev_boot_setup_add=0A= 8011ac74 g F .text 00000000 get_exec_domain_list=0A= 80127f10 g F .text 00000000 notifier_chain_register=0A= 801499c0 g F .text 00000000 open_exec=0A= 80172db4 g F .text 00000000 autofs4_expire_run=0A= 8018892c g F .text 00000000 tty_paranoia_check=0A= 801fff40 g O __ksymtab 00000008 __ksymtab_set_buffer_flushtime=0A= 801e6254 g F .text 00000000 vsprintf=0A= 8019f36c g F .text 00000000 sys_recvfrom=0A= 80178688 g F .text 00000000 sys_shmdt=0A= 801c74b8 g F .text 00000000 tcp_send_skb=0A= 801afa2c g F .text 00000000 ip_route_input_slow=0A= 80202040 g F .text.init 00000000 name_to_kdev_t=0A= 801ff620 g O __ksymtab 00000008 __ksymtab_invalidate_inodes=0A= 8021bb60 g O .data 00000048 ext2_file_operations=0A= 8021a0e0 g O .data 00000004 max_queued_signals=0A= 80116d80 g F .text 00000000 local_flush_tlb_page=0A= 801fce1c g O .kstrtab 0000000c __kstrtab_dst_destroy=0A= 802052d4 g F .text.init 00000000 add_wired_entry=0A= 80211a80 g O .data 00000000 _fdata=0A= 80183934 g F .text 00000000 ieee754sp_tulong=0A= 801ffdd8 g O __ksymtab 00000008 = __ksymtab_fsync_inode_data_buffers=0A= 80205b98 g F .text.init 00000000 init_idle=0A= 802134a0 g F .data 000000f4 handle_ri=0A= 80200390 g O __ksymtab 00000008 __ksymtab_dst_destroy=0A= 801fd13c g O .kstrtab 00000014 __kstrtab_dev_set_promiscuity=0A= 80140d70 g F .text 00000000 get_empty_filp=0A= 8010ffb4 g F .text 0000003c pgd_init=0A= 8021326c g F .data 00000000 handle_ibe_int=0A= 802002f8 g O __ksymtab 00000008 __ksymtab_neigh_table_clear=0A= 80139dfc g F .text 00000000 nr_free_buffer_pages=0A= 801ffad0 g O __ksymtab 00000008 = __ksymtab_unregister_sysctl_table=0A= 8020fdd8 g O .data.init 00000004 ic_host_name_set=0A= 801886b4 g F .text 00000000 tty_unregister_devfs=0A= 801a2fc0 g F .text 00000000 skb_copy_bits=0A= 801e7b30 g F .text 00000000 putDebugChar=0A= 801ac25c g F .text 00000000 eth_rebuild_header=0A= 802051a0 g F .text.init 00000000 ld_mmu_r4xx0=0A= 802004c8 g O __ksymtab 00000008 __ksymtab_in_dev_finish_destroy=0A= 801fc314 g O .kstrtab 00000007 __kstrtab_strsep=0A= 801dbcac g F .text 00000000 inet_unregister_protosw=0A= 80200488 g O __ksymtab 00000008 __ksymtab_ip_finish_output=0A= 801fd390 g O .kstrtab 0000000a __kstrtab_dev_alloc=0A= 801fbca0 g O .kstrtab 0000000a __kstrtab_del_timer=0A= 801dc08c g F .text 00000000 ip_mc_dec_group=0A= 80163d3c g F .text 00000000 proc_pid_read_maps=0A= 801ff6d0 g O __ksymtab 00000008 __ksymtab_submit_bh=0A= 8016e884 g F .text 00000000 autofs_hash_nuke=0A= 801fb618 g O .kstrtab 00000015 __kstrtab_shrink_dcache_parent=0A= 801280f0 g F .text 00000000 sys_setpriority=0A= 8014054c g F .text 00000000 sys_writev=0A= 80156334 g F .text 00000000 lock_may_read=0A= 801ffdc0 g O __ksymtab 00000008 __ksymtab_sys_tz=0A= 80316050 g O .bss 00000004 wait_init_idle=0A= 801fbeac g O .kstrtab 00000010 __kstrtab_ioport_resource=0A= 801bc5fc g F .text 00000000 tcp_recvmsg=0A= 80138668 g F .text 00000000 try_to_free_pages=0A= 8014d188 g F .text 00000000 set_fs_altroot=0A= 80210038 g O *ABS* 00000000 __setup_end=0A= 8021ac90 g O .data 00000048 rdwr_fifo_fops=0A= 801fc844 g O .kstrtab 0000000c __kstrtab_ether_setup=0A= 8020b780 g F .text.init 00000000 rd_load=0A= 801fba88 g O .kstrtab 00000011 __kstrtab_tty_check_change=0A= 801ff080 g O *ABS* 00000000 __start___dbe_table=0A= 801fcd68 g O .kstrtab 00000016 __kstrtab_neigh_sysctl_register=0A= 80173c18 g F .text 00000