From ralf@linux-mips.org Fri Feb 1 09:32:09 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Feb 2008 09:32:12 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:60567 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20026587AbYBAJcJ (ORCPT ); Fri, 1 Feb 2008 09:32:09 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m119W976018222; Fri, 1 Feb 2008 09:32:09 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m119W9HY018221; Fri, 1 Feb 2008 09:32:09 GMT Date: Fri, 1 Feb 2008 09:32:09 +0000 From: Ralf Baechle To: Chris Friesen Cc: linux-mips@linux-mips.org Subject: Re: kexec on SMP mips64? Message-ID: <20080201093209.GA18195@linux-mips.org> References: <47A21286.3020009@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A21286.3020009@nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18163 X-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, Jan 31, 2008 at 12:25:10PM -0600, Chris Friesen wrote: > We're starting work on an embedded highly-available product using dual > Octeon cpus, and I'm looking into the possibility of using kexec/kdump as a > "flight recorder" to dump fault information to a persistant storage > location. > > I saw the patch adding initial support for kexec, but I was curious about > the current status. Is anyone using kexec for mips64 SMP systems? Is it > known to be broken? I'm just trying to get a feel for how much work might > be involved. I would classify the code as untested and suspect. Ralf From nschichan@freebox.fr Fri Feb 1 12:21:45 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Feb 2008 12:21:55 +0000 (GMT) Received: from bobafett.staff.proxad.net ([213.228.1.121]:57730 "EHLO bobafett.staff.proxad.net") by ftp.linux-mips.org with ESMTP id S20027576AbYBAMVp (ORCPT ); Fri, 1 Feb 2008 12:21:45 +0000 Received: from localhost (localhost [127.0.0.1]) by bobafett.staff.proxad.net (Postfix) with ESMTP id 12E832868E; Fri, 1 Feb 2008 13:21:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at staff.proxad.net Received: from bobafett.staff.proxad.net ([127.0.0.1]) by localhost (bobafett.staff.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wqPvvLOgxsTe; Fri, 1 Feb 2008 13:21:43 +0100 (CET) Received: from nschichan.priv.staff.proxad.net (nschichan.priv.staff.proxad.net [172.18.3.120]) by bobafett.staff.proxad.net (Postfix) with ESMTP id D7E67CE8C; Fri, 1 Feb 2008 13:21:43 +0100 (CET) From: Nicolas Schichan Organization: Freebox To: "Chris Friesen" Subject: Re: kexec on SMP mips64? Date: Fri, 1 Feb 2008 13:21:43 +0100 User-Agent: KMail/1.9.6 References: <47A21286.3020009@nortel.com> In-Reply-To: <47A21286.3020009@nortel.com> Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802011321.43399.nschichan@freebox.fr> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: nschichan@freebox.fr Precedence: bulk X-list: linux-mips On Thursday 31 January 2008 19:25:10 you wrote: Hi, > We're starting work on an embedded highly-available product using dual > Octeon cpus, and I'm looking into the possibility of using kexec/kdump > as a "flight recorder" to dump fault information to a persistant storage > location. > > I saw the patch adding initial support for kexec, but I was curious > about the current status. Is anyone using kexec for mips64 SMP systems? > Is it known to be broken? I'm just trying to get a feel for how much > work might be involved. The code used to work on the 32bit mips board I have access to, but as far as I know it has not been tested on 64bit. I have not tested it on SMP, but chances are that kexec on mips is broken here too. Regards, -- Nicolas Schichan From veerasena_b@yahoo.co.in Fri Feb 1 18:14:58 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 01 Feb 2008 18:15:07 +0000 (GMT) Received: from web8406.mail.in.yahoo.com ([202.43.219.154]:63377 "HELO web8406.mail.in.yahoo.com") by ftp.linux-mips.org with SMTP id S20030019AbYBASO6 convert rfc822-to-8bit (ORCPT ); Fri, 1 Feb 2008 18:14:58 +0000 Received: (qmail 7972 invoked by uid 60001); 1 Feb 2008 18:14:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=XXiF+t2gJVn66gjvUZ1OjONzOY2n8+66gUGFHpAuU5bdh6XgkCPE42Pzmyn+Rf9Lri0eULQgbzk+mcPIOjvt73HnsS04Q4ELhxXxoubGdKgrH7HEiF/aqdYl+tY+Z7gQavbBEVgOT+q4Mfjyt9qaKk3vDiILkI7smyeRIozfxhE=; X-YMail-OSG: o4AhGD4VM1m0ingH3EVKHgslw5dNrvUWpYDEaxUKXDO5ojWa98Bg_WGIc029TG0d5G8Xj0i7OUGpZFForF.2be46odapEYPA1xm7Ta2uMosV7TJrtfXpUprDL_g9Cw-- Received: from [199.239.167.162] by web8406.mail.in.yahoo.com via HTTP; Fri, 01 Feb 2008 23:44:47 IST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Fri, 1 Feb 2008 23:44:47 +0530 (IST) From: veerasena reddy To: "linux-kernel.org" , linux-mips MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Message-ID: <416607.4159.qm@web8406.mail.in.yahoo.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: 18165 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: veerasena_b@yahoo.co.in Precedence: bulk X-list: linux-mips Hi, I have a requirement where i need to execute a user process even when the kernel is utilizing 100% of CPU time. Actual scenario is as below: I have a device on my board. this device keeps generating regular (for every 2secs) messages for a user process. the user process has to poll on the device for any message is there to read and get the message from the device. once the user process reads the message it will be removed in device and uses for further/subsequent messages. I have a test case where i need to send so much traffic through my board such that the kernel will be utilizing 100% CPU time to process this data. At this time (when CPU is 100% utilized) the user space process is not getting scheduled even after a long duration (say 10 minutes to 45 minutes). Mean time the message buffer in the device is filled up and the device halts (aka controlled crash; the device firmware has been designed like this) as there is no more memory on the device. To avoid this scenario of device's message queue getting filled up because of the user space process not reading them, could you please anyone suggest some technique for getting my user space process scheduled even when there is very heavy traffic as described above. In simple, i can put my requirement like this: Is there any way i can get a user space process get scheduled in the above condition (kernel occupying 100% of CPU due to heavy traffic) Thanks in Advance. Regards, Veerasena. Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php From sam@ravnborg.org Sat Feb 2 18:01:42 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Feb 2008 18:01:50 +0000 (GMT) Received: from pasmtpb.tele.dk ([80.160.77.98]:28623 "EHLO pasmtpB.tele.dk") by ftp.linux-mips.org with ESMTP id S20029889AbYBBSBm (ORCPT ); Sat, 2 Feb 2008 18:01:42 +0000 Received: from ravnborg.org (0x535d98d8.vgnxx8.adsl-dhcp.tele.dk [83.93.152.216]) by pasmtpB.tele.dk (Postfix) with ESMTP id 622FCE3148A; Sat, 2 Feb 2008 19:01:40 +0100 (CET) Received: by ravnborg.org (Postfix, from userid 500) id E53FF580D2; Sat, 2 Feb 2008 19:01:44 +0100 (CET) Date: Sat, 2 Feb 2008 19:01:44 +0100 From: Sam Ravnborg To: Ralf Baechle Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Remove __INIT_REFOK and __INITDATA_REFOK Message-ID: <20080202180144.GA25399@uranus.ravnborg.org> References: <20080130141408.GA6116@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080130141408.GA6116@linux-mips.org> User-Agent: Mutt/1.4.2.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: 18166 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-mips On Wed, Jan 30, 2008 at 02:14:08PM +0000, Ralf Baechle wrote: > Commit 312b1485fb509c9bc32eda28ad29537896658cb8 made __INIT_REFOK expand > into .section .section ".ref.text", "ax". Since the assembler doesn't > tolerate stuttering in the source that broke all MIPS builds. > > Since with this change Sam downgraded __INIT_REFOK to just a backward > compat thing and there being only a single use in the MIPS arch code the > best solution is to delete both of __INIT_REFOK and __INITDATA_REFOK (which > was equally broken) being unused anyway these can be deleted. > > Signed-off-by: Ralf Baechle Thanks Ralf - applied. And sorry for the MIPS breakage. Sam From kumba@gentoo.org Sat Feb 2 22:08:42 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 02 Feb 2008 22:08:50 +0000 (GMT) Received: from qmta07.emeryville.ca.mail.comcast.net ([76.96.30.64]:58780 "EHLO QMTA07.emeryville.ca.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20031130AbYBBWIm (ORCPT ); Sat, 2 Feb 2008 22:08:42 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id kd4v1Y00F17UAYkA70X900; Sat, 02 Feb 2008 22:08:32 +0000 Received: from [192.168.1.4] ([69.140.18.238]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id km8Y1Y00E58Be2l8Z00000; Sat, 02 Feb 2008 22:08:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=NO_UjUUC5dBMtSl9ZVQA:9 a=pljzPeXGaX0wzBsF5R0A:7 a=WgWhcjP_WEcGfe5YBQNgxSYBjIcA:4 a=XF7b4UCPwd8A:10 Message-ID: <47A4E9DF.5070603@gentoo.org> Date: Sat, 02 Feb 2008 17:08:31 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thomas Bogendoerfer CC: Ralf Baechle , Florian Lohoff , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed References: <20080115112420.GA7347@alpha.franken.de> <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> In-Reply-To: <20080126143949.GA6579@alpha.franken.de> Content-Type: text/plain; charset=ISO-8859-1; 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: 18167 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Thomas Bogendoerfer wrote: > no suprise here. As Ralf already noted cache barrier is a restricted > instruction, it will always cause a illegal instruction when used > in user space. Nevertheless it looks like all IP28 are affected > by the simple exploit. Flo built glibc 2.7 with LLSC war workaround > and this avoids triggering the hang. Ah, didn't know the 'cache' instructions was kernel-mode only. Explains why it survived then :) How does one enable the LLSC war workaround in glibc? --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From sfr@canb.auug.org.au Sun Feb 3 01:29:06 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 01:29:16 +0000 (GMT) Received: from chilli.pcug.org.au ([203.10.76.44]:15562 "EHLO smtps.tip.net.au") by ftp.linux-mips.org with ESMTP id S20031848AbYBCB3G (ORCPT ); Sun, 3 Feb 2008 01:29:06 +0000 Received: from ash.ozlabs.ibm.com (ta-1-1.tip.net.au [203.11.71.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by smtps.tip.net.au (Postfix) with ESMTP id 9EE15368003; Sun, 3 Feb 2008 12:29:02 +1100 (EST) Date: Sun, 3 Feb 2008 12:29:06 +1100 From: Stephen Rothwell To: macro@linux-mips.org Cc: linux-mips@linux-mips.org Subject: [PATCH] [TRIVIAL] sm1250: constify three stings. Message-Id: <20080203122906.eefb3ac4.sfr@canb.auug.org.au> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; i486-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: 18168 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sfr@canb.auug.org.au Precedence: bulk X-list: linux-mips This was noticed because sbmac_string is passed to platform_device_register_simple() which now takes a "const char *" as it first argument. Signed-off-by: Stephen Rothwell --- drivers/net/sb1250-mac.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) This has not even been compiled, but is fairly trivial. diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index 7b53d65..d83471a 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -350,10 +350,10 @@ static int sbmac_mii_write(struct mii_bus *bus, int phyaddr, int regidx, * Globals ********************************************************************* */ -static char sbmac_string[] = "sb1250-mac"; -static char sbmac_pretty[] = "SB1250 MAC"; +static const char sbmac_string[] = "sb1250-mac"; +static const char sbmac_pretty[] = "SB1250 MAC"; -static char sbmac_mdio_string[] = "sb1250-mac-mdio"; +static const char sbmac_mdio_string[] = "sb1250-mac-mdio"; /********************************************************************** -- 1.5.3.8 -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ From ralf@linux-mips.org Sun Feb 3 02:16:55 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 02:16:57 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:15076 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20031907AbYBCCQz (ORCPT ); Sun, 3 Feb 2008 02:16:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m132GnPJ016019; Sun, 3 Feb 2008 03:16:50 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m132GmRD016018; Sun, 3 Feb 2008 03:16:48 +0100 Date: Sun, 3 Feb 2008 03:16:48 +0100 From: Ralf Baechle To: Kumba Cc: Thomas Bogendoerfer , Florian Lohoff , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080203021647.GA15910@linux-mips.org> References: <20080115112420.GA7347@alpha.franken.de> <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A4E9DF.5070603@gentoo.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18169 X-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 Sat, Feb 02, 2008 at 05:08:31PM -0500, Kumba wrote: > > Thomas Bogendoerfer wrote: >> no suprise here. As Ralf already noted cache barrier is a restricted >> instruction, it will always cause a illegal instruction when used >> in user space. Nevertheless it looks like all IP28 are affected >> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround >> and this avoids triggering the hang. > > Ah, didn't know the 'cache' instructions was kernel-mode only. Explains > why it survived then :) > > How does one enable the LLSC war workaround in glibc? By modifying the code ;-) Ralf From flo@rfc822.org Sun Feb 3 06:30:25 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 06:30:34 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:17619 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20025424AbYBCGaZ (ORCPT ); Sun, 3 Feb 2008 06:30:25 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id 7B30B32CFF; Sun, 3 Feb 2008 07:27:11 +0100 (CET) Date: Sun, 3 Feb 2008 07:27:11 +0100 From: Florian Lohoff To: Ralf Baechle Cc: Kumba , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080203062711.GA28394@paradigm.rfc822.org> References: <20080115112420.GA7347@alpha.franken.de> <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20080203021647.GA15910@linux-mips.org> Organization: rfc822 - pure communication X-SpiderMe: mh-200802030725@listme.rfc822.org User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18170 X-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 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2008 at 03:16:48AM +0100, Ralf Baechle wrote: > On Sat, Feb 02, 2008 at 05:08:31PM -0500, Kumba wrote: >=20 > >=20 > > Thomas Bogendoerfer wrote: > >> no suprise here. As Ralf already noted cache barrier is a restricted > >> instruction, it will always cause a illegal instruction when used > >> in user space. Nevertheless it looks like all IP28 are affected > >> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround > >> and this avoids triggering the hang. > > > > Ah, didn't know the 'cache' instructions was kernel-mode only. Explain= s=20 > > why it survived then :) > > > > How does one enable the LLSC war workaround in glibc? >=20 > By modifying the code ;-) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D462112 Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little=20 security shall soon have neither - Benjamin Franklin --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHpV6/Uaz2rXW+gJcRAjkdAKCEvqw8qVHxGHiWFLK81Ga/y/lJ3ACfe6UN Ib3l6DMhVfc4kEk7IrOVIsA= =O6pE -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From giuseppe@eppesuigoccas.homedns.org Sun Feb 3 14:59:20 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 14:59:29 +0000 (GMT) Received: from host194-211-dynamic.20-79-r.retail.telecomitalia.it ([79.20.211.194]:25279 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20022951AbYBCO7U (ORCPT ); Sun, 3 Feb 2008 14:59:20 +0000 Received: from [192.168.1.33] (helo=[192.168.1.2]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JLt8O-0000Vi-Bp for linux-mips@linux-mips.org; Mon, 04 Feb 2008 05:40:46 +0100 Subject: new type of crash report? From: Giuseppe Sacco To: linux-mips@linux-mips.org Content-Type: text/plain Date: Sun, 03 Feb 2008 15:56:18 +0100 Message-Id: <1202050578.7035.11.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 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: 18171 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi all, with latest kernel I started getting problem like this one. How may I understand what part of the kernel produced the problem? Is it possible to get a stack trace from this report? Thank you very much, Giuseppe Got dbe at 0x2ac2bffc Cpu 0 $ 0 : 0000000000000000 0000000000000014 0000000000000000 000000002acf1758 $ 4 : 0000000000000000 00000000000073b0 0000000000000000 0000000000000000 $ 8 : 000000007fd06a64 0000000000000000 47a5ca5900000000 0000100000000000 $12 : 0000000000000000 0000000047a5ca59 0000000047a5ca59 0000000000000000 $16 : 0000000000000000 000000002acef588 000000002accbd68 0000000000000000 $20 : 0000000000546408 0000000000545e68 0000000000000000 0000000000530bb8 $24 : 0000000000000000 000000002abf8e58 $28 : 000000002acf7960 000000007fd069e0 000000007fd069f0 000000002ac2bfdc Hi : 0000000000000000 Lo : 0000000000000000 epc : 000000002ac2bffc 0x2ac2bffc Not tainted ra : 000000002ac2bfdc 0x2ac2bfdc Status: 8001fcf3 KX SX UX USER EXL IE Cause : 0000041c PrId : 00002321 (R5000) Index: 1 pgmask=4kb va=c00000ffc0126000 asid=6b [pa=00053946000 c=3 d=1 v=1 g=1] [pa=000538da000 c=3 d=1 v=1 g=1] Index: 2 pgmask=4kb va=c00000ffc003a000 asid=6b [pa=00054e25000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0 g=1] Index: 4 pgmask=4kb va=c00000ffc00d8000 asid=6b [pa=00000000000 c=0 d=0 v=0 g=1] [pa=00053921000 c=3 d=1 v=1 g=1] Index: 7 pgmask=4kb va=c00000ffc0042000 asid=6b [pa=00054cf7000 c=3 d=1 v=1 g=1] [pa=00054eaa000 c=3 d=1 v=1 g=1] Index: 8 pgmask=4kb va=c00000ffc012c000 asid=6b [pa=000539e5000 c=3 d=1 v=1 g=1] [pa=00000000000 c=0 d=0 v=0 g=1] Index: 10 pgmask=4kb va=c00000ffc00fa000 asid=6b [pa=000539ae000 c=3 d=1 v=1 g=1] [pa=000539af000 c=3 d=1 v=1 g=1] [...] From markus.gothe@27m.se Sun Feb 3 15:52:44 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 15:52:53 +0000 (GMT) Received: from mail.lysator.liu.se ([130.236.254.3]:16304 "EHLO mail.lysator.liu.se") by ftp.linux-mips.org with ESMTP id S20025543AbYBCPwo (ORCPT ); Sun, 3 Feb 2008 15:52:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 044E1200A23C; Sun, 3 Feb 2008 16:52:41 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16989-01-91; Sun, 3 Feb 2008 16:52:40 +0100 (CET) Received: from [192.168.0.2] (cust.fiber-lan.vnet.lk.85.194.49.173.stunet.se [85.194.49.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTP id 16BD4200A219; Sun, 3 Feb 2008 16:52:40 +0100 (CET) Cc: linux-mips@linux-mips.org Message-Id: <5BFC57F9-7E81-4667-9D15-72F5F20FA4DD@27m.se> From: Markus Gothe To: Giuseppe Sacco In-Reply-To: <1202050578.7035.11.camel@scarafaggio> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16-408453187" Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [SPAM] new type of crash report? Date: Sun, 3 Feb 2008 16:52:32 +0100 References: <1202050578.7035.11.camel@scarafaggio> X-Pgp-Agent: GPGMail d51 (Leopard) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.915) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18172 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: markus.gothe@27m.se Precedence: bulk X-list: linux-mips This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16-408453187 Content-Type: multipart/alternative; boundary=Apple-Mail-15-408453153 --Apple-Mail-15-408453153 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable You can always start with running run gdb at the read address (ra: =20 0x2ac2bfdc), I'd also try listing 0x2ac2bffc. //Markus On 3 Feb 2008, at 15:56, Giuseppe Sacco wrote: > Hi all, > with latest kernel I started getting problem like this one. How may I > understand what part of the kernel produced the problem? Is it =20 > possible > to get a stack trace from this report? > > Thank you very much, > Giuseppe > > Got dbe at 0x2ac2bffc > Cpu 0 > $ 0 : 0000000000000000 0000000000000014 0000000000000000 =20 > 000000002acf1758 > $ 4 : 0000000000000000 00000000000073b0 0000000000000000 =20 > 0000000000000000 > $ 8 : 000000007fd06a64 0000000000000000 47a5ca5900000000 =20 > 0000100000000000 > $12 : 0000000000000000 0000000047a5ca59 0000000047a5ca59 =20 > 0000000000000000 > $16 : 0000000000000000 000000002acef588 000000002accbd68 =20 > 0000000000000000 > $20 : 0000000000546408 0000000000545e68 0000000000000000 =20 > 0000000000530bb8 > $24 : 0000000000000000 000000002abf8e58 > $28 : 000000002acf7960 000000007fd069e0 000000007fd069f0 =20 > 000000002ac2bfdc > Hi : 0000000000000000 > Lo : 0000000000000000 > epc : 000000002ac2bffc 0x2ac2bffc Not tainted > ra : 000000002ac2bfdc 0x2ac2bfdc > Status: 8001fcf3 KX SX UX USER EXL IE > Cause : 0000041c > PrId : 00002321 (R5000) > Index: 1 pgmask=3D4kb va=3Dc00000ffc0126000 asid=3D6b > [pa=3D00053946000 c=3D3 d=3D1 v=3D1 g=3D1] [pa=3D000538da000 = c=3D3 d=3D1 v=3D1 =20 > g=3D1] > Index: 2 pgmask=3D4kb va=3Dc00000ffc003a000 asid=3D6b > [pa=3D00054e25000 c=3D3 d=3D1 v=3D1 g=3D1] [pa=3D00000000000 = c=3D0 d=3D0 v=3D0 =20 > g=3D1] > Index: 4 pgmask=3D4kb va=3Dc00000ffc00d8000 asid=3D6b > [pa=3D00000000000 c=3D0 d=3D0 v=3D0 g=3D1] [pa=3D00053921000 = c=3D3 d=3D1 v=3D1 =20 > g=3D1] > Index: 7 pgmask=3D4kb va=3Dc00000ffc0042000 asid=3D6b > [pa=3D00054cf7000 c=3D3 d=3D1 v=3D1 g=3D1] [pa=3D00054eaa000 = c=3D3 d=3D1 v=3D1 =20 > g=3D1] > Index: 8 pgmask=3D4kb va=3Dc00000ffc012c000 asid=3D6b > [pa=3D000539e5000 c=3D3 d=3D1 v=3D1 g=3D1] [pa=3D00000000000 = c=3D0 d=3D0 v=3D0 =20 > g=3D1] > Index: 10 pgmask=3D4kb va=3Dc00000ffc00fa000 asid=3D6b > [pa=3D000539ae000 c=3D3 d=3D1 v=3D1 g=3D1] [pa=3D000539af000 = c=3D3 d=3D1 v=3D1 =20 > g=3D1] > [...] > > _______________________________________ Mr Markus Gothe Software Engineer Phone: +46 (0)13 21 81 20 (ext. 1046) Fax: +46 (0)13 21 21 15 Mobile: +46 (0)70 348 44 35 Diskettgatan 11, SE-583 35 Link=F6ping, Sweden www.27m.com --Apple-Mail-15-408453153 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You can always start with = running run gdb at the read address (ra: 0x2ac2bfdc), I'd also try = listing 0x2ac2bffc.

//Markus

On 3 Feb 2008, at 15:56, = Giuseppe Sacco wrote:

Hi = all,
with latest kernel I started getting problem like this one. How = may I
understand what part of the kernel produced the problem? Is it = possible
to get a stack trace from this report?

Thank you very = much,
Giuseppe

Got dbe at 0x2ac2bffc
Cpu 0
$ 0 =   : 0000000000000000 0000000000000014 0000000000000000 = 000000002acf1758
$ 4   : 0000000000000000 00000000000073b0 = 0000000000000000 0000000000000000
$ 8   : 000000007fd06a64 = 0000000000000000 47a5ca5900000000 0000100000000000
$12   : = 0000000000000000 0000000047a5ca59 0000000047a5ca59 = 0000000000000000
$16   : 0000000000000000 000000002acef588 = 000000002accbd68 0000000000000000
$20   : 0000000000546408 = 0000000000545e68 0000000000000000 0000000000530bb8
$24   : = 0000000000000000 000000002abf8e58 =             &n= bsp;           &nbs= p;        
$28   : = 000000002acf7960 000000007fd069e0 000000007fd069f0 = 000000002ac2bfdc
Hi    : 0000000000000000
Lo =    : 0000000000000000
epc   : = 000000002ac2bffc 0x2ac2bffc     Not tainted
ra =    : 000000002ac2bfdc 0x2ac2bfdc
Status: 8001fcf3 =    KX SX UX USER EXL IE
Cause : 0000041c
PrId =  : 00002321 (R5000)
Index:  1 pgmask=3D4kb = va=3Dc00000ffc0126000 asid=3D6b
=        [pa=3D00053946000 c=3D3 d=3D1 = v=3D1 g=3D1] [pa=3D000538da000 c=3D3 d=3D1 v=3D1 g=3D1]
Index: =  2 pgmask=3D4kb va=3Dc00000ffc003a000 asid=3D6b
=        [pa=3D00054e25000 c=3D3 d=3D1 = v=3D1 g=3D1] [pa=3D00000000000 c=3D0 d=3D0 v=3D0 g=3D1]
Index: =  4 pgmask=3D4kb va=3Dc00000ffc00d8000 asid=3D6b
=        [pa=3D00000000000 c=3D0 d=3D0 = v=3D0 g=3D1] [pa=3D00053921000 c=3D3 d=3D1 v=3D1 g=3D1]
Index: =  7 pgmask=3D4kb va=3Dc00000ffc0042000 asid=3D6b
=        [pa=3D00054cf7000 c=3D3 d=3D1 = v=3D1 g=3D1] [pa=3D00054eaa000 c=3D3 d=3D1 v=3D1 g=3D1]
Index: =  8 pgmask=3D4kb va=3Dc00000ffc012c000 asid=3D6b
=        [pa=3D000539e5000 c=3D3 d=3D1 = v=3D1 g=3D1] [pa=3D00000000000 c=3D0 d=3D0 v=3D0 g=3D1]
Index: 10 = pgmask=3D4kb va=3Dc00000ffc00fa000 asid=3D6b
=        [pa=3D000539ae000 c=3D3 d=3D1 = v=3D1 g=3D1] [pa=3D000539af000 c=3D3 d=3D1 v=3D1 = g=3D1]
[...]




Mr Markus = Gothe
Software Engineer

Phone: = +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 = (0)13 21 21 15
Mobile: +46 (0)70 348 44 = 35
Diskettgatan 11, SE-583 35 Link=F6ping, = Sweden



= --Apple-Mail-15-408453153-- --Apple-Mail-16-408453187 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkel40AACgkQ6I0XmJx2NrwvlACeJNf96D4XQAbbKeYLZ8BdW58f DlYAn2lgdzHeKtW6rjYDRr+0y2bF2hFl =gE5t -----END PGP SIGNATURE----- --Apple-Mail-16-408453187-- From giuseppe@eppesuigoccas.homedns.org Sun Feb 3 16:00:25 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 16:00:34 +0000 (GMT) Received: from host194-211-dynamic.20-79-r.retail.telecomitalia.it ([79.20.211.194]:57013 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20025779AbYBCQAZ (ORCPT ); Sun, 3 Feb 2008 16:00:25 +0000 Received: from router-wag54gp2 ([192.168.1.33] helo=[192.168.1.2]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JLhGS-0004Hc-J9 for linux-mips@linux-mips.org; Sun, 03 Feb 2008 17:00:18 +0100 Subject: Re: new type of crash report? From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <5BFC57F9-7E81-4667-9D15-72F5F20FA4DD@27m.se> References: <1202050578.7035.11.camel@scarafaggio> <5BFC57F9-7E81-4667-9D15-72F5F20FA4DD@27m.se> Content-Type: text/plain Date: Sun, 03 Feb 2008 17:01:05 +0100 Message-Id: <1202054465.7035.20.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 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: 18173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Markus, Il giorno dom, 03/02/2008 alle 16.52 +0100, Markus Gothe ha scritto: > You can always start with running run gdb at the read address > (ra: 0x2ac2bfdc), I'd also try listing 0x2ac2bffc. [...] Thanks for your reply. I will try to understand how to use gdb on this context. (Any URI would be really appreciated.) Anyway I now understood that a dbe is a data bus error, so probably this is an error on the physical address, i.e. a kernel problem related to the mapping between vertical and physical addresses. Is this correct? Thanks, Giuseppe From kevink@mips.com Sun Feb 3 17:11:29 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 17:11:37 +0000 (GMT) Received: from dns0.mips.com ([63.167.95.198]:2487 "EHLO dns0.mips.com") by ftp.linux-mips.org with ESMTP id S20026652AbYBCRL3 (ORCPT ); Sun, 3 Feb 2008 17:11:29 +0000 Received: from mercury.mips.com (mercury [192.168.64.101]) by dns0.mips.com (8.12.11/8.12.11) with ESMTP id m13HAQpa026668; Sun, 3 Feb 2008 09:10:27 -0800 (PST) Received: from [127.0.0.1] (grendel [192.168.236.16]) by mercury.mips.com (8.13.5/8.13.5) with ESMTP id m13HB6BW001490; Sun, 3 Feb 2008 09:11:07 -0800 (PST) Message-ID: <47A5F580.8080300@mips.com> Date: Sun, 03 Feb 2008 18:10:24 +0100 From: "Kevin D. Kissell" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Giuseppe Sacco CC: linux-mips@linux-mips.org Subject: Re: new type of crash report? References: <1202050578.7035.11.camel@scarafaggio> <5BFC57F9-7E81-4667-9D15-72F5F20FA4DD@27m.se> <1202054465.7035.20.camel@scarafaggio> In-Reply-To: <1202054465.7035.20.camel@scarafaggio> Content-Type: text/html; charset=ISO-8859-1 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: 18174 X-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 Giuseppe Sacco wrote: 
Hi Markus,

Il giorno dom, 03/02/2008 alle 16.52 +0100, Markus Gothe ha scritto:
  
You can always start with running run gdb at the read address
(ra: 0x2ac2bfdc), I'd also try listing 0x2ac2bffc.
    
[...]

Thanks for your reply. I will try to understand how to use gdb on this
context. (Any URI would be really appreciated.)
Anyway I now understood that a dbe is a data bus error, so probably this
is an error on the physical address, i.e. a kernel problem related to
the mapping between vertical and physical addresses. Is this correct?
That's correct.  You didn't say what processor you were running on, so it's hard to be more specific - there are some which have a bus error input pin that can be asserted by the system for other reasons - but in general it means that there's a data reference at 0x2ac2bffc whose valid translation goes to a bad address.  Generally, that address range is where shared libraries are mapped, so to find the instruction you want to run the program that caused the crash under gdb, set a breakpoint very early (e.g. main), run to the breakpoint, and disassemble the virtual address.  I find it interesting that the register value reported for register $10 is a reasonable data address shifted up by 32 bits.  It's possible that code would have a real reason to do that, but I can't help wonder if that isn't part of the problem. We may be looking at a 2-level bug here:  User(?) code screwing up a base register used for a load or store, and the OS failing to handle the upper reaches of the 64-bit address space correctly.

          Regards,

          Kevin K.
From giuseppe@eppesuigoccas.homedns.org Sun Feb 3 22:58:49 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 03 Feb 2008 22:58:57 +0000 (GMT) Received: from host194-211-dynamic.20-79-r.retail.telecomitalia.it ([79.20.211.194]:10159 "EHLO eppesuigoccas.homedns.org") by ftp.linux-mips.org with ESMTP id S20032551AbYBCW6t (ORCPT ); Sun, 3 Feb 2008 22:58:49 +0000 Received: from router-wag54gp2 ([192.168.1.33] helo=[192.168.1.2]) by eppesuigoccas.homedns.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JLnnM-00019r-3p for linux-mips@linux-mips.org; Sun, 03 Feb 2008 23:58:42 +0100 Subject: Re: new type of crash report? From: Giuseppe Sacco To: linux-mips@linux-mips.org In-Reply-To: <47A5F580.8080300@mips.com> References: <1202050578.7035.11.camel@scarafaggio> <5BFC57F9-7E81-4667-9D15-72F5F20FA4DD@27m.se> <1202054465.7035.20.camel@scarafaggio> <47A5F580.8080300@mips.com> Content-Type: text/plain Date: Sun, 03 Feb 2008 23:59:34 +0100 Message-Id: <1202079574.18109.6.camel@scarafaggio> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 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: 18175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giuseppe@eppesuigoccas.homedns.org Precedence: bulk X-list: linux-mips Hi Kevin, Il giorno dom, 03/02/2008 alle 18.10 +0100, Kevin D. Kissell ha scritto: > Giuseppe Sacco wrote: [...] > > Thanks for your reply. I will try to understand how to use gdb on this > > context. (Any URI would be really appreciated.) > > Anyway I now understood that a dbe is a data bus error, so probably this > > is an error on the physical address, i.e. a kernel problem related to > > the mapping between vertical and physical addresses. Is this correct? > > > That's correct. You didn't say what processor you were running on, so > it's hard to be more specific - there are some which have a bus error > input pin that can be asserted by the system for other reasons - but > in general it means that there's a data reference at 0x2ac2bffc whose > valid translation goes to a bad address. Generally, that address > range is where shared libraries are mapped, so to find the instruction > you want to run the program that caused the crash under gdb, set a > breakpoint very early (e.g. main), run to the breakpoint, and > disassemble the virtual address. I find it interesting that the > register value reported for register $10 is a reasonable data address > shifted up by 32 bits. It's possible that code would have a real > reason to do that, but I can't help wonder if that isn't part of the > problem. We may be looking at a 2-level bug here: User(?) code > screwing up a base register used for a load or store, and the OS > failing to handle the upper reaches of the 64-bit address space > correctly. The complete bug report is available at http://bugs.debian.org/463808. The cpu is an "R5000 V2.1 FPU V1.0". The system is Debian stable, running mainly with courier-imap-ssl and exim4 (often in TLS mode). I cannot find a single program to debug, but I know for sure that if I leave the machine with those two daemons, it will hung in about 30 minutes. If I run a kernel build (using gcc-4.2 from dDebian testing), then the machine hungs in a few minutes. One time out of three gcc get a segmentation fault, other two times the machine stop. Thanks for your help, Giuseppe From imp@bsdimp.com Mon Feb 4 01:18:03 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Feb 2008 01:18:12 +0000 (GMT) Received: from bsdimp.com ([199.45.160.85]:21239 "EHLO harmony.bsdimp.com") by ftp.linux-mips.org with ESMTP id S20032737AbYBDBSD (ORCPT ); Mon, 4 Feb 2008 01:18:03 +0000 Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m141ChhK081133; Sun, 3 Feb 2008 18:12:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 03 Feb 2008 18:14:36 -0700 (MST) Message-Id: <20080203.181436.-1947424537.imp@bsdimp.com> To: gregor.waltz@raritan.com Cc: linux-mips@linux-mips.org Subject: Re: Toshiba JMR 3927 working setup? From: "M. Warner Losh" In-Reply-To: <47840D53.50009@raritan.com> References: <477E6296.7090605@raritan.com> <20080105144535.GA12824@linux-mips.org> <47840D53.50009@raritan.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / 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: 18176 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: imp@bsdimp.com Precedence: bulk X-list: linux-mips In message: <47840D53.50009@raritan.com> Gregor Waltz writes: : Ralf Baechle wrote: : > You may want to switch to a recent binutils like 2.18 and gcc 4.2.2. : : Ralf, are you or anybody else using that combination for mips? Speaking of toolchains, are there known problems on mips with gcc 4.2.1? Warner From rkota@broadcom.com Mon Feb 4 05:50:51 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 04 Feb 2008 05:50:59 +0000 (GMT) Received: from mms2.broadcom.com ([216.31.210.18]:3599 "EHLO mms2.broadcom.com") by ftp.linux-mips.org with ESMTP id S20021627AbYBDFuv convert rfc822-to-8bit (ORCPT ); Mon, 4 Feb 2008 05:50:51 +0000 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Sun, 03 Feb 2008 21:50:09 -0800 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 7376896F; Sun, 3 Feb 2008 21:41:25 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E5EB0953; Sun, 3 Feb 2008 21:41:24 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id GJI31601; Sun, 3 Feb 2008 21:41:24 -0800 (PST) Received: from NT-SJCA-0752.brcm.ad.broadcom.com (nt-sjca-0752 [10.16.192.222]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 8567D20502; Sun, 3 Feb 2008 21:41:24 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: (no subject) Date: Sun, 3 Feb 2008 21:41:23 -0800 Message-ID: In-Reply-To: <416607.4159.qm@web8406.mail.in.yahoo.com> Thread-Topic: (no subject) Thread-Index: Achk/nZNV5d8tkTXQPm2kxAavxWLGwB8ea2w References: <416607.4159.qm@web8406.mail.in.yahoo.com> From: "Ramgopal Kota" To: "veerasena reddy" , "linux-kernel.org" , "linux-mips" X-WSS-ID: 6BB8781B3B01705449-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18177 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: rkota@broadcom.com Precedence: bulk X-list: linux-mips Hi, You can set a real-time priority to the user-process. Ramgopal Kota -----Original Message----- From: linux-mips-bounce@linux-mips.org [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of veerasena reddy Sent: Friday, February 01, 2008 11:45 PM To: linux-kernel.org; linux-mips Subject: (no subject) Hi, I have a requirement where i need to execute a user process even when the kernel is utilizing 100% of CPU time. Actual scenario is as below: I have a device on my board. this device keeps generating regular (for every 2secs) messages for a user process. the user process has to poll on the device for any message is there to read and get the message from the device. once the user process reads the message it will be removed in device and uses for further/subsequent messages. I have a test case where i need to send so much traffic through my board such that the kernel will be utilizing 100% CPU time to process this data. At this time (when CPU is 100% utilized) the user space process is not getting scheduled even after a long duration (say 10 minutes to 45 minutes). Mean time the message buffer in the device is filled up and the device halts (aka controlled crash; the device firmware has been designed like this) as there is no more memory on the device. To avoid this scenario of device's message queue getting filled up because of the user space process not reading them, could you please anyone suggest some technique for getting my user space process scheduled even when there is very heavy traffic as described above. In simple, i can put my requirement like this: Is there any way i can get a user space process get scheduled in the above condition (kernel occupying 100% of CPU due to heavy traffic) Thanks in Advance. Regards, Veerasena. Now you can chat without downloading messenger. Go to http://in.messenger.yahoo.com/webmessengerpromo.php From kumba@gentoo.org Tue Feb 5 07:11:17 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Feb 2008 07:11:25 +0000 (GMT) Received: from qmta01.emeryville.ca.mail.comcast.net ([76.96.30.16]:58805 "EHLO QMTA01.emeryville.ca.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20023976AbYBEHLR (ORCPT ); Tue, 5 Feb 2008 07:11:17 +0000 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id lVWT1Y00216AWCUA10d300; Tue, 05 Feb 2008 07:11:02 +0000 Received: from [192.168.1.4] ([69.140.18.238]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id ljB61Y00258Be2l8S00000; Tue, 05 Feb 2008 07:11:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=xNf9USuDAAAA:8 a=yzZtjsIgX-HcIXBt9YEA:9 a=GvoO7B1UHpgB1oHFA9wA:7 a=Tcex07jpsPutSQbRQqsc4_egSxAA:4 a=GZmr5YlNZX8A:10 Message-ID: <47A80C0A.4040106@gentoo.org> Date: Tue, 05 Feb 2008 02:11:06 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Florian Lohoff CC: Ralf Baechle , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed References: <20080115112420.GA7347@alpha.franken.de> <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> In-Reply-To: <20080203062711.GA28394@paradigm.rfc822.org> Content-Type: text/plain; charset=ISO-8859-1; 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: 18178 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Florian Lohoff wrote: > On Sun, Feb 03, 2008 at 03:16:48AM +0100, Ralf Baechle wrote: >> On Sat, Feb 02, 2008 at 05:08:31PM -0500, Kumba wrote: >> >>> Thomas Bogendoerfer wrote: >>>> no suprise here. As Ralf already noted cache barrier is a restricted >>>> instruction, it will always cause a illegal instruction when used >>>> in user space. Nevertheless it looks like all IP28 are affected >>>> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround >>>> and this avoids triggering the hang. >>> Ah, didn't know the 'cache' instructions was kernel-mode only. Explains >>> why it survived then :) >>> >>> How does one enable the LLSC war workaround in glibc? >> By modifying the code ;-) > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112 > > Flo Interesting. Is there a reason the kernel uses an #ifdef to choose between 'bezq' and 'bezql' that's not needed in glibc itself? Or does glibc itself lack a mechanism to detect CPU types to single out this specific change? And any idea if uClibc will need similar mods? Thanks!, --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From ths@networkno.de Tue Feb 5 12:22:18 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Feb 2008 12:22:28 +0000 (GMT) Received: from relay01.mx.bawue.net ([193.7.176.67]:48562 "EHLO relay01.mx.bawue.net") by ftp.linux-mips.org with ESMTP id S20026310AbYBEMWS (ORCPT ); Tue, 5 Feb 2008 12:22:18 +0000 Received: from lagash (intrt.mips-uk.com [194.74.144.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by relay01.mx.bawue.net (Postfix) with ESMTP id F41DF48916; Tue, 5 Feb 2008 13:22:12 +0100 (CET) Received: from ths by lagash with local (Exim 4.69) (envelope-from ) id 1JMMoV-0001sZ-Rj; Tue, 05 Feb 2008 12:22:11 +0000 Date: Tue, 5 Feb 2008 12:22:11 +0000 From: Thiemo Seufer To: Kumba Cc: Florian Lohoff , Ralf Baechle , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080205122211.GA24136@networkno.de> References: <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A80C0A.4040106@gentoo.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ths@networkno.de Precedence: bulk X-list: linux-mips Kumba wrote: > Florian Lohoff wrote: >> On Sun, Feb 03, 2008 at 03:16:48AM +0100, Ralf Baechle wrote: >>> On Sat, Feb 02, 2008 at 05:08:31PM -0500, Kumba wrote: >>> >>>> Thomas Bogendoerfer wrote: >>>>> no suprise here. As Ralf already noted cache barrier is a restricted >>>>> instruction, it will always cause a illegal instruction when used >>>>> in user space. Nevertheless it looks like all IP28 are affected >>>>> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround >>>>> and this avoids triggering the hang. >>>> Ah, didn't know the 'cache' instructions was kernel-mode only. >>>> Explains why it survived then :) >>>> >>>> How does one enable the LLSC war workaround in glibc? >>> By modifying the code ;-) >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112 >> >> Flo > > Interesting. Is there a reason the kernel uses an #ifdef to choose > between 'bezq' and 'bezql' that's not needed in glibc itself? Or does > glibc itself lack a mechanism to detect CPU types to single out this > specific change? glibc for mips has currently no such mechanism. Note that this change breaks MIPS I CPUs, so it is not generally applicable. > And any idea if uClibc will need similar mods? It needs a similiar change to support R10000 v2.5. Thiemo From ralf@linux-mips.org Tue Feb 5 15:23:22 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 05 Feb 2008 15:23:24 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:18650 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20028989AbYBEPXW (ORCPT ); Tue, 5 Feb 2008 15:23:22 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m15FN6TW019277; Tue, 5 Feb 2008 16:23:06 +0100 Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m15FN4mM019276; Tue, 5 Feb 2008 16:23:04 +0100 Date: Tue, 5 Feb 2008 16:23:04 +0100 From: Ralf Baechle To: Kumba Cc: Florian Lohoff , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080205152304.GA18157@linux-mips.org> References: <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A80C0A.4040106@gentoo.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18180 X-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, Feb 05, 2008 at 02:11:06AM -0500, Kumba wrote: >>>> Thomas Bogendoerfer wrote: >>>>> no suprise here. As Ralf already noted cache barrier is a restricted >>>>> instruction, it will always cause a illegal instruction when used >>>>> in user space. Nevertheless it looks like all IP28 are affected >>>>> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround >>>>> and this avoids triggering the hang. >>>> Ah, didn't know the 'cache' instructions was kernel-mode only. Explains >>>> why it survived then :) >>>> >>>> How does one enable the LLSC war workaround in glibc? >>> By modifying the code ;-) >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112 >> >> Flo > > Interesting. Is there a reason the kernel uses an #ifdef to choose between > 'bezq' and 'bezql' that's not needed in glibc itself? Or does glibc itself > lack a mechanism to detect CPU types to single out this specific change? > > And any idea if uClibc will need similar mods? The kernel has rather detailed knowledge about which workarounds are required for what platform and is optimized based on this knowledge. Userspace is different. The basic promise is that userspace will run on any platform above certain minimum specs. That is something like MIPS II code is expected to run find on MIPS III or MIPS32 r1 or MIPS64 r2 hardware for example. This promise includes even workarounds as far as practicable and occasionally requires doing things that are somewhat suboptimal for performance or coding style. But it keeps things deterministic for users. Ralf From kumba@gentoo.org Wed Feb 6 03:26:01 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Feb 2008 03:26:09 +0000 (GMT) Received: from qmta04.emeryville.ca.mail.comcast.net ([76.96.30.40]:1713 "EHLO QMTA04.emeryville.ca.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20034991AbYBFD0B (ORCPT ); Wed, 6 Feb 2008 03:26:01 +0000 Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id m22W1Y0031HpZEsA406j00; Wed, 06 Feb 2008 03:25:45 +0000 Received: from [192.168.1.4] ([69.140.18.238]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id m3Rq1Y00Z58Be2l8a00000; Wed, 06 Feb 2008 03:25:53 +0000 X-Authority-Analysis: v=1.0 c=1 a=mHkp4NPBQMTj-ToxHy0A:9 a=C1SEP9C3daKCn9w2vRhkrsVy384A:4 a=XF7b4UCPwd8A:10 Message-ID: <47A928BF.5000302@gentoo.org> Date: Tue, 05 Feb 2008 22:25:51 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thiemo Seufer CC: Florian Lohoff , Ralf Baechle , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed References: <20080115112719.GB7920@paradigm.rfc822.org> <20080117004054.GA12051@alpha.franken.de> <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> <20080205122211.GA24136@networkno.de> In-Reply-To: <20080205122211.GA24136@networkno.de> Content-Type: text/plain; charset=ISO-8859-1; 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: 18181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Thiemo Seufer wrote: > Kumba wrote: > > glibc for mips has currently no such mechanism. Note that this change > breaks MIPS I CPUs, so it is not generally applicable. I'll have to ask one of our devs who knows autoconf really well. I figure that's probably a good place to catch something like this. Have configure check /proc/cpuinfo and look for "R10000", and if it finds it, mod CFLAGS to pass -DR10k_LLSC_WAR, and #ifdef on that in atomic.h. Sound plausible? >> And any idea if uClibc will need similar mods? > > It needs a similiar change to support R10000 v2.5. Thought it would. I'll keep this in mind if we ever get that running again. Cheers, --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From flo@rfc822.org Wed Feb 6 08:59:44 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Feb 2008 08:59:53 +0000 (GMT) Received: from hydra.gt.owl.de ([195.71.99.218]:47756 "EHLO hydra.gt.owl.de") by ftp.linux-mips.org with ESMTP id S20025449AbYBFI7o (ORCPT ); Wed, 6 Feb 2008 08:59:44 +0000 Received: by hydra.gt.owl.de (Postfix, from userid 1000) id 5B49732CE4; Wed, 6 Feb 2008 09:56:10 +0100 (CET) Date: Wed, 6 Feb 2008 09:56:10 +0100 From: Florian Lohoff To: Kumba Cc: Thiemo Seufer , Ralf Baechle , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080206085610.GA20751@paradigm.rfc822.org> References: <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> <20080205122211.GA24136@networkno.de> <47A928BF.5000302@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <47A928BF.5000302@gentoo.org> Organization: rfc822 - pure communication X-SpiderMe: mh-200802060854@listme.rfc822.org User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18182 X-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 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 05, 2008 at 10:25:51PM -0500, Kumba wrote: > >Kumba wrote: > > > >glibc for mips has currently no such mechanism. Note that this change > >breaks MIPS I CPUs, so it is not generally applicable. >=20 > I'll have to ask one of our devs who knows autoconf really well. I figur= e=20 > that's probably a good place to catch something like this. Have configur= e=20 > check /proc/cpuinfo and look for "R10000", and if it finds it, mod CFLAGS= =20 > to pass -DR10k_LLSC_WAR, and #ifdef on that in atomic.h. >=20 > Sound plausible? No - the very same GLIBC does not work on mips1 machines and vice versa. Might by okay for gentoo but debian needs a run everywhere glibc which means some ld.so tricks like with the libc6-i686 to load a different glibc from my understanding. Flo --=20 Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little=20 security shall soon have neither - Benjamin Franklin --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqXYqUaz2rXW+gJcRAu/rAKCzxlBQ4JiAzXd6DnSTB0sZ7VyGrgCg50Qj zV6jpJliUjUF02HrPVQzjRY= =r7c6 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From weo@reccoware.de Wed Feb 6 11:15:50 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Feb 2008 11:15:59 +0000 (GMT) Received: from bes.recconet.de ([212.227.59.164]:2505 "EHLO bes.recconet.de") by ftp.linux-mips.org with ESMTP id S20035316AbYBFLPu (ORCPT ); Wed, 6 Feb 2008 11:15:50 +0000 Received: from trinity.recco.de (trinity.intern.recconet.de [192.168.11.241]) by bes.recconet.de (8.13.1/8.13.1/Recconet-2005031001) with ESMTP id m16BFo3p006790 for ; Wed, 6 Feb 2008 12:15:50 +0100 Received: from trinity.recco.de (localhost.localdomain [127.0.0.1]) by trinity.recco.de (8.13.1/8.13.1/Reccoware-2005061101) with ESMTP id m16BFkoO004327 for ; Wed, 6 Feb 2008 12:15:46 +0100 Received: (from apache@localhost) by trinity.recco.de (8.13.1/8.13.1/Reccoware-Submit-2005061101) id m16BFkME004324; Wed, 6 Feb 2008 12:15:46 +0100 X-Authentication-Warning: trinity.recco.de: apache set sender to weo@reccoware.de using -f Received: from 217.91.120.40 (SquirrelMail authenticated user weo) by morpheus.dyn.recconet.de with HTTP; Wed, 6 Feb 2008 12:15:46 +0100 (CET) Message-ID: <1846.217.91.120.40.1202296546.squirrel@morpheus.dyn.recconet.de> Date: Wed, 6 Feb 2008 12:15:46 +0100 (CET) Subject: au1xxx dbdma.c minor fix proposal From: "Wolfgang Ocker" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.8-4.0.1.el4.centos MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20080206121546_79237" X-Priority: 3 (Normal) 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: 18183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: weo@reccoware.de Precedence: bulk X-list: linux-mips ------=_20080206121546_79237 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Attached a minor patch for dbdma.c: """0 is a valid device id (DSCR_CMD0_UART0_TX), so we can't use it to mark an empty entry in the device table. Use ~0 instead and search for id ~0 when looking for a free entry.""" Wolfgang ------=_20080206121546_79237 Content-Type: text/x-patch; name="dbdma_devtab_fix.patch" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="dbdma_devtab_fix.patch" 0 is a valid device id (DSCR_CMD0_UART0_TX), so we can't use it to mark an empty entry in the device table. Use ~0 instead and search for id ~0 when looking for a free entry. diff -up linux-2.6.24/arch/mips/au1000/common/dbdma.c.devtab_fix linux-2.6.24/arch/mips/au1000/common/dbdma.c --- linux-2.6.24/arch/mips/au1000/common/dbdma.c.devtab_fix 2008-01-24 23:58:37.000000000 +0100 +++ linux-2.6.24/arch/mips/au1000/common/dbdma.c 2008-02-06 11:51:16.000000000 +0100 @@ -161,22 +161,22 @@ static dbdev_tab_t dbdev_tab[] = { { DSCR_CMD0_ALWAYS, DEV_FLAGS_ANYUSE, 0, 0, 0x00000000, 0, 0 }, /* Provide 16 user definable device types */ - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, - { 0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, + { ~0, 0, 0, 0, 0, 0, 0 }, }; #define DBDEV_TAB_SIZE (sizeof(dbdev_tab) / sizeof(dbdev_tab_t)) @@ -209,7 +209,7 @@ au1xxx_ddma_add_device(dbdev_tab_t *dev) dbdev_tab_t *p=NULL; static u16 new_id=0x1000; - p = find_dbdev_id(0); + p = find_dbdev_id(~0); if ( NULL != p ) { memcpy(p, dev, sizeof(dbdev_tab_t)); ------=_20080206121546_79237-- From ralf@linux-mips.org Wed Feb 6 14:23:40 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 06 Feb 2008 14:23:42 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:38036 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20035993AbYBFOXk (ORCPT ); Wed, 6 Feb 2008 14:23:40 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.14.1/8.13.8) with ESMTP id m16EMIXV007807; Wed, 6 Feb 2008 14:22:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.14.1/8.14.1/Submit) id m16EMHm4007806; Wed, 6 Feb 2008 14:22:17 GMT Date: Wed, 6 Feb 2008 14:22:17 +0000 From: Ralf Baechle To: Florian Lohoff Cc: Kumba , Thiemo Seufer , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed Message-ID: <20080206142217.GA7633@linux-mips.org> References: <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> <20080205122211.GA24136@networkno.de> <47A928BF.5000302@gentoo.org> <20080206085610.GA20751@paradigm.rfc822.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080206085610.GA20751@paradigm.rfc822.org> User-Agent: Mutt/1.5.17 (2007-11-01) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18184 X-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, Feb 06, 2008 at 09:56:10AM +0100, Florian Lohoff wrote: > No - the very same GLIBC does not work on mips1 machines and vice versa. > Might by okay for gentoo but debian needs a run everywhere glibc which > means some ld.so tricks like with the libc6-i686 to load a different > glibc from my understanding. There is the long standing plan to generate a shared library on on the fly during kernel initialization and move atomic operations and performance relevant functions like memcpy to it. Thiemo's latest work on tlbex.c got us a tiny step closer to that. Ralf From aurelien@aurel32.net Thu Feb 7 02:16:53 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 02:17:01 +0000 (GMT) Received: from hall.aurel32.net ([88.191.38.19]:61385 "EHLO hall.aurel32.net") by ftp.linux-mips.org with ESMTP id S20036629AbYBGCQx (ORCPT ); Thu, 7 Feb 2008 02:16:53 +0000 Received: from volta.aurel32.net ([2002:52e8:2fb:1:216:d3ff:fe17:fd00]) by hall.aurel32.net with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JMwJj-0006HT-N8; Thu, 07 Feb 2008 03:16:47 +0100 Received: from aurel32 by volta.aurel32.net with local (Exim 4.68) (envelope-from ) id 1JMwKC-0000vM-Kc; Thu, 07 Feb 2008 03:17:16 +0100 Date: Thu, 7 Feb 2008 03:17:16 +0100 From: Aurelien Jarno To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] [MIPS] Add platform MTD support for the WGT634U machine Message-ID: <20080207021716.GA3350@volta.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline X-Mailer: Mutt 1.5.17 (2007-12-11) User-Agent: Mutt/1.5.17 (2007-12-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: aurelien@aurel32.net Precedence: bulk X-list: linux-mips The patch below adds MTD support for the WGT634U machine by defining a new platform_device for the flash. Signed-off-by: Aurelien Jarno --- arch/mips/bcm47xx/wgt634u.c | 69 +++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 66 insertions(+), 3 deletions(-) diff --git a/arch/mips/bcm47xx/wgt634u.c b/arch/mips/bcm47xx/wgt634u.c index 5a017ea..997e540 100644 --- a/arch/mips/bcm47xx/wgt634u.c +++ b/arch/mips/bcm47xx/wgt634u.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include @@ -43,6 +44,61 @@ static struct platform_device wgt634u_gpio_leds = { } }; + +/* 8MiB flash. The struct mtd_partition matches original Netgear WGT634U + firmware. */ +static struct mtd_partition wgt634u_partitions[] = { + { + .name = "cfe", + .offset = 0, + .size = 0x60000, /* 384k */ + .mask_flags = MTD_WRITEABLE /* force read-only */ + }, + { + .name = "config", + .offset = 0x60000, + .size = 0x20000 /* 128k */ + }, + { + .name = "linux", + .offset = 0x80000, + .size = 0x140000 /* 1280k */ + }, + { + .name = "jffs", + .offset = 0x1c0000, + .size = 0x620000 /* 6272k */ + }, + { + .name = "nvram", + .offset = 0x7e0000, + .size = 0x20000 /* 128k */ + }, +}; + +static struct physmap_flash_data wgt634u_flash_data = { + .parts = wgt634u_partitions, + .nr_parts = ARRAY_SIZE(wgt634u_partitions) +}; + +static struct resource wgt634u_flash_resource = { + .flags = IORESOURCE_MEM, +}; + +static struct platform_device wgt634u_flash = { + .name = "physmap-flash", + .id = 0, + .dev = { .platform_data = &wgt634u_flash_data, }, + .resource = &wgt634u_flash_resource, + .num_resources = 1, +}; + +/* Platform devices */ +static struct platform_device *wgt634u_devices[] __initdata = { + &wgt634u_flash, + &wgt634u_gpio_leds, +}; + static int __init wgt634u_init(void) { /* There is no easy way to detect that we are running on a WGT634U @@ -54,9 +110,16 @@ static int __init wgt634u_init(void) if (et0mac[0] == 0x00 && ((et0mac[1] == 0x09 && et0mac[2] == 0x5b) || - (et0mac[1] == 0x0f && et0mac[2] == 0xb5))) - return platform_device_register(&wgt634u_gpio_leds); - else + (et0mac[1] == 0x0f && et0mac[2] == 0xb5))) { + struct ssb_mipscore *mcore = &ssb_bcm47xx.mipscore; + wgt634u_flash_data.width = mcore->flash_buswidth; + wgt634u_flash_resource.start = mcore->flash_window; + wgt634u_flash_resource.end = mcore->flash_window + + mcore->flash_window_size + - 1; + return platform_add_devices(wgt634u_devices, + ARRAY_SIZE(wgt634u_devices)); + } else return -ENODEV; } -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net From kumba@gentoo.org Thu Feb 7 05:30:48 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 05:30:56 +0000 (GMT) Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16]:17358 "EHLO QMTA01.westchester.pa.mail.comcast.net") by ftp.linux-mips.org with ESMTP id S20022204AbYBGFas (ORCPT ); Thu, 7 Feb 2008 05:30:48 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA01.westchester.pa.mail.comcast.net with comcast id mLrh1Y02U1GhbT8510Ja00; Thu, 07 Feb 2008 05:30:35 +0000 Received: from [192.168.1.4] ([69.140.18.238]) by OMTA07.westchester.pa.mail.comcast.net with comcast id mVWf1Y00G58Be2l3T00000; Thu, 07 Feb 2008 05:30:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=8rNRuJ1kDQyzUA1EHfYA:9 a=ZluIzpL3rFPDPbGnU7FQLa_zARIA:4 a=GZmr5YlNZX8A:10 Message-ID: <47AA977E.5000205@gentoo.org> Date: Thu, 07 Feb 2008 00:30:38 -0500 From: Kumba User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Florian Lohoff CC: Thiemo Seufer , Ralf Baechle , Thomas Bogendoerfer , linux-mips@linux-mips.org, debian-mips@lists.debian.org Subject: Re: Tester with IP27/IP30 needed References: <479609A6.2020204@gentoo.org> <20080122154958.GA29108@linux-mips.org> <479AA532.5040603@gentoo.org> <20080126143949.GA6579@alpha.franken.de> <47A4E9DF.5070603@gentoo.org> <20080203021647.GA15910@linux-mips.org> <20080203062711.GA28394@paradigm.rfc822.org> <47A80C0A.4040106@gentoo.org> <20080205122211.GA24136@networkno.de> <47A928BF.5000302@gentoo.org> <20080206085610.GA20751@paradigm.rfc822.org> In-Reply-To: <20080206085610.GA20751@paradigm.rfc822.org> Content-Type: text/plain; charset=ISO-8859-1; 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: 18186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: kumba@gentoo.org Precedence: bulk X-list: linux-mips Florian Lohoff wrote: > No - the very same GLIBC does not work on mips1 machines and vice versa. > Might by okay for gentoo but debian needs a run everywhere glibc which > means some ld.so tricks like with the libc6-i686 to load a different > glibc from my understanding. While I could test this easily on gentoo, I was thinking of it more as an upstream fix. I suppose one of those configure switches could be included to skip the check as well, with the default being on. Figured I'd see what you guys thought, since it does seem to be a bug that should to be addressed somehow rather than patched forever in one of the distros. --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond From post@pfrst.de Thu Feb 7 12:42:52 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 12:43:01 +0000 (GMT) Received: from mail1.pearl-online.net ([62.159.194.147]:44573 "EHLO mail1.pearl-online.net") by ftp.linux-mips.org with ESMTP id S20024640AbYBGMmw (ORCPT ); Thu, 7 Feb 2008 12:42:52 +0000 Received: from SNaIlmail.Peter (85.233.39.216.static.cablesurf.de [85.233.39.216]) by mail1.pearl-online.net (Postfix) with ESMTP id E9FE0B186; Thu, 7 Feb 2008 13:42:55 +0100 (CET) Received: from Indigo2.Peter (Indigo2.Peter [192.168.1.28]) by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id m1621vZM000748; Wed, 6 Feb 2008 03:01:58 +0100 Received: from Indigo2.Peter (localhost [127.0.0.1]) by Indigo2.Peter (8.12.6/8.12.6/Sendmail/Linux 2.6.14-rc2-ip28) with ESMTP id m17CfTb5000410; Thu, 7 Feb 2008 13:41:29 +0100 Received: from localhost (pf@localhost) by Indigo2.Peter (8.12.6/8.12.6/Submit) with ESMTP id m17CfTQw000407; Thu, 7 Feb 2008 13:41:29 +0100 X-Authentication-Warning: Indigo2.Peter: pf owned process doing -bs Date: Thu, 7 Feb 2008 13:41:29 +0100 (CET) From: peter fuerst X-X-Sender: pf@Indigo2.Peter Reply-To: post@pfrst.de To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: [PATCH] [MIPS]: fix CAC_ADDR/UNCAC_ADDR In-Reply-To: Message-ID: References: <54038cd4f87a03884e4f59f8f3697889dfb63c54.1201030614.git.jengelh@computergmbh.de> 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: 18187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: post@pfrst.de Precedence: bulk X-list: linux-mips With commit db38501511a7513ec4f0ae9922d847c135cf3c78 PAGE_OFFSET was redefined as CAC_BASE+PHYS_OFFSET, but [UN]CAC_ADDR - which are used in dma_alloc_coherent() and dma_free_coherent() respectively, and in drivers/video/au1100fb.c - were not adjusted accordingly. with kind regards Signed-off-by: peter fuerst --- a/linux-2.6.24/include/asm-mips/page.h Fri Jan 25 12:23:51 2008 +++ b/linux-2.6.24/include/asm-mips/page.h Wed Feb 6 23:26:31 2008 @@ -184,8 +184,8 @@ #define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \ VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) -#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + UNCAC_BASE) -#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET) +#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + PHYS_OFFSET + UNCAC_BASE) +#define CAC_ADDR(addr) ((addr) - UNCAC_BASE + PAGE_OFFSET - PHYS_OFFSET) #include #include From yoichi_yuasa@tripeaks.co.jp Thu Feb 7 13:45:21 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 13:45:30 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:49470 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20037395AbYBGNpV (ORCPT ); Thu, 7 Feb 2008 13:45:21 +0000 Received: by mo.po.2iij.net (mo31) id m17DjH6n000642; Thu, 7 Feb 2008 22:45:17 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox303) id m17DjF0j026628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 22:45:16 +0900 Date: Thu, 7 Feb 2008 22:27:17 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][2/5][MIPS] remove lasat unused definitions Message-Id: <20080207222717.7d58f50a.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> References: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-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: 18188 X-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@tripeaks.co.jp Precedence: bulk X-list: linux-mips Removed unused lasat definitions. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/lasat.h mips/include/asm-mips/lasat/lasat.h --- mips-orig/include/asm-mips/lasat/lasat.h 2007-12-11 23:12:53.674363750 +0900 +++ mips/include/asm-mips/lasat/lasat.h 2007-12-12 00:14:56.073369250 +0900 @@ -245,9 +245,6 @@ static inline void lasat_ndelay(unsigned #define LASAT_SERVICEMODE_MAGIC_1 0xdeadbeef #define LASAT_SERVICEMODE_MAGIC_2 0xfedeabba -/* Lasat 100 boards */ -#define LASAT_GT_BASE (KSEG1ADDR(0x14000000)) - /* Lasat 200 boards */ #define Vrc5074_PHYS_BASE 0x1fa00000 #define Vrc5074_BASE (KSEG1ADDR(Vrc5074_PHYS_BASE)) diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h mips/include/asm-mips/mach-lasat/mach-gt64120.h --- mips-orig/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-11 23:12:54.162394250 +0900 +++ mips/include/asm-mips/mach-lasat/mach-gt64120.h 2007-12-12 00:13:39.216566000 +0900 @@ -11,17 +11,6 @@ /* * GT64120 config space base address on Lasat 100 */ -#define GT64120_BASE (KSEG1ADDR(0x14000000)) - -/* - * PCI Bus allocation - * - * (Guessing ...) - */ -#define GT_PCI_MEM_BASE 0x12000000UL -#define GT_PCI_MEM_SIZE 0x02000000UL -#define GT_PCI_IO_BASE 0x10000000UL -#define GT_PCI_IO_SIZE 0x02000000UL -#define GT_ISA_IO_BASE PCI_IO_BASE +#define GT64120_BASE KSEG1ADDR(GT_DEF_BASE) #endif /* _ASM_GT64120_LASAT_GT64120_DEP_H */ From yoichi_yuasa@tripeaks.co.jp Thu Feb 7 13:45:50 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 13:45:54 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:50494 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20037335AbYBGNpV (ORCPT ); Thu, 7 Feb 2008 13:45:21 +0000 Received: by mo.po.2iij.net (mo31) id m17DjIV9000651; Thu, 7 Feb 2008 22:45:18 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox301) id m17DjGwW020650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 22:45:17 +0900 Date: Thu, 7 Feb 2008 22:39:45 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][3/5][MIPS] fix LASAT_CASCADE_IRQ Message-Id: <20080207223945.32f20b2d.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20080207222717.7d58f50a.yoichi_yuasa@tripeaks.co.jp> References: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> <20080207222717.7d58f50a.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-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: 18189 X-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@tripeaks.co.jp Precedence: bulk X-list: linux-mips Fixed LASAT_CASCADE_IRQ Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-lasat/irq.h mips/include/asm-mips/mach-lasat/irq.h --- mips-orig/include/asm-mips/mach-lasat/irq.h 2008-01-13 16:43:14.160048268 +0900 +++ mips/include/asm-mips/mach-lasat/irq.h 2008-01-14 21:27:55.180821709 +0900 @@ -1,7 +1,7 @@ #ifndef _ASM_MACH_LASAT_IRQ_H #define _ASM_MACH_LASAT_IRQ_H -#define LASAT_CASCADE_IRQ (MIPS_CPU_IRQ_BASE + 0) +#define LASAT_CASCADE_IRQ (MIPS_CPU_IRQ_BASE + 2) #define LASAT_IRQ_BASE 8 #define LASAT_IRQ_END 23 From yoichi_yuasa@tripeaks.co.jp Thu Feb 7 13:46:15 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 13:46:24 +0000 (GMT) Received: from mo31.po.2iij.NET ([210.128.50.54]:51518 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20037407AbYBGNpW (ORCPT ); Thu, 7 Feb 2008 13:45:22 +0000 Received: by mo.po.2iij.net (mo31) id m17DjJAu000665; Thu, 7 Feb 2008 22:45:19 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox304) id m17DjISA004480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 22:45:18 +0900 Date: Thu, 7 Feb 2008 22:41:40 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][4/5][MIPS] remove lasat unused functions Message-Id: <20080207224140.30878819.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20080207223945.32f20b2d.yoichi_yuasa@tripeaks.co.jp> References: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> <20080207222717.7d58f50a.yoichi_yuasa@tripeaks.co.jp> <20080207223945.32f20b2d.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-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: 18190 X-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@tripeaks.co.jp Precedence: bulk X-list: linux-mips Removed lasat unused functions. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/setup.c mips/arch/mips/lasat/setup.c --- mips-orig/arch/mips/lasat/setup.c 2007-11-13 17:14:03.236286250 +0900 +++ mips/arch/mips/lasat/setup.c 2007-11-13 17:14:33.802196500 +0900 @@ -46,13 +46,7 @@ #include "prom.h" -int lasat_command_line; -void lasatint_init(void); - extern void lasat_reboot_setup(void); -extern void pcisetup(void); -extern void edhac_init(void *, void *, void *); -extern void addrflt_init(void); struct lasat_misc lasat_misc_info[N_MACHTYPES] = { { From yoichi_yuasa@tripeaks.co.jp Thu Feb 7 13:46:45 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 13:46:55 +0000 (GMT) Received: from mo32.po.2iij.net ([210.128.50.17]:48657 "EHLO mo32.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20037419AbYBGNpX (ORCPT ); Thu, 7 Feb 2008 13:45:23 +0000 Received: by mo.po.2iij.net (mo32) id m17DjJb4029128; Thu, 7 Feb 2008 22:45:19 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox300) id m17DjEH3030763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 22:45:15 +0900 Date: Thu, 7 Feb 2008 22:26:01 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][1/5][MIPS] remove lasat unused struct Message-Id: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-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: 18191 X-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@tripeaks.co.jp Precedence: bulk X-list: linux-mips Removed unused struct bootloader_header. Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/image/head.S mips/arch/mips/lasat/image/head.S --- mips-orig/arch/mips/lasat/image/head.S 2007-11-05 08:41:37.923119250 +0900 +++ mips/arch/mips/lasat/image/head.S 2007-11-05 08:31:39.865743000 +0900 @@ -1,4 +1,5 @@ -#include +#define LASAT_K_MAGIC0_VAL 0xfedeabba +#define LASAT_K_MAGIC1_VAL 0xbedead .text .section .text.start, "ax" @@ -21,7 +22,6 @@ .word _kernel_entry /* Here we have room for future flags */ - .org 0x40 reldate: .word TIMESTAMP diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/head.h mips/include/asm-mips/lasat/head.h --- mips-orig/include/asm-mips/lasat/head.h 2007-11-05 08:41:37.991123500 +0900 +++ mips/include/asm-mips/lasat/head.h 1970-01-01 09:00:00.000000000 +0900 @@ -1,22 +0,0 @@ -/* - * Image header stuff - */ -#ifndef _HEAD_H -#define _HEAD_H - -#define LASAT_K_MAGIC0_VAL 0xfedeabba -#define LASAT_K_MAGIC1_VAL 0x00bedead - -#ifndef _LANGUAGE_ASSEMBLY -#include -struct bootloader_header { - u32 magic[2]; - u32 version; - u32 image_start; - u32 image_size; - u32 kernel_start; - u32 kernel_entry; -}; -#endif - -#endif /* _HEAD_H */ From yoichi_yuasa@tripeaks.co.jp Thu Feb 7 13:47:25 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 13:47:33 +0000 (GMT) Received: from mo30.po.2iij.NET ([210.128.50.53]:64563 "EHLO mo30.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20037430AbYBGNpb (ORCPT ); Thu, 7 Feb 2008 13:45:31 +0000 Received: by mo.po.2iij.net (mo30) id m17DjRPc018661; Thu, 7 Feb 2008 22:45:27 +0900 (JST) Received: from delta (224.24.30.125.dy.iij4u.or.jp [125.30.24.224]) by mbox.po.2iij.net (po-mbox302) id m17DjJfx000906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Feb 2008 22:45:19 +0900 Date: Thu, 7 Feb 2008 22:44:54 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][5/5][MIPS] cleanup lasat reset functions Message-Id: <20080207224454.1f4254f0.yoichi_yuasa@tripeaks.co.jp> In-Reply-To: <20080207224140.30878819.yoichi_yuasa@tripeaks.co.jp> References: <20080207222601.def26d7d.yoichi_yuasa@tripeaks.co.jp> <20080207222717.7d58f50a.yoichi_yuasa@tripeaks.co.jp> <20080207223945.32f20b2d.yoichi_yuasa@tripeaks.co.jp> <20080207224140.30878819.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed 2.4.5 (GTK+ 2.12.0; i486-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: 18192 X-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@tripeaks.co.jp Precedence: bulk X-list: linux-mips Clean up lasat reset functions Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/reset.c mips/arch/mips/lasat/reset.c --- mips-orig/arch/mips/lasat/reset.c 2007-12-13 10:20:15.537626250 +0900 +++ mips/arch/mips/lasat/reset.c 2007-12-13 10:17:32.751452750 +0900 @@ -17,18 +17,21 @@ * * Reset the LASAT board. */ -#include +#include +#include +#include #include +#include #include -#include #include -#include "picvue.h" #include "prom.h" -static void lasat_machine_restart(char *command); -static void lasat_machine_halt(void); +#define LASAT_SERVICEMODE_MAGIC_1 0xdeadbeef +#define LASAT_SERVICEMODE_MAGIC_2 0xfedeabba + +static void __iomem *reset_reg; /* Used to set machine to boot in service mode via /proc interface */ int lasat_boot_to_service; @@ -38,10 +41,13 @@ static void lasat_machine_restart(char * local_irq_disable(); if (lasat_boot_to_service) { - *(volatile unsigned int *)0xa0000024 = 0xdeadbeef; - *(volatile unsigned int *)0xa00000fc = 0xfedeabba; + writel(LASAT_SERVICEMODE_MAGIC_1, + (void __iomem *)KSEG1ADDR(0x24)); + writel(LASAT_SERVICEMODE_MAGIC_2, + (void __iomem *)KSEG1ADDR(0xfc)); } - *lasat_misc->reset_reg = 0xbedead; + + writel(0xbedead, reset_reg); for (;;) ; } @@ -53,9 +59,25 @@ static void lasat_machine_halt(void) for (;;) ; } -void lasat_reboot_setup(void) +static int lasat_reboot_setup(void) { + switch (mips_machtype) { + case MACH_LASAT_100: + reset_reg = (void __iomem *)KSEG1ADDR(0x1c840000); + break; + case MACH_LASAT_200: + reset_reg = (void __iomem *)KSEG1ADDR(0x11080000); + break; + default: + printk(KERN_ERR "Unknown LASAT board\n"); + return -EINVAL; + } + _machine_restart = lasat_machine_restart; _machine_halt = lasat_machine_halt; pm_power_off = lasat_machine_halt; + + return 0; } + +arch_initcall(lasat_reboot_setup); diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lasat/setup.c mips/arch/mips/lasat/setup.c --- mips-orig/arch/mips/lasat/setup.c 2007-12-13 10:20:15.553627250 +0900 +++ mips/arch/mips/lasat/setup.c 2007-12-13 10:17:32.755453000 +0900 @@ -46,20 +46,6 @@ #include "prom.h" -extern void lasat_reboot_setup(void); - -struct lasat_misc lasat_misc_info[N_MACHTYPES] = { - { - .reset_reg = (void *)KSEG1ADDR(0x1c840000), - .flash_wp_reg = (void *)KSEG1ADDR(0x1c800000), 2 - }, { - .reset_reg = (void *)KSEG1ADDR(0x11080000), - .flash_wp_reg = (void *)KSEG1ADDR(0x11000000), 6 - } -}; - -struct lasat_misc *lasat_misc; - #ifdef CONFIG_DS1603 static struct ds_defs ds_defs[N_MACHTYPES] = { { (void *)DS1603_REG_100, (void *)DS1603_REG_100, @@ -121,7 +107,7 @@ void __init plat_time_init(void) void __init plat_mem_setup(void) { int i; - lasat_misc = &lasat_misc_info[mips_machtype]; + #ifdef CONFIG_PICVUE picvue = &pvc_defs[mips_machtype]; #endif @@ -131,8 +117,6 @@ void __init plat_mem_setup(void) atomic_notifier_chain_register(&panic_notifier_list, &lasat_panic_block[i]); - lasat_reboot_setup(); - #ifdef CONFIG_DS1603 ds1603 = &ds_defs[mips_machtype]; #endif diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/lasat/lasat.h mips/include/asm-mips/lasat/lasat.h --- mips-orig/include/asm-mips/lasat/lasat.h 2007-12-13 10:20:15.569628250 +0900 +++ mips/include/asm-mips/lasat/lasat.h 2007-12-13 10:17:32.755453000 +0900 @@ -24,12 +24,6 @@ #ifndef _LANGUAGE_ASSEMBLY -extern struct lasat_misc { - volatile u32 *reset_reg; - volatile u32 *flash_wp_reg; - u32 flash_wp_bit; -} *lasat_misc; - enum lasat_mtdparts { LASAT_MTD_BOOTLOADER, LASAT_MTD_SERVICE, @@ -242,9 +236,6 @@ static inline void lasat_ndelay(unsigned #endif /* !defined (_LANGUAGE_ASSEMBLY) */ -#define LASAT_SERVICEMODE_MAGIC_1 0xdeadbeef -#define LASAT_SERVICEMODE_MAGIC_2 0xfedeabba - /* Lasat 200 boards */ #define Vrc5074_PHYS_BASE 0x1fa00000 #define Vrc5074_BASE (KSEG1ADDR(Vrc5074_PHYS_BASE)) From jon.dufresne@infinitevideocorporation.com Thu Feb 7 15:20:36 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 15:20:45 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:1231 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20037787AbYBGPUg (ORCPT ); Thu, 7 Feb 2008 15:20:36 +0000 Received: (qmail 8093 invoked from network); 7 Feb 2008 15:20:34 -0000 Received: from unknown (HELO ?10.41.13.129?) (38.101.235.133) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 7 Feb 2008 08:20:33 -0700 Subject: iomemory causing a data bus error From: Jon Dufresne To: linux-mips@linux-mips.org Content-Type: text/plain Date: Thu, 07 Feb 2008 10:20:02 -0500 Message-Id: <1202397602.3298.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 18193 X-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.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips Hi, I am writing a linux mips device driver for a PCI device. I am currently running into a strange problem when writing a lot of data to iomemory. I have written a test function that looks like this: void test_iomem(struct pci_dev *dev) { void __iomem *mem; unsigned long start; unsigned long size; start = pci_resource_start(dev, 0); size = pci_resource_len(dev, 0); printk("start=%08lx size=%08lx\n", start, size); mem = ioremap(start, size); while(1) { printk("memset %p\n", mem); memset_io(mem, 0, 10000); } } This function is just being used to test the iomemory. If this works, it should just keep writing 0's to the iomemory forever (at least as I understand it). When I run insmod on this device driver I see the following output: start=20000000 size=04000000 memset c0580000 memset c0580000 memset c0580000 ... ... ... And this goes on for quite some time. Eventually it will stop, moments later I will see a kernel panic with the following output: > memset c0580000 > memset c0580000 > memset c0580000 > Data bus error, epc == c027a64c, ra == 800aa27c > Oops[#1]: > Cpu 0 > $ 0 : 00000000 10008400 c0363050 00063050 > $ 4 : 00000037 82937800 8109d000 10008401 > $ 8 : 10008400 1000001f 80320000 80320000 > $12 : 80320000 00000001 83133bf8 8031c960 > $16 : 8311c600 00000080 00000001 00000037 > $20 : c02815e8 802e1ae4 c025a000 8008cde4 > $24 : 00000008 00000000 > $28 : 83132000 83133be8 c02815ac 800aa27c > Hi : 00000000 > Lo : 00000800 > epc : c027a64c Tainted: P > ra : 800aa27c Status: 10008403 KERNEL EXL IE > Cause : 1080801c > PrId : 00061200 > Modules linked in: tmman1700(P) mousedev usbhid usb_storage phStbFB(P) phStbFBRead(P) phStbVideoRenderer(P) phStbVideoRenderer_Layer(P) phStbStreamingSystem(P) phStbDraw(P) snd_usb_audio snd_usb_lib snd_rawmie > Process insmod (pid: 790, threadinfo=83132000, task=833e1278) > Stack : 801ecd20 801ecd20 00000000 00000037 8311c600 00000080 00000001 800aa27c > 00000000 8008c23c 0000004f 810b9c00 802f7dc0 810c3c00 00000037 810b9c00 > 800aa398 800aa340 10008400 8008c31c 80320000 80320000 00000000 04000000 > c0280000 8006386c 80320000 c027e814 10008401 8031c570 80061310 802e1ae4 > c025a000 8008cde4 00000008 00000000 00000000 80062040 83132000 83133ca8 > ... > Call Trace:[<801ecd20>][<801ecd20>][<800aa27c>][<8008c23c>][<800aa398>][<800aa340>][<8008c31c>][<8006386c>][<80061310>][<8008cde4>][<80062040>][<80086918>][<8019f924>][<8008cde4>][][<8017039c>][<801] > > Code: 3c030006 34633050 00431021 <8c430000> 2402ffff 1062002e 00a08821 38620001 30420001 > Kernel panic - not syncing: Fatal exception in interrupt I am at a complete loss as to what could be causing this to occur. Any ideas about why this would crash? In case it helps this is what my PCI configuration space looks like: 00: 31 11 06 54 02 00 90 02 00 00 80 04 00 40 00 00 10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18 40: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I thought the command register and latency timer looked wrong, so I did modify them before running the above function. And now it looks like the following: 00: 31 11 06 54 16 01 90 02 00 00 80 04 00 40 00 00 10: 08 00 00 20 00 00 00 24 00 00 00 1c 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 36 11 17 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 01 09 18 40: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Still no luck. Anyone have an idea? Thanks, Jon From florian.fainelli@telecomint.eu Thu Feb 7 18:32:33 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 18:32:42 +0000 (GMT) Received: from smtp4.int-evry.fr ([157.159.10.71]:40860 "EHLO smtp4.int-evry.fr") by ftp.linux-mips.org with ESMTP id S20030687AbYBGScd (ORCPT ); Thu, 7 Feb 2008 18:32:33 +0000 Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 57850350AD0 for ; Thu, 7 Feb 2008 19:32:28 +0100 (CET) Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 6F89C3ED168 for ; Thu, 7 Feb 2008 19:32:26 +0100 (CET) Received: from ibook (unknown [77.192.17.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 57A6D8D16BA for ; Thu, 7 Feb 2008 19:32:26 +0100 (CET) From: Florian Fainelli To: linux-mips@linux-mips.org Subject: early_ioremap for MIPS Date: Thu, 7 Feb 2008 19:32:21 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1331865.8f1bbS9ugm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802071932.23965.florian.fainelli@telecomint.eu> X-int-MailScanner-Information: Please contact the ISP for more information X-int-MailScanner: Found to be clean X-int-MailScanner-SpamCheck: X-int-MailScanner-From: florian.fainelli@telecomint.eu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: florian.fainelli@telecomint.eu Precedence: bulk X-list: linux-mips --nextPart1331865.8f1bbS9ugm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi list, Is there any need for early_ioremap on MIPS ? Seems like only x86_64 is=20 implementing it for now. Thank you for your answer. =2D-=20 Cordialement, Florian Fainelli =2D----------------------------- --nextPart1331865.8f1bbS9ugm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBHq063mx9n1G/316sRAk2tAJ47if9r67hp57CfcH1HWFfOOzyaEQCgxYsW zj7v8YvkuSJQLCp9fmpPW4Y= =1vBs -----END PGP SIGNATURE----- --nextPart1331865.8f1bbS9ugm-- From opencode@gmx.net Thu Feb 7 18:41:43 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 18:41:51 +0000 (GMT) Received: from mail.gmx.net ([213.165.64.20]:22661 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S20038613AbYBGSln (ORCPT ); Thu, 7 Feb 2008 18:41:43 +0000 Received: (qmail invoked by alias); 07 Feb 2008 18:41:37 -0000 Received: from vpn58.rz.tu-ilmenau.de (EHLO [192.168.1.100]) [141.24.172.58] by mail.gmx.net (mp001) with SMTP; 07 Feb 2008 19:41:37 +0100 X-Authenticated: #44099387 X-Provags-ID: V01U2FsdGVkX19mpMBZ9JJmIBiZ+qKkXKo69bKHjP9z/hZayvc/I2 ASZNmCqLOEGfuC Message-ID: <47AB50DD.2050504@gmx.net> Date: Thu, 07 Feb 2008 19:41:33 +0100 From: Andi User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Problems booting Linux kernel on Sigma SMP8634 X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 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: 18195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: opencode@gmx.net Precedence: bulk X-list: linux-mips Hey Folks, we are working on a SMP8634-based box to get Linux running on it. Since we don't have any documentation, neither hardware nor software, there is a lot of re-engineering work to be done. However, we managed it to let the box load a Linux kernel .. but it still fails at a certain point. It's right before the kernel loads the "NET: .."-stuff. I got this from an other SMP8634-based box, which runs the same kernel. Any hints about what might doesn't work? Regards, Andi Execute final at 0x90020000 .. Linux version 2.6.15-sigma (rolandhii@venus) (gcc version 4.0.4) #118 PREEMPT We d Jan 23 10:43:14 CST 2008 Configured for SMP8634 (revision ES6/RevA), detected SMP8634 (revision ES6/RevA) . SMP863x/SMP865x Enabled Devices under Linux/XENV 0x48000000 = 0x00023efe BM/IDE PCIHost Ethernet IR FIP I2CM I2CS USB PCIDev1 PCIDev2 PCIDev3 PCIDev4 SC ARD Valid MEMCFG found at 0x10000fc0. CPU revision is: 00019068 Determined physical RAM map: memory: 05ee0000 @ 10020000 (usable) On node 0 totalpages: 89856 DMA zone: 89856 pages, LIFO batch:15 DMA32 zone: 0 pages, LIFO batch:0 Normal zone: 0 pages, LIFO batch:0 HighMem zone: 0 pages, LIFO batch:0 Built 1 zonelists Kernel command line: pci=disabled ip=dhcp root=/dev/nfs noinitrd Primary instruction cache 16kB, physically tagged, 2-way, linesize 16 bytes. Primary data cache 16kB, 2-way, linesize 16 bytes. Synthesized TLB refill handler (20 instructions). Synthesized TLB load handler fastpath (32 instructions). Synthesized TLB store handler fastpath (32 instructions). Synthesized TLB modify handler fastpath (31 instructions). PID hash table entries: 2048 (order: 11, 32768 bytes) Using 148.500 MHz high precision timer. Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 86656k/97152k available (3399k kernel code, 10476k reserved, 536k data, 3108k init, 0k highmem) Calibrating delay loop... 292.86 BogoMIPS (lpj=146432) Mount-cache hash table entries: 512 Checking for 'wait' instruction... available. CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 9006aea0, ra == 9036dd88 Oops[#1]: Cpu 0 $ 0 : 00000000 00000001 90a7f87c 00000000 $ 4 : 95e88d38 90a7f870 00000001 00000000 $ 8 : 90702b80 90700000 90a7b000 00000000 $12 : 90a7e000 95e88cc0 00000012 00000010 $16 : 90a6df70 95e88d34 90a75be8 95e88d38 $20 : 90420000 90700000 00000030 90420000 $24 : 00000001 00000000 $28 : 90a7e000 90a7f860 90380000 9036dd88 Hi : 2a8b2775 Lo : 355f2140 epc : 9006aea0 Not tainted ra : 9036dd88 Status: 10001c02 KERNEL EXL Cause : 7080800c BadVA : 00000000 PrId : 00019068 Modules linked in: Process swapper (pid: 1, threadinfo=90a7e000, task=90a75be8) Stack : 00000000 00000000 00000001 00000000 00000001 90a75be8 90047cd0 95e88d38 00000000 00000001 90a6df70 95e88d34 90700000 00007948 90420000 9009a838 90a7b000 00007948 90420000 90700000 00001846 900b4d60 00000000 00000000 900c9ec4 90a7b000 00000000 90a7f908 90a7b000 900b87c8 90a6df70 00000000 90710000 00000000 00000000 00000000 00000000 9009a8e8 90420000 90700000 ... Call Trace: [<90047cd0>] [<9009a838>] [<900b4d60>] [<900c9ec4>] [<900b87c8>] [<9009a8e8>] [<9009a900>] [<903fa270>] [<903fa2ec>] [<903faa64>] [<903700 00>] [<903fb10c>] [<9008190c>] [<903fb92c>] [<903fc5f0>] [<90053b74>] [<90 053b44>] [<900204d0>] [<90026bdc>] [<90026bcc>] Code: 24a2000c aca4000c ac820004 ac470004 10c00002 41606000 4160 6020 000000c0 Kernel panic - not syncing: Attempted to kill init! From ddaney@avtrex.com Thu Feb 7 19:04:04 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 19:04:13 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.144]:49052 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20038717AbYBGTEE (ORCPT ); Thu, 7 Feb 2008 19:04:04 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id D585E31222D; Thu, 7 Feb 2008 19:04:05 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 7 Feb 2008 19:04:05 +0000 (UTC) Received: from dl2.hq2.avtrex.com ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Feb 2008 11:03:49 -0800 Message-ID: <47AB5614.5010804@avtrex.com> Date: Thu, 07 Feb 2008 11:03:48 -0800 From: David Daney User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Andi Cc: linux-mips@linux-mips.org Subject: Re: Problems booting Linux kernel on Sigma SMP8634 References: <47AB50DD.2050504@gmx.net> In-Reply-To: <47AB50DD.2050504@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2008 19:03:49.0862 (UTC) FILETIME=[2C556060:01C869BC] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Andi wrote: > Hey Folks, > > we are working on a SMP8634-based box to get Linux running on it. > Since we don't have any documentation, neither hardware nor software, > there is a lot of re-engineering work to be done. > However, we managed it to let the box load a Linux kernel .. but it > still fails at a certain point. > It's right before the kernel loads the "NET: .."-stuff. I got this from > an other SMP8634-based box, which runs the same kernel. > > Any hints about what might doesn't work? > You need symbols so that you can interpret the stack trace. It is impossible to tell anything without that. . . . > Determined physical RAM map: > memory: 05ee0000 @ 10020000 (usable) This seems like an odd value. I would expect either 03fe0000 or 07fe0000 David Daney From jon.dufresne@infinitevideocorporation.com Thu Feb 7 20:33:30 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 20:33:38 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:41187 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20038975AbYBGUda (ORCPT ); Thu, 7 Feb 2008 20:33:30 +0000 Received: (qmail 32425 invoked from network); 7 Feb 2008 20:33:28 -0000 Received: from unknown (HELO ?10.41.13.129?) (38.101.235.133) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 7 Feb 2008 13:33:28 -0700 Subject: Re: iomemory causing a data bus error From: Jon Dufresne To: linux-mips@linux-mips.org In-Reply-To: <1202397602.3298.25.camel@localhost> References: <1202397602.3298.25.camel@localhost> Content-Type: text/plain Date: Thu, 07 Feb 2008 15:32:56 -0500 Message-Id: <1202416377.3298.44.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 18197 X-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.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips I took some time and wrote a VERY simplified driver. The driver is now doing only the required steps to test this error. I figured this would localize the problem as much as possible. When I run this new driver. I now see the following error: ohci_hcd 0000:00:09.0: OHCI Unrecoverable Error, disabled ohci_hcd 0000:00:09.0: HC died; cleaning up irq 55: nobody cared (try booting with the "irqpoll" option) Call Trace:[<8006926c>][<8006926c>][<800ab1cc>][<800ab434>][<800aa27c>][<800aa27c>][<800aa3b8>][<8007faac>][<80085e9c>][<80085e70>][<8006386c>][<80061310>][<8009e3c4>][<8019d278>][<80062040>][<80062040>][<800] handlers: [<801dd630>] [<801ecce8>] [<801ecce8>] [<801ecce8>] [<801ae6c8>] Disabling IRQ #55 It looks to me like there is a problem with the USB driver. An interesting note is that my device's interrupt is also irq 55. I have tried this simplified driver both requesting the interrupt, in which case it is never triggered, and not requesting the interrupt. Both cases end the same way. After I get that message the system is still running, but extremely slowly. Any ideas? Thanks, Jon From jon.dufresne@infinitevideocorporation.com Thu Feb 7 21:01:45 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 21:01:54 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:62593 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20038266AbYBGVBp (ORCPT ); Thu, 7 Feb 2008 21:01:45 +0000 Received: (qmail 30516 invoked from network); 7 Feb 2008 21:01:43 -0000 Received: from unknown (HELO ?10.41.13.129?) (38.101.235.133) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 7 Feb 2008 14:01:43 -0700 Subject: RE: iomemory causing a data bus error From: Jon Dufresne To: Don Hiatt , linux-mips In-Reply-To: References: <1202397602.3298.25.camel@localhost> <1202416377.3298.44.camel@localhost> Content-Type: text/plain Date: Thu, 07 Feb 2008 16:01:11 -0500 Message-Id: <1202418072.3298.49.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 18198 X-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.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > Take a look at /proc/interrupts to see if you have something firing > that you do not expect. I took a look and this is what I see: # cat /proc/interrupts CPU0 2: 0 PNX Level IRQ GIC 7: 0 PNX Level IRQ Timer 10: 661 PNX Level IRQ pnx8550-1 11: 605 PNX Level IRQ pnx8550-2 13: 1 PNX Level IRQ ohci_hcd:usb2 23: 583 PNX Level IRQ i2c 24: 845 PNX Level IRQ i2c 28: 334 PNX Level IRQ pnx8xxx-uart 34: 1 PNX Level IRQ Drawing Engine 47: 0 PNX Level IRQ vmsp1 49: 0 PNX Level IRQ vmsp2 55: 15876 PNX Level IRQ libata, ehci_hcd:usb1, ohci_hcd:usb3, ohci_hcd:usb4, eth0 75: 18 PNX Level IRQ i2c 78: 192 PNX Level IRQ i2c 79: 80239 PNX Level IRQ timer 80: 19 PNX Level IRQ Monotonic timer ERR: 99373 It looks like there are quite a few devices on irq 55 even before I load my module. Is it at all possible that I could get my device to use a different interrupt line? or is this totally restricted by hardware? Also what does the "ERR" mean? Does this keep a tally of errors? If so does 99K errors seem high? > If you are sharing the same IRQ as USB, do you request the IRQ as > shared? Does the USB as well? My device does, yes. At this point I have to assume the USB driver is too. But even if that was the problem, it wouldn't explain why the error also happens when I don't request the interrupt at all. Thanks, Jon From jon.dufresne@infinitevideocorporation.com Thu Feb 7 21:41:07 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 07 Feb 2008 21:41:16 +0000 (GMT) Received: from host.infinivid.com ([64.119.179.76]:57491 "EHLO host.infinivid.com") by ftp.linux-mips.org with ESMTP id S20039087AbYBGVlH (ORCPT ); Thu, 7 Feb 2008 21:41:07 +0000 Received: (qmail 3879 invoked from network); 7 Feb 2008 21:41:05 -0000 Received: from unknown (HELO ?10.41.13.129?) (38.101.235.133) by host.infinivid.com with (RC4-MD5 encrypted) SMTP; 7 Feb 2008 14:41:05 -0700 Subject: RE: iomemory causing a data bus error From: Jon Dufresne To: Don Hiatt Cc: linux-mips In-Reply-To: References: <1202397602.3298.25.camel@localhost> <1202416377.3298.44.camel@localhost> <1202418072.3298.49.camel@localhost> Content-Type: text/plain Date: Thu, 07 Feb 2008 16:40:34 -0500 Message-Id: <1202420434.3298.53.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) 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: 18199 X-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.dufresne@infinitevideocorporation.com Precedence: bulk X-list: linux-mips > For ERR: http://lkml.org/lkml/2005/1/12/356 Thanks, I read through that. Seems like I could be dealing with some imperfect hardware. Whether or no my device is plugged into the box, I get an order of magnitude of 10^4 ERRs. Does this seem like a huge amount to anyone else? Is there anything I can do to try to reduce this number? Or should I even worry about it? Could this be connected to the device driver issues I am having? Thanks, Jon From opencode@gmx.net Fri Feb 8 09:24:15 2008 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 08 Feb 2008 09:24:25 +0000 (GMT) Received: from mail.gmx.net ([213.165.64.20]:15068 "HELO mail.gmx.net") by ftp.linux-mips.org with SMTP id S20022283AbYBHJYP (ORCPT ); Fri, 8 Feb 2008 09:24:15 +0000 Received: (qmail invoked by alias); 08 Feb 2008 09:24:09 -0000 Received: from vpn79.rz.tu-ilmenau.de (EHLO [192.168.1.100]) [141.24.172.79] by mail.gmx.net (mp003) with SMTP; 08 Feb 2008 10:24:09 +0100 X-Authenticated: #44099387 X-Provags-ID: V01U2FsdGVkX19XcKYArHFXuG56mY5feqTD5e6uhcGEBdnJRO2rvS IWkk1F+P+r1kFa Message-ID: <47AC1FB5.4060208@gmx.net> Date: Fri, 08 Feb 2008 10:24:05 +0100 From: Andi User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 CC: linux-mips@linux-mips.org Subject: Re: Problems booting Linux kernel on Sigma SMP8634 References: <47AB50DD.2050504@gmx.net> <47AB5614.5010804@avtrex.com> In-Reply-To: <47AB5614.5010804@avtrex.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 To: unlisted-recipients:; (no To-header on input) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 18200 X-ecartis-version: Ec